Greg Nudelman discusses breadcrumbs in one of his chapters in Designing Search: UX Strategies for eCommerce Success. This post mainly details notes from Nudelman’s book.

One problem with breadcrumbs, Nudelman notes, is that “breadcrumbs cannot show customers where to could go next. They show only where they’ve already been” (p. 199).

Nevertheless, Nudelman says the breadcrumb aligns with a search/browse pattern that supports common finding practices. Nudelman cites a presentation by Peter Morville called “Search & Discovery Patterns,” where Morville explains that “browse and search work best in tandem… The best finding interfaces achieve a balance, letting users move fluidly between browsing and searching.” (p. 203-4)

In other words, when looking for content, users prefer to search and browse, browse and search. Users perform a combination of the two as they try to find what they’re looking for. This is because, Morville explains, “what we find changes what we seek.” For example, search results for your initial query might show you the correct terms, which then informs your next search.

Breadcrumbs are powerful tools because users can easily modify the breadcrumb path to browse the information they want to see. Nudelman explains,

Providing the ability to change attributes while automatically retaining all relevant query information turns the breadcrumbs into a powerful and flexible finding mechanism, without making the resulting interface overly complicated or difficult to use. (p. 210)

For example, in the above screenshot, I may not want instructions for creating a drop-shadow effect. But rather than returning to the raw search and formulating a new query, I can click the Special Effects breadcrumb and browse the other special effects available. The breadcrumb allows me to modify part of my search without starting over from scratch. Nudelman says users would rather salvage part of their search and refine it rather than starting over:

In my research, people seldom want to start the query over completely from scratch, unless they specifically indicated this action. Instead, a vast majority of the people interviewed wanted to retain as much of the query as possible with every change of the facet values and desired the system to help them construct a query that “makes sense,” gracefully dropping facet selections that no longer applied to their modified query. (p. 208)

One problem with breadcrumbs in most webhelp system is that they perpetuate the myth that content lives in just one place, which is not necessarily true.  Content in the digital space can appear in many different arrangements and paths.

Nudelman notes that Edmunds.com’s search results show tag selections as breadcrumbs.

I would like to see webhelp move away from a single hierarchical organization of content to one that simply shows tags that are stacked together in the query. This shift would be a new paradigm for the way help is organized. In Edmunds.com, each of these keywords is metadata for the content. There may not be an official hierarchical order to the content, like there is most webhelp systems. The order is dynamically generated based on the metadata you select.

I recently wrote about tags as being more of a web-based method for classifying information. See Using Tags to Increase Findability.

For more information about Greg Nudelman, see his site, Design Caffeine.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Search Patterns: Design for Discovery (2010, O’Reilly), by Peter Morville and Jeffrey Callender, explores search in depth, from every possible angle. Search Patterns is a must-read for anyone interested in search and findability. It should be particularly applicable to technical communicators, who rely on search as a key method for users to locate information. The book is foundational and, though brief, highlights ten search patterns that we would do well to implement on any site or help system.

Although it only occupies 50 pages of the book, the Design Patterns section is the core value of the book. Patterns are recurring models that work well. They are “repeatable solutions to common problems” (82).

Morville and Callender highlight the following ten search patterns: autocomplete, best first (similar to recommended results), federated search (searches across multiple collections, sites, databases), faceted navigation, advanced search, personalization, pagination, structured results (embedded charts, videos, music, or graphs in search results), actionable results, and unified discovery.

Throughout the book, Morville and Callender emphasize the need to browse and search in combination. Because of this, they herald faceted navigation as a key strategy. In fact, they call faceted navigation “arguably the most significant search innovation of the past decade” (95).

The genius of faceted navigation is that “incremental clarification and refinement reduce results until the need for paging and scrolling virtually disappears” (116). In other words, faceted navigation allows you to first search and then refine the results by browsing the facets, so it allows search and browse to work together. Some sites even offer scoped searches, which allow you to search within a defined facet.

Morville and Callendar explain that “faceted navigation will surely adapt to every context and platform because the need to narrow exists at the crossroads of behavior and the box” (101). Narrowing is a key behavior with search. Users don’t merely search and find, or browse and locate. We search and learn the right keywords, which informs a new search, which may lead us to browse the right facets or menu, and so on.

The core of Search Patterns involves the design patterns, but the rest of the book isn’t without interest. In the latter third of the book, Morville and Callender explore a variety of search techniques on sites, looking at different approaches to search. At times the exploration of these search techniques seems to be somewhat meandering, but the authors note that we have much to learn about search. We only scratch the surface of our understanding with these ten patterns. In many ways, it feels that Morville and Callender are searching to find and explain more patterns from their large sampling of sites.

The writing can at times be a little thick, but it’s also filled with great one liners, such as “Search ends with an exit” (52). “Predictability assures usability” (74). “Innovation requires improvisation” (80). “What we find changes what we seek” (87). “Discovery requires that we move beyond what we know” (131). I loved finding these nuggets.

