Instructional Text on the User Interface: Some Counter Intuitive Implications--
User assistance occurs within an action context (the user doing something with the application) and is almost always delivered in close proximity to the focus of that action, that is, the application it supports. When user assistance is displayed within the application as instructional text on the user interface, conventional principles of good information design must be modified to accommodate certain forces within an interactive user interface.

Consider the following assumptions. If you accept them, they are going to lead to some implications for UA design that might seem counter intuitive to some.

• The flow of focus by which users process information on a computer screen is the same as when they process information on a page. In English, for example, that would be left-to-right and top-to-bottom. In Arabic, for example, that would be right-to-left and top-to-bottom.
• Users within an application are motivated to take action, and their focus is easily drawn to action objects, such as text fields, menus, and buttons.
• Once the user's focus is drawn downstream in the focus flow, it is difficult to redirect it upstream. In other words, if something initially draws the user's attention to the middle of a screen, it is far more likely that they will continue going over and down as opposed to going back up. This is especially true if there are additional action objects downstream.

Example
So let's consider a simple application with a two-button radio button group, and you would like to explain the concepts needed to make the appropriate selection. An example I've used before is a report output dialog box that has the user select HTML or PDF for the output medium.

If you have an instructional design background or have been well-grounded in information mapping, your instinct will be to define the terms and give appropriate selection principles before you present the radio buttons. In other words, you will be inclined to put the instructional text above the radio button group. In a document that is removed from the action focus, it makes a lot of sense to introduce definitions and principles early in the document in order to prepare the reader/learner for what comes later. But if you accept the three assumptions I presented earlier, you will understand that the following scenario is what typically happens in a UI:

1. The user's focus is pulled almost immediately to the radio buttons because the user is motivated to act.
2. This jumping immediately to the buttons causes the user to leap-frog over the instructional text.
3. Once downstream of the text, the user does not go back and read it, even if unsure of what the buttons mean. The user makes a best guess and moves on (attracted by the next action object downstream).

I have seen this scenario played out in countless usability tests of form-based web applications where instructional text is placed at the top of the web page. The problem is exacerbated by the resultant appearance of seemingly a lot of words being presented as a dense block. Much the way that quantum physics says that dense matter bends space, I hold that dense text bends users' "eye rays" rendering dense text invisible. The user tries to read it but at the last second their eye rays get deflected and they see the action object instead. (OK, the physics is a little flaky on that one, but you get the point.)

Implications
When putting instructional text on the user interface, apply the following principles:

• Divide dense instruction up by action objects, and put the appropriate text in close proximity to its respective action object.
• Put the text next to the action object (in the downstream direction preferably) or just below it.
• If the text is too long, and this orientation disrupts the screen layout for the action objects, for example disrupting the grouping of a radio button group, provide a link that opens a pop-up or dynamic pane. I have seen links be very effective when phrased like an FAQ.

Instructive Labels--
I should have learned by now not to trust my instincts. Instincts are often the manifestation of programmed learning, which means that our creative and critical circuits have been turned off. That's why collaborative teams are so useful; members can challenge each other's programming.

Huh?

I'm working these days on a team designing an online, interactive workbook that helps a network administrator plan how to install and deploy a security appliance. The workbook has three purposes:

• Advise the administrator about some decisions that need to be made
• Provide a checklist at the end that lists the steps the administrator must go through (based on how he or she answers certain questions in the workbook)
• Direct the administrator to the correct deployment documentation (once again, based on how he or she answers certain questions in the workbook)

I wireframed an approach that I thought had great merit. (It turns out it had merit, just not GREAT merit.) A typical page asked whether the user would use the device in routing mode or transparent mode and was set up like this:

1. The page contained a short intro paragraph that explained the device could operate in two different modes and that the administrator had to designate which mode.
2. Two radio buttons were provided, labeled "routing" and "transparent".
3. Next to each radio button was a thumbnail diagram that showed a typical typography for that mode.
4. Next to each diagram was a description of when/why the user might want to select that mode.
5. Beneath that explanation was a link to provide more detail about the mode if the user wanted it.

//In my next post, I'll talk about why I rejected the design of explaining the required concepts before asking the user to select the mode. That's an entirely different topic.//

Step 2 is where my instincts did me in. It just seemed so right that a radio button group for selecting options should have the names of the options as labels. (Hence my lack of embarrassment--it's not one of those decisions that screams "stupid.")

Then one of the writers on the team asked one of those questions that just makes me go "huh!"

"Instead of labeling the buttons with the names of the modes, which we then have to go on and explain, can't we just label them as statements that get right to the main selection criteria?"

Example
Let's say you have a report output dialog box that includes selecting the output format. The two choices are HTML and PDF.

My instinctive approach is to have a radio button group with two buttons labeled HTML and PDF respectively. My user assistance instinct is to provide a tool tip or UI text that would elaborate on those choices, e.g., "Choose HTML to view the report online; choose PDF to have a printable version."

My colleague's suggestion in the first example would have the labels themselves say "I want to view the report online (HTML)." and "I want a printable version (PDF)."

Clutter or good user assistance? It depends. If you were going to take up screen text explaining the label (as in my first example), my colleague's approach is clearly better. In the second example, we have to make a judgment call about how well known the output labels of HTML and PDF will be. In an authoring tool meant to be used by tech writers--clutter. In a business intelligence application meant to be used by financial managers and analysts--maybe worth the screen real estate.

At any rate, it's always a question worth asking. Let your creativity and critical thinking challenge your instinctive approach.

Expert Guidance in User Assistance--
Those who read my ramblings in this blog on this topic, can read a more coherent discussion in my article in UXMatters. I've decided to make this topic my point of passion this year :-)

Stay posted.

Happy New Year--
And speaking of new year, the theme of the January issue of SIGCHI's magazine, Interactions, is "Help: User assistance and HCI." I have an article in that issue called "A pattern language for user assistance." I've posted a copy to my website, and you can link directly to that copy here.

I will be doing a presentation at the WritersUA conference in March on this same topic.

I have another article coming out next week in UXMatters. That article is called "User assistance in the role of domain expert." This is a topic I have discussed in this blog, and will include a practical example of a pattern language.

I will also writing a regular column for UXMatters called "User assistance: Putting Help in context." I will be drawing a lot from the material I experiment with in this blog (and benefitting from a GREAT editor, Pabini Gabriel-Petit).