1. 1 Information Architecture for the World Wide Web Thunder Lizard’s Web Design World ‘99 Seattle, Washington July 21, 1999 Louis Rosenfeld Argus Associates, Inc.

2. 2 Introduction Who am I? Brief Bio President of Argus Associates, an information architecture consulting firm (Ann Arbor, Michigan). Bias: Librarianship and Information Science (LIS) background. Bias: Work on larger, heterogeneous corporate sites (primarily intranets) for Fortune 500 companies. Columnist for Web Review, Internet World magazines. Co-author of Information Architecture for the World Wide Web (O’Reilly & Associates, 1998) and others.

3. 3 When do you know you have problems? When you hear these questions. Users: “Why can’t I find what I’m looking for?” Content Owners: “Where should my new content go? And what should I do about all this ROT (Redundant, Outdated, and Trivial content)?” CIO: “Where’s my ROI? I want my ROI!!” VP: “How come that other VP’s content is more prominent than mine?” The Web Team: “Who’s in charge here anyway?” You: “Why can’t I find what I’m looking for?”

4. 4 “umbrella” site Common Problem #1 Site development is “organic”, disorganized. Content lives in subsites or “silos” that are locally maintained and often reflect the “org chart”. The organization and users want an “umbrella”, a common interface to all content. Individual subsites are poorly architected and have few or no policies or procedures to deal with maintenance issues. subsites

5. 5 Common Problem #2 Site structure is an abstract concept. New medium means that initial focus is on the tangible and sexy; attention has been diverted by the lure of: Aesthetically charged visual design. Hi-octane functionality. Lucid text (and as much as possible). Other Cool Stuff. Analogous to building a house without a blueprint. Subsequent problems are all too apparent in later generation sites.

6. 6 Common Problem #3 “Information Retrieval” is a foreign phrase. Information retrieval performance is reduced when addressing the diversity typical of most sites: Content (formats, types, subject domains). Users. Missions/goals/constraints. Information retrieval is already difficult in narrower contexts. Rarely one right answer (relevance is subjective). Based on language, which is inherently ambiguous. Example: homographs and synonyms of pitch.

7. 7 What is Information Architecture? No single definition is perfect... “Information architects organize content and design navigation systems to help users find the information they need.” In the context of the Web: Organize means to group and label content at the macro (e.g., collections, areas) and micro (e.g., pages, fields) levels. Navigation refers to the default organization of the site, the design of page components, and tools such as search engines, indexes, and site maps. Many definitions; mine clearly biased by librarianship/information science background.

8. 8 Why Is Information Architecture Important? User’s perspective. Inability to find information is a major complaint. Information needs vary (known item, exploratory, comprehensive research). Preferences vary (searching, browsing; precision, recall). Expertise varies (query languages, technology literacy). Scary Fact #1: According to Zona Research, 20% of Internet savvy users have given up at least 3 times while shopping on the Web.

9. 9 Why Is Information Architecture Important? Producer’s perspective. Cost of finding information. Cost of not finding information. Maintenance costs. Political costs. Scary Fact #2: According to Jakob Nielsen and many others, a poor navigation system in a large corporate intranet can cost the company millions in lost employee productivity.

10. 10 Introduction to Information Architecture Where it fits. In the context of site development: Often leads the discovery/recommendations phase. Highly collaborative during conceptual design phase. Minimal involvement in production/implementation phase.

11. 11 Introduction to Information Architecture What the deliverables are. Blueprints (from top level to “chunk” level). Major page mockups/templates. Navigation systems. Labeling systems/controlled vocabularies/thesauri. Policies and procedures. Production work (e.g., classification and indexing). Training (e.g., educating an indexing operation).

12. 12 Introduction to Information Architecture Top-down vs. bottom-up varieties. “Top-down” Information Architecture Tie together disparate pockets of content for improved searching and browsing. Highly focused on users and information needs. “Bottom-up” Information Architecture Improve searching and browsing within a single, high-volume pocket of content. Highly focused on content, content attributes. Each approach informs the other (no mutual exclusivity).

13. 13 Introduction to Information Architecture Top-down vs. bottom-up varieties. Top-down example: Create a common information interface (“umbrella site”) for a corporate intranet with dozens of separate sub-sites. Bottom-up example: Re-architect a large collection of technical reports. “umbrella” site local subsites Bottom-Up Approach Top-Down Approach

14. 14 Top-Down Components: Organization Systems Definitions. Organization Structures The shape of the information space. The types of relationships between content areas or items. e.g. hierarchies, databases, hypertext. Organization Schemes Pathways for intellectual access. e.g. by author, by topic, by audience.

15. 15 Top-Down Components: Organization Structures How should a site’s content be structured? Types of Organization Structures Hierarchies: useful for the top levels of a site. Databases: organize large bodies of homogeneous content Hypertext: complement other structural types. Hybrids: often make most sense within a site. hierarchy database hypertext

16. 16 Top-Down Components: Organization Schemes How should my site’s content be organized? Exact Organization Schemes. By name, alphabetically (e.g., white pages). By geography (e.g., atlas). By chronology (e.g., timeline). Characteristics. Neat and easy to maintain. Everything has a place (one right answer). Extremely useful for users who know exactly what they’re looking for.

17. 17 Top-Down Components: Organization Schemes How should my site’s content be organized? Ambiguous organization schemes. By topic (e.g., bookstore, yellow pages). By task (e.g., buy, find, contact). By audience (e.g., home, small business, government). Characteristics. Messy and full of overlap. Hard to implement and maintain. Extremely useful for users who don’t know exactly what they’re looking for (subject searching, associative learning).

18. 18 Top-Down Components: Labeling Systems The basics. Symbols that represent concepts. Types: Labels within navigation systems. Titles and headings. Links. Index terms (keywords). Icons (visual representations of information). Strive for systems of labels which are: Specific and clear (for intended audiences) Predictable Consistent

19. 19 Top-Down Components: Labeling Systems Where should I get my labels? Existing Site/Other Content Don’t throw out the baby with the bath water. Other Sites Check out the competition. Controlled Vocabularies (CVs) and Thesauri Standardized sets of terms which describe a specific domain (thesauri contain CVs, relationships between terms (e.g., broader, narrower, see also), and scope notes). Users and Subject Experts Focus groups, query analysis, user testing.

20. 20 Top-Down Components: Navigation Systems Types of navigation systems. Global (site-wide) navigation systems: rule-based. Local (sub-site) navigation systems: rule-based. Contextual navigation systems: hand-crafted. Supplementary navigation systems. Tables of contents/site maps. Site indexes. Guides and guided tours.

21. 21 Top-Down Components: Navigation Systems What makes a navigation system succeed? Navigation systems need to: Provide context. (Where am I?) Provide flexibility (Where can I go?) Provide guidance (How can I get there? And get back to here?) Make sense (Separate global and local systems) Avoid competing with content. Test your site by seeing if users can answer these questions for random pages.

22. 22 Top-Down Components: Navigation Systems What supplementary navigation type is best? Table of Contents/Site Map Reflects site’s organization system (mental model). Good for subject searching. Site Index Flattens organization system (greater granularity). Supports known-item searching. May provide multiple browsable indexes. Guide Highlights a few of the site’s resources for a specific audience, topic, or task. Good for introducing users to an aspect of the site’s content.

23. 23 Top-Down Components: Searching Systems Searching really sucks... “Using an on-site search engine actually reduced the chances of success.” (1998 Usability Study by User Interface Engineering) http://world.std.com/~uieweb/searchart.htm

24. 24 Top-Down Components: Searching Systems …but users demand it. “Search is one of the most important user interface elements in any large web site...Our usability studies show that more than half of all users are search- dominant.” (Jakob Nielsen, Alertbox, 1997) http://www.useit.com/alertbox/9707b.html

25. 25 Query Top-Down Components: Searching Systems Finding involves more than searching... Browse Search Ask Search Ask Browse Search Ask Browse Search Browse Search Browse Search Ask Browse Search Browse Search Browse Ask Browse Search

26. 26 Query Search Interface Top-Down Components: Searching Systems …and searching involves more than an engine. Search Engine Content Results Query Language Query Builders

27. 27 Top-Down Components: Searching Systems How can searching be improved? Utilize multiple search interfaces. Expert vs. simple. Distinguish by user background/discipline/expertise. Support common information needs (known item vs. exploratory vs. research). Utilize search zones and leverage document structure. Support iterative, integrated searching and browsing (including a “no-dead ends” policy). Explain what is being searched and how it can be searched. Avoid default engine configurations, especially default relevance rankings.

28. 28 Top-Down Illustrated Typical scenario. “umbrella” site local subsites access by task access by topic access by audience S S S To C Ind

29. 29 Top-Down Case Study Background and challenges. Began with unclear goals for site. Tension between central administration and subsidiaries (political divisions, “rogue” Web sites, look and feel issues). No in-house process for developing a large, distributed, cross-departmental information system. Many different purposes for site. Multiple audiences for site.

