February 2003

Articles Archives Printable PDF version

Approach

Development time can be dramatically shortened, and synergy can be created between project cycles, by incorporating business intelligence and technical expertise into the user interface (UI) design process. Following this approach changes the role of the prototype from a throwaway demo to a living extension of use cases, wire frames, and working front-end code from which the developers can build.

In older approaches, built around letting each group independently handle their domain of expertise, prototypes were created as a guide for the next team to integrate independently. Most of the time, documentation from one team defined what the next team needed to produce and complete before the next group could proceed. As timelines tightened, the demands on the deliverable increased, resulting in lag time and costly ripple effects.

The key to bridging design and implementation is to create a functional HTML prototype that shows the interaction via use cases, provides a platform on which design patterns can be tested, and a creates a back-end technology platform from which the developer can build. In this approach, ideas are molded into reality, and diagrams are turned into functional code. To accomplish this, a visual framework and supporting technical framework are created. Congruency between the two frameworks can result in a solid prototype that can be validated with usability tests, while gaining immediate traction on the subsequent iterative development cycles.

Visual Framework

Successful UI designs focus on the wants and needs of customers, leverage familiar usability patterns, and maintain a consistent navigational flow. This can be accomplished through research on industry segments, interviewing users, conducting focus groups, and examining best-of-breed competitors. All user research, UI corporate guidelines, and product UI guidelines should be factored into the model to support the implementation.

The resulting visual framework supports a variety of models including the presentation model, which defines the overall look and feel of the application and important design decisions, such as browser support, layout constraints, and UI controls for navigation. A solid navigation model and supporting visual design patterns (VDP) to implement the essential user interactions are also included in the resulting visual framework. For instance, if the presentation model uses tab-based navigation in a web application, a documented VDP for tabs should be supported in the HTML prototype.

Sample Visual Design Pattern: Using Tab Patterns with Web Applications

Christopher Alexander, the famous architect and author of "A Timeless Way of Building" provides the inspiration behind patterns:

"A pattern describes both a problem, which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Classic System Solutions' continuous work on projects in enterprise application design has provided us with many opportunities to encounter, ponder, and solve many user interface problems. One of them is selecting a single item from a list of categorized items using a folder metaphor, in other words, tabs. An example of tabs is shown below.

Issues this Pattern Solves

The purpose of the tab pattern is to allow the user to easily see all of the options available and select one. When implemented correctly, the user can easily relate the tab metaphor to a traditional paper file set of tabs, providing quick recognition of the selected tab and a basic understanding of how to make a selection. This pattern can also be used to show a complex object as whole, with each of its peer components displayed as a tab.

How this Pattern Works

Typically, tabs work as follows.

There should be a set of six to eight tabs, from which the user can select. Using more than eight tabs can significantly reduce usability, as the user is being asked to select a single item from too large of a domain set.

Ideally, the items under the tabs should be already known to the user or easy to categorize. The categorization of items should match the user's conceptual model of the data being displayed.

The tabs should be presented to the user one at a time. While the tabs can be categories, they can also be points on a discrete scale, for example, the letters in an alphabetical index.

All of the tabs should be shown to the user, with the items for the current tab placed immediately underneath it. Tabs should be shown as tabular sheets. This relationship should be reinforced by showing the tabular sheets visually, i.e., connecting the items area to the current tab.

Tabs should be placed horizontally. Consequently, the number of tabs that fit in a layout is usually less than ten, unless an alphabetical index is used. The tab labels should also be shown horizontally.

There should always be a default tab that is the first one displayed.

The currently selected tab should be highlighted visually.

It should be easy for the user to switch between the tabs. Each tab should be reachable with one click.

Use tabs when the items to be categorized are static and mutually exclusive. Make sure that a folder metaphor matches the user’s mental model of viewing the data. Avoid using tabs with dynamic data.

Use tabs when the amount of information can be placed into a relatively small number of categories. To increase the utility of the tab metaphor, some designers will use multiple rows of tabs. Unfortunately, this increase in utility comes at great sacrifice to usability. Multiple rows of tabs are confusing and intimidating, particularly to new users. These users find it difficult to locate the desired tab. In addition, screen real estate is compromised, and the repositioning of the tabs to the front row causes tremendous confusion and complexity. For instance, Amazon got into trouble when they decided to use a tab for each store they opened. Soon, a single row of tabs evolved into a multi-row nightmare (shown below) which was eventually abandoned.

Examples

Good HTML Example -- This example illustrates the use of tabs in a web application. HTML tables and in-line images are combined to create the illusion of a tab control. The user sees multiple tabs on a single web page, when, in reality, selecting a tab loads a new HTML page from the server (often referred to as "round-trip HTML").

For high volume transactional systems that display complex data across a set of tabs, you can open multiple threads to a server and asynchronously load and cache data from multiple tabs. This reduces the number of trips to the server and significantly improves the response time of the user interface, as the user moves between the tabs.

Bad HTML Example (confusing appearance) -- The Downloads "tab" in this example is currently selected, but it seems to be part of one of two much larger tabs, each having five menu items. The diagonal line between Monitoring and Testimonials confuses the eye by suggesting that the right hand "tab" is layered in front. Tabs should be recognizable as tabs; text contained in a rectangular box with square corners does not look like a tab. Too often, web page designers confuse navigation bars with tabs.

Good and Bad HTML Example (color identification) -- Notice how the Home tab is separate from the remaining tabs. This is a good approach if there is a logical distinction between the tab categories. This is also an example of how NOT to use colors and font styles. The white text looks washed out over the pastel colors, and the shadowed font is very hard to read. Black or a dark font color would have been more effective.

Back to Articles