I argued in Too Big to Browse; Too Small to Search, that search works best when it has a large amount of content to work with. But it occurs to me that there is a really important caveat to be made, which I can best express as the difference between findability and searchability.
The distinction I want to make is not clear in the common usage of the words “find” and “search”. They are often used as synonyms, particularly in computer interfaces. But I think there is nevertheless a significant difference in the connotations, which points to a significant distinction we should pay attention to when we think about the findability of our content.
Find is a word often used to describe locating something known and/or in an expected location. For instance, I might set out to find my keys (a known object) in one of the familiar places I leave them: in my pockets, on the dresser, in the door. I find a word in the dictionary (given a known word and and expected location). Search is a word often used to describe locating something not specifically known, or not in an expected location. If I can’t find my keys where I usually leave them, I may have to search the house for them. If I am lost in the woods, I search for food.
Here’s a tech comm example that illustrates the difference. If I am a programmer and I know that I need to call a certain function, but I don’t remember the exact syntax of the function call, I can find the function by name (something known and specific) in the API Reference (an expected location). But if I want to solve a particular programming problem, and I don’t know whether or not there is a function for it, I will probably search Google (not a specific location) by attempting to describe the problem I am trying to solve (not a specific or known object). The answer may come from the API reference, if there is actually a function that does what I need, but I did not start out with enough information to find it there — I had to search more generally. Next time, though, if I remember the function name, I may find it directly in the API reference, rather than having to search again.
Searching and finding are different in a some important ways that can make a substantial difference to our findability strategy.
- Searching works best with a larger body of material. Finding works best on a small body of material. If I am lost in the woods, the more territory I can search for food, the better my chances of turning up something to eat. If I lose my car keys in the woods, then the less territory I have to look in, the better my chances of finding my keys.
Lost in the woods
- People find things by name. They search for things by problem. That is, if I want to find the syntax of printf(), I enter “printf” in the find box. But if I want to find a way to get the user’s home directory from an XSLT script, I enter my problem “get the user’s home directory from XSLT” in the search box.
- Finding addresses “where is the” questions; searching addresses “is there a” questions.
- Searching can be a multi-step process, which can involve multiple searches, or searching followed by browsing links. Finding is generally one-and-done. If the specific object I want to find is not in the expected location, I switch from finding to searching.
These differences have important consequences for the kinds of findability aids we provide:
- Searching requires a relevance engine to correlate a non-specific search string with useful resources. Relevance engines work best with large volumes of content and large numbers of query strings to profile, which in practical terms means your help system’s search/find function will suck for search. The most effective search strategy is probably going to be to put your content where Google can index it.
- Finding requires a specific vocabulary to match the specific find term with a specific known resource. Your help system’s search/find function and/or its index function is going to work much better for finding than searching.
- Traditional book-based aids, such as TOCs and indexes, are finding aids, not searching aids. (This may leave those of us who grew up in a book-based civilization a tacit bias in favor of finding over searching, which we will need to examine and get over.)
- Other findability aids, such as faceted search, are likely to work much better for finding than for searching.
- Taxonomies are finding aids, not searching aids.
- Links between topics are much more important for search behaviors than for finding behaviors.
- Hierarchies, up to a point, may be useful finding aids (though they are still limited by their artificial subordination of categories), but they are useless for searching (indeed, I believe they are a positive hindrance to searching).
Once we recognize the difference between finding and searching, we have to ask ourselves some questions:
- Which is more important to my user base, finding or searching? What role does industry, role, or demographics play in their preferences?
- Is finding a bigger issue for some content, and searching the bigger issue for other content? For instance, is finding a bigger issue for reference content and searching a bigger issue for task-support content?
- Can I design my content to support both finding and searching well? (For example, is my linking strategy good enough to support the refinement stage of the search process?)
- Do I have both a findability strategy and a searchability strategy?
Do you? Do you have both a findability strategy and a searchability strategy?
Loved this article – it expresses some of what I’ve been struggling with and now allows me to talk about the problem more intelligently! We’ve got all of our documentation on a public MediaWiki, so users can use both Google and the MediaWiki search. Keep up the thoughtful posts.
Hi Helen. Thanks for the comment. It would be really interesting if you were able to capture and analyze the search strings that people use in each system. That would tell us a lot about the current state of information finding habits — at least among your user base.
Good overview of this concept. This is one of those areas where duties within Tech Comm and IA are overlapping. However, from my experience: Taxonomies can be used to filter search results–so depending on how you implement it, one can view taxonomies as aiding search.
Hi Fer, thanks for the comment.
Yes, I think there are definitely scenarios where search tools can lead you to find tools, and that is great as long as you arrive at the find tools with enough information to be able to use them successfully. In that sense, I think we have to look at all of the searching and finding aids (relevance-based search, keyword search, taxonomy, index, linking, etc.) as working together to get people to the content they need. What we really need is an integrated findability and searchability strategy.
“Hierarchies, up to a point, may be useful finding aids (though they are still limited by their artificial subordination of categories), but they are useless for searching (indeed, I beleive they are a positive hindrance to searching).”
This is something of a sticking point to me. And not because I (entirely) disagree. I think that hierarchies are great for the person creating the content, but often inscrutable to the user. I’ve seen this many times: Someone asks me about a list of features introduced in previous versions of the API. “Why, obviously it’s under Getting Started with the API > API Versions > Previous Versions. Simple!”
Which means that the reader is forced to use the site’s search function to find anything.
But a single-level list of topics (hundreds or thousands of topics) isn’t a solution, either. Maybe a better landing page is the answer, or something that guides the user through the documentation. But that assumes that I can anticipate what they want to read…
Sorry, no solutions from me. I’m looking for answers, too!
With hierarchies, I think it comes down to whether you know what the hierarchy is. For instance, if you are trained in biology, the hierarchical taxonomy of species probably works for you because you know how it works.
But for most doc sets, the hierarchy is an invention of the doc team, and the reader has no idea where to find anything. I think writers often deceive themselves on this, believing that if they create a hierarchy that is a good logical organization of the entire doc set, it will be easy for people to find things. The truth is that it is only easy for people with a good knowledge of the entire doc set.
I agree that a single-level list of topics isn’t a solution either. I don’t think there is a solution that involves there being a single landing page or start page (that’s the too big to browse part of the problem I described in /2012/03/03/too-big-to-browse-too-small-to-search/).
The solution? Don’t rely on a single landing/start page. Make every page page one.
Insightful, Mark. As usual. I’d say that a good TOC or index–especially a good index–is both a finding aid AND a searching aid. Skilled indexers put a lot of thought into building entries that support both modes of looking things up.
P.S.
This quotation says much better what I meant to say (re: “traditional book-based” indexes):
“In an index[,] related information is grouped together under subject headings, making accidental discovery of useful items a common bonus for index users. You may know exactly what you are trying to find, but
there may be more relevant information you did not expect to find or even know to consider. The cross references and logical structure of an index guide you to what is relevant to your research. You can browse through index headings or [look up] specific terms.”
[Bureau of National Affairs, Essential Information Expert Analysis, copyright 2008, doc #0608-JO4498]
Hi Marcia,
Thanks for the comment. I agree that traditional indexes were designed to support both finding and searching. They were developed, after all, in an age before there were any of the modern search tools available, and before content was kept in a place where such tools could find it. As search tools today, however, they suffer from three major problems.
The first is that they simply don’t cover very much content. Before you can search the index, you must first find the book. Unless you know exactly which book contains the information you are looking for, and have it ready to hand, that means you have a lot of work to do. (And if you know which book contains what you are looking for, you must know what you are looking for, which means you are finding rather than searching.)
The second problem is that few books have good indexes (because good indexes are difficult and expensive). The result is that if you are trying to search through a collection of books, chances are most of them have lousy indexes, making this a poor search strategy, even if one of two of the books have fantastic indexes.
The third problem is that indexes don’t cover the long tail of information. The Internet contains a vast trove of incredibly specific answers to incredibly specific questions that are far to numerous, and of far too limited interest, ever to be collected into books or to be indexed by human effort. Yet a huge number of the practical questions that people ask by their millions every day are answered in that long tail. Google finds those answers. An index never could.
The upshot is that people rarely use indexes for searching anymore, which sets up a vicious cycle, because it means there is less motivation for publishers to pay for good indexing, which means there will be fewer indexes, which means that fewer people will use indexes for searching, and so the downward spiral goes.
Because indexes are still useful as finding aids, I expect we will continue to see them produced, but I suspect more and more will be mechanically created either from structured content metadata, or from some form of textual analysis software. Certainly, if you have a structured writing system, there is no reason not to produce an index, and to produce an index that covers the whole content set, rather that individual books.
Traditional manual indexing is a grand high art, but I fear it is not going to continue to be practiced much outside a few select niches.
Mark,
You’re so right about traditional manual indexing being “a grand high art.” And you’re right about indexes not covering “very much content,” although I’d put it a different way: they cover closed information systems–not big, sloppy, constantly changing constellations like the Web.
FYI, the American Society for Indexing has quite an active Digital Trends Task Force. There’s a lot of discussion in their LinkedIn group. These folks are all over getting e-book standards to accommodate better indexes, for example. Stay tuned!
Marcia
Here’s a link to the source I’ve cited above:
http://subscript.bna.com/pic2/lsll.nsf/id/DTRS-5L3RPC
Cheryl Landes adds this (in a recent email to me, which I’m sharing with her permission):
“This isn’t explained clearly, but the online index BNA is talking about is from its CDs of legal publications, which are used as reference materials at law firms. The CDs [now] have indexes. The BNA [had previously] decided to save money by eliminating the indexes and expecting its customers to rely on search. The customers hated it and complained loudly. The complaints were so numerous that BNA resumed indexing the material.”
I love this story!
Hi Marcia,
That’s is a great example, and it seems to me to be exactly what the theory would predict. That is, this sound much more like a find case, with people having a clear idea of what they are looking for an a location where they expect to find it. The theory would predict that find tools, such as indexes, would be important for that audience.
Of course, I think we also have to realize that we are still in a time of transition, and that while the migration to the Web way of finding information is proceeding very quickly, there are still people, and professions, who have not made the move, and may be slow to do so. This seems to be particularly true of some professions which have a natural tendency to guard entrance to the literature of their profession. Scientists have, by and large, moved to the open notebook model eagerly and voluntarily, while Realtors have fought tooth and nail, unsuccessfully, to maintain exclusive access to their content.
The law, which has built so much professional privilege on a foundation of arcane language, may be one of the last to move to the open marketplace of ideas which is the Internet. Who else, after all, still publishes on CD-ROM?
Great piece – detailed, thoughtful, and really nice to see the distinction between find and search so clearly illustrated and dissected. Thanks for recognizing indexing as “a grand high art” 🙂 I think Marcia makes a good point about indexes being designed for a closed information system rather than a big open one like the web. As such, indexes serve both find and search needs. For example, if you have a book on XSL and you want to locate information on how to do loops, you can “find” xsl:for-each (if you know the function name) or you can “search” under loops or iteration (the desired task you want to perform). O’Reilly still routinely commissions human-created indexes for all their technical books and I’d hate to try and use some of those big reference works without one. As to machine-produced indexes — I think natural language processing has a long way to go before it’s capable of making the more sophisticated connections that a human indexer can, or determine whether a passing mention is deserving of capture.
Hi Michelle,
Certainly if you are forced to work in a closed information system, then indexes are one of the tools you will use for searching, especially because closed information systems tend to be too small to search effectively using algorithms. What is happening more and more, of course, is that people are rejecting the closed information system altogether and opting to search the open information system of the Web. They are increasingly opting for low-precision/ high-probability of search over the high-precision/low-probability of find.
The case you pose is an interesting one, since I don’t think it is a clear cut case of search. True, “loops” is not quite so precise a term as “xsl:for-each”, but it is still part of the recognized vocabulary of computer science, and of programming. A reader who knew anything about programming would expect to find information on “loops” in any programming book. So really, it is still a case of finding a known term in an expected location.
But that said, this is also a query you could satisfy using search, by Googling “loops in XSLT”. In part, at least, therefore, your choice of a find vs. search strategy is determined by whether you have a closed or an open information system available to you.
Where I think we are all in agreement is that if you are going to create a closed information system, you would still be well advised to give it an index.
Your system of information assumes that everyone searching for something will know WHAT they are searching for. I maintain that there still is a big need for documentation within each organization which provides context for the users of that information. Otherwise each group within your organization will create their own context for their own useful information set, over and over and over again. Indexes are needed, no matter where you post them or what they are called. I can see that you want to build a good case for the elimination of structured information, but I maintain that a user viewpoint will always benefit from context.
Where I think we are all in agreement is that if you are going to create a closed information system, you would still be well advised to give it an index.
Yes indeed 🙂
Yes indeed, indeed.
I maintain an online help system. As the software is an advanced geophysical analysis tool and as I have training in indexing, the online help has a manually created index along with a TOC and a one-word search function (s/w limitation). We have run some user surveys during courses to see how (or if) they use the help. What I found is that everybody uses the search, despite the problem that geophysics has a large number of compound terms that don’t work well in a one-word search. Nobody bothered to use the index. No matter how I tried, I was competing for attention with the hundreds of sloppy indexes out there and they won the opinions of the users.
David, thanks for the comment. I think you have hit on something really important. People come to our content with information-finding habits formed based on their experience of everybody else’s content. However great a great index may be, great indexes are so rare that no one looks for them. On the other hand, Google is always Google, and while not every search is Google, Google accustoms us to searching.
The simple truth is that Google requires no sophistication of either the author or the reader. Indexes require it of both. That’s a pretty steep hill to climb.
Ultimately, the question isn’t which kind of search/find tool is best, but which one will people use. There are specific cases where the answer is index, as Marcia has pointed out, but we can’t change what it is for our content, we can only provide what the reader is willing to use.
People tend to be sophisticated about their own trades, and simple about everything else. In the case Marcia cited, the audience were, essentially, professional researchers who are sophisticated about how they locate legal information. Tech writers are often professional researches as well (not all are, because some write from experience) and so have a taste for sophisticated research tools. But if our readers are not professional researchers, expecting them to value or use such tools is vain. Our first rule is supposed to be, know thy reader.
David, How disappointing for you, manually building an index that rarely got used. I’ve seen that happen in Help systems simply because users didn’t realize the index was there. The search pane came up on top, so naturally that’s what everyone used. The index was a click away–the word “Index” practically waved at people from the tab–but no one saw it.
Ironic, isn’t it, that the tool that could have best helped people find what they were looking for was itself, in practice, unfindable.
David
Years ago, I used to create Indexes for documents, but found people rarely, if ever, used them. Unfortunately, during my research of indexes I found so many that were merely alphabetic TOCs or created using a key word list and were basically useless. MS Word at the time claimed to make great indexes using a key word list, but sadly it wasn’t so. Most of what came back was garbled and hard to figure out. I found it much easier to simply pore through the document and create the entries by hand. Time consuming, yes, but much more accurate. Now, Indexes seem undone by the search function, if you know a key word or term. Most people today don’t know what an index is all about anyway.
David
Neil Perlin has an excellent, concise tip (courtesy of Maxwell Hoffmann’s summary) on indexing for online Help systems:
“At a minimum, make each topic’s title an index entry. Better still, make each title and its inverse index entries. For example, for a topic called Print Dialog Box, create the index entries ‘Print Dialog Box’ and ‘Dialog Box, Print’.”
http://blogs.adobe.com/techcomm/2012/04/review-top-10-mistakes-to-avoid-when-starting-a-help-project.html
I argue that there are not such distinct difference between find and search as you are claiming. Information scientist are making a difference between “known item search ” and “subject search” which would map to “find” and “search” but later it has been discussed that “known item search ” is not as straight forward as it sounds.
An individual can perceive an item to be known, but what does that mean? Our cognitive state may fools us to believe that an item exists while it does not. I may believe that a printf() function exists, but does it really? A known item search may be the case if the individual has a distinctly close relationship to the object sought, one closer than simply knowing it exists.
A known item search could for example be a situation where the individual is set out to find an item a user has had previous contact with or a situation in which a user is trying to find an item previously read, and consequently in which the user’s memory of the item is of primary importance. But the memory can fail us. Then I may know that an item exists, but what is it called?
What about looking for information?