Subject First; Context Afterward

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.