Making Rich Web Application Architecture Usable

“Focus on the user and all else will follow" is a philosophy that can make or break a product.

Software designers have become notorious for concentrating on implementation patterns and neglecting the user. It is easy to get lost in grand concepts at an abstract level and get excited over stuff that makes your work as a developer easier; thus, the needs and desires of the "real" users may sometimes take a back seat. Identifying the usability constraints and designing within them keeps the focus on the user.

Usability Constraints

Users have certain basic likes and dislikes with various types of interaction. They are valid not only with human-computer interactions, but also in real life. Removing what users don't like and concentrating what they do like is the first step towards improved user satisfaction. Listed below are 10 things that users hate:

Users Hate Learning

Learning requires a cognitive investment by the user. It doesn't make sense to learn new interactions if there's no return on the investment we must make to learn them. Using standard elements in the interface, and keeping those elements visually consistent among interactions, enables the user to learn once and then apply that knowledge anywhere. Real world metaphors can speed learning and help users understand the finest details, as they allow the designer to leverage what the user has already learnt in real life.

For example, the traveling metaphor that's used on the World Wide Web makes it simple for everybody to surf, and a button's bevel invites the user to ‘push' it.

Each user has a different preexisting model in mind when they approach the interface. The interface should be flexible enough to accommodate all these user models. For example, a user might enter a phone number as 617-493-4984 or (617) 493 4984, so the interface should be prepared to accept either.

Characteristically, users will try to learn the positions of various elements in the interface and subsequently try to interact with them without looking at the element every time. Helping the user remember important elements and fixing those elements' locations will improve the efficiency of learning. An interface should be clean and simple -- this makes it easy for advanced users to remember things, and prevents new users getting lost in the interface. Categorizing elements into different groups keeps the interface uncluttered. Personas can also help developers prevent feature bloat and stay focused on the user.

Users can find it easier to learn new information little by little, so giving users a few new tasks at a time can be more effective than deluging them with information. The learning material shouldn't hinder the user's access to the real content, however; thus the elements in the interface should be both learnable and scanable. This will allow novice users to learn new features, while expert users will be able to perform tasks quickly.

Buttons, for example, should have text/tool tip and an icon. The text/tool tip makes a button learnable, while the icon makes it scanable. Maintaining a slow evolution of the interface also helps user learning and builds on previous successes to create a mature product. Testing new features on a minor portion of the real users provides the developer with an indication of realistic performance of the modifications, and allows slow evolution to occur.

Users Hate Repeating

No one likes entering data; we like to repeat data even less. How many times have you skipped entering personal information on the Web? How do you feel when you lose data you've spent time and effort entering (for example, a question or comment in a Web form)? Automatic data collection and the reuse of information will save your users the hassle of data entry.

Users want to obtain or write data once, and be able to use it anywhere. Any data that can be collected automatically, such as contextual information about the location, task, state, etc. should be acquired in this way. The prime advantage of rich Internet applications is that they keep the data rich even on the client side and enable reuse of the downloaded data with client side logic. Information must be able to flow, in accordance with the user's interaction with the site, to other connected content. Using standard formats to store data will keep the user happy by making this kind of interoperability possible. By locking data into a particular application, users may use the application, but they'll hate it if it doesn't support a particular task they need.

The default values of the various components in the interface should reflect majority preferences, yet they should also be easily deleted so the user can set new values. For example, text fields should be filled with default values and pre-selected to allow easy deletion. Auto-completion is another way to reuse data even if the software doesn't completely understand that data. Storing all data collected on the server gives the user a continuous experience across different devices. For this reason data should be backed up, instead of being overwritten, to prevent data losses.

Users Hate Waiting

Waiting for someone or something to appear is tedious. How many times have you grown bored waiting for a friend to show up? We hate waiting even more if we don't know how long we have to wait. So it's important to load data quickly and show progress -- the user can plan and fit in other tasks. Giving users access to the previous task and showing progress will occupy the user's attention and keep them informed while the data loads. Shifting between tasks while they wait requires user effort – and is another reason why speed is important. Displaying partially loaded data will also help minimize the perceived wait.

If long wait times can't be avoided, the user should be informed that they'll receive an alert after the data loads.

Appropriate alerts should be sent on completion pending requests when the user goes back online. Different types of alerts are needed to prevent disturbing the user during an important task. For example, one type of alert pops up with a sound, irrespective of what the user is doing. Another alert type is aggregated in a list that the user will see when they're free. One other pops up on a ticker within a side panel that the user will glance at when they're available. Alerts should be configurable by the user.