User Interface Design for Browsers

The needs of the users who browse your site to find content (or products to buy) are very different from users who work with an application. Peter Vogel shows you how you can help your visitors find what they want.

 

Many Web sites include a “browsing” component. This is the part of the Web site that allows the user to find information or products that they’re interested in. It’s the content portion of the site as opposed to the application portion. Amazon.com is an example. Users can investigate the content to find the book, CD, DVD, or baby toy that they want—that’s the browsing portion of the site. Once customers have found what they want, they enter the part of the web site that allows them to buy it—the application component.

An application-oriented UI design must clearly define how to start, continue, and end the process. A browsing-orient UI design is less directive. When browsing, a user can’t simply be told to “go here” and “do this.” Instead, your user interface must be designed to support the typical strategies that users follow to find the content that they want. Fortunately, there is research that identifies those strategies. And, to define the interface appropriate for those strategies, you can look at the field of wayfinding, the discipline used to create signs and direction markers.

Strategies

Here’s a typical scenario that a shopper might follow when trying to find a product in a bricks and mortar book store:

Entering a bookstore, our shopper looks around for ideas for her father’s birthday. Spotting the banner over the Sports section, she heads there. On the way to the Sports section, she remembers that her father has always been a fan of Ty Cobb. She detours to the Biography section to see if she can find the book there. Since biographies are organized alphabetically, she quickly determines that there is no Ty Cobb biography. She continues to the Sport section. Scanning the books there she narrows her search to the golf section. At this point she asks one of the store staff for help. The staff person asks if her father would be more interested in a book on how to play golf better or a more general book about the game. Our shopper responds that a how-to book isn’t what she wants—but she does want a book under $25.00. The staff person suggests Boswell’s “Stokes of Genius” as a good gift and the sale is made.

As this scenario suggests, browsers use a variety of strategies to meet their goals. Research by Cognetics Corporation has shown that users follow four strategies when browsing a Web site (provided that the Web site supports those strategies). Ranked by the demand that these strategies place on the user’s knowledge from the most knowledge required to the least, the strategies are:

1)      Find: The user provides the item’s identifier and is presented the single matching item (or is told that it doesn’t exist)

2)      Query: The user provides general criteria and is presented with all matching items

3)      Structured search: The user responds to a series of questions to be presented with the requested content

4)      Explorer: The user investigates the content of the site.

Before implementing a user interface that supports these strategies, you need to decide which ones are appropriate based on your content and your users.

Explorer

Exploring is based on presenting characteristics of the content items to the user to allow them to select between groups of related content. Exploring assumes only that a user can recognize characteristics that they are interested in and are willing to discover the content behind those characteristics. You might, for instance, just show users typical examples from a category to allow them to identify items of interest.

One characteristic that’s often used to support exploring scenario is the category that each content item is slotted into. Amazon.com’s music site is a typical example that allows users to browse by categories of music and sub-categories with each category (see Figure 1).  

Figure 1. Amazon allows users to explore music by category.

Users appear to be willing to explore as many as three levels deep to get to their content, provided that the two middle levels have a limited number of sub-categories. In addition to getting discouraged as the number of levels increase, users’ motivation to continue diminishes rapidly as the number of perceived choices at each level increases. One way to reduce the perceived choices at each level is to keep the list of categories presented to the user homogenous. Having selected artist’s essentials category on Amazon.com, for instance, the next selection of categories presented is artists’ names rather than a mixture of artists’ names and musical styles (see Figure 2).

Figure 2. The artist essentials list presents a homogenous list of artist names.

Structured Search

Structured search performs the same function as exploring—narrowing the list of material based on characteristics of the content. Unlike exploring, structured search  assumes that users have some information about the content that they are interested in.

In a structured search, the user is presented with questions whose answers narrow the range of content to be presented. Structured search can cover a wider range of material than exploring content because a single page can present a user with a set of questions with a wide set of responses.

If the user only needs to select items from a multiple choice list and never needs to generate values to search on (i.e. is never required to type in a text box), a structured search is really just a variation on exploring. Normally, though, a structured search will require the user to enter some information.

As an example, on the Veterans Association hyperFAQ site (www.va.gov/hyperFAQ) the user responds to a series of Yes/No questions (“I’m looking for information on how to receive a benefit”, “I’m interested in health care”) to get a list of available resources (see Figure 3).

Figure 3. The Veterans Association guides users to the content that they want by asking a series of yes/no questions.

The Yes/No questions can do a very efficient job of sorting content (in theory, if every question divides the content in half, the number of questions to get to your list is the square root of the number of available choices). However, it’s not necessary, as the hyperFAQ does, to restrict your page to a single question or just yes/no responses.

Query