The book is also full of visualizations (beyond screenshots). Diagrams, workflows, and other eye candy populate nearly every page, which allows you to move swiftly through the various concepts and ideas in a pleasurable way. Callender, the graphic designer, helps visualize the ideas that Morville expounds. As one critic pointed out, though, with many of the screenshots, the figures often don’t appear on the same page as the discussion. More lengthy captions below the images would have been welcome.

The book gave me a strong understanding of the multi-faceted nature of search. As a technical writer, I’m eager to incorporate some of these patterns into my help systems. But I admit that figuring out the technical aspects of search, including how to implement faceted search, best first (recommended results), autocomplete, or even customizing the display of search results, are still mountains to climb.

Note that this book is not a technical how-to, nor does it contain step-by-step instructions for implementing these techniques. Morville and Callender say that designers must work with engineering teams to achieve more innovation in search, to take it past the magic black box. I wasn’t expecting a technical how-to, but I would have welcomed a few more down-to-earth references on implementation. (They do mention several search vendors.)

Interestingly, with autocomplete, the authors show an HTML Help display with the Index tab open. When you start typing, your keyword matches automatically read from the index entries you’ve added. I hadn’t considered how index and autocomplete might work together like this, but they do. (The index feature in a help authoring tool is probably the poor-man’s autocomplete.)

Finally, as a reader, I wanted to do some of my own “pearl growing” from Search Patterns. (Pearl growing is when you “find one good document, then mine its content and metadata for query terms and leads” (57)). There aren’t many sources for further reading mentioned in the book, but there is a short reading list here. Partly, I think the lack of references is because there aren’t many books written on search. I believe the list of search patterns Morville and Callender write about will be foundational to other books on search that follow.

Overall, Search Patterns: Design for Discovery is a thought-provoking book well worth reading. For technical writers working with large bodies of help content, we should be more innovative with our approach to search. Incorporating the ten design patterns for search is a great starting point. As such, I highly recommend this book — particularly to the technical communication community. We need to implement more of these techniques in our help systems.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Notice that I said “organize.” You’re still organizing your content, but on a smaller level. Rather than organizing topics within groupings or folders, you’re organizing the words within the topics. To make the topic visible, you have to organize the words in a way that maximizes visibility in the search.

But here is where things get confusing. Almost no one understands how search works. Google’s search works differently from Flare’s search. Flare’s search works differently from WordPress’s search. I’m guessing that the search in RoboHelp differs from the search in Author-it, which differs from the search in DITA-produced Eclipse help, and so on.

Each search engine has a unique algorithm that sorts and ranks information based on a set of variables and other factors, much more than simple keyword frequency. Here’s the key point: you can’t optimize search until you understand the search algorithm you’re optimizing for.

Google’s search algorithm

Although Google’s search algorithm is complex, it’s unquestionable that Google’s search results are based on some of the following factors:

• The number of links pointing back to your site
• The authority of the sites pointing back to your site
• The text used in the links pointing back to your site
• The location of the keywords the user is searching for, especially in the title and h1, h2, h3 tags
• The frequency of the right keywords that the user is searching for
• Your own site’s page rank

What about meta keywords and title tags? Not that important. You could stuff a ton of keywords into the header of your topic, but Google has been gamed with that trick long ago, so it ranks these keywords low. The genius of Google’s search stems from the collective wisdom of hyperlinks.

WordPress’ search algorithm

According to Lorelle Van Fossen, WordPress orders search results with the date as a major factor:

When you search in your WordPress blog, your search results are listed chronologically. Not by “most likely”, “most popular”, “most frequent use of the phrase”, or even alphabetically, just by date. And the chronological order runs from most recent to oldest. If the most likely post to provide the information the user is searching for is older, they will have to scroll towards the end of the list to find the most likely candidate for information. What are the odds they will, huh? This frustrates me no end.

Another frustration with WordPress searching is that it only searches posts. It does not search comments nor Pages. Only post content.

Notice that while links pointing to your content factor high in Google, these same backlinks are non-factors in the WordPress search algorithm. In WordPress, the date of the post seems to matter most.

Madcap Flare’s search algorithm

Since Flare is the help authoring tool I’m currently using, I’ll dive into its search algorithm with more depth. According to Rob Houser in Flare Tip: How the full-text search works, Flare’s search weighs the following three factors with the most significance:

• Exact matches
• Frequency of the words
• Location of the words

Rob explains,

Flare ranks exact matches of the term the user enters higher than partial matches. An exact match uses the same form of the term (for instance, an exact match for “deleting files” would be “deleting” or “files”). A partial match may share the same root word as the original search term, but the terms aren’t exactly the same (for instance, the user might search for “deleting files” and the search would also find “delete”, “deletion”, “file”, and “filed”).

