Do Short Topics Make Information More Findable?

In my last post, which now has more than 80 comments, I noted that authoring with DITA seemed to encourage authors to create a lot of little topics. DITA experts chimed in to say DITA doesn’t constrain users with topic length in their outputs — authors can combine topics as needed. However, one commenter noted that short topics are a best practice anyway:

Most users I have written for have no desire to read or skim through a long page of information. They want an answer to a specific problem. For these users, chunking instead to [create] narrowly defined topics is far preferable, even if it results in a longer table of contents. Providing an effective search mechanism is increasingly vital to the usability of any content, and search paired with small topics is an efficient way to get your users the specific answers they need.

In other words, shorter topics make it easier for users to find the information they’re looking for, since there isn’t as much content on the page to sort through.

I don’t single this comment out for its uniqueness but rather for the way it touches upon minimalism and a general style with topic-based authoring.

Is it really true that shorter topics increase the findability of content?

When The Short Model Succeeds

In some cases, I agree that a short topic might make information more findable. For example, when a user formulates a precise search query that connects dead center with the right topic, a short topic that answers the question more concisely than a long page helps the reader get to the information more quickly. Online examples of successful short topics might be Yahoo Answers or Stack Overflow.

Unfortunately, except for simple, direct questions, that kind of search-and-retrieve accuracy with help content doesn’t always happen. More frequently, the search fails to connect to an answer in the help, which forces the user to instead browse around for the information.

If the information is fragmented into too many small topics, the browsing becomes frustrating for the user because the table of contents has too many paths and sub-paths and sub-sub paths. This leads the user to attempt more searches, which often turn up fruitless. After pogo-ing around on half a dozen short topics without finding the answer, the user gives up.

Let me expand more on the three main reasons why shorter topics don’t always increase the findability of content.

Reason 1: The User Doesn’t Know the Right Terms to Search For

The search-and-retrieve argument for short topics assumes that the user knows the right terms to search for. Yet routinely, interfaces and applications use a terminology foreign to the user. The application might use “widget” instead of “sidebar section,” “module” instead of “plugin,” “template” instead of “php include,” and so on. Without a knowledge of the correct terms, the user won’t be able to connect to the right topic via search.

Reason 2: The User Doesn’t Construct Well-Formed Search Queries

The second reason the search-and-retrieve model fails is because users don’t often construct well-formed search queries. If you’ve ever looked at a list of search queries from a web analytics engine, the queries are short (one or two words), vague, and often hard to understand.

For example, a user searching for information on setting up a widget might simply type “web layout” or “design site.” The chances that this search connects with the topic “Configuring and Setting Up Widgets” are small.

According to Jakob Nielsen, users get progressively worse with each query reformulation:

Given that search is becoming old hat on the Internet, you might think users would develop advanced search skills. Not so.

Typical users are very poor at query reformulation: If they don’t get good results on the first try, later search attempts rarely succeed. In fact, they often give up. We recently studied a large group of people as they shopped on various e-commerce sites . Their search success rate was:

- First query success rate: 51%

- Second query success rate: 32%

- Third query success rate: 18%

In other words, if users don’t find the result with their first query, they are progressively less and less likely to succeed with additional searches. Many users don’t even bother: In our study, almost half the users whose first search failed gave up immediately. (See Search: Visible and Simple.)

Reason 3: The User Can’t Articulate the Real Problem

The third reason the search-and-retrieve model fails is because users often cannot articulate the real problem they’re having. Users can’t search for concepts they don’t yet know. But even if they do know the concept or task they want, it’s sometimes hard for users to articulate what’s actually wrong.

For example, suppose the user is having computer issues with slow performance, viruses/adware, and lack of storage space. The user needs help and wonders how to fix the issues.

In such a scenario, the user might search for a variety of issues but never quite pinpoint the exact issue. The user might search with queries such as “computer slow reboot not helpful” or “remove viruses reinstall” or “disc drive time performance”.

These searches reinforce the idea that the user doesn’t exactly know what he or she needs. That’s why the user is searching in the first place — to try to find information. If the user already knew the exact terms and question to ask, he or she probably wouldn’t be using search.

(By the way, earlier I wrote about some of these search issues in Browse versus Search: Stumbling into the Unknown Unknown, so check out that post to dive deeper into this topic.)

