Week 13: Information Condensation, Or, It's Only a Model!

This week’s reading: Borgmann, Part 2

“Holding On to Reality” is simultaneously the most general and the most personal treatment of information science I’ve yet read as part of the library science curriculum, and reading it is exhilarating. I’m not ready yet to address Ess’s analysis of Borgmann cited in the lecture notes, since Ess focuses primarily on Part 3 of Borgmann. Instead, I’ll return this week to the needs of users – a focal component of IA – and discuss what user needs have to do with Borgmann’s treatment of information.

Tying physical architecture to his discussion of the distinction between signs and things, Borgmann opines, “No design can specify its realization fully. To convey exactly as much information as the thing realized, a design would have to exhibit just as many features as the thing. But then it would be a duplicate of . . . the thing” (p. 113). That is, a fully realized (or fully imagined) thing must necessarily lose fidelity when it is condensed into a sign. Borgmann’s insight here is the very principle that makes indexers, abstracters, and information architects necessary. Many library users, and information consumers in general, need to know what they’re accessing before they access it. But to know exactly what a journal article says without reading the article is impossible by Borgmann’s principle. Users, then, need a general idea of what an article says – a low-fidelity version of the article. The job of an abstracter is to reduce a cataloged item (a thing) to an abstract of a more digestible length (a sign) with minimal loss of fidelity. A good abstracter makes it possible for users to make reasonable guesses about where a sign points without having to walk down the indicated road and see for themselves.

Labeling components of an information architecture is precisely analogous to abstracting media; it requires the same faculty of condensation, and has much the same end in mind in terms of how the user is served. Yet one difference between information architecture and physical architecture, which is Borgmann’s subject in Chapter 10, is that an edifice, once built, is stripped of the cultural signs used in its creation. The low-fidelity artifice of the blueprint outlives its usefulness, and the building’s users rarely need a blueprint to navigate the building. By contrast, abstracts and labels within an information system are useful precisely because they are condensed, and are indispensable for users long after the system goes live. There seems to be a fundamental disanalogy here: we can apprehend a building with our senses, and hence we navigate a building with the aid of natural signs (like a luggage carousel in an airport or a blackboard in a school) as well as cultural ones, while an information architecture is invisible to the senses and we can navigate it only through cultural signs and the guidance of the architect. Exploring a building is inherently an interactive experience; exploring an information architecture is not.

I think that this idea – the idea that an information architect must also be an information tour guide, providing signs that are naturally deficient in an online environment – is a key to overcoming user frustration with website interfaces and layouts. Since we cannot be physically present to help our users with their needs, our indexing and labeling functions are crucial to this aim. Just as John Harrison’s robust mechanical clock effectively condensed the vast grid of the world map into a longitude (p. 78), our navigation tools need to clearly help the user locate herself within the architecture; and rather like that map’s rigorous grid makes the sign revisable to match the thing, we should be ready to relabel our websites in a way that better matches the thing, or even revise the thing to match user expectations. This last possibility – the ability of the information architect to revise online reality for the convenience of the user – is probably the most exciting aspect of information architecture, and it might well be the subject of Borgmann’s Part 3, subtitled “Information As Reality.”

Week 6.1: IA drafting

This week’s reading: Morville & Rosenfeld, Chapters 12 and 13; jjg.net; semanticstudios.com

I’ll be dividing this week’s response into two blog posts. This first post represents my first stab at practicing the design skills described by Morville and Rosenfeld; I’ve drawn a partial blueprint for the website Wiktionary.org. Please click to view the large version.

This blueprint is necessarily far from comprehensive, but it effectively shows how a user can navigate Wiktionary from either of two access points: the front page or the page for an entry. I’ve used the same visual vocabulary as the examples in the textbook: gray boxes represent pages, white boxes show components of a page, stacked boxes show collections of pages, and dashed rectangles show groups of interrelated pages. It’s imperfect, but in the process of making it I had to think about what components of a page actually need to be represented in a high-level blueprint, and in what cases it might be acceptable to show representative examples rather than every content area and hyperlink.

