Search, Browse, Surf: Pick Three and Add Something Extra

By | 2011/05/17

The Web provides three basic modes of navigation: search, browse, and surf. Few web sites, and still fewer doc sets do all three well.

The something extra? “Pick three and add something extra” comes from Peter Sheahan’s book Flip, in which he flips the traditional business motto “good, fast, cheap: pick two” into what he regards as the new price of admission for business: “good, fast, cheap: pick three and add something extra.”

With findability being the new price of admission of content, I’d suggest that search, browse, surf: pick three and add something extra is the new standard we have to meet.

Wikipedia is a good example of a site that seems to pay attention to all three modes of navigation. Their articles perform reliably in searches (that is, it is likely that the Wikipedia article that shows up in search results is actually relevant to the subject of your search). They are richly linked internally (thanks, I suppose, to thousands of people editing the topics and adding links to them). And while browsing is probably the least used navigation method in Wikipedia, it is still well supported, with their portal pages and the categories they provide for directed browsing.

A lot of tech pubs organizations focus heavily on browse, devoting much effort to manually constructing elaborate hierarchies of topics.  However, their individual topics seldom work well as “page one” when you arrive via a search, and again, linking is usually sparse or nonexistent.

Search does get attention in tech pubs groups, but it tends to play second fiddle to browse. Perhaps because browse is something that pubs groups are more familiar with, or something they feel they have more control over. But it is the reverse of the importance that browse and search play for most readers today.

A focus on browse sequences and hierarchies can be detrimental to creating content that is easy to search, especially if we expand the definition of easy to search to mean not only that the content is easy to find, but that is is also useful once found. A search that drops you into the middle of a browse sequence in which topics depend on their place in the sequence means that the topic probably won’t answer the reader’s question the first time. Dropped into the middle of something large, readers will have to work to get their bearings before finding the information they actually came for. Focusing first on creating content that is easy to search (and that works well when found) and only afterwards constructing a browse sequence might produce better results.

Surf — following links directly from one page to another — is and always has been the most neglected navigation mechanism in tech pubs organizations. No doubt this is partly because it has traditionally been expensive to create and maintain links between topics. The neglect has been exacerbated by the difficulties of managing links in reusable content, which has resulted in some organizations actively removing links from their content. (I recently presented a  paper on a method for making it easier to create and manage linking. I call it soft linking. More on that another day.)

But surf is an important part of the total navigation package. The ideal may be that a single topic should answer each user’s question and allow them to get back to work immediately. But in reality, some users will need ancillary information: to understand concepts that are not familiar to them, to find procedures for creating objects needed for the current task, to find reference material to supply needed data. If they can’t get to these things by following links in your text, then they must either go back to the search box, or navigate out to the browse sequence and try to find the information that way. Either way, you are forcing the reader back into search mode and delaying their quest to get back to work.

The something extra? There are quite a few interesting possibilities. Tom Johnson has recently been looking (unsuccessfully) for a help system that supports faceted search. Used car web sites allow you to narrow your search by selecting any combination of independent variables such as make, model, year, transmission, etc, but I have yet to see anything like this show up in documentation sets.

But for my money, the most important something extra is still to make sure that when the user finds content, by whatever method, the content they find works for them. In short, its about making sure that every page is an effective page one.

Category: Content Strategy Tags: , , ,

About Mark Baker

I am an aspiring novelist and former technical writer and content strategist. On the technical side, I am the author of Every Page is Page One: Topic-based Writing for Technical Communication and the Web and Structured Writing: Rhetoric and Process. I blog at and tweet as @mbakeranalecta.

2 thoughts on “Search, Browse, Surf: Pick Three and Add Something Extra

  1. kevinmcl

    OK fine. But a writer of WebHelp or other documentation for a product needs to force the reader to perform some basic tasks in certain orders.

    If your product needs to have software or driver installed before it can be used, then that task – and the reason for it (some people want reasons for doing things) – must be done before the reader jumps in at “any page is page one” to learn to do some specific task.

    If your product needs configuration before it can be used, then the same applies. Perhaps your product does the customer’s task just fine, but in a generic, factory-settings kind of way, and only does it in a personalized, useful way if they have performed the config chores first, identifying themselves or their organization, setting up network or partner links, adjusting firewalls and proxies (or any of dozens of possible things a product might need) in order to do a good and useful and specific job for the customer.

    Then you get to the sort of situation where EVERY page has so many “you must first….” and “if you have not already” statements and links, that all (every page is page one) pages look identical above the fold and you don’t get to the meat until you’ve scrolled for a while. Next thing you know, you’ve got MadCap’s Flare Help…

    … badump-bump-tsh!

    OK, small joke there, but I think you get what I mean.

    But now that I’m thinking about Flare (which I use) – they’ve gone to considerable trouble to have a very explicit user interface AND contextual help, but people (ok, _this_ people and enough others to justify them having gone the extra distance) STILL need the larger, broader help system AND the forums.

    Aside from easing back on the explosion of featuritis, what else might they have done better/differently?

    I mean, in the context of this blog topic, Madcap seem to be doing both sufficiently good-fast-cheap as well as search-brows-surf to have growing sales, year after year. People buy and use and recommend their products. Of course, people also bitch and moan and ask whiny questions… but see the previous sentence.

    (Disclaimer: I’m only a product user, and have no other connection to MadCap, and have had my share of days when I consider blowing it up and converting to AuthorIt! or Doc2Help. But who hasn’t?)

    1. Mark Baker Post author

      Thanks for the comment, kevinmcl

      There are some products for which you can force the reader to read and perform operations in a certain order. Pilots, surgeons, and nuclear power plant operators have to study and be certified before they can actually start doing their jobs. If we could impose the same conditions on the users of all products, the life of a technical writer would be very different.

      But in practice we have no way to force the reader to read docs or do tasks in a particular order. We can write documents as if we expected them to read or to do in the order those docs dictated, but that won’t change how they actually behave.

      So yes, given that we can’t induce most users to read before doing, I think we are indeed stuck with stating the prerequisites of a task. This is what minimalism means by supporting error recovery. The user attempts the task, fails, and looks to the docs for help. The doc then needs to say, “well, you need to do this, that, and the other before you try to do this task.”

      I can’t speak to the Flare documentation, which I have never seen, but I can easily believe that this style can get a little out of hand sometimes, especially is the product installation and configuration is more complex than we might wish. But I don’t see any option that is consistent with how most users actually behave.


Leave a Reply