Rich Internet Applications (RIA)

First note that the speakers Ben Galbraith and Don Almaer are co-founders of ajaxian.com, which is clearly an AJAX-shop. They claim that Web technologies and Java went stagnent in the UI space. Ajax and JavaFX have the characteristics of a renaissance. They structure the talk in the form of a “discussion” or a series of arguments, where one supposedly pits the advantages of said technology against the other.

•    Argument #1: Java performs way faster than JavaScript; on the other hand JavaScript is getting faster all the time (V8 team at Google); plus apps like Google wave demonstrate that performance is good enough.
•    Argument #2: Responsiveness improved by worker-threads in a Java GUI. Yet using “web workers” we can overcome the limitation of JavaScript to a single thread. Demo of Pictastic proves the point. Having said that, web workers are still 10 times slower than Java; plus the API is extremely limited. In “web worker”, worker threads don’t share state, which is way safer than the totally flexible Java approach.
•    Argument #3: GC way more advanced in Java. On the other hand, incremental GC in Mozilla is improving all the time. A lousy fact of the JVN is having to determine how much memory the app requires (or how much is available) wherever the app is deployed.
•    Argument #4: Graphical capabilities of Java surpass what web apps can do. But performance of Bubblemark benchmark app shows that Google chrome achieves 100 frames per second. By comparison JavaFX achieves 24 FPS. With vector graphics Chrome is back down to 30 FPS. What the speakers don’t consider is that JavaFX is a very new and to-date under-optimised technology.
•    Argument #5: An Ajax 3D demo “metatunnel” is pretty impressive. Most browsers, apparently, are offering 3D extensions. It’s still at the experimental stage, however. JavaFX, on the other hand, has nothing to show in 3D.
•    Argument #6: Java is weak on fonts. The speakers claim that can’t use native fonts in Java (is this true? I seem to remember supplying Java with some additional fonts some years back.) Control over fonts in the Ajax world is even more limited, however.
•    Argument #7: JavaFX provides “amazing” video support. Counter argument: Flash plugin us ubiquitous and surpasses JavaFX in terms of maturity. Open Web Video offers sophisticated video functions.
•    Argument #8: Binding in JavaFX is compact and elegant. Web toolkits are very clumsy by comparison. The speakers quickly mention Mixins, Animation and Effects. All of this is way easier in JavaFX…
•    Argument #9: Legitimate critisisms are raised about JavaFX syntax. Speakers suggest that JavaScript is actually easier and closer to Java than JavaFX Script. And, of course, JavaFX totally lacks widgets like table/tree. Web toolkits even provide some very cool layout management and tools for constructing GUIs.
•    Argument #10: Tooling superior in the Java world.
•    Argument #11: Deployment. Web wins here, obviously, except for significant browser incompatibilities. Applets, Mac etc. are lousy too, however.

Conclusion: A pretty damning result for JavaFX, which is for the most part justified (at least today.) What the speakers fail to do, however, is talk more fairly about the significant problems faced by AJAX developers on a daily basis.

What contributes to the richness of a RIA (Rich Internet Application)?
What contributes to the poorness of a PUWA (Poor Ugly Web Application)?
How does a RIA compare to a PUWA?

In this post, I’ll discuss forms and what they look like in a RIA. Forms are the sort of things that you find a lot in business applications. For example, bank employees use them to manage customer data, to view account transactions, or to calculate mortgage offers. Or what you, as a brave citizen, use to submit your taxes. But forms are not limited to business applications. You can find them in games to set up your player or to configure the game server.

Consider the following screenshot showing a form to calculate a mortgage offer:

What exactly makes the above form a rich form? Can you spot it? Sorry to disappoint you, but it is not possible to see form richness. The only way to decide that a form is rich or not is to feel the form. And of course with a static screenshot it is really not possible to feel the form. Richness comes from interaction design and not from graphical design. This is a common source for misunderstanding. So let’s repeat it: Richness comes from interaction design and not from graphical design. Two topics in interaction design define the richness of a form: input feedback and input support.

Input Feedback
Let’s start with input feedback. The easier the user can connect the feedback to his or her user interaction, the richer the form. Given this fact, a form within a PUWA can never be rich. A PUWA is page-oriented and the user does not get feedback at the time when he or she enters wrong values. Instead he or she gets feedback only when he or she commits the form (see this groundbreaking article that compares PUWAs with Ajax-based web applications). A measurement for the richness of the feedback is the kind of feedback that is available to the user. Basically we distinguish between syntactical and semantic feedback. Syntactical feedback tells the user that field input is not well formed, e.g. error messages such as this is not a number, this is not an email address, this number has to be between 0 and 18. Whereas semantic feedback puts the input in a broader context and checks for business rules, e.g. the total loan amount may not be greater than 80% of the object’s value, or you are not authorized to withdraw more than 2000€ per week. The more semantic feedback the richer the form.

Input Support
The second measurement for the richness of a form is input support. One well known example for input support is suggesting valid field values as the user types. You can check out this feature at Google Suggest. Other forms of input support are the calculation of dependent values (e.g. calculating the city name for a given zip code) or disabling of non-mandatory fields (e.g. fields defining the legal guardian for underage persons). The more input support, the richer the form.

How does UltraLightClient ‘08 fit into this? First, its server-side architecture is a perfect fit for ultra-easy semantic feedback. This is because all of your code runs always on the server-side. There is no need to split code and propagate business logic to the client. Just access the business objects you need, it is that easy! Second, UltraLightClient ‘08 includes an high-level form component out-of-the-box. This makes the implementation of forms both, efficient and ultra-easy. The application that provided the screenshot above is implemented with UltraLightClient ‘08 and contains all forms of input feedback and input support.

Summary
Richness comes from interaction design (feel) and not from graphical design (see). There are two measurements to decide if a form is rich or not:

• Input feedback: the more semantic feedback the richer the form
• Input support: the more support the richer the form

UltraLightClient ‘08 is a perfect fit for both measurements. Its server-side architecture makes it ultra-easy to provide full semantic input feedback and its high-level form component enables full input support out-of-the-box.