Query lets users enter the information that describes, in general, what the user is looking for. Query goes beyond the guided search by assuming that the user knows not only what they want but also the terms that can be used to find the content that they want. When using a query strategy, the user is given one chance to enter the criteria for their search and then is presented with a list of matching content (one extension to a query is to allow the user to search within the results of a first search). The “advanced search” page on most sites is an example of a query.

Find

Find lets the user ask for the item that they want. A find interface can support multiple criteria if, when all elements are specified, a single result is given. A user might, for instance, enter the model, color, and screen size to specify which television set they want to buy. As more fields are required it becomes more important that the system tolerate the typical errors that a user can make (e.g. common misspellings). Find assumes that users know exactly what they are looking for and, furthermore, what it is called.

Unlike the previous strategies, the find strategy doesn’t let users retrieve a set of topics. Instead, the user retrieves only a single item. This can make Find a poor choice for some scenarios. For research based work, for instance, the find strategy actually prevents users from achieving their goals by preventing them from finding related material.

The Final List

All of the strategies eventually present the user with a list of content items. Normally, this list shouldn’t have more than twenty-five items or users get discouraged at the number of choices still to review. It’s also important that each item be presented with enough information that the user can tell which one(s) they want.

Here again, Amazon.com is a good example (see Figure 4). The music site final list gives a picture of the CD, the name and artist, and the original release date which should be enough to let the typical user determine which item they want. The notable exception to a good ‘final list design’ on the Amazon site, is that Amazon.com lists are essentially unlimited in length.

 

Figure 4. On the Amazon music Web site, a list of CDs gives you enough information to decide which of the items you’re interested in.

Supporting the Strategies

The first step in supporting browsing is looking at your audience. You need to ask two questions:

1)      How much does the user know about the content that they want? Providing a Find box when users will never know the unique identifier of their content is a waste of everyone’s time.

2)      What is the typical scenario that a user follows? If browsers are typically looking for a range of choices, supporting query and exploring strategies makes sense. If users are typically want to bore in to locate a specific item then supporting a structured search strategy would be a good choice.

While a straight text search of your content is a minimal implementation for browsing, it doesn’t really support any of the four user strategies. Supporting each strategy comes down to building a database that provides enough data about each content item to support the appropriate strategy.

To begin with, you need to determine what information about each item will allow your users to identify the content that they want. This could be a picture of the cars that you sell, a summary of a house’s major features (floor space, number of rooms, number of bathrooms), or an abstract of a technical paper. This means knowing enough about your audience to identify what are key features to them.

For example, to support an exploration strategy based on categories, you’ll need a category field added to the table. If content items can be in multiple categories, you’ll need a separate category table and a category-to-content table that implements the many-to-many join between items and categories. If your site is going to support sub-categories within categories, a second table that defines the categories’ hierarchy is also required.

To support structured search and query, the attributes that can be queried must be added to the table. If an attribute has a limited number of valid values, you should also consider a lookup table of those values to let you populate list boxes in the user interface. While a general purpose, table-driven interface will support a query strategy, the series of questions in a structured search will probably require each page to be hand-coded (one of the reasons that a structured query is less frequently implemented than the other strategies).

Supporting the find strategy consists of defining a field to act as a unique identifier for each content item—something that you’ll have to do as part of your table design, anyway. However, for the find strategy to be useful to your users, this unique field will have to contain meaningful data rather than an arbitrary autonumber. For performance reasons, you may choose to have two unique fields in your table: an autonumber field that’s used for foreign keys to speed joins along with a meaningful identifier to support the user’s find strategy.

For all of these strategies it’s essential that an audience analysis be done first. You can’t use the attributes and data values that are important to you. You must use categories, attributes, and data values that will be meaningful to the user and helpful in finding the content that they are interested in.

Supporting Explorers

Most of the browsing strategies are easy to implement. The most difficult strategy to support is exploring. Fortunately, the field of wayfinding can help here. Wayfinding emerged in the 1970s to both study how people find their way through a space and to provide techniques for helping them. That research can also be applied to supporting explorer-based browsing.

            Wayfinding assumes that users perform three kinds of activities:

·        Creating a plan to reach a destination.

·        Executing the plan

·        Gathering the feedback to know whether they’re on track

You should begin by looking at how to support the user’s feedback activities. You need to decide what information to make available to your users and how to present it to them in a way that they can use. Wayfinding studies have found that users want both information that provides an overview of the whole site and information on where to go next in their path. To put it another way, you need to provide two sets of information:

1)      Destinations to go to

2)      Access points from the current point that lead to those destinations.

Given a set of information a user will build a decision plan that consists of several levels. As an example, A high level wayfinding plan might cover the decisions necessary to drive to a house in Ann Arbor, Michigan from a house in Goderich, Ontario, Canada. That’s only the top level, though. The next level down in the decision plan might consist of reaching four sub-destinations:

·        A border crossing

·        Detroit

·        Ann Arbor

·        The house

The next level down would consist of individual tasks allow the user to reach their goal.

