John Battelle came by to talk to a bunch of us folks at salesforce.com yesterday. He gave an interesting talk that combined points from his book (
The Search: How Google and Its Rivals Rewrote the Rules of Business and Transformed Our Culture ) and some other, related comments. One of the things he talked about is a search scenario he recently posted on his blog: Google Launches Biz Local AdWords: It's Just the Start..... Go read the scenario and then come back here (I know his blog is much more interesting than mine, but let's finish this dialog, then go read more there).
The scenario is interesting from my point of view as an information designer that wants to make information access more effective. The truth is, for most things, the problem isn't finding the information, it's finding the appropriate information. John's scenario is very similar to an existing search, but adds two contexts - location (the shopper is in a particular location) and interest (s/he wants to buy a bottle of wine, known from the location [in a grocery store's wine section] but also from the search engine choice).
The context is what makes the search results valuable. I can do this search now while at the grocery store using my Nokia 770. The information I want will be retrieved, but since the search engine won't know the context, I will have to filter it myself to gain the same value. I probably won't be very successful because there is too much information for me. People are amazing pattern matchers, but we cannot effectively handle the volume of content such a search would return.
Traditional documentation does the same thing. We put out there a bunch of information, and the users have to use the table of contents, index, or search to find the content they want, and then they have to filter it for their context. We need to add context if we're going to solve the information glut problem.
Context sensitive help is a step in the right direction. We link from a particular UI to a particular bit of information. That's good, but it's very rare that a UI is simple enough that one help topic can be sure to give the user exactly what they want. Usually the content is too broad, forcing the user to dig into it (which takes away most of the advantages you gain from the context sensitive link). Sometimes the content is too narrow, which is even worse.
Contextual embedded help is the next step. Some software products already do this. Tax software programs are a great example. They give you information on how to complete each task without forcing you to ask for help. They don't forget though, that users often need more help, and they include links to that as well.
One thing that I haven't seen in embedded contextual help is something I call "the onion" for lack of a better term.
Embedded context help needs to be specific enough to be useful, but if it's too specific, it might not help me put this current task in context of the user's goal (quick aside, a task is a specific action, and a goal is what you want to accomplish - for example, figuring out your gross income is a task, completing your taxes is a goal). Each embedded context help topic needs to include a weighted related topics list, that gets more general the further out you go. Depending on the topic, it may also have a related topics list that gets more specific.
Here's an example. My goal is to complete my taxes. My current task is to compute my gross income. When I get to the UI page for doing that, the embedded help topic is "Computing your gross income". It has two sets of links, one a list of more specific tasks ("Calculate earned interest income", "Calculate income from salary", etc.). The second set of links is more general and includes concepts about gross income, other types of income, and a link to the overview of the entire tax preparation process.
It's an onion rather than a ladder because you may move out to a more general layer, but it may be to a topic that isn't a direct hierarchical parent of the topic you are looking at. For example, from computing your gross income, you may move to a conceptual topic on the alternative minimum tax. Related topics, sure, but you wouldn't put them in the same information hierarchy.
There's a huge information design problem that needs to be solved to make this model work, but I think it's worth the effort.
