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 3: It looks nice, but does it work?

This week’s reading: Morville and Rosenfeld, Chapters 5 and 6

Our reading this week focused on two interconnected topics: how to conceptualize and group the organizational items of a system, and how to choose words or labels to represent them. It was an exciting pair of chapters, because the effectiveness of an information system like a website submits to empirical testing. That is, broadly speaking, it is actually possible to decide which of two possible schemes is better, in the sense of helping more of the users more of the time. In this comment I’ll focus on how we might apply empiricism to the ideas described in these chapters.

The text outlines organizational schemes appropriate for both exact and ambiguous searches. To use the language of my last entry, “fully realized” questions can be answered with straightforward schemes like alphabetical or chronological arrangement of data, but “fuzzy” questions – or items of information that fall into “fuzzy” categories – require more creativity in their organization. Most of the textbook’s examples of good interfaces give the user several access points in these ambiguous cases. Dell’s website (p. 65), for example, allows its customers to browse by topic (notebooks, desktops, support) or by audience (home, small business, government). A multiplicity of access points is likely to help some users and confuse others. Site analytics might help Dell empirically determine whether the former outnumber the latter.

A relevant metric of effectiveness might be the number of visitors who click on Dell’s topic links versus its audience links. A priori, I would expect that few visitors click “Home & Home Office” from the audience menu; these users are likely to have a more clearly defined need, and thus are more likely use the topic links. If analytics bear out this intuition, Dell should consider eliminating this hyperlink from its audience menu. Conflicting with this impulse, however, is the principle of comprehensiveness (p. 100): if we have special links for business and government audiences, shouldn’t we have a special link for home audiences? Retaining the “Home & Home Office” link might improve the menu’s consistency and thus help the user build a mental model of the Dell website, even if the link is rarely used.

The challenge, then, is to design an empirical test to settle the question of whether our little-used link contributes more than it detracts. A first approach might be to recruit a panel of diverse users, each with a genuine need. Through an automated survey, the website could prompt users to articulate their need. Half of these users could be directed to Dell’s usual site, while the other half are directed to a version of the site with the questionable link omitted. Their progress through the respective designs could be tracked and their success quantified through an exit survey. If one version of the site connects users with content with significantly higher consistency, and no intervening factors such as internal politics intervene, Dell should adopt the more successful architecture. This approach could be tested on micro aspects of design, such as whether to include a particular hyperlink, or on macro aspects, such as an entire top-down site redesign.

The Dell homepage reprinted in the book is dated 2006. I note with interest that in the intervening four years, Dell has given its site a complete revamp – consistent with the textbook authors’ emphasis on ongoing improvement. In 2006, the topical menu had pride of place on Dell’s site, while audience was relegated to a small-type menu of hyperlinks. By contrast, in 2010, the audience menu is splashed prominently across the top of the site; mousing over one of the labels (“For Home,” “For Small and Medium Business,” and so on) drops down a topic menu pertaining to the audience. This integration combines the advantages of both menus in a seamless way that is intuitive to Net-savvy audiences, though empirical testing could be useful to determine whether this two-layer sorting of content might be confusing to Internet novitiates.

Dell’s changes to its labels also merit attention. In 2006, the audience menu was headed “Solutions for:”, and its items were “Home & Home Office,” “Small Business,” “Medium & Large Business,” and “Government, Education, & Healthcare.” In 2010, the audience menu has no heading. The mouseover points are labeled “For Home,” “For Small & Medium Business,” “For Public Sector,” and “For Large Enterprise.” Three changes are interesting here. First is the change to the format of the list’s items. “Solutions for” rings of corporate jargon, which the text’s authors warn against (p. 85-86); Dell’s new formulation sounds much more natural. Second, we see that “Public Sector” has replaced the unwieldy “Government, Education, & Healthcare.” The latter choice is more descriptive, but the three indicated subcategories are heterogeneous; clicking this link is likely to lead us to a narrow, deep architecture where we’ll have to further specify that we work in education, then that we work in K-12 education, and so on. Public Sector, by contrast, denotes the same services more transparently – the label is effectively invisible to users who don’t need it – and the drop-down menu allows much of the disambiguation to take place in one click. Finally, we see that medium businesses have been reclassed with small businesses, while the term “large business” has been replaced with “large enterprise.” This could be an organizational change, but it’s more likely to be a labeling change; Dell has likely determined that its services for large businesses are disparate with the needs of medium-sized businesses, and has relabeled its categories to guide medium-sized business owners to the content most likely to be relevant to their need. The choice of the word “enterprise” in particular is clearly a labeling decision. “Enterprise” is an uncommon word whose connotation of scale may further help medium-sized business owners decide which menu category to pursue. All three of these changes have implications for the site’s overall architecture which could be user-tested by an experiment something like the one I described earlier.

