Section 2.1. THE BASICS OF INFORMATION ARCHITECTURE: DIVIDING STUFF UP

2.1. THE BASICS OF INFORMATION ARCHITECTURE: DIVIDING STUFF UP

In the Preface, I talked a bit about interface idioms.^[1]. These, you might recall, are interface types or styles that have become familiar to some user populations. They include text editors, forms, games, command lines, and spreadsheets. They're useful because they let you start a design with a set of familiar conventions; you don't have to start from first principles. And once a first-time user recognizes the idiom being used, she has a head start on under-standing the interface.

^[1] The term "idiom" comes from Scott McCloud's Understanding Comics, where it's used to describe a genre of work that has developed its own vocabulary of styles, gestures, and content. Another term might be "type," as used in Malcolm McCullough's Digital Ground to describe architectural forms and conventions.

Whatever it is you're building, you've probably decided which idioms to use. But what may not be so obvious is how to organize the "stuff" you're presenting via these idioms. If your application is small enough to fit on one page or physical panel, greatyou're off and running. But odds are good that you're dealing with a lot of features, tools, or content areas. The nature of the high-tech industry is to keep cramming more stuff into these interfaces, since features usually are what sell.

If you've done any work on web sites, you may know the term "information architecture." That's essentially what you'll be doing first. You need to figure out how to structure all this content and functionality: how to organize it, label it, and guide a user through the interface to get what they came for. Like a real-world architect, you're planning the informational "space" where people will dwell.

But applications are different from traditional web sites. Think about it in terms of "nouns" versus "verbs." In web sites and many other mediabooks, movies, music, graphic design you work with nouns. You arrange them, present them, categorize them, and index them. Users know what to do with text and images and such. But applications, by definition, exist so people can get things done: write, draw, perform transactions, interact with others, and keep track of things. You're manipulating verbs now. You need to structure the interface so users always know what to do next (or at least have a good idea where to look).

Most applications (and many web sites) are organized according to one or more of the fol-lowing approaches. Some use nouns, others use verbs:

• Lists of objectse.g., an inbox full of email messages

• Lists of actions or taskse.g., browse, buy, sell, or register

• Lists of subject categoriese.g., health, science, or technology

• Lists of toolse.g., calendar, address book, or notepad

You should base your choice on several interrelated factors: the nature and domain (subject matter) of the application, users' domain knowledge, users' comfort level with computers in general, and, most of all, how closely your application needs to match the mental models that users already have of the domain. (Mental models represent what users believe to be true about something, based on previous experience or understanding: classifications, vocabulary, processes, cause and effect, and so on.)

You can trace many problems in UI design to a poor choice here, or worse, a confusing mixture of more than one type of organizationlike tools and subject categories mixed into one navigation bar with ambiguous titles.

On the other hand, sometimes a mixed organization works fine. Some of the more interesting small-scale UI innovations have come from mixing nouns with verbs on the same menu, for instance; its usability depends on context. Also, you can apply these divisions not only to the top level of the application, but to numerous levels inside them. Different parts of an interface demand different organizational approaches.

Again, this isn't rocket science; you've seen these concepts before. But sometimes it's easy to choose one kind of division by default and not think carefully about which might be best. By calling them out, we make them visible and amenable to discussion. This will be true about many patterns and organizational models described in this book.

Let's take a closer look at these four categorizations and see what they're each best for.

2.1.1. LISTS OF OBJECTS

Most of the time, it will be pretty obvious when to use this categorization. Collections of email messages, songs, books, images (see the iPhoto example in Figure 2-1), search results, and financial transactionswe cope with them in the software we use every day. From these lists, we reach various familiar interface idioms: forms to edit things, media players to play things, and web pages to view things.

Figure 2-1. Lists of photos in iPhoto, sorted by album and displayed as thumbnails in a table

You will find these objects in selectable lists, tables, trees, or whatever is appropriate; some UIs are very creative. At one extreme, cell phone phonebooks may be short and linear, comprising only a few entries that you can scan quickly on a tiny screen. But TiVos list their recorded TV shows in multilevel hierarchies that you must traverse with several clicks, and the most sophisticated email clients allow all kinds of complex sorting and filtering. When you build these kinds of interfaces, make sure the design scales up appropriately, and take care to match the capabilities and needs of users with the functionality your interface provides.

There's much to be said about organizing and presenting the objects in such an interface. That's your next task as information architect. These models are most common:

• Linear, usually sorted

• 2D tables, also sorted, which often let the user sort via column headers, or filter according to various criteria

• A hierarchy that groups items into categories (and possibly subcategories)

• A hierarchy that reveals relationships: parent/child, containers, etc.

• Spatial organizations, such as maps, charts, or desktop-like areas in which users can place things where they want

In fact, all of these models (except 2D tables) apply to all four approaches to dividing up an interface: objects, tasks, categories, and tools. Your choice should depend upon what people want to do with the application, what best fits their mental models, and what best suits the natural organizationif anyof the objects in question.

If you present timetables for city buses, for instance, the natural organization is by bus or route number. A linear list of routes is a valid way to organize it. But not everyone will know what bus number they want; a spatial organization, like an interactive city map, may be more useful. You also might consider a hierarchy of areas, stations in those areas, and routes leaving those stations.

Chapter 6, Showing Complex Data, covers these organizational models for "nouns" in more detail. Of the patterns in this chapter, Two-Panel Selector is commonly used to structure this kind of interface, as is One-Window Drilldown.

Then, once the user has selected some object, what do they do with it? Read on!

