Unconscious Meaning Suggested from the Structure and Shape of Help

I’m continuing to make my way through James Kalbach’s book, Designing Web Navigation. In chapter 2, he says the structure and format of content helps users anticipate the meaning of the content. He writes,

The human visual system naturally seeks structure in information, often very rapidly. Scientists refer to this as “pre-attentive” processing. This occurs in such a way that interpretation of a display is determined by the design itself. People can therefore infer relationships between elements on a web page before actively reading the page. This sets the stage for subsequent interactions. (p. 39)

We do this pre-attentive processing all the time. As an example, Kalbach says if you were to format a telephone book entry as a dictionary definition, users would assume the content was a dictionary definition rather than a phone list. Similarly, if you were to replace the telephone list with a lot of Xs rather than real content, users would still guess the list referred to telephone numbers, because the structure and format of the content suggests its meaning.

Here’s another example, more related to help content. Based on the shapes below, what kind of information you would find in each one?

Shapes of content. Can you predict the type of information from the shape alone?

Did you guess that the first shape would explain conceptual material, the second, how-to instructions, and the third, reference information?

DITA has a strong influence in this area. Help topics typically fall into three main formats: concept, task, and reference.Rob Hanna, in his presentation on Information Ecosystems, says these three formats roughly reflect a beginning (concept), middle (task), and end (reference) pattern, so in that sense, DITA ties in with a larger story archetype.

Styles and preferences vary here, but in general, concepts are formatted in paragraphs, tasks in lists, and references in tables. When readers see information in paragraphs, they know the information will explain conceptual information. When users see a numbered list format (1, 2, 3), they know the information will contain sequential instructions for doing something. When readers see a table, they know it contains reference information.

Minimalist style enforces this shape of help. In minimalist style, task topics don’t have any introductory paragraph information at all, except for one or two sentences. As a result, after the topic heading, you dive directly into the numbered list. Here’s an example:

Add new posts

  1. In the Dashboard, go to Posts > Add New.
  2. Type a title and add content in the body of the post.
  3. In the sidebar, select a category and add descriptive tags for the post.
  4. Click Publish.

This task does not explain when or why you would create a new post, or SEO strategies for posts, or what kind of content you might explore in the posts you write. That information would more suitably fit a concept topic. Instead, you jump directly into the list of steps, without even a stem sentence to introduce the list (such as “To add a new post:”).

In contrast, here’s a concept topic:

About posts

If you want your blog to be visible and read, you need to publish posts on a regular basis — usually about three posts a week. This can require a good deal of time, sometimes two or three hours per post. This time can easily add up to a part-time job, taking you away from time you might otherwise spend with your family, exercising, or developing other talents.

Because blogs require the same amount of time as a part-time job but often don’t pay much in return, you should explore topics on your blog that you find personally enjoyable. The compensation should be writing itself and the enjoyment that comes from creatively exploring topics you care about.

To find what you’re passionate about, consider answers to the following: what do you read/do/think about in your spare time? What direction do you want to be moving in your career? Remember that regardless of the topic you choose, you’ll most likely fall back to writing about what you know. If you’re involved in writing help documentation all day long, you’ll probably have a lot to say about documentation strategies on your blog.

This can be both a good thing and a bad one — good because your experience gives you a foundation of content to explore, bad because you may be tempted to write only what you know, rather than exploring unfamiliar but potentially more rewarding topics.

You’re soaking in the concepts, right, without any expectation to actually follow a series of steps. You could have guessed that by merely glancing at the format rather than reading it.

Finally, here’s a table format:

Rich text editor reference

The following buttons appear in the toolbar when writing new posts.

Add MediaAllows you to upload photos and other media, resizing the uploads in the three sizes set in your Media Settings page.
BlockquoteIndents a paragraph of text, usually setting it off in a graphically appealing way.
Align buttonsAligns text right, left, or center. If you’re trying to align an image, don’t use these buttons. Instead, use the image classes in the picture editor.
Insert More TagBreaks a post into two parts, with the first part shown on the home page. The second part is visible when users click the post title and view the post in the single post view.
StrikethroughPuts a line through content to show that the content is no longer valid.
Bold, ItalicFormats the content as bold or italic. The tags added are <strong> or <emphasis> rather than <b> or <i>. This provides more information about the semantic nature of the tags.
Toggle SpellcheckerSpellchecks your content by adding a red squiggly line under words that are misspelled.

 Mixing content types

It seems rather straightforward to organize help like this, but content does get more complicated. Suppose you have a two-paragraph conceptual explanation for a topic. Do you separate this conceptual information into its own concept topic? If you leave it in the concept mixed in with the task, does this mixing of structures make it more difficult for users to anticipate what the information will cover? Here’s an example. Quickly glance at what follows and consider whether the structure lets you know what the content is about:

Writing posts

