|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2007 --> Hierarchies in online information: balancing depth and breadth
Vous êtes ici : Essais --> 2007 --> Hierarchies in online information: balancing depth and breadth
by Geoff Hart, Fellow
Previously published as: Hart, G. 2007. Hierarchies in online information: balancing depth with breadth. Intercom November 2007:38–39.
Books package information in a single object subdivided into chapters and sections. Moving books online strains that paradigm, because even when the information is packaged in a single file, users encounter it in a series of self-contained chunks (windows). With a low-complexity document, such as a short newsletter containing a handful of articles, a single scrollable window suffices; readers can read articles without opening more windows. With an insanely complicated document, such as the online reference to the Planet Earth Operating System® (PEOS), using a single scrollable window would be impractical: readers will prefer to open new windows rather than scrolling endlessly within a single window.
You'll often hear that information chunks must be small and self-contained. Though there's some truth to this, it can mislead us into producing (in extreme cases) pages that contain nothing more than a few lines of text describing a single menu function. That's acceptable for reference manuals, whose primary goal is to explain single functions, largely without reference to their context. More often, readers focus on tasks: they don't care about individual functions, but rather about how to accomplish tasks by combining those functions. Then, our design must group the necessary information for all parts of a task (so readers don't have to assemble the information themselves), and must eliminate extraneous detail so readers can focus on only the important details.
In short, we must aim between the newsletter and the PEOS manual, without sacrificing the benefits of either—respectively, packaging all the information we need in one place, versus separating less-relevant information into different windows. In this article, I'll show how understanding hierarchies lets you choose an appropriate balance.
Grouping of information has been the subject of much research, much of it related to hierarchies—the order in which information is grouped. That's an abstract concept, but one with clear practical implications. Consider the example of a library, with book being the top level of the hierarchy, chapters the next level down the hierarchy, chapter sections (indicated by headings) at the next lowest level, and so on (Figure 1). In this example, the hierarchy is both wide (1000 books) and deep (six levels, from book to sentence). Compare this with the menu structure for a simple program (Figure 2): here, the hierarchy is both narrow (only two menus at the top) and shallow (only two levels, menu and menu choices).
Figure 1. A wide and deep hierarchy: that of a library.
Figure 2. A narrow and shallow hierarchy: that of a simple program.
Choosing an effective combination of width and depth is tricky. In online information, a wide but shallow hierarchy is often most effective. Users of the hierarchy pay a cost whenever they navigate a hierarchy: if they choose incorrectly at the top level, they may travel deep into the hierarchy before discovering they took the wrong path, and must then retrace their path to the top and start again. A wide hierarchy provides clearer distinctions among the alternative paths into the information, thereby reducing the risk of following the wrong path; a shallow hierarchy minimizes the cost if readers reach a dead end and must return to the top to try again. This cost is measured in mouse clicks (one click on the "Back" button per level of the hierarchy) and mental effort (remembering the full path). The latter cost relates to Miller's famous "magic number seven": most of us can hold about seven chunks of information in working memory simultaneously (in this case, seven links that were followed), and the closer we approach this limit, the more difficult it becomes to remember how we got somewhere. For wide, deep hierarchies, it's helpful to provide "bread crumbs"—a series of clickable links that shows the path followed to reach the current location (Figure 3). Bread crumbs reveal the hierarchy, thereby eliminating the cost of holding it in working memory; clickable links minimize the cost to return to a previous level in the hierarchy.
Effective Onscreen Editing --> Chapter 4. Personalizing your software --> Track Changes Settings
Figure 3. An example of bread crumbs for the Library in Figure 1.
To support users performing a task, we should present most of the information required to perform the task in one place (a single window), thereby eliminating the need to open a profusion of windows or follow a long and branching path through a deep hierarchy. Determining the required amount of information is a difficult task, and requires a much longer article. Here, I'll illustrate that task by example. (Requirements analysis may become a future article.)
Once you understand how much information must appear in a single window, a simple trick makes the window's hierarchy clear: Start the page with a table of contents (TOC). This provides instant feedback, without needing to scroll and scan, about whether the window answers the reader's question. If so, they can read on; if not, you've minimized their cost because they can return immediately to the previous level and try again. Next, hyperlink each TOC entry to the corresponding heading in that window to provide one-click access. Because some users haven't yet learned about the "Back" button (or keyboard shortcut) in their browser, add a "Return to the top of this page" link at the end of each section to provide a one-click return to the TOC.
To further clarify the context, add a statement before the TOC that explains how it works: "This page contains the following topics:" When combined with the underlined (thus, hyperlinked!) text for each heading, this says two things: first, you can click a list item to go to that topic; second, you won't leave the current page and have to retrace your path through many windows. The latter is important: it's easy to become hopelessly lost following a series of links, and explicitly stating this won't happen is tremendously reassuring.
You can adapt this technique for tasks that comprise many subtasks. Here, the first window readers see starts with a description of the overall task, then lists the steps (sub-tasks) required to accomplish that task—similar to a TOC, but for the steps in a procedure rather than the headings in a window. If readers only need a reminder of the sequence, they see it all in a single screen. But if they need details for any step, clicking that step takes them to the details.
I prefer to open the topic that contains the details in a new window so that the original window (the overall sequence) never disappears; that window provides a safe home port in an uncharted sea of information. I also try to open no more than two windows simultaneously, because many readers object to spawning an endless stream of open windows. (Readers can always force more windows to open using the "Open link in new window" command.) Already-followed links are highlighted by a color change, thereby providing a checklist: readers see at a glance what steps they must still perform (i.e., ones whose color hasn't changed) to complete the task. Again, you can clarify how this works: "Click any step to open a new window that provides details. When you're done, close that window to return to this list of steps."
For complicated tasks or bodies of information, combine these various approaches. Thus, the first window provides a TOC that lists the sub-tasks described in that window. Each sub-task lists the steps to accomplish that sub-task, and each step links to a new window that provides details of that step.
The approach makes good sense, and is supported by some research, but it's not a "best practice" that applies to all situations. I've used this approach successfully in several previous help projects and in online newsletters without a single complaint and with occasional compliments. But if you're going to unleash this on your own audience, test it first to ensure that they like the approach and can use it effectively.
©2004–2024 Geoffrey Hart. All rights reserved.