Can you embed help?

Print topic Print topic Previous topic  Next topic

Users don’t like to ask for help. They don’t like to admit to themselves that they need assistance. “Help” implies failure, and no one likes to fail.

The idea of embedding help is to provide just-in-time assistance right within the user interface when it’s needed and where it’s needed.

Embedded help is especially prominent if it’s placed on the left side of controls so that it comes “before the control” (for users who are used to reading from left to right). Embedded help is more unobtrusive if it’s placed on the right side of controls.

Most often, embedded help is used for software, but you can also apply the same principle to hardware.

Expand /Collapse All Subsections

Examples

Tips that appear when users hold the pointer over a button or over another control:

Brief texts that appear on the status bar, based on a selected menu item or other control. The maximum text length is one or two sentences:

Short supportive texts (so-called affordances) directly next to entry fields or other controls. Typically, these texts consist of only a few words or of a single sentence:

Small, fixed help panes within a window. The typical text length here is from one sentence up to a few paragraphs. In addition to the text, small images can also be used—either static images or animated images:

A help pane embedded into the main window of a program. Often, users can undock and resize this help pane. The shown content depends on the current context within the program. Text, images, and multimedia can be used:

Texts and images within a wizard that guides you step by step through a process:

Advantages and disadvantages

Advantages of embedded help are:

The most important information is always visible.

Users perceive the given information as a tip, not as “help” or “instruction.”

Users don’t have to perform any additional interaction to get help.

There isn’t any help window overlapping parts of the program.

Disadvantages of embedded help are:

It adds more clutter to the user interface.

It may be annoying for advanced users.

It must be short, so often it can contain only the most important information.

The implementation needs close cooperation between application developers and help authors. In particular, you need to agree on:

where exactly help will be embedded

how much screen real estate will be allocated

where the information is stored, which formats are used, and how the information is embedded at runtime

Depending on the chosen implementation method, help texts may need to be stored right within a program’s source files rather than along with the main documentation’s source files. This requires an extra workflow.

Recommendations

Add embedded help if:

your product is a product that users use only rarely

most of your product’s users will always remain beginners or intermediate users, and won’t become advanced users or expert users

Don’t add embedded help—or provide an option to disable embedded help—if:

users use your product very frequently

your product is mostly used by advanced users, specifically if advanced users are your primary user group (note: “advanced” in this case means advanced in using your product)

the user interface of your product doesn’t provide much screen real estate

the user interface of your product can’t be changed to provide room for embedded help

If you add embedded help:

Plan for embedded help early and coordinate your plan closely with interaction design, interface design, and development.

Anticipate the users’ questions at the field level. Often, this concerns:

reminders (for example, the meaning of an acronym)

exceptions (“what if …”)

relationships and dependencies that aren’t obvious

Embed only the most important and most frequently needed information.

In addition to embedded help, also provide traditional help that includes detailed help topics, in particular concepts and procedures. Link to the detailed help topics from embedded help.

When linking to traditional help, don’t use vague link text such as “Help” or “More ….” Use descriptive link texts that communicate clearly what users can expect when they click the link, and that motivates them to overcome their resistance to “asking for help.” Often, a good solution is to use a question such as “How do you …?”, “Why is …?”, or “What does … mean?”.

Embedding help on hardware

Although embedded help is traditionally used for software, you can use a similar approach for hardware as well.

For example, you can print some “embedded help” on labels that you place next to particular operator controls. If you use detachable labels, users can even remove this form of assistance when they don’t need it anymore.

Warnings and other vital information are often printed directly onto a product. Fire extinguishers are a typical case. Operation instructions are printed onto the front side, so you don’t have to waste any time to find and open a manual while, for example, your home is burning. The needed information is right where you need it, when you need it. It’s always tied to the product and can’t get lost.

 

 


Context sensitivity