By: Viswanath Gondi

September 27th, 2003

Reader Rating: 7.5

“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.

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.

A Usable Architecture

Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. In order to develop usable rich Internet applications, it is necessary that the development process be as simple as possible, without neglecting any of the above usability constraints.

Patterns make it easier for the architect by providing them a system in which to store the lessons they've learnt. Most software patterns help the designer to cognitively grasp the problems encountered by others, and side-step them. A pattern that reduces complexity for the programmer without allowing them to lose track of the user will benefit the application designer.

To design a complex structure, one powerful technique is to discover viable ways of dissecting it into semi-independent components that correspond to its many functional parts. The design of each part can then be carried out with some degree of independence -- as each will affect the others largely through its functionality -- and independent of the details of the mechanisms that accomplish the function.

The complexity of the application is reduced when it's split into less dependent pieces. This separation into manageable parts will also make the application capable of evolution, rather than revolution, as this approach allows easy and small changes to be made.

The question now is: how do we split a rich Internet application so that designing under the above usability constraints becomes simpler? Dividing the application into pages and navigation will help. Each page is composed of data, components, logic, and presentation. The pages are encapsulated in the navigation shell, which again has data, components, logic and presentation.

Page

The page is an aggregation of data, components, logic and presentation. All interactions that are carried out together are grouped to form a task. The page encapsulates all these interactions. The users interact by visualizing and modifying various objects on a page through different views. Modifying the object in one view could immediately be reflected in the other views in the page because the rich Internet application is dealing with the data model of the object, rather than the data view of the object.

Reflecting the data model locally will enable offline interactions as well. For example, a tabular data object can be shown in different views. The table with all the columns, a slider with the maximum and minimum values of a column, and tick boxes containing the values of a column are a few views of the table data object with which the user might interact. Adjusting the slider view should update the table view in real-time. The modifications that are made to the data can be sent to the server when the user connects to the network.

Separating the navigation from the page doesn't mean that that the pages should not contain any links to other pages. If the page fits in a default process, the navigation should be integrated into it to help novice users. Clean and simple pages are easily learnable. Simplicity can be achieved by reducing the number of elements in the interface and by categorizing them into groups. The Interaction architect is responsible for the task-based page design.

Navigation

Navigation provides links from a given page to various other pages, depending on the context of the user's original location. It is an aggregation of navigation data, navigation logic, navigation presentation and navigation components within pages. Navigation data organizes the relations between a page and other pages into different facets.

Standard formats like Xfml (eXchangeable Faceted Metadata Language) can be used to store the navigation data. Other data, such as the navigation path followed by users, can also be used in navigation.

Having a consistent navigation layout supports easier browsing of the site's pages. Categorizing related links or reducing the number of links makes the navigation simple. Giving a URL to the pages and making them accessible from the Web will make the applications findable.

The Information architect is responsible for the navigation layout and contextual linking of various pages.

Data

Data is separated in rich Internet applications as it comes from the server or is collected separately on the client side. A few of the different types of data include application data, preferences data, logging data, and navigation data.

Some data exists only on the client side, but reflecting all data on the server provides the user with a consistent experience across various devices. The Web services on the server side handle the complexities of sending out the application data according to the requests received. Restricting shared data access and managing it efficiently among applications will help the site owner maintain security. Also, using standard formats to store data will achieve interoperability between applications.

Logic

Logic is the code that describes the behavior of the application. It connects components, presentation, and the data. Object oriented principles can be used to reduce the complexity in the logic. The application programmer is responsible for the logic that goes into the application.

Components

Components are the basic building blocks of the interface. A few types of components are interaction components, data loading components, navigation components and agent/alert components.

Interaction components provide visualizations and get interactions from the user for a particular data type. Separation of the component from logic, data presentation, and structure will assist rapid development and give the application designer the flexibility to implement accessible user interfaces. The components should take in text and provide accessible visualizations to all users.

Providing various ways to input the same information helps users interact with the application without changing their user model. Auto-completion-capable components also reduce the work load on the user.

Ensuring the learnability and scanability of components make them easy for both novice and advanced users. The components should be able to log user actions and take in actions to enable the undo feature.

Real world metaphors and affordances enable the user to interact with the software without learning new things. Various metaphors can be used to make the interaction with the components simpler.

The Web uses the travel metaphor, where users click on objects to go to a new page to perform an operation. Desktop applications use the workshop metaphor, where we have lots of tools to work on different selectable objects. In the morphic graphic system, the tasks appear on the objects itself after selecting it, which comes under the examine metaphor. A set of industry wide standard components following a consistent metaphor will make it possible for the user to learn once and use that knowledge anywhere.

Data loading components manage the data on the client and the server side. They provide the progress updates to the page, send partial data downloads to the interaction components and provide seamless online and offline data access. Navigation components encapsulate the page and navigation information in the application. Alert or agent components run in the background and give different types of alerts to the user.

Presentation

Presentation deals with the visual display of the components. The location, sizes, colors and backgrounds of the components are defined by the presentation.

Consistent location for similar types of elements is encouraged by separating the presentation from the application. Most of the benefits that come with using CSS in Web pages apply here too. The visual designer is responsible for the presentation part of the application.

Advantages of the Pattern

In summary, the pattern provides the application designer and developer with a range of benefits that help them develop usable rich Internet applications. The pattern...

1. decouples tasks according to expert domains, allowing semi-parallel application development
   
2. allows the developers to work within usability constraints
   
3. separates components from the software, enabling faster development
   
4. creates an environment where the page is independent of navigation, which supports just-in-time processes
   
5. makes presentation independent of pages, encouraging consistent page layout
   
6. provides greater scalability of the application due to reduced complexity
   
7. allows for easier maintenance through the splitting of the application into different parts

Even if the current tools do not support this pattern, it is advantageous to think of an application in this way because of the benefits it presents: it provides flexibility, gives independence to domain experts, and simplifies the problem with out losing track of usability constraints.

The availability of multiple options sometimes overwhelms new designers and increases complexity. The restrictions introduced through design patterns breed creativity under design constraints.

Patterns help reduce complexity and enable the easier understanding of a given problem. However, a design pattern is not a silver bullet or panacea to any problem, and should only be applied when the flexibility it affords is actually needed.

For more information, see:

HTML's time is over. Let's move on.
http://www.boxesandarrows.com/archives/htmls_time_is_over_lets_move_on.php [1]

Macromedia central white paper.
http://www.macromedia.com/software/central/whitepaper/central_wp.pdf [2]

Smart client application model and .NET framework.
http://msdn.microsoft.com/netframework/using/building/windows/analystreports/smartclient.aspx [3]

Java Web start architecture.
http://java.sun.com/products/javawebstart/architecture.html [4]

[1] http://www.boxesandarrows.com/archives/htmls_time_is_over_lets_move_on.php
[2] http://www.macromedia.com/software/central/whitepaper/central_wp.pdf
[3] http://msdn.microsoft.com/netframework/using/building/windows/analystreports/smartclient.aspx
[4] http://java.sun.com/products/javawebstart/architecture.html