Because of the way that users build decision plans, it’s not enough just to tell the user what’s on the next page. That design supports only the tasks involved in reaching a sub-destination and doesn’t support the higher level of your users’ decision plans.

One way to deal with supporting multiple levels in wayfinding is to divide your site’s destinations up into local and distant ones. For distant locations, you don’t need to provide as much detail as you need for local destinations. On the Microsoft MSDN site, for instance, expanding and collapsing menus fulfil this function (see Figure 5). The main menu headings provide information about “distant” locations. Clicking on the heading opens that menu item to display “local” destinations. On the Amazon.com site, the tabs across the top of the page provide access to sub-sites (“distant” locations). Once on a sub-site, information on “local” destinations is provided.

Figure 5. Microsoft’s MSDN Web-site uses expanding and collapsing menus to show both distant and local destinations.

 

Finally, you must support helping explorers execute their plans. The key to supporting plan execution is to clearly identify the links on the page. Among other cues, users will count on the layout of your page to help them execute. For instance, the current convention is that the navigation menu is down the left hand side of a page. Given a page with a long narrow frame on the left-hand side, most users will look for links there. Users also benefit if all links share a common “look and feel” and use common conventions to identify themselves (e.g. all links—and only the links—on a page are underlined and in a different color).

Where a large number of options exist at any level, you can reduce the perceived number of choices by organizing the choices on the page. This lets the user ignore most of the page’s options to concentrate on the ones that matter to them. For instance, Amazon.com allows user to browse with a music category by favorites, various styles, artists by alphabet, editors picks, and ‘new and notable’ (see Figure 6). All of the categories are differentiated to allow users to limit their search to just part of the page.

Switching Strategies

Your audience analysis will probably show that your users will want to use a variety of strategies. And, as my example of the bookstore shopper showed, a user typically moves from one strategy to another as they define or re-define their needs.

The key here is to provide some of the information from your database on each page. For instance, you can display a list of the attributes for the current item (or items) as part of the item’s display. If the user can change the values and initiate a search based on their new values, you’ve given the user the ability to switch to a query/structured search strategy, regardless of what strategy brought them to this page.

Turning those displayed attributes into links that take the user to a list of related items allows the user to switch to an explorer strategy. Simply putting on the page a link to an item’s category allows the user to switch to exploring the content items in that category.

For structured and query strategies, it may be enough to provide a link to a dedicated search page. However, when the user is taken to those pages, it’s worthwhile to pre-load the page with values from the last item the user looked at. The assumption here is that the user is most often going to be searching for something similar to what they were just looking it. A Clear button that clears the page supports the scenarios when that isn’t true.

While it may be easy to do, you shouldn’t provide support for strategies that your users aren’t going to use. For instance, providing a single text box for a find strategy doesn’t require much screen real estate. However, the only real unique identifier for a book is its ISBN number and it’s unlikely that many users will know the ISBN number for the book they want. Providing an ISBN search, as Barnes and Noble did on their main page, is unnecessary and probably explains why that option is gone. Amazon combines support for a single item query with support for an ISBN find into a single field on the page (presumably, code behind the text box does a find if the entry is numeric, a query for non-numeric entries).

As Barnes and Noble’s experience suggests, you won’t get your audience analysis right the first time. Monitoring how your site is actually used is critical. For instance, if you pre-fill the fields on your search page as I recommended earlier, you may find that most user click the Clear button to blank out those fields. If that’s true, you can eliminate the pre-filling code and the Clear button.

One Last Note

For all the time that I’ve spent on navigating your site, it’s worthwhile to remember that users aren’t interested in the navigation system—they’re interested in your site’s content. You need to make sure that your navigation system doesn’t come to dominate your site and can be read at a glance. When it comes to applying a style to your site you may want to keep the navigation system plainer than your content. Grouping your navigation entries into groups of three items allows users to pick up material at a glance, for instance. Making sure that the text has a high contrast (no pink letters on a red background) also helps.

            Whatever you do, by recognizing how users want to browse your content and then supporting those activities you will make bother yourself and your users more productive.

Peter Vogel (MBA, MCSD) is a principal in PH&V Information Services. PH&V specializes in system design and development for systems that use Microsoft systems. Peter has designed, built, and installed intranet and component based systems for Bayer AG, Exxon, Christie Digital, and the Canadian Imperial Bank of Commerce.  He is also the editor of the Smart Access and XML Developer newsletters, and wrote The Visual Basic Object and Component Handbook (Prentice Hall, currently being revised for .NET). In addition to teaching for Learning Tree International, Peter wrote their Web application development, ASP.NET, and Technical Writing courses, along with being technical editor on their COM+ course. His articles have appeared in every major magazine devoted to VB based development, can be found in the Microsoft Developer Network libraries, and will be included in Visual Studio.NET. Peter also presents at conferences around the world. peter.vogel@phvis.com.