Search is Not Enough: Why We Need Multimodal Navigation

Last week I wrote about the death of hierarchy as the dominant form of content organization. One of the comments on that post asked me to “comment on the different perspectives between this blog post and “Search is not enough” by the Nielsen Norman Group?”

Let me get the central question out of the way right up front. I agree. Search is not enough. In fact, there are a lot of things wrong with search.

The Nielsen Norman Group article, by Raluca Budiu, decries what she describes as the tendency of websites to minimize navigation and rely on search alone. She lists the limitation of search:

1. Search Requires Knowledge of the Search Space

2. Search Increases Memory Load

3. Search Has Higher Interaction Cost than Browsing

4. Site Search Often Works Poorly

5. Users Have Poor Search Skills and Don’t Know How Search Works

These are all true. To address each in turn.

Search does require knowledge of the search space. This is much more true of site search than it is of Web search, because search is a big data problem and web search has more data to work with. It is even more true of help system search, which has virtually no data to work with other than the text of the content itself.

But the navigation of a hierarchy requires knowledge of the search space as well. Hierarchies impose a particular subordination of ideas, and unless you understand its system — often arbitrary — you won’t be able to navigate it.

In fact, all navigation requires some knowledge of the search space. Any quest for information that begins in complete ignorance of the subject space is going to be a long road. In part, that knowledge is gained as part of the search itself, which is why contextual linking is such useful form of navigation — it presents just the immediate subject relationships that matter in a particular context.

Search does increase memory load. And, as Budiu argues, “navigation replaces the recall with recognition”. But navigation can only supply a little bit of recognition at a time. There are only so many links you can put on any page. With any degree of complexity in the information set, navigation also relies on memory. With a formal hierarchy, it requires memory of the schema of the hierarchy, of its vocabulary or taxonomy. With anything less than formal hierarchy — and formal hierarchies are rare and hard to maintain — it requires memory of where things are.

On first encounter, though, there is often neither recognition or memory to rely on and the reader must make a tedious navigation down multiple paths with no certainty of success — which is why people often turn to search instead.

Where a navigation based on recognition can be particularly effective, however, is in local navigation among topics closely related to each other by their subject matter. When a topic refers to a related subject, there is generally immediate recognition of that related subject, and navigation in the form of a link to a topic on that subject provides very effective navigation within the immediate subject space that the reader is navigating.

Search does have a higher interaction cost than browsing. You have to type a search phrase; you just click a link. One search definitely costs more than clicking one link. The question is, can an effective navigation be accomplished by clicking just one link? If it can, then it is clearly preferable. This is why I think rich local linking is important, because it provides simple steps through the content no matter which page the reader is currently on.

But in a hierarchy, particularly a large hierarchy, navigation often cannot be accomplished in one click. And the problem is not simply that you may have to drill down through several steps to get where you are going. It is that at every step you have to do a new assessment, and that in many cases the path you follow will prove fruitless and you will have to back up and try again. The interaction cost of a complex navigation like this is far higher than that of search.

Site search indeed often works poorly. In fact, it virtually always works poorly. Help system search is even worse. This is a very good reason to provide navigation as an alternative. But (see the next point) most readers don’t know that site search works poorly. There is no way for them to tell if a search returning no results because there is nothing to find or because the search engine just isn’t very good. A good number of them, therefore, will use search anyway, and will often get results that are not what they are really looking for.

If we want to supplement search with navigation, therefore, we have to consider not only navigation as a top-level alternative to search, but also navigation after the user has made their initial, often not entirely successful search. Here again, we need bottom-up navigation — the kind of local subject-based linking that can get the reader from where they landed to where the want to be.

And while Web search is usually far better at returning relevant results than site search, it can often lead the reader to the not-quite-right destination as well. Once again, it is important to provide rich local linking to help readers travel the last mile to the information they need.

Users do have poor search skills, and don’t know how search works. They also don’t fully understand most other navigation mechanisms — which is partly their fault, and partly the fault of the people who design them based on principles of organization that make sense to the author, but are entirely opaque to the reader. The curse of knowledge applies as much to the design of navigation systems as it does to the writing of content itself.

The fact is, finding information is hard. The fact that Google works as well as it does as often as it does is truly remarkable. It is part of what is making readers increasingly search-dominant in their behavior. But it is not, and never will be, perfect.

Never will be? With so many advances being made so quickly, how can I assert with such assurance the search never will be perfect? Because perfect search requires perfect search queries, and human beings are not going to get to be perfect at search queries.

What all this means is that, while hierarchy is dead, search is not, and never will be, a sole replacement for hierarchy. If we want to provide effective navigation, we have to think in terms of multimodal navigation. We need search, and navigation, and lists, and rich local linking.

Equally, we need content that is designed to work with multimodal navigation. In the age of hierarchy, content was often written to work with hierarchy. Indeed, it was common practice to start by writing a table of contents and then fill it in with content. That won’t work for multimodal navigation. It won’t work when readers can enter a content set anywhere and navigate through it using multiple navigation tools that can lead them in multiple directions.

This is an environment in which every page is page one. To provide good navigation in such an environment, we not only needs multiple modes of navigation, navigation that works from the top down and from the bottom up, we need Every Page is Page One content, so that the pages work when readers find them, no matter how they find them.

, ,

One Response to Search is Not Enough: Why We Need Multimodal Navigation

  1. Patty 2014/10/07 at 13:47 #

    Thanks for addressing this issue, Mark. I work on a large online help system. Based on the user surveys and studies I have performed, many users use a combination of Search + other navigation to find the information they are looking for.

    Experienced users are more successful with a Search Only strategy because they know what they are looking for and are familiar with the terminology used in the software.

    New and occasional users often navigate the TOC and then, when they feel they are getting close, use the labels from the TOC to search for the specific information they are looking for. Others use some variation of this approach.

    The following are answers from some users when asked how they prefer to find information in our help system:

    Natural word search, with a filtering priority on whatever tool I just came from. Show me where the topic fits in your TOC hierarchy so I see other topics to look for.

    Search. 2. Workflow based. 3. Lots of linked to related topics.

    Navigating through the tree system. If this doesn’t work, I would use the search field.

    Contextual Help (F1 / ?) 2. Search on keywords 3. Navigating the table of contents

    Search with location in TOC highlighted after search