Understanding Context

by Andrew Hinton

  For environments that depend on semantics, information architecture determines the invariant, nested structures that act as the river’s banks, the valley, the surrounding hillocks, and which way is north. The continual, ever-shifting challenge for information architecture involves finding a balance between order and resilience: establishing invariance necessary for understanding to happen, while providing flexible room for being human.

  Figure 19-3. The steps required on Google Plus mobile to post in the circle you’re already “in”. The test message I’m writing is “Will this post to Family only?”

  * * *

  [377] Kahn, Louis. (Twombly, Robert, Editor) Essential Texts. W.W. Norton & Company: 2003:254.

  [378] Fitzgerald, Andy. “Taxonomy for App Makers IA Summit 2013, Baltimore, MD,” (http://www.slideshare.net/andybywire/taxonomy-for-app-makers).

  [379] Captured with screenshots from YouTube: http://bit.ly/1z2CSQV

  [380] McCullough, Malcolm. Digital Ground: Architecture, Pervasive Computing, and Environmental Knowing. Cambridge, MA: MIT Press, 2004:47, Kindle edition.

  [381] ———. Digital Ground: Architecture, Pervasive Computing, and Environmental Knowing. Cambridge, MA: MIT Press, 2004:19.

  [382] ———. Digital Ground: Architecture, Pervasive Computing, and Environmental Knowing. Cambridge, MA: MIT Press, 2004:21.

  [383] Szalavits, Maia. “Do E-Books Make It Harder to Remember What You Just Read?” Time (time.com) March 14, 2012.

  [384] Flood, Alison. “Readers absorb less on Kindles than on paper, study finds” The Guardian (guardian.com) August 19, 2014 (http://bit.ly/11z8CCn).

  [385] Ingram, Mathew. “Twitter CFO says a Facebook-style filtered feed is coming, whether you like it or not” (gigaom.com), September 4, 2014 (http://bit.ly/1zvQrcI).

  [386] Resmini, Andrea, and Luca Rosati. Pervasive Information Architecture: Designing Cross-Channel User Experiences. Burlington, MA: Morgan Kaufmann, 2011:55.

  Chapter 20. The Materials of Semantic Function

  “When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”

  “The question is,” said Alice, “whether you can make words mean so many different things.”

  “The question is,” said Humpty Dumpty, “which is to be master—that’s all.”

  —LEWIS CARROLL, THROUGH THE LOOKING-GLASS

  My cow is not pretty, but it’s pretty to me.

  —DAVID LYNCH

  Elements

  TO ADDRESS HOW INFORMATION ARCHITECTURE COMPOSES CONTEXT, we need to look at what materials the practice requires for designing environments. What are the elements that it uses—the bricks and mortar, studs and joists—that create the joinery of coherently nested places?

  The material for information architecture is mainly the semantic function of language. Names, categories, links, and conditional actions are not just for organizing objects but for also establishing place and shaping systemic relationships for entire environments. We can distill these elements into three categories (Figure 20-1): Labels, Relationships, and Rules.

  Figure 20-1. My own take on the materials of information architecture: Labels, Relationships, and Rules[387].

  I’ve mentioned these in various forms in previous chapters, but bringing them together into a three-part list helps solidify them as a model.

  These three items loosely correlate with the three levels in a model developed by information architect (and colleague) Dan Klyn: Ontology, Taxonomy, and Choreography (Figure 20-2).

  Figure 20-2. Dan Klyn’s model for information architecture: Ontology, Taxonomy, and Choreography[388]

  I should note a few things about these models:

  These are general framing devices for helping us think through what we are making, and with what elements. However, I still recommend learning about the details—topics such as controlled vocabularies, synonym rings, metadata standards, and thesauri—from methods-based resources on information architecture and information science.

  I’m explaining the parts of these models in tandem, one pair at a time, because they resonate nicely with each other, but I don’t mean to fully equate them. Labels have a lot to do with ontology, and vice versa, but they’re lenses on how we locate specific meaning, not synonyms.

  There are other models for these ideas that I’m not including here.[389] They are all wonderful in their own ways. I encourage everyone to investigate them all and find the perspectives that help you most.

  Labels and Ontology

  Label: The word sounds deceptively trivial, like something we spit out of a grocery-store pricing gun. But, as Chapter 9 points out, labels are powerful, flexible devices that make it possible for us to have language at all, allowing us to create what philosopher Andy Clark calls the “new realm of perceptible objects.”[390]

  We could just as easily say “names” or “categories” or “classes” but these would be subsets of all the things we can mean by “labels.” A label can be something we add to a physical object, or it can be the mechanism we use to talk about something that isn’t specific or physical at all; for example a category, such as “jazz.” It can be the name of a person, a code for a concept, or a class in a CSS file.

  Clark further explains that “the simple act of labeling the world opens up a variety of new computational opportunities and supports the discovery of increasingly abstract patterns in nature.”[391] Labeling the world structures it beyond what the structures of physical information alone can support. Ontology is a way of constructing a fully defined label; taxonomy is a way of associating labels with one another in a system of meaning.

  Labels can be graphical or textual, or even gestures, but whichever way they appear, they function as language. We tend to think of labels as “extra,” because a thing is the same thing whether it has a label or not. Hopefully, though, our foray into context, cognition, and language has made it clear that labels are anything but merely extra. Labels change the experienced nature of the things they name and otherwise signify.

  For information architecture, labels are central. They’re the ingredients we use for categories and classification schemes. They’re the signifiers we use to represent the function and behavior of relationships and rules as well as the effects of digital agency. Even when we add longer text as instructional information, the instructions are finally just definitions for labels.

  In semantic interfaces, labels are also the environmental objects that get the attention of agent perception; users seek them out to pick up information about where they can go, how the environment is nested, and what objects and events are available there. Users look for structural cues from the graphical user interface, as well, but words are always eventually necessary for context.[392] Far beyond interfaces, the purposeful definition of every component and connection within a service, system, or organization requires the use of labels.

  Ontology is the way we establish the meaning of labels in semantic systems. As I’ve mentioned before, I’m not using the word in precisely the formal, technical manner or the conceptual, philosophical manner, but in a way that involves both. As Dan Klyn puts it succinctly, ontology is about “what we mean when we say what we say.”[393]

  Whether a formalized, technical ontology is necessary, there should be clarity about the semantic cornerstones that will set the alignment for everything else. Most organizations run on inherited assumptions and arbitrarily accumulated convention. They can stay in business for years, selling “product” to “customers” but never settle on what those words actually mean to the company. But, when their market is disrupted and complicates what their product is and who their customers are, the explicit definition of those terms becomes critical to survival.

  When companies invoke a metaphor such as “the funnel” for marketing and retail, or “cloud”—as in cloud computing—the term eventually influences the way those companies think about and design their services.

>   “Cloud” has become a particularly pernicious rubric in the last few years. What’s wrong with “cloud”? It obscures complexity rather than making it understandable.

  Consider Apple’s iCloud service. I’m often frustrated trying to understand how the places of iCloud work. For example, Figure 20-3 depicts a dialog box warning me if I turn off iCloud syncing for “Documents & Data, all documents stored in iCloud will be removed from this Mac.” I’ve encountered similar warnings when changing iCloud settings, and each time I’m struck with anxiety, trying to sort out the difference between “there” and “here,” and which documents on my laptop’s drive are “in iCloud” and which are on my hard drive. This message box does nothing to help me remember the specific location of my files. What if none of them are on other devices? Does it delete them entirely? If they’re on my laptop, why wouldn’t they just be left there, but disconnected from syncing with the cloud service?

  Figure 20-3. An ambiguous and not very helpful iCloud message box: iConfused

  According to one study, many Americans think cloud computing has something to do with actual clouds. Of the 54 percent of those surveyed who claimed never to use cloud computing, 95 percent actually do use cloud services without realizing it. When asked to explain what the cloud is, people tend to fake their way through the explanation.[394]

  Ontology is at the root of this problem. There’s no coherent invariant structure implied by the metaphor. In fact, cloud is an abdication of that architectural responsibility. It avoids the question of “where is my stuff, and what is happening to it?” by pretending as if no hard edges have to be understood—instead, the magic vapor in the sky will take care of it all for you. A cloud is, by definition, disconnected from the ground—it’s a nonplace. But the fact is, your information is definitely in one or more places, on storage media in server farms that take up acres of land and gigawatts of electricity. It has rules and boundaries associated with it, structures that most users do not see or understand. We can use buildings because we can see the joinery in them and the complexity of their structure. A cloud has no clear structure. Though it can be pretty from the outside, from within it’s just fog.

  One of the more troublesome terms to define online is “account.” Every place seems to need us to have an account, but an account is not something we can really point to or put our hands on. It’s another reified idea, because an account is really just language. We can use the term for just about any sort of business relationship, which is why we end up with something like Figure 20-4, which shows an example at Kohls department store’s website.

  Figure 20-4. Kohl’s disambiguation of “account”

  The word “groups” can also be a bedeviling bit of semantic architecture. In physical life, your body can only cluster with one group of bodies at a time, and there’s lots of tacit information about each group’s context. But online, there are only labels, links, and conditional rulesets that form the architecture of these groups. You can be logged in to many at once, and the only way to differentiate between them is through their display-based signifiers. Also, the structures and rules that make it a group can differ widely from one group to another.

  Google’s use of the groups label is widespread, as is amply demonstrated in Figure 20-5. There are groups that you can create in your Contacts for use in Gmail; there are Google Groups (based on the long-acquired Deja News, which was a UseNet mirror); the Groups in the Google Apps for Business email platform, like personal Gmail groups but for businesses and custom domains; and others. You can convert a Business Apps Email Group to a Google Groups for Business Group, but doing so is daunting and requires comprehending both administrative paradigms. All this is not to mention the new Google Plus dimension of Circles that now intersects most of the Google ecosystem.

  Figure 20-5. Just a few examples of groups among the many in the Google ecosystem

  Undoubtedly, Google has defined formal ontologies for all these species of group in their backend systems. Yet, Google’s environment struggles to establish coherent semantic function on the frontend, for human users. Data architecture does not equal information architecture, though each certainly depends on the other for user success.

  Making multicontextual structures understandable is a difficult architectural problem to solve, especially when adding multiuser access. What users need is for those problems to be solved, not ignored. Rather than pretending everything is “seamless,” we instead need well-crafted seams that we can see and understand how to use. In the words of Mark Weiser, one of the early pioneers of ubiquitous computing, we should make “beautiful seams” that transparently reveal the inner workings of these clockworks we now inhabit.[395] Our bodies can perceive how stairs work because of the structure implicit in the seams joining their surfaces. Likewise, semantic environments need seams that clearly indicate where and how one context joins to another. Seams demand the work of ontology, because seams are possible only if the edges of elements are defined in the first place.

  Relationships and Taxonomy

  Relationships are the associations between elements in an environment. A relationship is really an abstraction. Even with physical information, we don’t perceive relationships, per se; we perceive surfaces and objects, which are nested as layouts. But the context of one thing’s relation to another brings additional meaning for those elements.[396]

  Sometimes, it’s the nested relationships of superordinal to subordinal places and objects, as in a smartphone where an app is contained in a home screen, contained in the mobile device itself, all aggregating into the compound object we call “smartphone.”

  Moreover, sometimes these relationships are about the connections between separate objects or places. Ecologically, we evolved to depend upon these connections as stable paths. Thus, we tend to expect even our digital connections—from hyperlinks to API calls—to be invariant, even when we perceive only the outer effects of their digital inner workings.

  Just as a river can connect various cities with trade, digital connections can make relationships that entire markets depend on. Consider when Twitter changed its API in 2012, removing support for RSS and limiting the API’s usage by certain third-party clients: app developers who had depended on the old API as an invariant part of the environment found themselves without a product anymore.[397]

  To work with semantic relationships, we use signifiers that indicate what is related. These signifiers are also labels, with all the qualities of labels, as previously outlined. In user interfaces, we pay a lot of attention to these semantic signifiers because they have to do all the heavy lifting for expressing relationships. A bakery on the street can be called “Jane’s” on the sign, but the smell of bread and the baked goods in the window can do the rest of the work. Online, though, we need semantic equivalents of the smell of bread and the shop window, from the company name to the metadata for Yelp, Google, and the rest.

  In fact, with digital information, we can make relationships between things that we can’t even see but whose well-defined relationships are crucial for infrastructure. The relationships defined in database schemas are arguably now the majority of important semantic-information relationships in our world.

  Web-centered information architecture has long been concerned with hyperlinks and their relationships; but hyperlinks—though revolutionary in their own way—are only one way we establish relationships online or off. Here’s a question I find myself asking often in projects: in what way can information architecture use semantic information to shape and clarify the relationships between physical life and digital function? Starting with that frame of mind can open up many opportunities for great work, beyond hyperlinks.

  A general term we use for making relationships with language is taxonomy. There’s a common assumption that a taxonomy is always a hierarchical classification scheme—a “tree-shaped” structure, with the broadest category at the top, and subsequently narrower categories on the way down. That’s a common type of taxonomy,
but not the only one.

  Taxonomies are always semantic in nature, and they always have to do with the relationships between elements. But, they can take many forms, such as lists, hierarchies, matrices, facets, and even continuums or systemic maps.[398] Many of the models in this book are actually taxonomies, expressed as diagrams.

  The term comes from two Greek roots: “taxis,” which means the ordering or arrangement of things; and “nomos,” which is “anything assigned, usage or custom, law or ordinance.” In Organising Knowledge: Taxonomies, Knowledge, and Organisational Effectiveness (Chandos Publishing), Patrick Lambe defines taxonomy as “the rules or conventions of order or arrangement.”[399] Taxonomy creates relationships that arrange and order units of meaning. And, it can do so using an explicitly defined rule, or through tacitly emergent convention, or through some means between those extremes.

  Hence, taxonomies are the ways we arrange the world with language. They’re what we use to represent the physical and semantic information of our environment, creating structures and relationships, classifications and nested places. They’re the way we put joinery between semantic surfaces into the environment.

  Ontologies and taxonomies have a symbiotic relationship; arguably you can’t truly create one without the other. Ontologies require defining, and definitions are (by definition!) about relationships that give context to the thing defined; taxonomies have a hard time being very solid until at least some of the key terms in them have been well delineated, or else they can become too porous, absorbing generalities until they lose specific utility.