Why Long Topics Are Better for the User

In my previous post, Do Short Topics Make Information More Findable, I argued that shorter topics make it more difficult for users to find information. I ended the post by saying that topics that are more substantial make content more findable.

But how big should the topics be? Obviously not the length of a book, because that switches us right back into the book paradigm.

There’s probably not an exact way to determine topic length, because so much depends on the context of the information and the task at hand. But basically, a good topic answers a good question.

What’s a good question? Questions can scale to a low or high order, being very specific and mundane to being abstract and conceptual. A one-sentence topic might provide the answer to a question (e.g., How many feet are in a yard?), while a 300-page dissertation might provide the answer to another question (e.g., What was Chaucer’s influence on the Renaissance?).

In other words, you could construct the question so that it scales for any length of topic.

However, if you can construct an intriguing question (or at least a relevant question within the user’s business scenario), that question merits enough information for a good-sized topic.

The following table lists some good questions versus lower-order questions in what might be a help file for an SDK.

Good QuestionsLower-Order Question
How can I get started with the SDK?What does SDK stand for?
What kind of information can I access through the SDK?What is the user list property that the SDK returns?
How do I make calls with the SDK?What arguments does the constructor accept?
What methods are available to use?What information gets returned when there isn’t data?
How do I troubleshoot errors with the SDK?What does error msg 4555 mean?
What kinds of outputs can I use the SDK to generate?Can I create a list of users via the SDK?
How do you include the SDK library?Where should the library be included in the page’s code?
What are some best practices to make the calls perform faster?Can I use local storage to cache the library and increase performance?

The lower-order questions all lead to a quick one paragraph response. On the other hand, the “good” questions will require more detail.

Granted, not every system merits longer topics. For example, if you have an encyclopedia of birds, each entry is probably a bird description in your TOC. But for most help topics I’ve written, I think a good sized topic is usually around 500 to 1,500 words, with exceptions.

Why 1,500? In an earlier post I wrote, Making Help Content Enjoyable to Read — Impossible Question?, I noted that Clive Thompson of Wired magazine says the most popular blog articles are about 1,600 words in length (see “Clive Thompson on How Tweets and Texts Nurture In-Depth Analysis”). 1,600 words is about a seven-page double-spaced essay. Granted, that’s probably not a help article, but it bucks the idea that each web page should be short little snippets of thought.

Length alone isn’t much of an argument. So why do longer topics make content more findable? Here are several reasons.

Reason 1: Fewer Search Results to Sort Through

First, the obvious argument. If a user searches the help, there are fewer results to sort through if the topics are lengthier. For example, if you don’t present the user with 37 hits for “widgets”, it’s more likely that the user will open (perhaps among 5 choices) the right search result containing the answer.

Reason 2: Browsing Becomes More Practical

If users don’t find anything via search, they can browse the table of contents (TOC). Longer topics mean fewer TOC entries to browse through. The TOC that was once impossible to parse through is now something that users can glance at and get some meaning from.

Reason 3: Interconnected Learning Helps Users Learn More

Now for the insightful, compelling reason why long topics are better. Information that is grouped together increases the inter-relatedness of information, helping users see the larger picture about a topic they’re interested in.

For example, If you have 10 separate topics about widgets, the user may land on “adding widgets” and find a quick answer but not realize that he or she can also “fork widgets” or perhaps “decompile widgets.”

By grouping related information about widgets together, you increase the chances that users will broaden their understanding of a concept and leave with more knowledge than they arrived.

In short, browsing through a long page of content helps users discover what they don’t know.

Almost every grocery store uses the tactic of the long page. You arrive at a grocery store for milk, eggs, and bread. Almost always, the grocery store puts those items in the back of the store, forcing you to visually “sort through” all the other goods in the store. By the time you make it to the mlik section and then to the checkout counter, you’ve picked up a box of cookies, some lunchmeat, and some macaroni that was on sale.

Long topics create the add-on learning for your users. The user who just had a quick answer about hummingbird wingbeat speed suddenly learns that some hummingbirds weigh less than a penny, can live up to a decade, and are the only bird that can fly backwards. If all of that information had been separated out into discrete topics, the user would have probably walked away with the wingbeat speed answer only.

Try this experiment yourself. Click the following two images and check out the difference in content. The topic on the left, from Askville.com, is a short paragraph only, while the Wikipedia article on the right is quite a bit longer.



While the Askville page gives you a specific answer, the Wikipedia page gives you information that you didn’t even know to ask. Which approach to you prefer?

In summary, even if long topics don’t deliver information faster to the user, they’re a better practice because they help the user learn more through a tighter grouping of information.

Long Topics Are More Maintainable

I have a few other points to make about advantages with long topics — they are much more maintainable. If you have thousands of discrete topics in your system, not tightly connected together, maintaining the information as a coherent whole when you need to make updates becomes a nightmare.

For example, let’s say you have 20 topics about hummingbirds. Your subject matter experts push out new findings that change some aspects of our hummingbird knowledge. Now you have to hunt and peck around your help system for all the various topics that touch on hummingbirds. If the information were grouped together, you can more easily see the places you have to update.

Ways to Break Up Long Topics

So that my advice isn’t misconstrued, I’m not suggesting that every technical writer suddenly start creating long walls of text.

A page of long text needs to be broken up by subheadings, graphics, lists, and white space. A great reference for designing the visual aspects of a page (not necessarily adding graphics, but influencing the visual nonetheless) is Visual Composing: Document Design for Print and Digital Media. See also my post titled Subheadings: Perhaps the Most Useful Technique in Technical Writing.

