Week 14: Extraordinary Claims...

This week’s reading: Borgmann, Part 3

I had planned to use this final post to address Kellner’s criticism of Borgmann, but I can’t bring myself to. I agree with Kellner on many points, but – now that I’ve read Borgmann’s final section – it feels much more important to engage with Borgmann directly. Briefly, I think Kellner errs in finding Borgmann’s argument theological, but Kellner is correct insofar as he critiques Borgmann for arguing from bias rather than fact.

Borgmann errs frequently and badly in describing the vistas of virtual reality. Where Borgmann is factually wrong – as in his critique of computer photorealism on page 198 – his attitudes reflect a pervasive and unjustified pessimism about the power of technology, and where he is factually correct he draws judgments about technological information that are not grounded in those facts. His treatment of virtual information strikes a strange poise between encyclopedic surface knowledge and deeper ignorance. Part 3 of “Holding On to Reality” reads like a nuanced and valuable discussion of the social context and aesthetic forms of the popular music of the latter half of the twentieth century, only to conclude with a cantankerous dismissal of kids these days and their rock and roll music. Consider, for example, Borgmann’s striking statement that the virtual ambiguity of MUDs “renders virtual reality trivial, and, when pressed for its promise of engagement, evaporates” (p. 190). This implicitly moral judgment is preceded by a careful objective examination of the information environment of MUDs, but not by any grounds for condemnation, and the same is true of Borgmann’s subsequent writing off of online relationships as mere “virtual vacuity” (p. 190). Similar argumentative structure is echoed throughout Part 3. Borgmann relies on intuition rather than evidence to make his broadest points, and while such bald assertions may be effective when preaching to the choir, they are less so when trying to convince an undecided audience such as myself. His proclamations about the loss of intelligence, thing, and context in the virtual environment, even if true, repeatedly made me wonder aloud, “So what?”

Borgmann does not get around to answering that big question – “so what?” – until his conclusion, where he starkly warns, “The preternaturally bright and controllable quality of cyberspace makes real things look poor and recalcitrant by comparison” (p. 216). This is precisely my own worry about information technology – the reason I have felt sympathetic to Borgmann throughout the reading. But his final bases for this assertion, like the dreariness of science fiction novels and the basic seductibility of human beings, are themselves not obvious and are certainly not grounded in Borgmann’s study. Indeed, in some areas, from art to war, virtual information sometimes seems to have given reality a heft that previous generations did not always have the chance to acknowledge. Reading the final pages of the book gave me the same sinking feeling one experiences when one’s favorite sports team commits basic errors of play, or when a normally eloquent advocate of one’s own political view stumbles badly in an important debate. If the central question of “Holding On to Reality” is whether it is worse to experience information virtually than to experience it through nature or culture, and the book represents the best argument that can be made in favor of the answer “Yes,” I can hardly blame society if it answers “No.”

With all that said, Borgmann succeeds in making me want to engage more with reality, even if he fails in convincing me to promote this engagement as a cultural rule. And some of his closing ideas, like his worry that the “sheer disorganized and imposing mass” (p. 230) of hyperinformation will guarantee its future loss, have profound resonance for information architects. In a world where people’s preferred way of engaging with information seems likely to remain irremediably virtual, information architects have the momentous task of preserving that imposing mass of virtual information in a usable form. If, because of the nature of the information or its environment, we aren’t able to situate that information in a reality beyond the virtual, I don’t think that makes us contemptible; our mission is merely to organize, present, and expedite. But if we are able – if we can encourage our users to relate deeply to the information they’re gathering – then we will certainly have done our society and our users a subtle service.

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 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 6.2: Intuitive architecture

In this post I’d like to briefly engage with Jesse James Garrett’s ideas about empiricism in his 2002 essay “ia/recon.”

Garrett’s attitude towards IA research, especially in Parts 3, 4, and 6 of his essay, can fairly be characterized as dismissive. Garret emphasizes that information architecture is an art, and that its practice is heavily informed by intuition and “hunches” rather than user research of the kind described by Morville and Rosenfeld. He bemoans the necessity for information architects to justify their decisions to their superiors by means of usability studies, which he believes inhibits the discretion of the architect. Research, he says, should not be used “to tell us what to think.”