30. 30 Top-Down Case Study Solutions. Created umbrella architecture that draws appropriate borders between centrally-maintained site and autonomous departmental sub-sites. Multiple ways of navigating content. Search. Browse by topic, task, audience, political unit. Table of contents, site index. Clear divisions between central and autonomous content embodied in the architecture and related procedures and policies for maintaining content.

31. 31 Bottom-Up Components: Content Analysis Look for order in the chaos of your content. Analogous to user surveys. Requires review (generally iterative) of content samples. Looking for: Logical patterns within messy content (e.g., press releases vs. product descriptions). Ways to group content (leads to “bottom-up” organization systems design). Meta-information opportunities (e.g., existing meta-information, approaches and sources for adding new meta-information). Relationships between document types (e.g., parent-child, related, sequential).

32. 32 Bottom-Up Components: Content Modeling and Mapping Getting control of content. Concentrate on meaning and value rather than physical formats (e.g., MS Word vs. Lotus Notes). Develop document types (logical). Use grouping exercises. Enlist content specialist and expert user input. Develop templates (physical). Delineate required vs. optional content components. Determine prominence, grouping, and sequence of components. Strive for consistency in presentation across as well as within templates (usability gains).

33. 33 Bottom-Up Components: Content Modeling and Mapping Matching the model with reality. ROT (Redundant, Outdated, and Trivial content) removal: Policy based. Impacts all aspects of content creation, maintenance, deletion. Identify missing content. Determine granularity for content “chunking”: Break up longer mixed-concept content. Join together fragments. Consider contexts: usability, display, retrieval, reuse, authoring.

34. 34 Bottom-Up Components: Meta-Information Information about information. If stored as a record, meta-information constitutes a document surrogate; if stored within document, acts as a representation or labeling of document. Provides context (e.g., date, publisher). Facilitates retrieval (e.g., author, title, subject index). Serves as alternative to major organization scheme. An effective alternative to full-text searching. Can be leveraged for creation of browsable indices/menus. Consider value of controlled vocabularies for descriptive indices.

35. 35 Bottom-Up Components: Meta-Information Indexing: to automate or not? Automated Approach Software identifies keywords, eliminates stop words, assembles inverted index. Relatively inexpensive. Poor performance, especially with heterogeneous content domains and document “richness”. Manual Approach Human reviews content, identifies key concepts, and selects keywords from controlled vocabulary. Expensive: Forrester Report, v2, n8, October 1997 says $960,000 for average corporate intranet. Better performance (context sensitive).

36. 36 Bottom-Up Components: Relationships How should content types be linked? Ad-Hoc Links Handcrafted; expensive to create and maintain. Capable of making powerful associations, but often subject to interpretation; therefore, “hit or miss” in cognitive value. Rule-Based Links Simple: “If a process document and a rate table document both deal with Product X, then they should always be linked to each other.” Rules allow for easy human link creation or automated linking (useful with huge collections of content).

37. 37 Bottom-Up Design Content modeling “Messy” Content relationships (links) ProductProcessReference content model Contact Handling “How To” document types Sequence (step 1, 2, …) Conditional (If…, Then...) template types presentational meta- information Format/Style Color Platform logical meta-information Name Content Owner Process Owner Geographic Eligibility

38. 38 Bottom-Up Case Study Background and challenges. Distributed inbound call centers (8,000 customer care associates). Intranet-based work support application (6,000 unstructured documents). Users were memorizing, not navigating. Erroneous information was being provided to customers. Negative impact on training and churn. Single semi-topical hierarchy… hand-maintained. Content management nightmare.

39. 39 Bottom-Up Case Study Solutions. Structured content model. Suite of document templates. Linking relationships. Indexing system with multiple controlled vocabularies. Functional specifications (auto-generated browsable indexes). Development and production indexing. Training and documentation.

40. 40 Conclusion A convergence of perspectives, communities. Traditional Top-Down Perspective User-centric work is what “we” (the Web community) have been doing. Goals: presentation and usability. Traditional Bottom-Up Perspective What mark-up and data modeling communities traditionally have been up to. Goals: content reuse and maintenance. Another Kind of Convergence Web community increasingly content-centric. Mark-up/database communities increasingly user-centric.

41. 41 Information Architecture Design Process A phased approach.

42. 42 Argus Associates Contact information. Louis Rosenfeld (lou@argus-inc.com) Argus Associates, Inc. 221 North Main Street, Suite 200 Ann Arbor, Michigan 48104 734.913.0010 voice 734.213.8082 fax info@argus-inc.com http://argus-inc.com This presentation available from: http://argus-inc.com/conferences/tl-seattle/