I’m not sure where Rob is getting his information, whether through experimentation with Flare or conversations with Flare developers. But let’s assume Rob is right. There are still many questions unanswered, namely how to create an exact match. If the topic title doesn’t provide the exact match, how do you create the match?

The Problem with Using Index Keywords

Flare doesn’t have a section where you can stuff a file with meta keywords. But you can stuff a topic with index keywords. Index keywords are included in the search algorithm. (Concept keywords are excluded, by the way.)

However, using index keywords as meta keywords presents a dilemma. If exact matches factor highest in the search, you should add index keywords according to the phrases you think users will search for in the help, right? But the way users enter keywords in search boxes differs from the way users browse an index.

With Flare you’re forced to make a decision about how you want to use the index keywords. If you use index keywords to beef up your search, your index will look random. If you choose index keywords for readability in a traditional index, you cripple the search.

Let me give an example. Suppose my topic is “Properly Delivering a Burn Notice.” Users searching for this topic might enter the following phrases:

• burn notice
• deliver burn notice
• drop off burn notices
• burn notices sending
• how to present a burn notice
• cutting off undercover agents
• severing ties with field agents
• burn notice protocol
• best way to handle burn notice
• give burn notice to operatives

Because exact matches factor the highest in Flare, it’s important to include these phrases as index keywords, and to insert those index keywords into the highest ranking location in the topic — that is, inside the h1 tags of the topic title.

But if I’m going to also produce an index in the help file or in the printed guide, the keywords and phrases need to be written and ordered differently. A typical string of index keywords might look like this:

• burn notices, delivering
• protocol, for burn notices
• field agents, delivering burn notices
• operatives, terminating
• tactics, presenting burn notices

When you browse an index, you look for the main word first, which is usually a noun. Users don’t usually browse to “give” or “deliver” when looking for a topic in an index.

But when users search, they usually do include verbs to lead off the phrase. I tend to search for exactly what I’m trying to do. If I want to download an mp3 file of a James Bond soundtrack, I search for “download mp3 James Bond.” If I want to figure out how to stop water leaking through my window well cracks, I search for “stop leaks to window wells.” I lead with the verb.

Stems?

Another question is to determine how the search algorithm handles stems. Exact matches factor highly, so when I have a phrase like “drop off burn notices,” do I need to add drops off burn notices, dropping off burn notices, dropped off burn notice, drop off burn notices, and so on for each of these search keyword phrases?

I wrote to Madcap to ask them for this information, because it’s not in the help file. They replied that the search will automatically look for partial matches, so if I just include “drop off burn notices,” Flare will look for partial matches with the other verb forms. But an exact match still trumps a partial match in search engine weight.

What? It’s not in the help!

I felt a little bewildered that Flare’s help, which is comprehensive and complete in almost every way, had nothing to say about one of the most important elements of help authoring: how to influence the search to increase topic rank.

And then I realized something ironic. In the application I’m documenting at work, search is a key feature, included in four separate places in the interface. And yet beyond keyword matches, I have no idea how the search algorithm works.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

The key trends are as follows:

• Help is embedded in a browser because the browser is the predominant mode people use to find information.
• Search is the main method for navigating content. There’s still a table of contents, but no more index.
• When you choose a topic, you see contextual topics related to the topic you’re viewing.
• You can choose to include online content into the search.
• The help is “decoupled” from the Visual Studio application, so the help authors can update the help without waiting for the next release of Visual Studio. (This is what I referred to in my content independence post.)

The direction the Visual Studio Help team is moving reflects my own trends as well: moving towards a web-like experience with help, relying more on search, adding contextual topics based on what the user is viewing, and publishing help in a location I can update on the fly.

(Thanks to Keith Soltys for the link.)

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Here’s the principle, as Mike puts it: “Help needs to be a mile wide—it must cover everything—and 30 seconds deep—tackling only small amounts of detail at any given point.” In other words, your help file should be comprehensive, especially covering niche topics, but your treatment of each topic need not be much—a conceptual paragraph and a list of steps perhaps.

Mike bases his reasoning from user observation and two principles. After watching hundreds of people use help, Mike concludes that “Users go to Help only when they’re stuck and stay there only until they feel unstuck.” It makes sense, then, to focus on areas where the users might get stuck (which might be the niche topics), and to only provide enough information for users to unstick themselves, after which users return to the application.

Mike warns about the danger of providing too much information, citing John Carroll’s adaptation of the Heisenberg Uncertainty Principle: “The more complete training is, the less usable it will be; the more usable it is, the less complete it can be” (The Nurnberg Funnel). In other words, providing too much information actually hurts the usability of the information. People have a small “intake bandwidth,” as Mike phrases it, when it comes to help. Overload them and they choke.