Reason 4: Users Don’t Rely on Search as Much as We Sometimes Think

There’s another reason short topics fail. We often assume that because we like to use Google so much, users must also use our site’s search box as their default mode for finding anything. Yet  Web Usability Blog found that only about 5% of a site’s visitors used the search (see Navigation versus search).

Even if you account for ten times more searchers, that’s still only half your audience. How are the other half finding content?

If users aren’t relying on search to find the information, they’re most likely browsing. If you’ve fragmented your help into 500 little topics, the browsing experience will be one of constant page hopping.

Solution: Widen the Target

Without a more accurate search, it’s unlikely that users will hit the target they seek. While some technical writers believe the user is a skilled hunter with a compound crossbow aiming at a target 30 feet away, the scenario is more like a kid with a toy bow from Wal-Mart trying to hit a target 100 yards away. The search rarely connects with the right topic. The shorter the topic, the harder it is to hit it.

Shorter topics do add more little targets in the field. So the user has a higher chance of hitting one of the targets, but it’s unlikely that any of the targets will provide the exact answer the user is looking for.

One solution might be to tag short topics with a common tag, and then output related topics as links based on that tag. This provides a second-level navigation experience but relies on the fact that users will scan through related topics and follow links. You’re limited to about half a dozen related links per topic before the list starts to look unhelpful.

Another approach is to make the targets bigger. You make the targets a bit bigger by providing more information in the topic. Rather than fragmenting your help into a lot of little topics, combine and group similar information into a more substantial topic that is likely to address more issues.

How much information should a topic contain, and why is longer better? I’ll make those arguments in another post.

follow us in feedly

Adobe RobohelpMadcap Flare

This entry was posted in findability on by .

By Tom Johnson

I'm a technical writer working for a gamification company called Badgeville in the Silicon Valley area in California. I'm primarily interested in topics related to technical writing, such as visual communication (video tutorials, illustrations), findability (organization, information architecture), content development (DITA, testing), API documentation (code examples, programming), web publishing (web platforms, Web design) -- pretty much everything related to technical writing. If you're trying to keep up to date about the field of technical communication, subscribe to my blog either by RSS or by email. To learn more about me, see my About page. You can also contact me if you have questions.