When a Topic Is Too Long

Although I like longer topics, there’s a practical limit to a topic’s length. When I’ve gone over 2,000 words with my blog posts, I’ve noticed that the comment count plummets. The web form doesn’t work well with really long content. That’s why I actually broke this post and its predecessor into two parts.

While blogging and tech comm are separate genres, the predominance of blogs on the web has set a trend for expected article length and attention span online. A good editorial is usually about 800 words for a reason. Just as a Windows PC has trouble moving around information more than 2GB, our brains also have trouble working in 2GB topics. Shorter is cognitively easier to handle. But not too short.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

  • http://www.straygoatcopywriter.co.uk craig wright

    I think you’re right in some aspects, but I can’t help but think that 1500 words per topic is too long. Even with white space, that’s quite a lot of content for a single page. If sub-headings can be used, then those sections could (and some would argue, should) be in separate, referenced topics. Personally, I’d look for a topic to be 800-1000 words, with links to relevant information. That’s not a hard-and-fast rule, of course.

    Another thing you haven’t mentioned is the medium being used to read the information. Reading long topics on some mobile devices can be off-putting (smart phones especially).

    I hate to say it, but I have a nagging suspicion that age and culture may be an issue too. In years to come, it may be that short and sweet topics are the norm simply because that’s how that generation of writers and readers communicate. It seems that everything is ‘bite size chunks’ these days.

  • http://idratherbewriting Cindy Caldwell

    Re: The article “Why Long Topics Are Better for the User”
    Good information. But, there’s a boo-boo. “Plumits” isn’t a word. Try “plummets.” :)

  • http://www.excosoft.se/index.php/about-us/blog/item/54-why-is-the-result-often-a-million-little-pieces-even-though-dita-does-not-encourage-authors-to-fragment-information-in-such-a-way-a-million-littl Jonatan Lundin

    One aspect that impacts how long a topic should be is, what in SeSAM is called the assumed knowledge level. Every user in the target group has an actual knowledge level and as a technical writer you are assuming that users have a certain knowledge level. The assumed knowledge level is, very simplified, the average actual knowledge level. As a consequence, there are often many assumed knowledge levels such as novice and advanced users for a typical product.

    So the length of a topic, answering a question such as “What kind of information can I access through the SDK?”, must differ to a great extent depending on if the topic is written for a novice user or an advanced user. You say that a topic answering a good question is about 500 to 1,500 words, but what knowledge level are you then assuming?

    I like your reasons to why topics should be rather long. But I’m not sure that long topics are better for the user. For Re #1 you are assuming a Google kind of result list. I’ve seen articles that say that users only open the three first results no matter their length. So a result list of 5 or 37 topics would probably not matter? Also, if we are talking about a guided faceted navigation interface (as the mock up you saw the other say) the user will end up, after having done some 4 or 5 selection, with hopefully only one (1) answer left to examine. So there is no catastrophe if the first fact selection yields some 37 topics.

    Re #2 is a somewhat moving target? If I have many small topics, the TOC becomes big. I then make the topics bigger and the TOC gets smaller. But what if I have many big topics? Then my TOC gets big, but it is a bad solution to make the big topics even bigger just to make the TOC small? But I agree that small topics in a TOC often make you frustrated. But we shall soon leave the book paradigm, so why worry 😉

    Regarding Re #3 your making an interesting point that users may stumble over information they recognize they need when seeing it, but could not recall needing it. This is called serendipity which is a word coined by the English writer Horace Walpole in The Three Princes of Serendip to refer to the knack of making fortunate discoveries unexpectedly, by accident or coincidence.

    My view point is that the main factors that impacts topic length (that is, is the answer to a user question) are 1) the type of user question which must be derived from predicting the user information-seeking and reading goal. And 2) the assumed knowledge level.

    There could be reason to make a short version topic, that answers a broad question such as “What kind of information can I access through the SDK?”, when we output the content to a mobile. Then the topic should have a reference to the full version available elsewhere. This is what we often do when we embed UA in the interface. A short version of the topic is embedded and then we supply a link to the full length version.

  • Eileen Bator

    I think we are walking on thin ice when we compare Help topic lengths to blog entries, editorials, and magazine articles. A person using a Help system usually comes to the topic text with an expectation of short-and-sweet, to-the-point, just-in-time information to get back to work. A person reading a blog, editorial, or article is often not in such a hurry, and expects to be “entertained” for a longer amount of time, to dig deeper into a subject area (not necessarily a topic) for information. Help reading is often work related; blogs, editorials, essays, and articles often serve other purposes where the reader’s attention span is tuned to a more leisurely pace. Expectations and assumed knowledge level vary greatly. Blog entries may, indeed, tell us what a reader’s tolerance level is for length, but that doesn’t mean that the Help reader has the same tolerance.

    • http://everypageispageone.com Mark Baker

      I agree with Eileen. Topic length tolerance is proportional to motivation. Fewer people will attempt the more difficult tasks and subjects that demand longer topics. But that does not mean that topics should be made shorter than they need to be to meed the needs of those who do attempt the more difficult things. Proper topic length is not an absolute, or even an average; it is based on need. More on that here: http://everypageispageone.com/2013/05/13/fewer-people-read-longer-topics-and-thats-okay/

  • http://www.app-developers-india.com/ Modan Farhan

    Long topics title gives brief information about the content of the article, for the seo perspective it’s provide long tail keywords ranking for better traffic.