Week 12: The IA That Quashed a War

This week’s reading: Burnett & Marshall, Chapters 8 and 9 and Conclusion; Borgmann, Introduction and Part 1

Borgmann’s reading this week promises to grow into a rigorous information-science foundation in which to root information architecture, and next week I’ll begin examining the conjunction of his work with IA. For this week, though, I can’t resist the provocations of Burnett and Marshall as they describe the distinctive characteristics of the online music industry. Since they wrote too early to see the evolution of the iTunes music store, I’ll apply some of their ideas to iTunes and see if any characteristics of online music consumers can be extrapolated.

Burnett and Marshall sum up their critique of the music industry’s response to Napster in three points (p. 193). The first and second are closely related: they are the industry’s underestimation of the impact of the Internet on their business, and the studios’ choice to see MP3 and Napster as threats and not opportunities. Both points exemplify a mistaken and unprofitable philosophy of change: “How can we continue to do business as usual as everything changes around us?” Studios, like other businesses (and like libraries), ought instead to have asked, “How can we stand at the vanguard of this change and be ready when mainstream consumers demand digital services?”

The studios never did develop their own business model to deal with MP3s; other entrepreneurs did it for them. KaZaA, YouTube, and the Pirate Bay have each tolerated or encouraged widespread piracy in their attempts to develop commercial models that would flout the studios entirely. Pandora, Rhapsody, iTunes, and others have taken a different tack, negotiating with studios for the right to play or out-license their songs legally. Stores like iTunes have effectively stepped into the digital niche of the physical retailer, doing the work of salesmanship while artists and studios produce new work to license.

Why iTunes took so long to appear on the music scene is a question that would consume a much longer paper than this weekly response. In large part, however, the answer must be that studios hoped that the Internet and its challenges would go away and leave them to their profits of the 1990s. Even today, studios’ willingness to license music online is only grudging, and came about from desperation to steal market share back from pirate sites rather than from their own innovative proclivities.

But come about it did: piracy is almost as easy today as it was in the days of Napster and KaZaA, yet iTunes has crafted a successful business out of selling songs for $0.69 to $1.29. iTunes does well even though its songs are licensed and not bought. Whether studios and artists do proportionally well is, predictably, a matter of some dispute, but both Metallica and its label Elektra clearly make more money when I buy “Enter Sandman” from iTunes than when I download it from the Pirate Bay.

Why do music fans pay money for licensed music from iTunes rather than downloading music free of license from the Pirate Bay? I suspect that part of the answer – but only a small part – is that fans want to support the artists they listen to. Another part – but again, only a small part – is that fans fear retaliation for piracy, though anti-piracy lawsuits against consumers are still uncommon. The most important part of the answer, by far, must be that iTunes is a nice piece of software. The architecture of iTunes and its store encourage easy navigation, search, and downloading in a way that pirate sites do not. iTunes’ built-in ability to organize and play music likewise advantages it over the Pirate Bay, which operates strictly on a bring-your-own-software basis. In the end, the copyright wars between studios and fans have calmed not because of legal settlements – still ongoing – but because of great information architecture that makes fans able and willing to pay for music.

Perhaps the conclusion of this week’s reading, then, is that when an Apple information architect is asked what he does for a living, he might answer “I end copyright wars!”

Week 9: The Architect's Garden

This week’s reading: Morville & Rosenfeld, Chapters 20 and 21; Burnett & Marshall, Chapter 1

Three diverse readings this week! The Burnett & Marshall chapter seemed to pivot away from information architecture and into the role of information technology in society. This is a legitimately fascinating topic, but the first chapter read like a fifty-page master’s thesis condensed by force into fifteen pages; interesting models and taxonomies are introduced only to be immediately abandoned without real exploration. This week I won’t worry about Web Theory, but instead will indulge myself in a case study. Riffing from Morville & Rosenfeld’s Chapter 21, I’ll talk about a social problem encountered by the users of an Internet forum I help administer, and explain how we used information architecture to solve it.

The forum in question, In the Rose Garden, has about 700 members, of whom several dozen are active contributors. Users are bound by our common interest in the Japanese anime “Revolutionary Girl Utena,” whose immense literary merits – though outside the scope of this blog – have proven multifaceted enough to sustain analysis and discussion throughout the three years of the forum’s existence. Three volunteers, including myself, administer the forum; most commonly, administration involves some routine content maintenance (dealing with multiple threads on the same topic, for example) and keeping an eye out for interpersonal conflicts on the boards.

