There is a myriad of web frameworks to choose from when developing a rich internet application. Most of them support the current buzzwords like “ria”, “web 2.0”, “ajax”.
However let us consider what is really import when choosing a web framework and how the user experience can really be “rich”, particularly in the context of an enterprise application.
Easy and fast data entry
It is actually a shame. In the evolution from terminal (and dos) based applications to (thick) gui applications to (thin) web applications we have generally evolved from applications where users could enter data very quickly using just the keyboard and the “enter” or “tab” keys to jump over unneeded fields to applications which look good, but are less practical and/or slower to work with.
Entering (bulk) data is still needed in modern applications, but it is often overlooked when focussing on more sexy aspects of the user interface. However this kind of easy of entering data should still (or again) be possible. Yes it is nice to be able to jump past a group of fields using your mouse, and yes the advanced graphical visualization techniques can be a major improvement, but we should not forget the basics. Applications should properly support quick keyboard-only data entry.
I suggest that you can choose between “tab” or “enter” to move to the next field. To assure actually submitting the information is easy, pressing “ctrl-enter” can be used. To make it clear what is going to happen in that case, it can be useful to make a visual distinction between the default submit button and the others (like making the label bold).
For a user, surprises make an application more difficult to use or even frustrating. As for many things the 80/20 rule applies. Users will spend 80% of their time in 20% of the application. They will get used to operating the parts they constantly use. However, when they need some of the screens or features they use less frequently, it is much more user-friendly to assure things look and feel the same. For example, if in a certain form the linking records is done in a particular way, and the links are displayed in a certain size and colour, then all other forms should allow linking records to be done in the same way, and the display should use size and colour in other pages. That way the user will immediately feel at ease and be able to complete their job a lot faster.
Sometimes this problem is approached by trying to remove some of these aspects out of the development loop. Some frameworks remove the need to have html/css knowledge. Often, it is “hoped” that the programmers sufficiently master the design and usability aspects. I don’t believe this is a good solution.
For me, it is clear that the different aspects should be handled by people who are trained and experienced in these areas, resulting in a split in three roles.
- The developers need to build an application that works. This requires the programming knowledge and probably some notions of html and css. As long as you assume your developers need to focus on getting things to run this should be fine.
- A web designer (or a team) should be responsible to make sure the user interface looks good. They need to have the feel for what “looks good” means in a user interface, and they will need to translate this to the html, css and images which are needed to build this user interface.
- A usability or ergonomics expert should then evaluate the application and give hints and tips to the developers and web designers to make the application easier and more user-friendly. This is a separate expertise and mostly overlooked. You could argue that this role is more important for web applications with an advertising goal than for enterprise applications. While this is probably true, applying this expertise will improve your user’s experience and make them happier with your products.
Considering the points mentioned above, there are some choices which can be relevant for the framework choices you make.
- Achieving the consistency in the user interface is a lot easier if your web framework is component based. You can then build component for the different types of objects or even for groups of objects. This should make your life a lot easier.
A step further towards this goal would be to generate your user interface from a domain model as much as possible. As long as this generation process is sufficiently customizable, this can be major time saver and assure the consistency.
- I am not in favour of frameworks which try to hide the html and css from the developer. This is good if the split between developer and designer is so clean that they don’t see each other’s work, but this seems impossible to achieve.
However, the framework should support the cooperation between the two. This requires a good application of the model-view-controller split. The developer and designer will need to communicate a bit and help each other, but it should be clear who is in control of which files (rather then – as in jsp/asp – both needing access equally much).
- The usability export is cross-cutting the above two considerations. When they have been met, integrating the recommendations should be a breeze.
So what are my choices? I use the tapestry framework. It has excellent support for components and very clean separation between component and page templates (which contain the html markup) and code. There are some notions the designer will need to understand, but nothing too difficult.
To augment this even further, the equanda framework allows the user interface to be generated and allow sufficient overwriting possibilities to be usable for generation the full crud user interface and provide useful components to help build extra custom pages. For example the keyboard support is standard in equanda generated user interfaces and even assures automatic navigation to the next tab page when these are used in your user interface.