Applying Progressive Information Disclosure to Online Help Navigation

At the last STC Summit, Andrea Ames gave a presentation on progressive information disclosure. If you follow progressive information disclosure, you avoid giving the reader all the information up front. Instead, you present a little bit of information to the reader and then let reader choose to view more if he or she wants.

A classic example is on-screen help text that presents a brief sentence followed by a “Read more” link, which takes the reader to a more detailed explanation on another page.

Many websites follow progressive information disclosure techniques with their navigation. On the top menu of a website, you see a dozen or so main buttons.  When you select a topic, the landing page for that topic presents you with many more specific options. Some people differentiate these two types of navigation menus as “main navigation” and “local navigation.”

For example, go to Amazon.com. Browse the main topics in the left sidebar. Click Books, and then from the flyout menu, choose Books again.

After selecting Books, you arrive at a landing page that has a lot more granular options relating to books. You can click Best Books of 2011, Summer Reading, Summer Reading for Kids & Teens, Best Books of the Month, Kindle Books, Textbook Store, twenty or more book categories, and many more options (which I’ve highlighted in the image below)

If Amazon were to present the reader with all of these options up front, on the home page, it would overwhelm the reader. And yet, this is exactly what help authoring tools set you up to do.

Aggressive Information Expansion

The classic webhelp file presents a table of contents on the left. You expand a book and find additional topics and sub-books inside. You expand the sub-books to view the topics inside of them. Hopefully there aren’t sub-sub-sub-books, but sometimes there are.

For fun, open up all the books in an online help file and look over the topics. Rather than following a progressive information disclosure model, webhelp systems follow an aggressive information expansion model. 

Here’s an example from Flare’s help:

And from Microsoft:

(By the way, I am by no means criticizing the help content. Both Microsoft and Madcap have excellent help content. I’m only pointing out that typical webhelp files do not embrace progressive information disclosure in their table of contents (TOC). Instead, we load up our TOCs with all the information we can possibly fit in there, assuming the user will browse for the topic he or she wants among hundreds of options.)

My brother-in-law job-shadowed me the other day at work, and as I opened up all the topics in one of my help files, he said his eyes just glazed over all that information. He said in seeing all those topics, his first reaction was to close that help file and look at it some other time [meaning never].

Presumably, one advantage to presenting the reader with so many options is that the user can quickly navigate to the right topic without wading through page reload after reload, moving to one topic after another to see if the content the user is looking for. Traditional websites don’t offer this navigation speed.

But most users get intimidated by a massive table of contents. It makes a help system appear much more complicated than it really is. The intimidation factor alone is enough to consider another approach.

Applying Progressive Information Disclosure to Help

The neat thing about progressive information disclosure is that it tricks readers into browsing and reading more information than they initially set out to consume.

My wife uses progressive information disclosure on our kids all the time. For chores, she asks them to unload 20 items from the dishwasher. Just 20, she will say. So the kids begin to unload 20 items, and before you know it, the kids have unloaded much more than that.

Sometimes it’s better if people don’t know everything they’re getting into.

The other day, I tried setting up my help according to a progressive information disclosure model in Flare. I narrowed down the topics to about 10 topics in the TOC (left sidebar). When you click a topic, you see a sidebar on the right that lists tasks related to that topic.

The right sidebar shows information from a relationship table. You only see those topics after selecting a topic from the table of contents on the left.

Unfortunately, this model cuts against the way Flare was designed. Each time I compile the help, I see warnings for topics that aren’t listed in the table of contents but are nonetheless linked in the help. It’s as if Flare wants me to list everything in the table of contents.

As I fiddled around with this approach, I decided to bag it. My brother-in-law pointed out how the links look similar to ads in gmail. The eye barely notices them. And navigating them felt odd, because with relationship tables, the page you’re viewing isn’t listed in the table, so the nav options kept changing with each click.

Hotspots

Another technique might be to include more topics as drop-down hotspots on the page itself, taking advantage of jQuery effects to show and hide content.

For example, you could begin the topic with a two paragraph conceptual explanation, followed by a “Read more” link that would expand to show more detail if the reader desired to read it. Below the conceptual intro to the topic, you could have various tasks collapsed in drop-down hotspots.

Flare help uses this technique a lot:

And I’ve also used it in my help:

My brother-in-law preferred this method because it gives readers options to see more if desired. And it doesn’t overwhelm the reader with too many topics in the table of contents.

Keeping Information Together

Embedding drop-down hotspots on a page may work better than splitting out the topics as separate entries in the TOC because it keeps the information together. In Designing Web Navigation, James Kalbach says,

Content might not have the same impact or meaning when it’s broken up into multiple smaller pages. … Keeping things together creates a antural relationship between pieces of information. (p.114)

Keeping similar information together helps prevent information fragmentation. Information fragmentation is precisely what happens when you separate information into a million topics in the TOC.

When you over-fragment your help information, the user may land on the page from a search and never realize that the tasks related to a concept are on separate topics from the concept itself, or that the concept lives somewhere other than the tasks, or that one task similar to another task is to be found on another topic.

One of my colleague’s pet peeves is to see a help topic that says she can do something but no details on how to do it. The task for the concept lives somewhere else.

Keeping similar information together as a coherent unit helps users navigate to the right place. And hiding that information in hotspots follows progressive information disclosure, since it lets users choose whether they want to read that information or not.

Adobe RobohelpMadcap Flare

This entry was posted in findability on by .

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm primarily interested in topics related to technical writing, such as visual communication (video tutorials, illustrations), findability (organization, information architecture), API documentation (code examples, programming), and web publishing (web platforms, interactivity) -- 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, email, or another method. To learn more about me, see my About page. You can also contact me if you have questions.

