Sun released JavaFX yesterday, which has a lot of great technology in it, but unfortunately the user experience is tragically poor. From my own experience, the first time I loaded a JavaFX applet I was presented with four dialogs: one security dialog for the JavaFX runtime, another security dialog for the JavaFX samples, a JavaScript warning dialog, and a JavaFX license agreement acceptance dialog. The applet took over two minutes to load.

A security dialog appears every time the SimpleVideoPlayer example is shown (if it manages to start at all). Imagine if YouTube required the user to navigate a security dialog every time a video was played.

It’s a shame, and it represents a lack of vision in the direction of JavaFX.

The overall vision of JavaFX should have included three items: A great animation framework, fast startup time, and frictionless loading – AKA no security dialogs.

Sun created a pretty good animation framework, with a new scene graph and the declarative JavaFX Script. Unfortunately not all effects are truly animatable. The effects example crawls on my machine. Part of the problem is the algorithm choice: the blur example uses a nice-looking, but CPU intensive Guassian blur instead of a fast, but lower quality, box blur. Plus, their effects framework requires native code – one of the reasons for the security dialogs. There is no good reason why a software-based effects cannot be developed optimized for HotSpot.

Startup time is improved with the new, Java 6u10 quick starter feature. However, the quick starter is moot because the JavaFX runtime libraries are so large. People are reporting – including myself – that many of the applets take several minutes to load – even the second time you load them. Based on posts from a Sun employee at the javagaming.org message board, this is a mistake that will be fixed in the next version. However, the problem should have never existed in the first place. Fast startup time should have been priority number one, and no code modifications should have been allowed that broke this feature.

Finally, it appears that most, or all, of the JavaFX applet examples require the user to naviagate a security dialog. On my Mac, I had to accept a security dialog just for JavaFX to compute prime numbers. (The demo was supposed to show how much faster JavaFX is compared to JavaScript, but ironically, if you count the loading time, the JavaScript version computes faster.) There is probably a very good technical reason for showing the security dialogs, but to a non-technical general audience, this doesn’t make any sense. Why should I have to navigate a dialog to see a blur effect or watch a video? Plus, because some applets perform additional loading after the dialog is accepted, the dialog appears in the middle of the entire loading sequence. For large web apps, I typically start loading the app in one browser tab while reading in another tab. If a dialog appears in the middle of the loading sequence, that means when I return to the app’s browser tab, I have to accept the dialog and wait again. Finally, security dialogs are an instant turnoff to many users: I don’t have hard statistics, but anecdotal evidence suggests some users never accept the scary, confusing dialogs.

There is a lot of good technology in JavaFX, and it’s a shame that the user experience is what it is. However, I don’t think all is lost. I believe the underlying technology truly doesn’t matter as long as there is a positive user experience. Idealistically, developers should be able to use the tools they want, not the tools they are forced to use. And I believe a positive user experience can be created in Java – that’s why I developed PulpCore. Sun has incredibly smart engineers, and they can fix the problem if they are intrinsically motivated to do so. Here what they should so:

1. Make sure everything can run without security dialogs. Both the video decoding and the effects framework should work entirely in software. HotSpot is entirely capable as is, plus GPU rendering won’t work on all machines anyway.
2. Dramatically decrease the startup time. As mentioned before, it appears the Sun engineers are already working to fix this.
3. Every effect should be animatable at 30 frames per second. Downgrade some of the effects if you have to (i.e. use box blur instead of Gaussian blur)

There’s a few other minor complaints I have of JavaFX (it appears Nodes can’t have their own BlendMode, dirty rectangle calculation is slow, and if I’m not mistaken it appears Nodes can’t display at fractional locations.) But these are small issues. The big picture is having a positive user experience, and although JavaFX doesn’t deliver that today, if it is moved in the right direction, it can.

P.S. This blog was hacked several months ago, and I didn’t even notice. The content of one post completely disappeared. Yes, I should update more often.

This entry was posted on Friday, December 5th, 2008 at 11:54 am and is filed under JavaFX, User Experience. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.