At first glance, Garrett’s attitude seemed very much at odds with the user-centric approach to IA advocated by Morville and Rosenfeld, and which I’ve invoked repeatedly in this blog. He also seemed to be waving off empiricism in general, which is a special interest of mine in IA and information science more broadly. On closer examination, however, this reading of Garrett misunderstands the core of his argument. He does not disown empiricism. In fact, he says that research “can be extremely useful in cases where user goals can be clearly identified and measured,” giving e-commerce and information retrieval as two examples. But almost all of the examples of IA we’ve studied in this course fall into these categories! No wonder the thrust of Morville and Rosenfeld’s work, with its special focus on e-business, is so different from that of Garrett, who seems to make the “user experience” – a subjective and difficult-to-measure criterion – central to his work.

Based especially on Garrett’s article in the DMI Review, I’m convinced Garrett is just as user-centric as I am. The difference is that I’m interested in metrics – did the user accomplish what he came to the site for? how long did it take? what menus were useful and useless? – while Garrett plumbs the strange and equally interesting depths of how to create emotional and sensory reactions to a website. Science is no more useful in Garrett’s pursuit than it is to an artist seeking to find a formula for how to paint pathos. His skepticism about empiricism is thus unsurprising and appropriate, and our points of view are compatible.

What’s perhaps most surprising about Garrett’s ideas is the notion that creating an emotional experience is the purview of an information architect, as opposed to a graphic designer or another engineer closer to the end user. I’ll keep an eye out for the aspects of IA that fall outside the proper domain of empiricism as the course continues!

Week 5: My first car

This week’s reading: Morville and Rosenfeld, Chapters 10 and 11

This week’s reading was more of a challenge than that of preceding weeks. Morville and Rosenfeld’s writing is perfectly clear; the problem is that I lack a frame of reference to instantiate into the general ideas they discuss. When our authors talked about issues of organization and navigation, I understood using my experience as a website user, but I’ve never architected a large website or intranet, nor participated in an architecture project run by someone else. As we move from product to process, therefore, I feel like an Amish teenager reading a Chevy owner’s manual: I just don’t have a way to situate the information and transmute it into knowledge.

The best way for the Amish teenager to address his confusion is to get inside a Chevy, and the best way for me to address mine would be to design a website, perhaps collaboratively. A first-person account of the decisions that went into building a hypothetical website might make a compelling term paper. The objective would be to produce a design that could be confidently handed off to the coders, along with some exploration of how I would review and administer the coders’ work. To elaborate on the research phase, I could identify relevant sites to benchmark my own project against, and I could even conduct some simulated user testing with the help of volunteers. The strategy phase would include some interesting visuals as I constructed metaphors, wireframes, and other tools for conceptualizing and rendering the information I wanted to present. This idea doesn’t match the usual notion of a “research paper,” but in a broader sense, a hands-on project like this would foster the clear understanding that is the purpose of research. I’ll be emailing Dr. Simon about the acceptability of this topic.

Consistent with this blog’s focus on empirical user-centrism, the most interesting part of the reading to me was the section on users and how they can be deployed in the research and strategy phases of site building. I was unfamiliar with the technique of card sorting, a thought-provoking means of recruiting users to help build taxonomies. I imagine that an information architect up to his or her neck in data, content, and bureaucracy might easily lose perspective on what categories belong together – or might simply have a different perspective than the future users of the project, who may be professionals in an industry that the architect is only now exploring. Card sorting could remedy that lack of perspective. However, I tend to agree with the authors that such studies should not be taken too far. Elaborate “affinity models” based on a few data points hide significant statistical uncertainty; what is more, users do not always know what they want and their responses may exhibit systematic bias of various kinds. In the authors’ Weather.com example, I would expect that card sorters would be moderately unlikely to group “gardening” with “stargazing” (p. 281), even though both tasks fall into the category of “reasons people care about the weather.” In the final wireframe in Figure 11-10 (p. 285), a wide number of disparate ideas are unified under the “How Will the Weather Affect Your...?” banner. It’s a solid model, but it seems likely to me that this was a top-down decision springing from the architects’ creativity and content research, not a bottom-up decision based on card groupings.

