Subject First; Context Afterward

By | 2014/11/20

In communication, they say, context is everything. Actually, “everything” consists of context and subject. Useful information is subject in context. The question is, which comes first: context or subject?

In the book era, the content search pattern was: context first, subject afterwards. That is, suppose you deliver three different products and have released three different versions of the product. Assuming only a single manual per product/version that meant you had 9 manuals, each with a page on feature X.

So, how did the reader find the feature X page for the product they were using (let’s say, product B version 2). Simple, they looked at the only book they actually possessed, which was for the product they had bought: Product B, version 2. The context had been established for them when they brought the product home — long before they had searched for the subject. Context first; subject afterward.

But maybe they were a corporate customer, and there were many versions of the product in use at the company. How then would they find the right page on feature X? Simple: they would go to the bookshelf and search the spines for the manual on Product B, version 2. Then they would use the TOC or index to find the page on feature X. Context first; subject afterward.

But in the Web world, things work differently. In the Web world, the first thing the user is going to do is search for the subject. They are going to type “Feature X” into Google or whatever search engine is available to them. And they are going to get the most highly rated page on feature X.

The most highly rated pages on feature X are likely going to be the page on the version in most common use, which means that if version 3 of your product has just been released, while version 2 has been on the market for a while, and if Product B is your biggest seller, every user, regardless of the product and version they have, is going to get search results dominated by content on version 2 of product B.

For example, if you search for information on the Python programming language, your results will be dominated by pages related to Python 2.7, even though the current version is 3.4. This is because version 2.7 has been out for far longer, and still has more active users today than version 3.4. (When it comes to programming languages, the upgrade cycle is very long, since a new version may require changes to existing code or introduce subtle incompatibilities that are hard to trace. People, therefore, do not upgrade automatically or casually.)

You can see the same pattern for all sorts of products. Even after most people have upgraded to a new version, it may take a while before search engines’ accumulated data on the popularity of a page catches up to the new version.

All of which means that when a person begins by searching for a subject, they will often arrive at pages in the wrong context, and need to find the right context to use the information effectively. Subject first; context afterward.

If the reader has arrived at the right subject, but the wrong context, how do they get to the right context.

There are a couple of problems here:

  1. How do they know what contexts are available? The person who consulted the version of the manual for the product they bought did not have to navigate context, since it was established for them. They did not need to know what other contexts there were. The corporate customer could survey the bookshelf to establish which contexts were available (which was limited to the ones relevant to what the company had purchased). But the person who searches could land in any context, and to get where they need to go, they have to know what all the parameters are of the context they need to get to.

  2. How do they get to the context they need to be in. If they knew what the parameters of the context were, they could try reformulating their search terms to narrow their results, but that is not always effective, and most people do not know how.

What they need is guidance in selecting the right context and links to get them there. And since they are now on a page on subject X (subject first; context afterward) they need that information on that page.

But in traditional information design, that guidance and those links are not there, because traditional information design assumes that context is established first, before the subject is accessed. If context is already established, the content on the subject does not need to deal with context. Context first; subject afterward.

But when you are writing for the modern reader, the reader who lives in the world of the Web, that approach is not going to work. That reader works subject first; context afterward. That means that the pages on individual subjects have to deal with context. This is why one of the principles of Every Page is Page One information design is that a topic must establish its context and make it navigable.

For example, when your search for a Python programming topic lands you in the Python documentation online it will almost inevitably be on a page about version 2.7. But in the top left corner of the page, there is a selection box where you can choose the version you are using. This both tells you what contexts are available and allows you to navigate to the page on the same subject in the correct context.

This approach not only applies to versions. It can be done for products too. Tom Johnson describes a similar approach to selecting the language to use with a particular API.

This is how we need to be writing our topics and designing our information sets today:  subject first; context afterward.

And notice that I am talking here about writing for the reader who lives in the world of the Web, not just about writing content specifically for the Web. People who have regular access to the Web live in the world of the Web. It shapes their habits and expectations of information seeking and consumption in ways that extend beyond content specifically found on the Web. In everything they do, they think subject first; context afterward.


6 thoughts on “Subject First; Context Afterward

  1. Tom Johnson

    Mark, this is an insightful post. Sorry I’m somewhat slow to get to it. You’re right on the money. I think this issue is probably one of the greatest we face in the tech comm industry. So much of tech comm practice is shaped around “delivering the right content to the right person at the right time” (to quote a phrase I hear everywhere). And to accomplish this, many strategies involve tagging content in a way that results in deliverables specialized to a particular audience. But having 16 different outputs is ridiculous and leads to all the problems you described here. It doesn’t seem so difficult to have more deliverables that let users choose on the fly what they want to see.

    Part of me wishes I worked in an industry where our documentation was searchable on the web — it would certainly change our strategies quite a bit.

    1. Mark Baker Post author

      Thanks Tom,

      Of course, realizing that we live in a subject first, context afterward world is a big part of persuading companies that they need to get their content on the Web. Assuming that the reader will come to you in search of your content is part and parcel of assuming that the reader will seek to establish context first. Once you realize that this is no longer true, you realize that you need to get your content on the Web or risk losing your audience.

      You are right that “delivering the right content to the right person at the right time” is part of the context-first model. To put it another way, it is part of the push model of publication — a model that assumes that the organization pushed content out through defined channels to selected audience that they understand.

      But that is not the model by which people seek information today. On the Web, the model is pull, not push. The reader pulls a variety of content on the subject that interests them, building dynamic semantic clusters of content from any different sites. Our real challenge today to to create content that works well when it gets pulled into a dynamic semantic cluster.

      Hopefully that means that the right content reaches the right person at the right time in the right format, but if it does so, it is as a result of how the reader chooses to pull content, not how the publisher choose to push it.

      1. Tom Johnson

        One reason this concept isn’t always important to tech writers is because their content may not be on the web. This is my case. I wish I could publish to the web, but it’s simply not allowed for a number of reasons.

        I actually received feedback that my content selector was too subtle and people want the programming languages separated out for more clarity. In a web context where people are searching for info, this would fail. But in a context where customers are given a specific link to doc, it works.

        One reason my content selector failed is because I didn’t implement it to follow standard predictable patterns on the web. mostly people see jquery tabs that show variants of content. They aren’t used to seeing a little switch in the upper-right corner of the screen. I’ll have to rearchitect things to make the tabs work, but for now I just separated everything out.

        1. Mark Baker Post author

          Yes, when it comes to context setting, I think integration with the overall design is vital. Part of the design question is what scope does the widget apply to. In the Python docs, for instance, the version selector is in the top left corner of the page, making it clear that it applies to the whole page. A selector in the body of a page in a tri-pane help system does not make it obvious what the scope is.

          I think tabs might be more effective than a widget as well. The Web is both a content platform and an application platform, but I am not convinced that it is helpful to readers to mix design elements from the two worlds. Tabs belong more to the content world. If used correctly, the reader understand the scope of the tab’s effect.

          In fact, I am coming more and more to believe in the virtues of plain content that uses only the basic hypertext devices: search, link, scroll, and back. Mobile reinforces the virtues of such a design, but it really works well for the desktop as well. But it works best for material that is genuinely hypertext, and tech comm has not really adapted to creating hypertext yet.

  2. Pingback: How Can We Help Users Judge the Relevance of Content?

  3. Pingback: How Can We Help Users Judge the Relevance of Content?

Leave a Reply