12 thoughts on “Applying Progressive Information Disclosure to Online Help Navigation

  1. Mark Baker

    Hi Tom.

    Very interesting. I had not considered progressive disclosure as something that applies to a table of contents, though online tables of contents have always had it in the form of hierarchical listings in which you can open or close the contents of a book or a section.

    I’d only connected progressive disclosure with showing more detail in the context of a particular task. So, for instance, if you have a procedure for changing a tire, step one might be “Jack up the car”. Some people will know how to jack up the car and some won’t, so rather than giving the full procedure for jacking up the car inline, you make it a link. If people click on the link, they see the procedure for jacking up the car.

    It is interesting to consider how analogous that is to the mechanism for allowing a user to navigate a large collection of things by showing and hiding categories and subcategories of things, which is what a TOC or Amazon is doing.

    Do the same principles apply? Are the advantages and disadvantages the same in each case. I’ll have to ponder that.

    One interesting thing about progressive disclosure as applied to an individual piece of content is how it jibes with user’s ability to recognize content by shape, which you talked about very recently. Applying progressive disclosure to a page could hide the shapes, thus hindering the reader’s ability to find content by scanning.

    While this would not always be the case — it is not the case in the “jack up the car” example, for instance — it is worth pondering if it is a technique that assumes that readers prefer drilling down over scanning.

    The question would seem particularly pertinent in you help TOC example. I think drill-down behavior is theoretically superior as an information finding technique, but it assumes a degree of certainty on the users part, and a match between the user’s classification instinct and the writer’s, neither of which may exist in the real world.

  2. Lopa

    I like this approach. It’s interesting, and I like the fact that the reader chooses to view what he/she wants. Moreover, finding a topic in a lengthy over crowded TOC always scares the user.
    I have seen this approach in many websites but have not been able to implement it because of the warning that Flare keeps popping up while generating the TOC!

    But I will try the hotspots method.

  3. Vinish Garg

    Tom

    First things first, thanks for the terms *aggressive and progressive information expansion systems*. While planning different types of information expansion models, I would often struggle to refer it by an appropriate name.

    Over last few months, I have realised that Progressive Information Disclosure is the preferred flavor with product owners. I developed a knowledgebase 3 months back, with an architecture comparable to http://www.getharvest.com/help, and I am working on another knowledgebase that is somewhat modelled on Skype Support Centre.

    However, even within a traditional Help system such as a WebHelp, we have scope for both–aggressive as well as progressive information expansion system. For example, I am in talks with a business for documentation of its ERP system, and another one in automatic-file-renaming system.

    The ERP system is for internal users (for instructions on customers, suppliers, inventory, invoices, payments, and timesheets). So, this help system need to be so planned that (a) all users may need to refer to documentation instructions to understand any feature or task, anytime (b) a user who needs to see instructions on how to approve a timesheet is likely to be interested to know about invoicing parameters and payment notifications settings. So, planning an *aggressive information structure* makes more sense, thus making all information available in a consolidated TOC.

    However, the automatic-file-renaming system has two types of users, basic and advanced and each user set may need to refer to a particular set of instructions depending on their roles. In this case, planning it for *progressive information expansion* makes more sense to me since user can explore what exactly they need, rather than dealing with a comprehensive TOC.

    Now the point is how we plan for *progressive*version. In your screen of *Calendar Management* topic, does it address requirements of advanced users who are familiar with the system; they are looking only and specifically for instructions on *how to approve calendar* and not an introduction to calendar management?

    Fundamental questions such as which expansion system makes more sense in the help system, and secondary questions such as how much information fragmentation is too much, are best addressed at audience analysis stage, and that brings us back to one of the fundamental principles of technical documentation–understanding the documentation audience.

  4. Jeff Coatsworth

    It would be quite cool if the tools we have to create helps systems were able to dynamically re-tool their ToC every time you narrowed your scope (a la your Amazon.com example). I just don’t think they support the display of multiple ToCs when required.

  5. Pingback: Using the Proximity Principle to Design Online Help Navigation | I'd Rather Be Writing

  6. Just Plain Karen

    Hi, Tom.
    Informative as always. I appreciate the thorough explanation as well as your honesty about its use in Flare.

    One of your comments grabbed my attention. Why do we need to “trick the user” into reading more than they’d intended? I think users just want to get into the help, find what they need right away, and get back out.

  7. Pingback: It’s Time To Start Separating Content From Behavior | The Content Wrangler

    1. Just Plain Karen

      I agree, but I think we’re confusing sales sites with online help systems. Amazon and others might use it because they want to sell; thus, the more time a user spends on a Web site, the more likely they are to buy something. Since Tom’s article was about online help, I think it’s disingenuous to use this technique to keep the user in the help system longer than they want or need to be there.

      1. Tom Johnson

        Thanks Just Plain Karen for your insight. I think you bring up a valid point — motives between sales sites and help sites might be different. But “disingenuous” seems a bit extreme. I think with help sites and progressive information disclosure, my main point was to avoid overwhelming the reader, not so much to trick the reader. But even if we give the illusion of simplicity, and the reader ends up browsing and staying longer than expected, isn’t that a good thing? Often users don’t know what they don’t know, until they browse around and read the help.

        1. Just Plain Karen

          Hm, I see your point then. Definitely agree: If users get more out of opening a doc/help system than they were hoping for, that’s an excellent thing; I just wouldn’t want to ask them to stay any longer than they absolutely have to. Your posts are always thought-provoking, Tom!–JPK

  8. Pingback: Subheadings: Perhaps the Most Useful Technique in Technical Writing | I'd Rather Be Writing

Comments are closed.