My point in this entry is that IA guidelines are often useful, as when they suggest that we avoid jargon, but that site analytics and empirical testing are the ultimate tests of whether a site serves its users as envisioned. A building can be beautiful but uncomfortable, and a textbook-compliant website might still fail its users. In my first entry in this blog I discussed my view that interaction design is the parent discipline of information architecture. If so, then empiricism is the means by which we can determine whether IA is a properly dutiful child!

Week 1: Definitions, and notes on taxonomy

This week’s reading: Morville & Rosenfeld, foreword through Chapter 2

I’m coming to the study of information architecture without formal experience in computer science – but I do have the important qualification that I’m a child of the Information Age. At various times in my life I’ve been a hobbyist computer programmer, an avid websurfer, a small-scale webmaster, an online forum administrator, and a student of library science. Each role has exposed me to what I now understand to be IA from a different perspective, and now that I’ve read a couple chapters on the topic, the meaning of the phrase “information architecture” has begun to fall into place.

While attaining my bachelor’s degree at the University of Chicago, I had the good fortune to become acquainted with a software engineer with a special interest in interface design. Through his website and blog, as well as my conversations with him, I learned some of the basic issues and philosophies surrounding software usability; most importantly, I became firmly convinced that most end-user frustrations should be blamed on poor design and not on user incompetence. As a result, I understand information architecture primarily as a branch of interaction design. A good design is by definition a design that is usable and humane – respectful of the needs, frailties, and limited patience of our users. Though outside constraints such as budget and institutional culture may sometimes trouble our pursuit of such a design, good information architecture should place the user first as often as possible. If a design is not usable, it is nothing.

Our book would interject here to point out that interaction design is far from the only discipline related to IA. Pages 10 and 11 usefully summarize the points of tangency between IA and a number of other fields of study. At this phase of my nascent understanding of IA, however, I can’t help but think of these as allied fields to IA, while interaction design is its parent field.

Consider, for example, a now-commonplace but once-striking implementation of information architecture: Gmail’s conversation-based system for organizing and displaying email. In the days of yore, way back in 2003, email services invariably displayed emails one message at a time. Messages were prefixed by a potential infinity of iterations of RE: and FWD:, and the contents of a protracted email exchange might be spread across several pages of a user’s inbox. Gmail changed that by sorting all emails with the same subject line into one conversation, the whole of which can be viewed at a click. This design choice is clearly an act of information architecture, since it changes the nature of Gmail’s information environment through tweaking the organization and navigation of email.

Clearly, conversation-based email grouping would have been impossible without the software developers who coded it, the graphic designers who concretized it, and the usability engineers who optimized it – but it wasn’t for any of their sakes that such grouping was invented. Conversation-based grouping was invented for the sake of interaction design. Gmail’s information architects implemented the new system because it improved user interactions with email software. Users could find, digest, and act on information more easily under the new system than under the old one. This is the exact goal of information architecture. Viewed this way, IA’s status as a subfield of interaction design could not be more apparent.

Going forward, I’ll continue to focus on how good information architecture addresses user needs. At the same time, I’ll stay alert to other issues raised by the readings, such as the question of how architecture shapes the people who dwell within it. Morville and Rosenfeld raise this question through Winston Churchill at the beginning of Chapter 1, and it’s not an unfamiliar one. Educators wonder whether the instant availability of certain information via Google and Wikipedia has changed how we learn; business owners struggle to understand and accommodate the expectations of a generation brought up with social media; and legal professionals are in the midst of a seismic organizational realignment brought about by the Internet’s liberation of legal materials from the monopoly of West Publishing. We will find the evolution of information architecture at the origin of all of these changes, and it is IA – rooted in the needs of its residents – that we will use to shape the future!