Information architecture concepts

information architecture best practices and information architecture diagram
JohenCorner Profile Pic
Published Date:02-08-2017
Your Website URL(Optional)
The Anatomy of an Information Architecture4 Visualizing Information Architecture Why is it important to be able to visualize information architecture? There are sev- eral answers. One is that the field is new, and many people don’t believe that things exist until they can see them. Another is that the field is abstract, and many who might conceptually understand the basic premise of information architecture won’t really “get it” until they see it and experience it. Finally, a well-designed information architecture is invisible to users (which, paradoxically, is quite an unfair reward for IA success). IA’s lack of tangible qualities forces all information architects to be salespeople to some degree. Because it’s highly probable that you’ll need to explain information architecture to several important people, including colleagues, managers, prospects, clients, and perhaps your significant other, it’s in your interest to be able to help them visualize what an information architecture actually is. 41 Let’s start by looking at a site’s main page. Figure 4-1 shows the main page for Gustavus Adolphus College in Saint Peter, Minnesota, USA. Figure 4-1. Gustavus Adolphus College’s main page 42 Chapter 4: The Anatomy of an Information Architecture What’s obvious here? Most immediately, you see that the site’s visual design stands out. You can’t help but notice the site’s colors (you’ll have to take our word for it), typeface choices, and images. You also notice aspects of the site’s information design; for example, the number of columns—and their widths—changes through- out the page. What else? With a careful eye, you can detect aspects of the site’s interaction design, such as the use of mouseovers (over main menu choices) and pull-down menus for “Go Quickly To” and search options. Although the college’s logo and logotype are prominent, the site relies on textual content (e.g., “Excellence,” “Community,” and so forth) to convey its message and brand. And although this particular site func- tions well, you’d learn something about its supporting technology (and related expertise) just from the main page—for example, if it didn’t load properly in a com- mon browser, you might guess that the designers weren’t aware of or concerned with standards-compliant design. Thus far, we’ve noticed all sorts of things that aren’t information architecture. So what is recognizable as information architecture? You might be surprised by how much information architecture you can see if you know how to look. For example, the infor- mation has been structured in some basic ways, which we’ll explain in later chapters: Organization systems Present the site’s information to us in a variety of ways, such as content catego- ries that pertain to the entire campus (e.g., the top bar and its “Calendar” and “Academics” choices), or to specific audiences (the “I am a...” area, with such choices as “Prospective Students” and “Staff Member”). Navigation systems Help users move through the content, such as the “A–Z Directory” and the “Go Quickly To...” menu of popular destinations. Search systems Allow users to search the content. Here, the default is set to search the Gustavus site, but one could also search the Gustavus calendar, its directory, or the whole web from the site’s search interface. Labeling systems Describe categories, options, and links in language that (hopefully) is meaning- ful to users; you’ll see examples throughout the page, some (e.g., “Admission”) more understandable than others (“Nobel Conference”). Figure 4-2 provides a visualization of these architectural components. As we can see from this figure and from Figure 4-3, these areas are just the tip of the iceberg. Categories group pages and applications throughout the site; labels system- atically represent the site’s content; navigation systems and a search system can be used to move through the site. That’s quite a lot of information architecture to cram into one screenshot Visualizing Information Architecture 43 Search Navigation Navigation Organization systems system system system Figure 4-2. This page is crammed with architectural components In effect, the Gustavus main page tries to anticipate users’ major information needs, such as “How do I find out about admissions?” or “What’s going on this week on campus?” The site’s information architects have worked hard to determine the most common questions, and have designed the site to meet those needs. We refer to this as top-down information architecture, and the Gustavus main page addresses many common “top-down” questions that users have when they land on a site, including: 1. Where am I? 2. I know what I’m looking for; how do I search for it? 44 Chapter 4: The Anatomy of an Information Architecture 3. How do I get around this site? 4. What’s important and unique about this organization? 5. What’s available on this site? 6. What’s happening there? 7. Do they want my opinion about their site? 8. How can I contact a human? 9. What’s their address? 2 1 2 3 2 6 4 5 6 5 2 5 6 8 6 6 7 3 3 2 1 1 6 9 8 Figure 4-3. A site’s main page is crammed with answers to users’ questions Visualizing Information Architecture 45 Figure 4-4 shows a slightly different example—pages tagged by one of the authors as relevant to enterprise user experience in, a social bookmarking service. Figure 4-4. Bookmarks tagged as about “enterprise_UX” in, a social bookmarking service. There is little to see here besides the information architecture and the content itself. In fact, as the content is just a collection of links to bookmarked pages from other web sites, the information architecture is the bulk of the page. It provides context for the content, and tells us what we can do while we’re here. • The information architecture tells us where we are (in, on a page maintained by user “louisrosenfeld” that contains bookmarks he tagged as “enterprise_ux”). • It helps us move to other, closely related pages (by, for example, scrolling through results (“ earlier later ”) and to pages we’ve bookmarked using different tags (under “tags” and “related tags”). • It helps us move through the site hierarchically (for example, we can navigate to the main page, or to recent or popular bookmarks) and contextually (for example, by clicking on “saved by 4 other people” or by seeing who else bookmarked pages using the same tag). • It allows us to manipulate the content for better browsing (we can display tags in alphabetical order, as is shown, or as a “tag cloud”; a variety of other configura- tion choices are displayed in the “options”). • It tells us where we can go for basic services, such as logging into our account or getting help (“contact us” and “help”). 46 Chapter 4: The Anatomy of an Information ArchitectureIn many respects, this page from is nothing but information architecture. Content itself can have information architecture embedded within it. The recipe in Figure 4-5 shows a nutritious drink from the Epicurious site. Figure 4-5. A recipe for the thirsty from Beyond the navigational options at the top of the page, there’s not much informa- tion architecture here. Or is there? The recipe itself has a clear, strong structure: a title at the top, a list of ingredients, then preparation directions and serving information. This information is “chunked” so you know what’s what, even without subtitles for “ingredients” or “directions.” The recipe’s native chunking could also support searching and browsing; for exam- ple, users might be able to search on the chunks known as “recipe titles” for “salty dog” and retrieve this one. And these chunks are sequenced in a logical manner; after all, you’ll want to know the ingredients (“Do I have four ounces of grapefruit juice?”) before you start mixing the drink. The definition and sequential placement of chunks help you to recognize that this content is a recipe before you even read it. And once you know what it is, you have a better idea what this content is about and how to use it, move around it, and go somewhere else from it. So, if you look closely enough, you can see information architecture even when it’s embedded in the guts of your content. In fact, by supporting searching and brows- ing, the structure inherent in content enables the answers to users’ questions to “rise” to the surface. This is bottom-up information architecture; content structure, sequencing, and tagging help you answer such questions as: Visualizing Information Architecture 47 • Where am I? • What’s here? • Where can I go from here? Bottom-up information architecture is important because users are increasingly likely to bypass your site’s top-down information architecture. Instead, they’re using web- wide search tools like Google, clicking through ads, and clicking links while reading your content via their aggregators to find themselves deep in your site. Once there, they’ll want to jump to other relevant content in your site without learning how to use its top-down structure. A good information architecture is designed to anticipate this type of use; Keith Instone’s simple and practical Navigation Stress Test is a great way to evaluate a site’s bottom-up information architecture ( uefiles/navstress/). You now know that information architecture is something that can be seen, if you know what to look for. But it’s important to understand that information architec- ture is often invisible. For example, Figure 4-6 shows some search results from the BBC’s web site. Figure 4-6. BBC’s search results include three “Best Links” 48 Chapter 4: The Anatomy of an Information Architecture What’s going on here? We’ve searched for “chechnya,” and the site has presented us with a couple of different things, most interestingly three results labeled as a “BBC Best Link.” As you’d imagine, all search results were retrieved by a piece of soft- ware—a search engine—that the user never sees. The search engine has been config- ured to index and search certain parts of the site, to display certain kinds of information in each search result (i.e., page title, extract, and date), and to handle search queries in certain ways, such as removing “stop words” (e.g., “a,” “the,” and “of”). All of these decisions regarding search system configuration are unknown to users, and are integral aspects of information architecture design. What’s different is that the “Best Link” results are manually created: some people at the BBC decided that “chechnya” is an important term and that some of the BBC’s best content is not news stories, which normally come up at the top of most retrieval sets. So they applied some editorial expertise to identify three highly relevant pages and associated them with the term “chechnya,” thereby ensuring that these three items are displayed when someone searches for “chechnya.” Users might assume these search results are automatically generated, but humans are manually modify- ing the information architecture in the background; this is another example of invisi- ble information architecture. Information architecture is much more than just blueprints that portray navigational routes and wireframes that inform visual design. Our field involves more than meets the eye, and both its visible and invisible aspects help define what we do and illus- trate how challenging it really is. Information Architecture Components It can be difficult to know exactly what components make up an information archi- tecture. Users interact directly with some, while (as we saw above) others are so behind the scenes that users are unaware of their existence. In the next four chapters, we’ll present and discuss information architecture compo- nents by breaking them up into the following four categories: Organization systems How we categorize information, e.g., by subject or chronology. See Chapter 5. Labeling systems How we represent information, e.g., scientific terminology (“Acer”) or lay termi- nology (“maple”). See Chapter 6. Navigation systems How we browse or move through information, e.g., clicking through a hierar- chy. See Chapter 7. Searching systems How we search information, e.g., executing a search query against an index. See Chapter 8. Information Architecture Components 49 Like any categorization scheme, this one has its problems. For example, it can be dif- ficult to distinguish organization systems from labeling systems (hint: you organize content into groups, and then label those groups; each group can be labeled in differ- ent ways). In such situations, it can be useful to group objects in new ways. So before we delve into these systems, we’ll present an alternative method of categorizing information architecture components. This method is comprised of browsing aids, search aids, content and tasks, and “invisible” components. Browsing Aids These components present users with a predetermined set of paths to help them nav- igate the site. Users don’t articulate their queries, but instead find their way through menus and links. Types of browsing aids include: Organization systems The main ways of categorizing or grouping a site’s content (e.g., by topic, by task, by audiences, or by chronology). Also known as taxonomies and hierarchies. Tag clouds (based on user-generated tags) are also a form of organization system. Site-wide navigation systems Primary navigation systems that help users understand where they are and where they can go within a site (e.g., breadcrumbs). Local navigation systems Primary navigation systems that help users understand where they are and where they can go within a portion of a site (i.e., a subsite). Sitemaps/Tables of contents Navigation systems that supplement primary navigation systems; provide a con- densed overview of and links to major content areas and subsites within the site, usually in outline form. Site indices Supplementary navigation systems that provide an alphabetized list of links to the contents of the site. Site guides Supplementary navigation systems that provide specialized information on a spe- cific topic, as well as links to a related subset of the site’s content. Site wizards Supplementary navigation systems that lead users through a sequential set of steps; may also link to a related subset of the site’s content. Contextual navigation systems Consistently presented links to related content. Often embedded in text, and generally used to connect highly specialized content within a site. 50 Chapter 4: The Anatomy of an Information ArchitectureSearch Aids These components allow the entry of a user-defined query (e.g., a search) and auto- matically present users with a customized set of results that match their queries. Think of these as dynamic and mostly automated counterparts to browsing aids. Types of search components include: Search interface The means of entering and revising a search query, typically with information on how to improve your query, as well as other ways to configure your search (e.g., selecting from specific search zones). Query language The grammar of a search query; query languages might include Boolean opera- tors (e.g., AND, OR, NOT), proximity operators (e.g., ADJACENT, NEAR), or ways of specifying which field to search (e.g., AUTHOR=“Shakespeare”). Query builders Ways of enhancing a query’s performance; common examples include spell check- ers, stemming, concept searching, and drawing in synonyms from a thesaurus. Retrieval algorithms The part of a search engine that determines which content matches a user’s query; Google’s PageRank is perhaps the best-known example. Search zones Subsets of site content that have been separately indexed to support narrower searching (e.g., searching the tech support area within a software vendor’s site). Search results Presentation of content that matches the user’s search query; involves decisions of what types of content should make up each individual result, how many results to display, and how sets of results should be ranked, sorted, and clustered. Content and Tasks These are the users’ ultimate destinations, as opposed to separate components that get users to their destinations. However, it’s difficult to separate content and tasks from an information architecture, as there are components embedded in content and tasks that help us find our way. Examples of information architecture components embedded in content and tasks include: Headings Labels for the content that follows them. Embedded links Links within text; these label (i.e., represent) the content they link to. Information Architecture Components 51Embedded metadata Information that can be used as metadata but must first be extracted (e.g., in a recipe, if an ingredient is mentioned, this information can be indexed to support searching by ingredient). Chunks Logical units of content; these can vary in granularity (e.g., sections and chap- ters are both chunks) and can be nested (e.g., a section is part of a book). Lists Groups of chunks or links to chunks; these are important because they’ve been grouped together (e.g., they share some trait in common) and have been pre- sented in a particular order (e.g., chronologically). Sequential aids Clues that suggest where the user is in a process or task, and how far he has to go before completing it (e.g., “step 3 of 8”). Identifiers Clues that suggest where the user is in an information system (e.g., a logo speci- fying what site she is using, or a breadcrumb explaining where in the site she is). “Invisible” Components Certain key architectural components are manifest completely in the background; users rarely (if ever) interact with them. These components often “feed” other com- ponents, such as a thesaurus that’s used to enhance a search query. Some examples of invisible information architecture components include: Controlled vocabularies and thesauri Predetermined vocabularies of preferred terms that describe a specific domain (e.g., auto racing or orthopedic surgery); typically include variant terms (e.g., “brewskie” is a variant term for “beer”).Thesauri are controlled vocabularies that generally include links to broader and narrower terms, related terms, and descriptions of preferred terms (aka “scope notes”). Search systems can enhance queries by extracting a query’s synonyms from a controlled vocabulary. Retrieval algorithms Used to rank search results by relevance; retrieval algorithms reflect their pro- grammers’ judgments on how to determine relevance. Best bets Preferred search results that are manually coupled with a search query; editors and subject matter experts determine which queries should retrieve best bets, and which documents merit best bet status. Whichever method you use for categorizing architectural components, it’s useful to drill down beyond the abstract concept of information architecture and become familiar with its more tangible and, when possible, visual aspects. In the following chapters, we’ll take an even deeper look at the nuts and bolts of an information architecture. 52 Chapter 4: The Anatomy of an Information Architecture Chapter 5 CHAPTER 5 Organization Systems5 The beginning of all understanding is classification. —Hayden White What we’ll cover: • Subjectivity, politics, and other reasons why organizing information is so difficult • Exact and ambiguous organization schemes • Hierarchy, hypertext, and relational database structures • Folksonomies, tagging, and social classification Our understanding of the world is largely determined by our ability to organize infor- mation. Where do you live? What do you do? Who are you? Our answers reveal the systems of classification that form the very foundations of our understanding. We live in towns within states within countries. We work in departments in companies in industries. We are parents, children, and siblings, each an integral part of a family tree. We organize to understand, to explain, and to control. Our classification systems inherently reflect social and political perspectives and objectives. We live in the first world. They live in the third world. She is a freedom fighter. He is a terrorist. The way we organize, label, and relate information influences the way people compre- hend that information. As information architects, we organize information so that people can find the right answers to their questions. We strive to support casual browsing and directed search- ing. Our aim is to design organization and labeling systems that make sense to users. The Web provides information architects with a wonderfully flexible environment in which to organize. We can apply multiple organization systems to the same content and escape the physical limitations of the print world. So why are many large web sites so difficult to navigate? Why can’t the people who design these sites make it easy to find information? These common questions focus attention on the very real challenge of organizing information. 53Challenges of Organizing Information In recent years, increasing attention has been focused on the challenge of organizing information. Yet this challenge is not new. People have struggled with the difficulties of information organization for centuries. The field of librarianship has been largely devoted to the task of organizing and providing access to information. So why all the fuss now? Believe it or not, we’re all becoming librarians. This quiet yet powerful revolution is driven by the decentralizing force of the global Internet. Not long ago, the responsi- bility for labeling, organizing, and providing access to information fell squarely in the laps of librarians. These librarians spoke in strange languages about Dewey Decimal Classification and the Anglo-American Cataloging Rules. They classified, cataloged, and helped you find the information you needed. As it grows, the Internet is forcing the responsibility for organizing information on more of us each day. How many corporate web sites exist today? How many blogs? What about tomorrow? As the Internet provides users with the freedom to publish information, it quietly burdens them with the responsibility to organize that informa- tion. New information technologies open the floodgates for exponential content growth, which creates a need for innovation in content organization (see Figure 5-1). And if you’re not convinced that we’re facing severe information-overload chal- lenges, take a look at an excellent study conducted at Berkeley. This study finds that the world produces between one and two exabytes of unique information per year. Given that an exabyte is a billion gigabytes (we’re talking 18 zeros), this growing mountain of information should keep us all busy for a while. As we struggle to meet these challenges, we unknowingly adopt the language of librarians. How should we label that content? Is there an existing classification scheme we can borrow? Who’s going to catalog all of that information? We’re moving toward a world in which tremendous numbers of people publish and organize their own information. As we do so, the challenges inherent in organizing that information become more recognized and more important. Let’s explore some of the reasons why organizing information in useful ways is so difficult. Ambiguity Classification systems are built upon the foundation of language, and language is ambiguous: words are capable of being understood more than one way. Think about “How Much Information?” is a study produced by the faculty and students at the School of Information Management and Systems at the University of California at Berkeley. See research/projects/how-much-info-2003. 54 Chapter 5: Organization SystemsVolume 1992 Internet explosion Content Growth 1900 London library (500,000 volumes) 1884 First mechanical typesetter 1450 1480 Gutenberg's Vatican library hand press (3500 volumes) 500 Monks copy books by hand 3000 BC Earliest written record Time 660 BC 330 BC 1876 1970 1994 Assyrian king organizes Alexandria Library includes Dewey SGML developed Information Architects tablets by subject 120 scroll bibliography Decimal System arrive Content Organization Figure 5-1. Content growth drives innovation the word pitch. When I say pitch, what do you hear? There are more than 15 defini- tions, including: • A throw, fling, or toss • A black, sticky substance used for waterproofing • The rising and falling of the bow and stern of a ship in a rough sea • A salesman’s persuasive line of talk • An element of sound determined by the frequency of vibration This ambiguity results in a shaky foundation for our classification systems. When we use words as labels for our categories, we run the risk that users will miss our mean- ing. This is a serious problem. (See Chapter 6 to learn more about labeling.) It gets worse. Not only do we need to agree on the labels and their definitions, we also need to agree on which documents to place in which categories. Consider the common tomato. According to Webster’s dictionary, a tomato is “a red or yellowish Challenges of Organizing Information 55 fruit with a juicy pulp, used as a vegetable: botanically it is a berry.” Now I’m con- fused. Is it a fruit, a vegetable, or a berry? If we have such problems classifying the common tomato, consider the challenges involved in classifying web site content. Classification is particularly difficult when you’re organizing abstract concepts such as subjects, topics, or functions. For exam- ple, what is meant by “alternative healing,” and should it be cataloged under “philos- ophy” or “religion” or “health and medicine” or all of the above? The organization of words and phrases, taking into account their inherent ambiguity, presents a very real and substantial challenge. Heterogeneity Heterogeneity refers to an object or collection of objects composed of unrelated or unlike parts. You might refer to grandma’s homemade broth with its assortment of vegetables, meats, and other mysterious leftovers as heterogeneous. At the other end of the scale, homogeneous refers to something composed of similar or identical ele- ments. For example, Ritz crackers are homogeneous. Every cracker looks and tastes the same. An old-fashioned library card catalog is relatively homogeneous. It organizes and provides access to books. It does not provide access to chapters in books or collec- tions of books. It may not provide access to magazines or videos. This homogeneity allows for a structured classification system. Each book has a record in the catalog. Each record contains the same fields: author, title, and subject. It is a high-level, single- medium system, and works fairly well. Most web sites, on the other hand, are highly heterogeneous in many respects. For example, web sites often provide access to documents and their components at vary- ing levels of granularity. A web site might present articles and journals and journal databases side by side. Links might lead to pages, sections of pages, or other web sites. And, web sites typically provide access to documents in multiple formats. You might find financial news, product descriptions, employee home pages, image archives, and software files. Dynamic news content shares space with static human-resources infor- mation. Textual information shares space with video, audio, and interactive applica- tions. The web site is a great multimedia melting pot, where you are challenged to reconcile the cataloging of the broad and the detailed across many mediums. The heterogeneous nature of web sites makes it difficult to impose any single struc- tured organization system on the content. It usually doesn’t make sense to classify The tomato is technically a berry and thus a fruit, despite an 1893 U.S. Supreme Court decision that declared it a vegetable. (John Nix, an importer of West Indies tomatoes, had brought suit to lift a 10 percent tariff, mandated by Congress, on imported vegetables. Nix argued that the tomato is a fruit. The Court held that since a tomato was consumed as a vegetable rather than as a dessert like fruit, it was a vegetable.) “Best Bite of Summer,” by Denise Grady, July 1997. 56 Chapter 5: Organization Systems documents at varying levels of granularity side by side. An article and a magazine should be treated differently. Similarly, it may not make sense to handle varying for- mats the same way. Each format will have uniquely important characteristics. For example, we need to know certain things about images, such as file format (GIF, TIFF, etc.) and resolution (640× 480, 1024× 768, etc.). It is difficult and often mis- guided to attempt a one-size-fits-all approach to the organization of heterogeneous web site content. This is a fundamental flaw of many enterprise taxonomy initiatives. Differences in Perspectives Have you ever tried to find a file on a coworker’s desktop computer? Perhaps you had permission. Perhaps you were engaged in low-grade corporate espionage. In either case, you needed that file. In some instances, you may have found the file immediately. In others, you may have searched for hours. The ways people organize and name files and directories on their computers can be maddeningly illogical. When questioned, they will often claim that their organization system makes perfect sense. “But it’s obvious I put current proposals in the folder labeled /office/clients/ green and old proposals in /office/clients/red. I don’t understand why you couldn’t find them” The fact is that labeling and organization systems are intensely affected by their cre- † ators’ perspectives. We see this at the corporate level with web sites organized according to internal divisions or org charts, with groupings such as marketing, sales, customer support, human resources, and information systems. How does a customer visiting this web site know where to go for technical information about a product she just purchased? To design usable organization systems, we need to escape from our own mental models of content labeling and organization. We employ a mix of user research and analysis methods to gain real insight. How do users group the information? What types of labels do they use? How do they navigate? This challenge is complicated by the fact that web sites are designed for multiple users, and all users will have different ways of understanding the information. Their levels of familiarity with your company and your content will vary. For these reasons, even with a massive barrage of user tests, it is impossible to create a perfect organization system. One site does not fit all However, by recognizing the importance of perspective, by striving to understand the intended audiences through user research and testing, and by providing multiple navigation pathways, you can do a better job of organizing infor- mation for public consumption than your coworker does on his desktop computer. It actually gets even more complicated because an individual’s needs, perspectives, and behaviors change over time. A significant body of research within the field of library and information science explores the com- plex nature of information models. For an example, see “Anomalous States of Knowledge as a Basis for Infor- mation Retrieval” by N.J. Belkin, Canadian Journal of Information Science, 5 (1980). Challenges of Organizing Information 57 † For a fascinating study on the idiosyncratic methods people use to organize their physical desktops and office spaces, see “How Do People Organize Their Desks? Implications for the Design of Office Information Sys- tems” by T.W. Malone, ACM Transactions on Office Information Systems 1 (1983).Internal Politics Politics exist in every organization. Individuals and departments constantly position for influence or respect. Because of the inherent power of information organization in forming understanding and opinion, the process of designing information archi- tectures for web sites and intranets can involve a strong undercurrent of politics. The choice of organization and labeling systems can have a big impact on how users of the site perceive the company, its departments, and its products. For example, should we include a link to the library site on the main page of the corporate intra- net? Should we call it The Library or Information Services or Knowledge Manage- ment? Should information resources provided by other departments be included in this area? If the library gets a link on the main page, why not corporate communica- tions? What about daily news? As an information architect, you must be sensitive to your organization’s political environment. In certain cases, you must remind your colleagues to focus on creating an architecture that works for the user. In others, you may need to make compro- mises to avoid serious political conflict. Politics raise the complexity and difficulty of creating usable information architectures. However, if you are sensitive to the politi- cal issues at hand, you can manage their impact upon the architecture. Organizing Web Sites and Intranets The organization of information in web sites and intranets is a major factor in deter- mining success, and yet many web development teams lack the understanding neces- sary to do the job well. Our goal in this chapter is to provide a foundation for tackling even the most challenging information organization projects. Organization systems are composed of organization schemes and organization struc- tures. An organization scheme defines the shared characteristics of content items and influences the logical grouping of those items. An organization structure defines the types of relationships between content items and groups. Before diving in, it’s important to understand information organization in the con- text of web site development. Organization is closely related to navigation, labeling, and indexing. The hierarchical organization structures of web sites often play the part of primary navigation system. The labels of categories play a significant role in defining the contents of those categories. Manual indexing or metadata tagging is ultimately a tool for organizing content items into groups at a very detailed level. Despite these closely knit relationships, it is both possible and useful to isolate the design of organization systems, which will form the foundation for navigation and labeling systems. By focusing solely on the logical grouping of information, you avoid the distractions of implementation details and can design a better web site. 58 Chapter 5: Organization SystemsOrganization Schemes We navigate through organization schemes every day. Telephone books, supermar- kets, and television programming guides all use organization schemes to facilitate access. Some schemes are easy to use. We rarely have difficulty finding a friend’s phone number in the alphabetical organization scheme of the white pages. Some schemes are intensely frustrating. Trying to find marshmallows or popcorn in a large and unfamiliar supermarket can drive us crazy. Are marshmallows in the snack aisle, the baking ingredients section, both, or neither? In fact, the organization schemes of the phone book and the supermarket are funda- mentally different. The alphabetical organization scheme of the phone book’s white pages is exact. The hybrid topical/task-oriented organization scheme of the super- market is ambiguous. Exact Organization Schemes Let’s start with the easy ones. Exact or “objective” organization schemes divide infor- mation into well-defined and mutually exclusive sections. The alphabetical organiza- tion of the phone book’s white pages is a perfect example. If you know the last name of the person you are looking for, navigating the scheme is easy. “Porter” is in the Ps, which are after the Os but before the Qs. This is called known-item searching. You know what you’re looking for, and it’s obvious where to find it. No ambiguity is involved. The problem with exact organization schemes is that they require users to know the specific name of the resource they are looking for. The white pages don’t work very well if you’re looking for a plumber. Exact organization schemes are relatively easy to design and maintain because there is little intellectual work involved in assigning items to categories. They are also easy to use. The following sections explore three frequently used exact organization schemes. Alphabetical An alphabetical organization scheme is the primary organization scheme for encyclo- pedias and dictionaries. Almost all nonfiction books, including this one, provide an alphabetical index. Phone books, department-store directories, bookstores, and libraries all make use of our 26-letter alphabet for organizing their contents. Alpha- betical organization often serves as an umbrella for other organization schemes. We see information organized alphabetically by last name, by product or service, by department, and by format. Figure 5-2 provides an example of a departmental direc- tory organized alphabetically by last name. Organization Schemes 59 Figure 5-2. A directory of people at Microsoft Research Chronological Certain types of information lend themselves to chronological organization. For example, an archive of press releases might be organized by the date of release. Press release archives are obvious candidates for chronological organization schemes (see Figure 5-3). The date of announcement provides important context for the release. However, keep in mind that users may also want to browse the releases by title, prod- uct category, or geography, or to search by keyword. A complementary combination of organization schemes is often necessary. History books, magazine archives, diaries, and television guides tend to be organized chronologically. As long as there is agreement on when a particular event occurred, chronological schemes are easy to design and use. Geographical Place is often an important characteristic of information. We travel from one place to another. We care about the news and weather that affects us in our location. Politi- cal, social, and economic issues are frequently location-dependent. And, in a world where mobile devices such as Blackberries and Treos are becoming location-aware, while companies like Google and Yahoo are investing heavily in local search and directory services, the map as interface is enjoying a resurgence of interest. With the exception of border disputes, geographical organization schemes are fairly straightforward to design and use. Figure 5-4 shows an example of a geographical organization scheme. Users can select a location from the map using their mouse. 60 Chapter 5: Organization Systems