RIA forms
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.