If you want your blog to be visible and read, you need to publish posts on a regular basis — usually about three posts a week. This can require a good deal of time, sometimes two or three hours per post. This time can easily add up to a part-time job, taking you away from time you might otherwise spend with your family, exercising, or developing other talents.

Because blogs require the same amount of time as a part-time job but often don’t pay much in return, you should explore topics on your blog that you find personally enjoyable. The compensation should be writing itself and the enjoyment that comes from creatively exploring topics you care about.

To write a new post:

  1. In the Dashboard, go to Posts > Add New.
  2. Type a title and add content in the body of the post.
  3. In the sidebar, select a category and add descriptive tags for the post.
  4. Click Publish.

Many people write help this way, mixing the two. But I believe it’s generally a bad practice. Dividing the two would make the forms clearer to the reader.

About posts

If you want your blog to be visible and read, you need to publish posts on a regular basis — usually about three posts a week. This can require a good deal of time, sometimes two or three hours per post. This time can easily add up to a part-time job, taking you away from time you might otherwise spend with your family, exercising, or developing other talents.

Because blogs require the same amount of time as a part-time job but often don’t pay much in return, you should explore topics on your blog that you find personally enjoyable. The compensation should be writing itself and the enjoyment that comes from creatively exploring topics you care about.

Write a post

  1. In the Dashboard, go to Posts > Add New.
  2. Type a title and add content in the body of the post.
  3. In the sidebar, select a category and add descriptive tags for the post.
  4. Click Publish.

Heading formats

The structure of headings poses more questions as well. The structure of a task topic differs from a concept topic in the verb tense of the topic. For the concept, I wrote, “About posts,” and for the tasks, “Add new posts.”

Using the gerund form would be more ambiguous. For example, does “Writing posts” address a task or concept? By adding the word “about” or “overview” in the topic, it helps identify the topic as a concept.

As far as reference topics are named, I don’t have a clear style defined for this, but I would probably use a form similar to concept topics.

Your feedback

I am interested to hear how you organize and name your help topics based on these three types of information. Do you have a clear way of styling verb tenses in your topic titles? Do you set off concept topics with “About” or “Overview”? Do you allow a few sentences before the task begins, or do you always put conceptual information into its own topic?

And if you always keep concepts separate from tasks, do you divide these two kinds of information into separate table of contents entries, or do you stack them together in the same topic under different headings?

follow us in feedly

Madcap FlareAdobe Robohelp

This entry was posted in findability, general 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.

