Making Rich Web Application Architecture Usable

Users Hate Searching

Not being able to find what you're looking for can be frustrating. It's not possible to remember where things are if their locations change frequently. Maintaining consistent navigation is important in helping users find the information they want. When we're in a new place, we get around by asking someone for help, or by looking at signs. Similarly, search and navigation are very important in finding material in an online environment.

In the real world, we divide our time among tasks, and arrange information by topics. We also like to have as many of our needs met as possible in the one place -- it's simple and it saves time.

This is why supermarkets and shopping malls have proven so popular. In the case of Web applications, the user looks for tasks they can follow in order to achieve specific goals. A sequence of tasks makes a process; the process varies for different users. The designer might not be able to envisage during the design phase all the processes the user may want to follow within application. Some scenarios may change at a later stage; some scenarios may not even exist during the design phase. Therefore, it's easier to ask where the user wants to go from a task, rather than list all the possible processes. If the interface is designed around a rigid process, users may feel locked in. One advantage of html is that the user can quickly and easily navigate through a site's information in ways that the designer may not have expected. The application needs to allow the user to build personal processes that span a group of services and content as required.

Processes successfully direct users towards the goal, imposing minimal cognitive load, yet they restrict interesting work by creative users. Novice users like to follow tasks that fall into a default process. Tasks connected by rigid navigation systems are easier for them to use, though these same systems often restrict advanced users. In order not to stifle the user's creativity, task-based interfaces should be loosely connected. Navigating from one task to another through the multiple facets into which those tasks fall suits advanced users well. Poorly designed interfaces are more likely to be organized around a specific function or internal structure, leaving the user to figure out which sequence of functions will accomplish their particular task. A task-oriented interface guides the user through sequences of actions by setting up tasks and linking them up via contextual navigation.

The user can also be directed towards an ideal process through efficient information architecture. The navigational data collected can also be used to direct users towards processes that others have followed. Microsoft's task pane is a good example of the provision of contextual navigation between different tasks.

Separating the application into task-based interfaces and giving each task a URL enables them to be linked to from the Web. Linking from the Web to various tasks within the application will make the application easy for users to find.

Users Hate Reading

A picture says a thousand words. Would you wade through pages of tabular data if you could view that same information as a graph? Reading information as text requires our brain to visualize the data. Representing that information graphically can reduce this effort.

People are good at scanning, and we recognize and remember images more easily than text. Graphical elements more easily facilitate comparisons of length, shape, orientation, and texture. Animation can show changes across time. Color helps us make distinctions. Images help us achieve these aims much more effectively than does text.

Graphical elements are more accessible than text for most people, but some disabled users have problems assessing graphical elements. Computers can't understand graphical data well either.

Text is a format that is universally interpretable. Thus the data coming from the server to the interface is more useful if it is textual. The interface should present this data in a way that's accessible to all users.

Users Hate Security Breaches

While we're happy to share some information with some people, we prefer to keep some information private. Unwittingly giving other programs access to private data can have disastrous consequences. For example, allowing any program to access a user's Microsoft Outlook address book would open a can of worms.

Users don't like to enter their information -- they prefer it to be automatically collected. The developer must be able to control the sharing of this data in order to prevent security breaches. The user's consent should be sought before their personal information or other collected data is shared. Listing the problems and advantages that may arise from the user allowing the site to share their information with others will help the user make the decision. If the user gives permission to share data, it should be made accessible to various other parties in standard formats.

Default security settings are very important, as few users bother to go through them. It is always better to begin with a strict security policy and loosen it as required than to try to move from a loose policy to one that's strict. The security and privacy implications of all new features and data collected should be considered before implementation.

Users Hate a Monotonous Look

Monotonous interfaces are boring. Humans want to stand out in the groups we belong to, and want to spill our identities onto the things we use; we like our belongings to reflect our personality. Backgrounds, skins and sounds are a few ways to give users the ability to change the look of applications they use. A simple preference for setting the background and sounds will satisfy most users.

But, beware! While users like new looks, they don't like to learn new interactions, which is why it's better to keep the interface elements visually consistent with interactions – this way, users won't have to re-learn the interface if they apply a new skin to your application.

Users Hate Platform Restrictions

We hate those who stop us from doing what we want to. Laws have been made to prevent restrictions in the real world. “Make it accessible to anybody, anywhere!" should be the motto. Applications should not be restricted to a particular operating system, form factor, or user's abilities.

Users like to learn to use the application once and then be able to use it anywhere: on the computer, on a handheld, or on a tablet. Users with varying abilities should also be able to access the application using specialized software.

The ability to deploy applications on various operating systems across different accessibility software is an important criterion when it comes to choosing the development platform.

Users Hate Rigid Functionality

One size does not fit all. A tool's functionality is vastly reduced if it doesn't fit the user perfectly. How would the world be if there was only one shoe size?

Options to add, remove and modify different functionality should be given to the user. It is unlikely that users will change all the preferences to make the application suit them. They expect the application will be custom made for them, or that it will know automatically what they want by following their actions.

Various presets can be made available to users according to different personas that you've identified as being likely to use the product. Preference setting can be made easier if the control panel is linked to from the context in which the user might want to make changes. A feature such as increased the font size can be very valuable to many users.

Users Hate Mistakes

We hate making mistakes, but often there's no way to prevent them. Having the ability to undo our actions can allow us to recover from mistakes and learn from them. How great it would be if the undo feature were present in the real world!

Your application should keep track of all user actions and enable them to undo those actions. Auto-saving all actions prevents data loss if the application is closed by mistake. The data collected by the undo feature can also help the user to keep track of the navigation path they followed. Tracking user actions allows interesting metadata to emerge from the user's interaction with the content; ways in which individuals might make use of that metadata to improve the way they work can also become apparent through this process.

Separating individual user actions can also help in the development of macros for repeating user actions. If a certain action is irreversible, a message saying “Are you really, really sure?" needs to be presented to the user before their request is effected. It's better to back up the data and give the user the ability to undo their actions than to deluge the user with these messages.

Tracking all user actions has enormous benefit in the process of logging actions. The Web browser informs the site owner about the referrer page, but leaves a gap in tracking information when the user leaves the site. Rich Internet applications should be able to gather all user actions, which is of enormous value to the designer, and has the ability to determine the future path of the application.

“Release early and release often" is a principle that sees user feedback incorporated into the software quickly. Better feedback can be obtained by testing a new feature on a sample of real users. Errors that occur as users try to learn the interface and issues with the measurement itself can be minimized by direct testing.