Though IRG members are brought together by Utena, the bulk of activity on the forum does not directly pertain to the anime. Sampling a few popular threads would reveal political and social discussions, sharing of other anime, airing of college angst, and conversations about shame, anger, and joy. The most frequently trafficked threads, however, are “forum games.” Forum games are threads in which posts follow a simple set of rules – one thread might ask posters to add two words to a developing story, while another is dedicated to the results of a personality quiz. These games, as played on IRG, are usually more reflexive than thoughtful, but they’re easy to join or to post to, which accounts for their disproportionate popularity.

In 2009, the proliferation of forum games grew to the point where many users on IRG perceived them as an unwelcome distraction. Because of their popularity, forum games were usually ranked highly on the chronologically-sorted thread directories, burying more serious or intimate threads in the same category. After experiencing the problem firsthand for months and receiving a few user complaints, I concluded that forum games were inconveniencing many users and stifling other threads. Banning such games, however, was not an acceptable solution; forum games are good social looseners, serve as an access point to IRG for many new users, and – most of all – make many of our users happy, even the ones who also want to be able to find and post to more serious threads.

The solution – obvious in hindsight – was a change to IRG’s organization. In consultation with the other administrators, I created a new subforum that would be devoted to forum games. The subforum was accessible from the front page of the forum. Migrating all the forum games to a single, dedicated area of the site addressed the problem in several ways, but they all boil down to usability. Site users after the change were able to easily identify what section of the site would contain the kind of thread they were looking for. Those who wanted to quickly join a forum game knew where to do that; those who wanted to have a thoughtful conversation weren’t distracted by the game-driven irrelevance of top results in other subfora. The number of clicks needed to access any given thread was constant before and after the change.

As might be expected, the investment of time needed to implement this change paid off in a big way. Forum games continued to thrive in “captivity,” while threads elsewhere enjoyed renewed popularity. I didn’t know it at the time, but I was doing information architecture: designing a website to meet the needs and expectations of its users in an efficient and organized way.

One footnote, apropos of Morville and Rosenfeld’s allusions to the unique aspects of the evolt community in Chapter 21: Many IRG users have a strong preference for either forum games or discussion, and rarely participate in the unpreferred category. From an IA perspective this strengthens the case for the change we made, but at the time the administrators worried that segregating forum games might be tantamount to segregating users. Our small community is tight-knit, unlike the communities of many large Internet forums, and we were concerned about the social impact of “marking” forum games (and, implicitly, their players) in such a visible way. Though the change certainly did not rend the social fabric, I’ve informally noticed that crossover between forum games and other threads has seemed less frequent in the ensuing year. A few game players whose activity previously spanned the forum have settled into their new subforum and rarely emerge from it. Fortunately, there are several others who still bridge the gap, and IRG has not diverged into two unconnected forums.

So much for my belief that IA is a totally new subject for me. It turns out that I am, in fact, an experienced and successful information architect!

Week 7: Case Studies In Why We Need Information Architects

This week’s reading: Morville & Rosenfeld, Chapters 14 – 16

Our reading this week covered a number of “small” topics within information architecture. The authors’ writing was as engaging as always, but I don’t have much to add with respect to their subject treatments, so I’ll focus in this entry on the information architecture of Google Sets and Textmap.com.

I’ll begin with Google Sets. I went in expecting a very classy information architecture; Google, after all, has reams of experience designing IAs and first rose to prominence in part because of its clean, easy-to-use interface. I had mixed luck with Google Sets as a search tool – it managed to complete a list of Greek moon goddesses, but not a list of recent U.S. presidents – but the effectiveness of the search algorithms that power Google Sets is mostly outside the scope of IA. I noted, however, that Google Sets also failed to return any results given the names Sleepy, Dpoey, Bashfull, and Dock [all sic]. Basic spell-checking is part of the domain of IA, a relative of controlled vocabulary, and Google Sets ought to have been able to reconcile these misspellings.

On a related note, on those occasions when my searches returned no results, Google Sets gave some tips for more effective searching. This is good design – but I was surprised when the tips included “use the full name” and “try being consistent.” There’s no reason a search company with the resources, artificial intelligence, and processing power of Google shouldn’t be able to algorithmically guess that “Harvard” means the same thing as “Harvard University” even without a formal authority file. From such experiences with this tool’s limitations, I’d have to say that Google Sets doesn’t live up to its potential as what could be an interesting tool for finding related keywords for the purposes of tagging or building a controlled vocabulary.