2.1.2. LISTS OF ACTIONS

This approach is verb- instead of noun-centered. Instead of asking the user, "What do you want to work on?", these kinds of interfaces ask, "What do you want to do?" Such interfaces range from TurboTax's high-level decision tree (one screen of which is shown in Figure 2-2) to long menus of actions to be performed on an edited document or selected object.

What's nice about these is that they're often described in plain English. People can take them at face value. When you understand the application's domain well enough to define the correct set of tasks, the interface you design becomes quite usable, even to first-time users.

The hard part is dealing with the proliferation of actions that might be available to the user. Too many actions, more so than too many objects, can make it very hard for users to figure out what to do.

Figure 2-2. A friendly task-based organization at http://turbotax.com, described in terms of verbs"Start" and "Continue"and supplemented by helpful explanations

Desktop applications have menu bars and toolbars available for displaying large numbers of actions at once; most users understand these familiar conventions, at least superficially. Applications that use the One-Window Drilldown pattern can present whole-page menus, provided they're not too long. And the Canvas Plus Palette pattern talks about one very typical way to organize creational actions for use in many kinds of visual builders. In fact, all of Chapter 5 is devoted to various ways of placing, sorting, and organizing actions on an interface.

But the designers of small device interfaces, such as cell phones and PDAs, have interesting constraints. All they can easily do is present single-click choices of a few functions: three at a time if they're lucky, but usually only one or two. For them, it's critical to prioritize which actions are the most frequently chosen at any given point in the interaction, so they can be assigned to those one or two "softkeys" or buttons (see Figure 2-3). That careful prioritization is good discipline, even for web and desktop applications.

Figure 2-3. This cell phone contains a linear list of entries in a phone book. At the bottom of the screen, you see a pair of softkeyschangeable labels for the hardware buttons underneath themlabeled "Exit" and "View." The lefthand button is almost always Exit for all applications (users thus can become habituated to that button). However, the righthand button changes according to what you're doingit's always the most common action.
All other possible actions are hidden inside a menu, reachable via the middle softkey with the T-shaped icon on it. This division of common versus not-so-common is an example of Extras On Demand, a pattern in this chapter. The designers had to make a difficult choice about which action was most important, since showing all of them at once wasn't an option.

2.1.3. LISTS OF SUBJECT CATEGORIES

Web sites and online references divide up their content by subject category all the time. They have large amounts of stuff for people to browse through, and it often makes the most sense to organize it by subject, or by a similar categorization. But the success of a category-based organization, like that of tasks, depends on how well you've anticipated what users are looking for when they first see your interface. Again, you need to understand the application's domain well enough to match the mental models that your users already have.

Most applications aren't organized this way. Subject categories are better for sorting out nouns than verbs, and action-oriented software usually isn't a good fit for it. That said, help systemswhich should be an integral part of an application's designoften do use it, and if an application really does combine knowledge lookup with actions (like medical applications or mapping software), this could come in handy.

Figure 2-4 shows a popular example. The iTunes Music Store organizes its thousands of songs by album, artist, and then genre; that's how its users browse the catalog when they're not using the search facility. What if it were organized by some other means, like the musicians' hair length at the time of the 2004 Grammy Awards? That organization doesn't match most people's mental models of the music universe (hopefully). No one could find anything they were looking for.

Figure 2-4. The iTunes Music Store categorizes songs by album, artist, and genre. iTunes itself adds playlists as a category. This organizational model, combined with the familiar media-player idiom, really is the heart of the iTunes application.

In any case, organization by subject category might be useful to your application. Related types of organizations include alphabetical, chronological, geographical, and even audience type (like frequent users versus first-time users). See the book Information Architecture for the World Wide Web (O'Reilly) for more information.

2.1.4. LISTS OF TOOLS

Operating systems, palmtops, and cell phones all provide access to a range of tools, or sub-applications, used within their physical frameworks. Some applications, such as Microsoft Money, work that way too, and some web sites offer self-contained web applications such as wizards or games.

Once again, this works best when users have a clear, predictable expectation of what the tools should be. Calendars and phone lists are pretty recognizable. So are check-balancing programs and investment interfaces, as one might find in financial applications like MS Money. If your web site offers some novel and strangely named web apps, and they are mixed in with subject categories, users generally are not going to "get it" (unless they're very motivated).

For some reason, a tool-based organizational model fails particularly badly when the names of tools mix with actions, tasks, or objects. Mixing them tends to break people's expectations of what those items dowhether presented as menu choices, list items, buttons, or linksespecially for new users who don't know what the names of the tools are yet. Users you observe often do not articulate this confusion well, so beware. You should watch them for subtle signs of confusion, but don't ask them about it directly.

On the other hand, if the user's goal isn't to get something important done, but rather to explore and play, then this strategy might work. Interesting names might attract attention and cause people to click on them ust to see what they are. (See the Intriguing Branches pattern in this chapter.) But in this case, predictability isn't necessarily a huge benefit. In most software, predictability is quite important.

How can you organize the presentation of a list of tools? Linear organizations are common, since there usually aren't many of them in the first place. PalmOS and many other small devices use a grid of them (see Figure 2-5), which essentially is a linear list. Usually they're sorted alphabetically, for lookup, by expected frequency of use. When there are lot of toolsand might add lots morethen you might group them by category, like the Windows start bar does. Some systems let the users place tools wherever they want.

In the next chapter, on navigation, there's a pattern called Hub and Spoke. It's often used to structure an application around a toolbased organizational model.

Figure 2-5. The PalmOS applications screen is a simple linear list of tools.