Week 4: Ups, downs, and in-betweens

This week's reading: Morville and Rosenfeld, Chapters 7, 8, and 9

While last week’s reading discussed how the interface should be built and named, this week we focused on how the user will interact with the interface. How will he find his way from one organizational chunk of our site to another? Will it be through browsing or through searching? How will we enable him to browse and search effectively without requiring him to become an expert on our website or on information science in general? There’s a lot of meat here, and the answer to each question is almost always “it depends,” but there’s a pattern to best practices that seems to illuminate a fundamental issue in designing IA for the user.

To illustrate this pattern, let me take examples from the chapter on navigation and the chapter on controlled vocabularies; I will draw parallels between them. In designing a classic thesaurus, the designer first identifies a preferred term for a topic (Cougar) and explains the content of the topic using scope notes (Cougar SN Felis concolor, a large predatory cat native to the Western Hemisphere). The thesaurus maps the term’s variants to the preferred term in the manner of an authority file (Mountain Lion Use Cougar); it also links the preferred term to the next broader term in its hierarchy (Cougar BT Cat), as well as to any narrower terms (Cougar NT Florida Panther). The thesaurus may also note terms that are qualitatively associated with the main entry, as determined by the compiler or by software (Cougar RT Jaguar). In sum, the thesaurus traverses several kinds of relationships (equivalence, hierarchy, and association) in trying to make sense of a search input or otherwise guiding the user to his endpoint.

Compare this straightforward if technical design of a thesaurus to the design of a website. When the user sets out to navigate a large website, the website is usually well served to provide him with global, local, and contextual navigation tools. The global tools move the user up in the site hierarchy, not unlike the “broader term” relationship of a thesaurus. Global navigation is unlike BT in that the user of global navigation can quickly navigate to a different area of the site entirely, while BT by design only connects the user to the next most chunked classification of the term he is already viewing, but both tools share the purpose of giving the user a way to see something more general.

Local navigation tools move the user within the subsite or site section he is already viewing; for example, within Amazon.com’s section on video games, a local menu allows the user to view games for the Nintendo Wii or Xbox 360. If the user clicks on Wii, another local menu prompts him to select a genre of video game. The process is analogous to the classic thesaurus’s “narrower term” relationship: both the local navigation system and NT serve to help the user find something more specific.

Contextual navigation tools most often take the form of hypertext links in the content. Users expect that the text of such links describes the content of the linked webpage. Designers insert hyperlinks when they need to escape website hierarchy and move laterally to pages that are related to the current page’s content. This type of navigation is analogous to the classic thesaurus’s “related term,” in that contextual navigation and RT each serve as a catch-all; they take the user to a place that is related nonhierarchically.

(It’s worth noting as an aside that navigation systems do not generally have a precise equivalent to the thesaurus’s equivalence relationship, because organization is unique and language is not. Some advanced navigation designs do admit parallels to equivalence relationships, but this discussion is tangential to the main point of this entry.)

Clearly, website navigation and thesaurus design have something in common. The commonality lies in how information can be related – broader, narrower, associated – and the likelihood that the user will want to move along one or more of these lines from one idea to another. This mostly-hierarchical relationship makes the organization of a website or a thesaurus transparent, allowing the designer to apply labeling skills to express its contents in a way that the user can readily navigate. I am left, however, with the question of whether hierarchy is uniquely suited to these tasks, or whether information can be organized in a way that is nonhierarchical and yet coherent. Morville and Rosenfeld gesture in this direction with their discussion of tag clouds, which resultantly seem to be a rich resource that semantic web software could use to guess what terms are related. Though creating clear and easily navigable hierarchies is obviously central to information architecture, I’ll remain alert to situational alternatives to the hierarchy that may present themselves!