From a navigation perspective, Google Sets is also faulty: to my surprise, I discovered that there is no way to revise one’s search from the results page – a mortal sin in a search engine! To end on a positive note, though, I enjoyed the metaphor of the Google Sets front page, which precedes each search field with a bullet point. This visual shorthand for a list effectively conveys what the user can do with this tool.

From Google Sets we turn to TextMap. TextMap’s IA is frankly baffling. Its “entity pages” are full of fascinating-looking metrics presented without explanation. Better labeling needs to be brought to bear on this site. At the very least, the user needs tooltips; the entity pages offer no explanation, for example, of what a “polarity rank” or “negative raw count” is. The former is defined in the site’s “Frequenty [sic] Asked Questions” – it involves whether the subject is regarded well or poorly – but there’s no indication of how TextMap makes that determination. Similarly, each entity page contains a “relational map” that links the central entity to related ideas, but there’s no way to know what prompts the relationships. The page for “cat,” for example, links the word to “Yusuf Islam.” I had to Google to figure out this relationship: the famous singer-songwriter Cat Stevens is a convert to this Islamic sect. Yet the “cat” page is clearly defined by TextMap’s terse scope note as “animal,” not “person,” so why do links pertaining to Cat Stevens appear here? The “cat” map also links to the name “Sparky,” and I still don’t know why. Each box in the relational map has a different shape – rectangle, oval, or hexagon – but no key is provided.

To draw lessons from the above, it seems that what we have in TextMap is information without architecture. No organizational skeleton puts content elements in a coherent order; no labeling scheme elucidates meaning; navigation is mostly unassisted by common conventions such as hyperlinking or a side menu; and even the search function is poor, failing to deliver the user directly to the desired page even when an exact match is found. Without architecture, the structure falls to the ground. I can’t think of a purpose that I’m confident TextMap would reliably serve.

One bright spot in TextMap is its fairly conscientious vocabulary control in the form of synonym rings. Sony’s entity page, for example, contains some forty synonyms with various permutations of capitalization and punctuation, including “SONY CORP.,” “Sony LLC,” and “Sony Electronics, Inc.” Not every permutation is covered, but the range is quite broad for a home-brewed project, and there are enough variations that a searcher could readily find the page by entering even an inexact synonym.

These two websites, then, each offer lessons in what not to do in building an information architecture. Google Sets reminds us of the importance of vocabulary control to help software make logical inferences about the user’s meaning; TextMap reminds us that data needs to be illuminated by architecture before it can properly be called information.

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 3.5: The information architecture of lib.usf.edu

The previous post is my "official" entry for the week, but I thought I'd cross-post the following from a discussion board entry of mine in LIS 6260, which I'm taking concurrently with this course. The question concerned how libraries can help users get the most out of electronic resources. I applied this week's readings to the question:

IA exhorts us to think about how we present information. For example, on lib.usf.edu, we've made a number of good layout decisions. It's easy to find crucial information like hours and contact information, and we have a mostly well-organized set of hyperlinks in the body. But we've also made some questionable decisions. Why are links to Articles and E-Journals, which are information sources, in the same menu bar with links to ILL and Help, which are services? Why does the link labeled Books take us to the library catalog, which manifestly contains more than just books? Why do we redundantly link to the same pages under the heading Research Tools that we do in the menu bar, and why are the pages labeled differently in one place than in the other? These inconsistencies make it harder for users to build a mental model of the site. Other parts of the page seem to be designed for librarians rather than our colleagues in other fields whom we serve: What is the difference between a database and an e-journal? What is PRONTO? What is RefWorks? (For that matter, what is ILL?) Where will I go if I click on the Karst Information Portal? You won't find the answers to these questions without more clicking.

Anyway, my point is that our website's front page is not bad, but it could be better. The site doesn't do much to point a novice user in the right direction. Its flaws become transparent to veterans like ourselves, but there's a lot an experienced information architect could do to streamline and clarify it. We should *not* cop out by saying that instructors just don't give us the opportunity to teach students how to use the library. If our users can't figure out how to use our interface, the answer is not to ask our users to be more perfect, but to design our interface to be more humane.

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!