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.