10 thoughts on “Unconscious Meaning Suggested from the Structure and Shape of Help

  1. Larry Kunz

    Tom, the answer to your question — Is it OK to mix a little bit of conceptual content into a task topic? — depends mostly on how you’ll reuse the content. If the conceptual content will accompany the task steps in every instance, then I think your first sample (titled “Writing posts”) is fine. Remember that keeping it all together in one topic means that the reader won’t have to click a link to move from conceptual content to task steps. Remember also that, as the reader of the topic, I can easily employ Kalbach’s “pre-attentive” processing” and skip to step 1 if I don’t think I need the conceptual content.

    However, if you want the task steps to appear sometimes with the conceptual content and sometimes by themselves, then you should develop both as separate topics. Additionally, if the conceptual content runs to longer than two or three paragraphs — and especially if it would push the steps “below the fold” when viewed on whatever equipment your readers are likely to use — then you need separate topics as well.

    Whew. That sounds more long-winded than I thought it would. Hope it’s helpful.

  2. Fer O'Neil

    While I agree that humans process visual information in the structures you discussed ‘today,’ I think that a great leap is made by attributing it to an innate “human visual system”. I’m not familiar with Kalbach’s research on this and whereas I assume that it’s true that human beings “seek structure in information” [citation needed], I wonder whether this is an intrinsic human quality or a result of generations of literacy. These may be the structures prevalent today but in the future (the future is now!) these systems and structures could be as varied as styles and preferences. Mind maps, videos, and augmented reality are early indications of possible changes to how humans visualize information.

  3. Helene B. Markussen

    For online help, I use “Overview” topics to present conceptual information and keep procedure topics separate, sometimes with one or two explanatory sentences at the beginning of a procedure topic. I always use active verbs such as “Create”, “Add”, Edit” in procedure topic headings.

    If the conceptual information in a procedure topic is short, and serves the purpose of a short introduction to or explanation of the task at hand, I agree with Larry Kunz that it makes sense to save a click and include a small amount of explanatory text in the procedure topic. For longer conceptual (overview) topics, in which I also may include a screenshot explaining the various parts of the screen in short help text style, I prefer to keep those as separate topics.

    Fer O’Neil’s comment on future information structures is very relevant. I agree that we will most likely see changes in the visualization and understanding of information structures, both deriving from existing technologies, but also from new mindsets and perceptions, and tech gadgets that we can’t even imagine today.

  4. Lopa

    Hi Tom!
    I was very delighted to see this post today, especially because I was contemplating on this concept. The SME was of the opinion that the TOC should include a list of topics that begin with “How do I?” I am completely against this idea, because I feel this unnecessarily lenghtens the topic name, and the task verb loses its significance in the long sentence. For example,”Creating Reports” is much more eye-catchy than “How Do I Create a Report”. Having a continuous verb gives a feeling to the user that it’s a task topic, and also instantly highlights the task at hand.
    Concepts should generally be kept separate from topics as long as they are very descriptive. I feel mixing concept and task topics is okay in case the concept is very important for the task to be performed.
    Having a stem sentence is important, especiallyfor tasks that have a concept preceding them. For a task topic that directly starts below the heading “Ctreating Reports” need not necessarily have a stem sentence.

  5. Mark Baker

    Tom, I stared at those shapes for some time and I did not get concept, task, reference from them. I was trying to fit something more specific to them: shopping list? photo album? list of tweets?

    I have no way to know for sure, but I suspect that most people, insofar as the recognize information by shape, probably recognize far more specific information types by far more specific shapes and combinations of shapes. (The single information type I suspect is most easy to recognize by shape is the recipe, which is a specific combination of several shapes, not on shape.

    If anything, I should have been more likely to recognize them as categories, since I have spend so much of the last few years battling the tyranny of the terrible troika. But I didn’t. I don’t think we recognize abstract concepts by shape; I think we recognize specific things by shape.

    I also think it does not matter. As tempting as it may be to overturn our whole design philosophy based on the latest tidbit of cognitive research, I don’t believe that the work put into this kind of thing returns anything like the value of working on the thing that readers actually value: helpfulness.

    On the subject of mixing concept and task content, your example is a bit of an Aunt Sally. That text clearly should not be used to introduce that procedure, not because it is “concept” and the procedure is “task” but because it introduces the whole subject of tasks generally, rather than introducing the task of posting specifically.

    A task topic should include everything a user needs to do the task, which include any information they need to understand the task. A procedure is not a task. A task is something the reader needs to accomplish; a procedure is how to manipulate a tool. There is more to say about most tasks than how to manipulate the tool, and that information is integral to the task topic — it should not be arbitrarily carved off to sacrifice on the alter of reuse.

    1. Tom Johnson

      Mark, thanks for your comment. I didn’t quite get your reference when you said you have been “battling the tyranny of the terrible troika” when it comes to categories. If you want to expound on that, I’d be interested to know what you meant. (On my blog, I use categories only for major content differences (podcasts, guest posts, book reviews, and blog posts) and tags for everything else.)

      Re tasks including everything a user needs to do the task, I find this interesting. I thought minimalistic style, as taught by JoAnn Hackos, would limit introductory information in a task to just a few sentences. Are you critical of that style? I’m not sure how one decides what kind of information is necessary to complete a task. In the examples I used above, would one need to know what each of the rich text editor buttons does in order to complete the task of writing a post? Probably not, but they would need to know some of the information, so it’s fuzzy to me where one draws this line.

  6. Lopa

    Mark’s comment provides a lot of insight. I am in full agreement with the last paragraph “A task topic should include everything a user needs to do the task, which include any information they need to understand the task. A procedure is not a task. A task is something the reader needs to accomplish; a procedure is how to manipulate a tool. There is more to say about most tasks than how to manipulate the tool, and that information is integral to the task topic — it should not be arbitrarily carved off to sacrifice on the alter of reuse.”

    When I started my career in technical writing, and learnt my first lessons of writing help, I was told that ‘concepts’ and ‘tasks’ should always be kept separate. However, I as a user have a different opinion to this. Every task that we perform on an application has some concept associated with it which is important for carrying out the task. Many things are ‘not-very-obvious-on-the-screen’, and need to be known beforehand to perform the task. Such information should always be kept with the task to prevent the user from hitting the navigation buttons to search the concept topic for the task.

    I understand that there are problems with keeping concepts and tasks together in situations where the concept is very elaborate. Such concepts take up almost an entire page, and the user keeps scrolling to find the procedure. But there is a catch here that we forget. As stated by Mark, we should understand that a task is not a procedure. Task is what-to-do, the procedure is how-to-do, and concept is the background behind them. Concepts can be kept separate, but the what-to-do and the how-to-do should go hand in hand. This prevents the task topics from having bulky conceot topics, and still provide the required information to the user at one consolidated place.
    All this organization needs to be backed up by correct naming conventions for topics as pointed out in my prvious comment. The first thing that a user does when needing help, is hit the search button. I as a user hit the search button on occasions when I am unable to locate the required topic in the TOC. If I am learning to operate a washing machine, I will look for a topic on rinsing or say adjusting water-level. If I cannot find it, I would hit search. My idea is why compel the user to hit search? Rather, give them the right topic at the right place with the right name.

  7. Pingback: The Tyranny of the Terrible Troika: Rethinking Concept, Task, and Reference | Every Page is Page One

  8. Pingback: Unconscious definition | Molluscmania

Comments are closed.