Eat Me, Drink Me, Push Me: In which the subtle arts of the interface are examined.

In: Articles

By Christina Wodtke

Published on December 10, 2002

You’ve gone through organizing content and designing interaction. Now you come to the last piece of the architecture pie: interface. How do you enable people to use all that brilliant structure?

Welcome to the sticky world of GUI. GUI stands for graphical user interface:

• Graphical – It uses pictures as well as words.
• User – It’s designed to help users talk to the computer.
• Interface – That lovely layer between structure and veneer.

Some information architects will design the page, but most will stop short of this. Like their real-world counterparts – building architects – the information architect suggests what is needed but not how it will be rendered.

In this blueprint, the architect has decided how many doors there should be and which way they will open. But the architect has not decided whether they are glass or mahogany. Or what the handle will look like. The information architect makes the same level of choice. She may decide that there needs to be a submit button at the end of a form, but she may leave it to the graphic designer to decide whether it should be blue or gray.

This chapter is an examination of the area co-owned by information architects and graphic designers.

From Box to Page

The first step in getting to the interface is to move from concepts to pages. In the past, you’ve used a box or two with an arrow in between to hold together your design. Now you get to decide whether you put the contents of one box or five on any given page.

When deciding how to convert your interaction design into pages, consider these factors:

• The audience’s technical sophistication
• The audience’s bandwidth
• The amount of information on a page
• The task the audience is trying to accomplish

For example, let’s take this flowchart of an online festival planner:

The interaction is clearly laid out. How will this translate into web pages? You could make each box a page. This would result in a site with a series of pages that looks like Figure 1.1.

Figure 1.1 – Each box becomes a page

In software design, a very simple one-step=one-page layout is called a wizard (see Figure 1.2). Wizards are used in the following situations:

• When users want to accomplish a goal that has many steps. Wizards are good at making sure you don’t miss a step.
• When the steps must be completed in order. Wizards are linear, so it’s impossible to complete them any other way.
• When the task is seldom performed. Wizards can seem slow and plodding, so they are best used in tasks you do only once in a while, like setting up a printer.

Figure 1.2 – An example of a wizard

The requirements are similar in web site design. After all, web sites are cousins of software and face many of the same design problems. Wizards are a good choice for web design under all the conditions previously listed, as well as when

• The audience is not technically savvy and likely to be confused by a page with a lot of choices on it. A web site can have novice users, and a wizard makes complex tasks seem easy.
• Bandwidth is low and downloading a single big page could take forever, or the tasks require several server calls¹ (link to footnote), which would also slow the page’s load.
• The task has several steps in it, performed only once a visit, such as checkout.

Figure 1.3 – All questions are combined onto one page

Control Panels: an alternative for experienced users

A complex many-steps=one-page layout is called a control panel. Figure 1.4 shows its software progenitor. Control panels are good in the opposite situation: when the audience is technically savvy and on a fast download.

Figure 1.4 – An example of a software control panel

Control panels are also a good choice when

• The application is easy to understand and the choices are straightforward.
• The elements gain context by being placed next to each other.
• The interface is used often enough that the audience will appreciate the convenience of a single page.

In applications, wizards are used for one-time situations, such as when a user sets up networking. Control panels are often used in situations in which occasional tweaking is required, such as configuring a program.

There is a third configuration for your interactive elements. Toolbars keep the tools for interaction conveniently close to the workspace they affect. This is useful when frequent tweaking is required, such as when you are writing or drawing. Imagine how painful it would be if you had to go to a different page every time you wanted to go from an eraser to a pencil!

Figure 1.5 – Adobe’s Photoshop interface

Adobe’s Photoshop has multiple toolbars that frame the workspace. You hardly have to interrupt your creative process to change from an eraser to a pencil.

Use toolbars when

• Many steps are in the task, and the steps can be done in any order.
• Steps need to be undone and redone as well as just plain done.
• The proximity of tools to the workspace is important for the task.
• The user’s technology can support the implementation (um, excuse me Mr. Engineer, I have another question for you…)