Gratifying in the reading was the discussion on before-and-after benchmarking, which bears some resemblance to my Week 3 idea of setting up two different web designs and testing user efficiency separately in each. This method is deeply empirical, making use of the scientific method to generate information that is independent of the intuition of either users or architects. The importance of intuition and creativity is not to be understated, but in the end, we would like to have a way to know whether we did our jobs right!

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 2: What do spam filters and information seekers have in common?

This week’s reading: Morville & Rosenfeld, Chapters 3 and 4

In Reference 101 – known to USF’s SLIS students as “Introduction to Information Sources and Services” – I was taught that a patron’s inquiry could be broken down into elements called givens, wanteds, and modifiers. Givens were delimiters of the domain of interest: for example, a query might concern one-armed baseball players. Wanteds were what the patron sought: the name of such a baseball player. And modifiers were restrictions on the form of the output: it must be a webpage in English.

This week’s reading convinced me that the given-wanted-modifier model cannot cope with much real-world information seeking, at least not in a single application. The idea that all or even most patrons come to the reference desk with a fully realized question that can be answered completely and concisely – “his name was Pete Gray” – is a chimera. A great deal of information seeking cannot be phrased in the form of a question, and the information need is not “answered” so much as iteratively fed and refined until the seeker achieves a subjective satisfaction with the outcome.

There is something deeply secret and human about this vision of a subjective, iterated, fuzzy search for information. I’m instantly put in mind of Bayesian probability, which finds its most widely recognized use in email spam filters. Using logic believed to be humanlike, these filters read incoming email and assign a probability that the email is spam based on whether its characteristics – its words, formatting, origin, and so on – resemble those of known spam messages. Critically, the output of Bayesian filters is linked to its input; users and administrators identify the filter’s blown calls, and the filter adjusts its notion of “what spam looks like” based on its mistakes. After enough iterations, the filter arrives at heuristics of satisfactory accuracy. (My email filter has correctly classified each of the last five hundred messages I’ve received as of this writing.)

Why this discursion? Because one way of viewing an information seeker, a way I believe the text supports, is to see them as a well-developed Bayesian machine for identifying relevance. A middle school student who needs to write a two-page biography of George Washington may not be able to identify exactly what information she’s looking for, but given a choice among webpages entitled The George Washington University, George Washington’s Mount Vernon Estate, and The Life of George Washington, she will immediately identify the third as the most likely to be relevant. A more advanced searcher might gravitate towards websites with names like EnchantedLearning.com, which are likely to present highly relevant information in a format designed for students’ ready comprehension, or AmesLab.gov, whose .gov domain connotes cognitive authority. A good traditional search engine should support searching and browsing of results based on these characteristics. Analogously, the information architecture of a website should play to the Bayesian heuristics of the human mind; whether presented as one-word taxonomic labels or paragraph-long synopses, metadata needs to help the user take a quick glance and accurately judge whether the data will be relevant.

What is more, information architecture should support the iterated refinement of a user’s understanding of her own objective. When our middle schooler finds information about George Washington’s service in the French and Indian War, she will need to contextualize this new knowledge to determine its significance and its likely role in her paper. Her ideal history website might, for example, make a tooltip available that defined the French and Indian War in a single sentence – enough to assure her that this conflict must have been significant – as well as a hyperlink to more information, which would help her place the event chronologically in Washington’s life and outline his involvement in it in more detail. The tooltip pushes the information over the Bayesian significance threshold, and the hyperlink provides a natural avenue to continue the reunderstood seeking process. If one or the other is missing, the student may discard the information as irrelevant (in the first case) or obscure (in the second). Good architecture not only helps the user find “what she’s looking for,” but also helps her identify it.

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!