Finally, Mike references the Long Tail, a concept from Wired Magazine’s Chris Anderson. The Long Tail asserts that, in the long run, online stores with niche products outsell physical stores focusing on mainstream products. Amazon.com is a case in point. With help materials, niche topics (those help topics addressing edge cases and infrequent situations or tasks) collectively receive more hits over time than the core how-to topics. With this reasoning, Mike recommends a help strategy that covers comprehensive, niche information but in short topics.

Mike’s strategy seems like a commonsensical approach, one that wouldn’t receive much opposition, but it’s not one adopted by everyone. For example, the help for Microsoft Office tends to be the opposite, with long help topics and a jump menu at the top for navigation. Some of the topics are so long they could be mini-essays. For example, this topic from Microsoft Word on inserting fields, quite typical of other Office 2007 topics, is 14 pages long.

Unlike Microsoft’s help, Techsmith’s help (for Snagit and Camtasia Studio) is short, but it also doesn’t address niche situations. The help is light, especially compared to their pages and pages of forums. At the last STC Summit, I asked someone at the Techsmith booth why their help didn’t include more of the information asked in the forums. The booth representative said the help was purposely light to minimize translation costs.

As I document an application at my work, I’ve been trying to implement the mile-wide-and-thirty-seconds-deep principle. In the previous version of the application, I focused on core topics, for the most part, covering only the essential tasks because I feared overwhelming users with too much information in the table of contents. After the release, as I received questions I began adding them to the help little by little.

With this second release, I’m now writing a help topic for every task I can conjure up, without fear of having a bloated, unnavigable table of contents. I assume people will only turn to the online help when they have specific questions, and they will search the help rather than navigate it. If they want a basic tutorial, they can refer to the quick reference guides (which I’m lengthening) or a variety of video tutorials. But when they search the help, I want the search results to contain the answers, like Google’s results.

I’m not sure how a multiplicity of short topics affects search results. Does the mile-wide-thirty-seconds approach fragment search results into dozens of possibilities, requiring readers to click back and forth ad nauseum looking for the right topic? Do the shorter topics provide more accurate results because they don’t contain an encyclopedia of information?

I don’t know. But I do know we live in the age of Google, and our users have a search-to-find-it mentality. The challenge is figuring out how to sharpen and optimize search results so that, like Google, the results are accurate.

What techniques are you using to optimize your search results? (By the way, you can follow Mike Hughes’ blog here.)

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

1. Make your help a mile wide and thirty seconds deep.

Users spend about 30 seconds on a help topic, so keep it short and get right to the point. On the other hand, try to cover as many of the problems users encounter as possible.

2. Don’t document everything. Instead, focus on the context of the user’s problems.

Avoid the trap of trying to provide “complete” instructions that don’t address problems users will likely have. Long introductions, tables of buttons, menu explanations, and other information not directly focused on the context of users’ problems will lead to unnecessary information glut.

3. Put help where users perform tasks.

Users need help in the application, so that’s where the help should appear, not in a separate training system. When you separate learning from work, users are less likely to stop work and turn to another system to learn. The tasks they do and the help for those tasks should be integrated in the same user interface.

4. The research about the usability of help is that people don’t use help.

Research about how people use help often specifically prompts them into a help file, but the natural tendency, without these prompts, is for users to ignore the help altogether.

5. Avoid obvious instructions.

If you can figure something out on your own, so too can the users. Let your help focus on the true problems that users will encounter. Look for points of paint and information gaps on each page. Ask yourself, where am I getting stuck? Where will users get stuck?

6. Search results are a great opportunity to include help.

An empty search results set is a perfect place to include links to help, such as FAQs or top problems, because users are specifically looking for help content. Many times help authors neglect this space.

7. Quick reference guides are read more than marketing material.

Users are more apt to read quick reference guides than marketing material. If you need to get a product message across, it might find more readership embedded in the quick reference guide.

8. Phrase help links as short questions in the interface.

Help links and buttons are practically invisible to the user. But if you phrase your help as short questions in the interface, users are more likely to click them. When you do this, be selective about how frequently you implement the question links.

9. Tools and technologies can distract you from what matters most: the content.

Sometimes spending too much time implementing bells and whistles that tools provide (for example, javascript drop-downs and custom skins) can remove your focus on  the content. DITA allows you to refocus on the content, since you no longer can control formatting (once you set it all up).

10. Almost everyone has a microphone for their computer.

This is the fourth podcast I’ve recorded that’s a “double-ender technique,” where both the interviewee and I record individually on each of our machines in Audacity and then I overlay and sync the two tracks. I’ve found that almost everyone seems to have a microphone and doesn’t have trouble recording in Audacity. Previously, I’d assumed this technique required too much from the interviewee.

Additional Resources

• “Straight Talk: Surviving Tough Times as a User Assistance Writer”
• UX Matters
• Mike Hughes’ blog

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree