Suggestions for streamlining the table of contents

[julierawe]

There is so much terrific information in these guidelines, and we greatly appreciate your efforts to chunk everything into short, easy-to-digest sections. But the breadth and depth of this document makes it daunting to read and, as currently structured, even the table of contents (TOC) is hard to skim.

Below are a few aspects of the TOC that jumped out at my Understood colleagues and me, and some possible alternatives:

(1) Headers for each objective are repeated in the 3rd and 4th chapters.
Right now the eight design objectives appear twice as section headers, first in the 3rd chapter ("User Stories") and again in the 4th chapter ("Design Guide"). We understand the logic of presenting user needs before presenting design solutions, but the current approach creates a weird echo and we're not sure if it's essential to cluster all of the user stories together in their own chapter.

Possible ways to avoid repeating the objective headers in consecutive chapters:

• Nesting the relevant user story in the relevant design pattern (instead of starting each pattern by summarizing and linking to user story in previous chapter)
• Or keeping the "User Stories" chapter intact but moving it down—along with the "Personas" chapter—so both appear as appendices.

One benefit of moving the "User Stories" chapter down into an appendix is that this would push the "Design Guide" chapter up much higher in the TOC. We think most users will be pressed for time and will be most interested in the info about practical implementation: "Just tell me what to do and, if I'm really curious, I'll read why you're telling me to do it."

(2) Starting many headers with the same word or phrase ("Objective," "Pattern," "User Story") makes the TOC harder to skim.
Here are some ways the repeated use of "Objective," "User Story" and "Pattern" make it harder to skim the TOC:

• The repeated words make it harder to find/focus on what's new
• The repeated words make each section header longer and, in many cases, spill onto a 2nd line in the TOC

Possible ways to help reduce visual clutter in the TOC:

• Using dropdown menus to help users focus on the design objectives and to allow users to opt in to expand the amount of information presented about each objective
• Removing "Pattern" and "User Story" from the headers (these words would not be needed if you decide to nest the user stories in the patterns, as suggested above.

(3) The top two items in the TOC entries are hard to notice.
The "Abstract" and "Status of This Document" are harder to notice because they aren't anchored by the numbering system on the left. We think users are likely to skip over these "floating" items at the top of the TOC and start focusing when they see the "1."

However, we do not recommend numbering the "Abstract" and "Status" items. Instead, we recommend:

• Moving the current top 3 sections into 1 chapter called "Getting Started" or "Introduction"
• And/or combining the "Abstract" and "Summary" into 1 section and perhaps calling it "Overview"

---

If you make the above changes, and if you use dropdown menus, the streamlined TOC might look like this:

1. Getting Started
2. Design Guide
3. Usability Testing
   A. Appendix: User Stories
   B. Appendix: Personas
   C. Appendix: Mapping Design Objectives to User Needs and Personas
   (And any other appendices deemed essential)

Another option would be to turn each of the design objectives into their own chapter, so the TOC would look like this:

1. Getting Started
2. Helping Users Understand What Things Are and How to Use Them
3. Helping Users Find What They Need
4. Using Clear and Understandable Content
5. Helping Users Avoid Mistakes or Correct Them
6. Helping Users Maintain Focus
7. Ensuring Processes Don't Rely on Memory
8. Providing Help and Support
9. Supporting Adaptation and Personalization
10. Testing With Real Users
    A. Appendix: User Stories
    B. Appendix: Personas
    C. Appendix: Mapping Design Objectives to User Needs and Personas
    (And any other appendices deemed essential)

One benefit to turning each design objective into its own chapter is that it would make the TOC look very actionable and appealing to users. It would also help show at a glance that the recommendations in these guidelines can be helpful to all users, not just people with cognitive and learning disabilities. And last but not least, under this chaptering system, each objective would appear in boldface, which would be especially helpful if dropdowns aren't an option.

[SteveALee]

@julierawe Thank you for your detailed and helpful feedback on how to improve the structure and navigation of Content Usable.

We have almost finished the last few editorial tweaks to the document after a long period of substantial rework. We felt now was a good time to respond to you to say we have considered your suggestions along with others and have arrived at a set of improvements that we are happy with.

The document now has to go through a review process at W3C WAI and will then be publicly announced.

To address your points:

(1) Headers for each objective are repeated in the 3rd and 4th chapters.

This is a tricky and your suggestions are most welcome. The Objectives provide the top level organisation of the document, yet we have a constraint of limiting the number of levels. In addition, the Patterns, Personas and User Stories are all important enough to remain in the main document as separate top level sections. For now we have decided to leave this as is and accept the repetition.

(2) Starting many headers with the same word or phrase

We rephrased each of these in a way that improves readability in the Table of Contents and yet provides useful
orientation in the main text. Thanks for pointing this out.

(3) The top two items in the TOC entries are hard to notice.

These two items are mandated for all W3C TR documents such as this note. We have explored options but for now they will remain as is with some minor adjustments.

Finally, in addition, you might like to know that we are working on an interactive web version of the Design Guide. This will have have a page per Pattern, and so should provide a structure and navigation that is more accessible than a single,
continuous, static document format.