11 thoughts on “Do Short Topics Make Information More Findable?

  1. Ellis Pratt

    I’m going to be lazy and do a mini-brain dump. It’s a bank holiday in the UK and I’m just meant to to be checking my emails for any important messages).

    1. Findable by what? Findable by the search within online Help or findable by Google? My understanding is that Google looks for keyword density, and this may encourage longer pages.

    2. If short is good, long is bad, would we see this reflected in How to? pages on the web? Would we see them becoming shorter? In general, web pages are getting longer (The average web page has grown 20% in just six months See http://www.webperformancetoday.com/2012/11/15/average-web-page-grows-20-percent/), and that may also be true for web based Help content. This may because microformats such as RSS and Twitter help us with discovering information.

    3. The magazine industry is struggling the length issue. Some are arguing for sub-compact publishing – smaller five article magazines. See http://craigmod.com/journal/subcompact_publishing/ and the-magazine.org . Forbes magazine, Longreads and others have argued that long form reading is finding its place on the web, particularly when people are reading on a tablet device. See http://www.forbes.com/sites/lewisdvorkin/2012/02/23/inside-forbes-how-long-form-journalism-is-finding-its-digital-audience/ and http://longreads.com/.

    4. Techcomms best practice has implicit assumptions: people are using complex technology that can be expensive; it can be stressful for them; screen technology, such as resolution and refresh rates, limits writers to presenting information in short chunks; users are not interested in mastering or hacking the product etc etc.

    Technical Authors are living in a “it depends” world: it depends on your audience and product. The assumptions and best practices we work with were set 20+ years ago, and this means we need to check the underlying assumptions still apply in each situation.

    1. Tom Johnson

      Ellis, thanks for commenting. I always appreciate reading your thoughts. You’re definitely right to ask what search algorithm we’re targeting, as Google does favor longer content. I think tech writers have to consider Google (if help is accessible online) in addition to any site-specific search tools they’re using.

      Re #2, I argue the opposite in my post (or at least that was my intent). I prefer long topics over short ones. My next post contains the logic justifying the longer topics.

      Thanks for the tips about the magazine industry’s dilemma. I didn’t know about that. The links you shared are helpful.

      Re tech comm and complexity, you’re right that chunking complex material makes it more comprehensible, but it also makes it less comprehensible at the same time. One gets a very focused view without understanding the larger picture.

      Look for my upcoming post for an expansion of these ideas. Thanks for participating in the conversation.

  2. Jonatan Lundin

    The information science research field has struggled to understand the search behavior of users for many decades know. And indeed as you say, users are many times having troubles in formulating their information need. Already in 1962 a guy called Robert Taylor formulated a four step process which in really famous in the information science field. To make a short story long, users must formalize and compromise their information need to the information system they are using. That is, users must put a label on their thoughts and “convert” the labels to suit the system used.

    It seems that the information science field has for long abandoned to study how users search content that are organized into static hierarchies (TOC). This is what you refer to as browse, even though I my definition of browse seem to differ from yours.

    I do not really understand the discussion that small or big topics make it easier or more difficult to search. Ok, many small topics means a lot of nodes in my TOC which can intimidate a user. But if I have many many big topics, I also get many nodes in my TOC. I argue that whether small or big topics make search more effective depends on the information-seeking goal (see below). I have discussed that we need to leave the book paradigm and find other ways of organizing content, as described here http://www.excosoft.se/index.php/about-us/blog/item/48-what-are-the-alternatives-to-deliver-content-besides-static-book-like-manuals.

    The information retrieval research field has coined some terms that I believe are really important when we talk about search performance. There is something called precision and recall. When we search, we want high precision and high recall. The design of the search algorithm and how you formulate your query do impact the precision and recall.

    Now, there are also terms such as relevance and pertinence. Relevance means how relevant the retrieved documents are to the formulated query. Relevance is a research subject on its own and there are multiple definitions and views of relevance. Pertinence means how well the retrieved documents correspond to the actual information need of the searcher. Thus, you can get high relevance when using Google but low pertinence as the query including the keywords did not *correspond* to the information need. As you say, some humans, especially users of technology, are often bad at expressing their information need. Here, we can talk about search vocabulary and design vocabulary.

    As regard to the topic length I think you are simplifying a bit if you say that a topic must either long or short. To me, the topic length depends on the information-seeking goal of users and especially on the search goals and the reading goal (which are sub goals to an information-seeking goal). Some answers (=topics) must therefore be short and some long.

    The reading goal means how I use the information I have found. There are different levels of reading goal. The lowest level is when I in fact do not even read or try to understand the information I found, but just transfer it from one location to another. This is the case when my information-seeking goal is to find a part number for a spare part, when I am ordering a spare part. In this case, I want to find the part number in the manual and write it down on a piece of paper and then enter it in a order page in a spare part ordering system; I do not want to learn the part number or remember it. In this case, the topic must be really short.

    Another reading goal is when I want to for example learn how to do something in future. Here I want to understand what the writer (the topic) is trying to say and I want to incorporate and internalize the information into my own knowledge. In this case, the topic can be really long. If the answer to my search and reading goal, when I want to learn how to do something, is scattered across many small topics, I get frustrated. But if my search and reading goal is to get a part number for my spare part, I get happy getting a short topic.

    If we understand what information-seeking goal (search and reading goal) users have, we can better understand what content to embed in UI as onboard user assistance, what content to output to mobile devices and what to output to PDFs. Here, the four main information-seeking categories I commented on in your previous blog post, helps us understand these goals.

    1. Tom Johnson

      Jonatan, I like your analyses and generally agree with your points, especially about topic length and reading goals. I agree that the user who has a specific question has a different reading goal than one who just wants to learn. A person who wants to know the arguments a method accepts just wants the answer, while a person who is trying to figure out what the method does and how to construct a response from an API needs more information.

      The situation isn’t too unlike the scenario of writing to accommodate both beginning and advanced users. Some users want a little bit of info while others want more. If you chunk into tiny topics you frustrate the beginner while pleasing the advanced user. If you group information into more substantial topics, you frustrate the advanced user while pleasing the beginner.

      I have more thoughts on topic length that I decided to put into another post, so look for next post for more detail. I agree that some lower-order info might best exist in the UI. I also like using progressive information disclosure. But overall I think it’s better to group information into more substantial topics to help users get the whole story about a topic.

  3. Vinish Garg

    Ellis is spot on when he says “Technical Authors are living in a “it depends” world”. Even if we optimize the help manuals to address the findability requirements, I am sure different documentation teams have their reasons to plan for short and longer topics.

    For example, if the deliverable is a browser based help developed in a CMS, long topics should not be a strict no-no. In addition, we can have scenarios where a single procedure calls for long topics and the write struggles to divide it into smaller topics for logical reasons. I ran into similar conundrum last year when a procedure in the manual was ‘How to schedule a session’. Originally, I planned different topics for its sections such as ‘’Specify basic details of a session’, ‘schedule a session’, ‘publish a session’ but these appeared disconnected. The client was not happy either since a user will always need to see all the three topics to understand the complete procedure for how to schedule a session. I could not help it though there were cross references and ‘see also’ sections. Fortunately, I was doing it in WordPress, and as Eliis has also mentioned above, long pages are the trend in planning the UI for web pages. However when we planned its corresponding Quick Guide, we had different topics for each sub section though concise.

    So even though (a) the writers can have their preferences (b) tech comm community may have some recommendations, conventions and trends, and (c) we understand that ‘findability’ is critical, finally ‘it depends’.

      1. Vinish Garg

        Tom

        Thanks for sharing the two links. This is exactly what I meant when I advocated Ellis’s point of ‘It depends’. I envision that the online manuals will be a hybrid model of long topics and smaller topics, for beginners and advanced users respectively. Your post on ‘Progressive Information Disclosure’ few weeks back and a few comments on that post connect to this topic well enough.

  4. Pingback: Why Long Topics Are Better for the User | I'd Rather Be Writing

  5. shoba shanker

    Thank you for the good read Tom. There are two things in this post that peeve me:
    length of topic influences findability.
    users don’t use search functionality but browse using a static structure (TOC).

    I agree with Jonatan and Ellis. While the technical writer lives in a “it depends” world, the dependency is on the user goal. Instead of spending time on deciphering the length of the topic the tech comm community must focus on making the content findable by focusing on user goals. There are two sides to this coin too. One, is to make the information findable and the other is to make the information usable. There are myriad ways to make information findable: use semantic tags, devise a taxonomy that is intuitive to the user, use folksonomy and so on. In order to make the topic usable focus on the users’ information need making sure that the topic answers the user question. I don’t think the length of the topic would matter as long as, the user question is answered.

    While statistics might’ve shown that users tend to gravitate away from the search button, we need to ask ourselves “what if I make search central to my user documentation?” I think that a combination of search and browse is what users do to find information. We are getting too many things mixed when we say that the user does one over the other.

  6. Mark Baker

    RE: “In other words, if users don’t find the result with their first query, they are progressively less and less likely to succeed with additional searches”

    This is, of course, true. It could not be otherwise. Nobody searches a second time if they succeed the first time, so the very fact that a second search takes place indicates either that the information does not exist or the user does not know how to look for it. It would be a statistical anomaly of major proportion if success improved on subsequent searches.

    What Neilsen’s numbers actually suggest is that user’s succeed 79% of the time within the first three search terms they try. Considering that he is talking about site search on ecommerce sites, that is an astonishingly high number. I’d expect a far higher percentage of site searches to fail for the simple reason that the product people are searching for does not exist, rather than from any defect of the user’s search strategy.

    Re: “If users aren’t relying on search to find the information, they’re most likely browsing.” I disagree. Site search sucks, but that does not mean people rely on browsing, much less via a table of contents. One of the most important points about Web site design is that people do not use websites. They use the Web. They navigate via search and socially curated links and they land on your pages, not on your site. Your site’s own navigation is at best a secondary aid to navigation in the immediate vicinity of the page they have landed on. Every page is page one means also that every page is a hub of its local vicinity.

    That said, I agree with your conclusion that topics that are not complete page one topics will be harder for the user to hit. EPPO is good SEO. But on the other hand, I don’t think we should size topics to make TOC’s work. The most important thing about a topic is not how easy it is to find, but how well it works when found. (And, in fact, working well when found is great SEO, not to mention social curation optimization, which is something we should probably care about just as much these days.)

Comments are closed.