Although toolbars are common in software (see Figure 1.5), they are not widely used in web design, mostly because of the technical limitations of older browsers. More and more toolbars are being used, though, as more applications come to the web and browsers become more sophisticated. Figure 1.6 shows how our Festival planner would look in a toolbar and palette format.

Figure 1.6

Some Examples

There is less of a standard on the web than there is in applications. Complex procedures such as account setup or checkout can sometimes be laid out either as wizards or as control panels. It varies. For example, Dell and Compaq both provide a tool to help their customers select a computer from their vast product lines. Compaq has chosen to use a wizard, and the choices are spread across multiple screens (see Figure 1.6). Dell has chosen a control panel layout, and all the choices are on a single screen (see Figure 1.7).

Figure 1.6 – Compaq uses a wizard for its Selection Assistant.

Figure 1.7 – Dell uses a control panel for its Computer Finder.

The Dell Computer Finder is simple to use and fast. Choose your specs and see the results. The Compaq Selection Assistant takes you through seven pages of questions before you see a computer. Does the Dell solution seem better?

What if you don’t know the difference between a Pentium and a Celeron processor? With the Dell design, you have no way to know if you are choosing wisely.

Meanwhile, Compaq asks questions you definitely know the answers to; for example, where in the house will you be using the computer? Each question is easy to answer and builds the customer’s confidence while designing a profile Compaq can use to recommend a computer. These same pages of questions would drive a computer-savvy buyer insane.

In each case, the designer had the same problem to solve: with hundreds of products, how can we help the user find the correct one? Compaq and Dell’s designers chose different tactics, both designed to meet the needs of their user base.

Nike ID, a web-page-based tool that customers use to design their own shoes, provided its designer with a slightly more complex problem than Compaq or Dell. Style is not as important with computers as it is with shoes, so seeing how the computer looked was less important than picking the specifications. But shoes are all about style.

Nike ID’s designer chose a toolbar layout so that users could see the effect of their choices on the shoe, getting instant feedback on important matters, such as seeing that teal and peach might not be the best of color combinations (see Figure 1.8).

Figure 1.8 – The Nike ID choices made via the toolbar on the right affect the shoe on the left.

As you move from interaction design to interface, consider what page configuration will give the user the control he needs to make the right decisions without leaving him bewildered.

You have to make similar choices as you design pages for your content organization. Just because you have a category doesn’t mean it should be a page. Some levels of a category only exist to provide an explanation of organizational logic. For example, in faceted classification you will probably want to label each facet. But should each label be a page?

In Figure 1.9, we can see that 1-800-flowers has provided a way for its customers to browse through the facets of the flower gift collection: by brand, by department, and by price. These facet labels act as dividers in the navigation to provide context to the list items. The dividers also give the long list some visual clarity, making it easier to scan. However useful they are to navigation, 1-800-flowers has no reason to dedicate a page to each divider, and it wisely does not.

Figure 1.9 – 1-800-flowers.com‘s gift page navigation. Only the subcategories are actually links to pages.

The important thing to keep in mind as you decide what pages should exist is that each page should have a purpose. Ask yourself, “What is this page doing?” and if you don’t have a good answer, get rid of it.

---

Footnote

¹ This is an example of why getting your engineer on board during design is important. When a user requests a page, the browser requests the page’s data from the server hosting the page. This takes a bit of time. Sometimes the browser has to ask for several bits of data, such as HTML and images, and sometimes the browser has to request data from more than one server, which takes even more time. It may prove useful to break all those requests across several pages so that each page loads quickly. Your engineer can help you determine which design will result in a noticeably speedier page. A wizard is not the only choice. Just because your flowchart shows one page, one box, doesn’t mean you don’t have other choices. You could also combine all the questions in the Festival Planner onto one page, which would make the section look more like Figure 1.3.
Back to content

This is the first few pages of chapter eight of Information Architecture: Blueprints for the Web. The chapter continues, explaining interface design, including design principals and practical examples of good interfaces.

Related Topics: Information Architecture, Navigation