Best practices for online help

Question

we're currently developing a fairly complex web portal. To improve the user experience, we want to provide a context-sensitive online help system that can aid the user in understanding certain aspects of the site.
In our case, the site has a variety of widgets that display all kinds of tabular data, graphs, etc. For instance, one such widget may display the VIX and a the help system would offer a brief description of what the VIX is.

Now, I've looked around in the internet and found some interesting articles such as the Design Checklists for Online Help, but most of what I found seems fairly outdated. What I'm specifically interested in are design issues such as these:

• whether (or when) to use popups, divs, or link to external pages
• how comprehensive should the help entry be? how much is the average user willing to read?
• what's a good way to provide access to the help system? cluttering the UI with questionmark-icons is certainly not optimal
• should the help entry be loaded on demand with AJAX (kinda sucks, you want the info right away) or preload it (causing tons of unnecessary traffic)
• other dos and don'ts

The answers to some of these questions may seem obvious, but when it comes to usability I've made the experience that the intuitive answer isn't always the best. Secondly, I'm a software developer and as such I tend to look at things from an engineer's point of view. And I think we all know that this is, more often than not, a pretty poor angle from which to approach the design of a user interface. This is why I would very much like get some feedback from people more experienced in this field.

Answer 1

I'm going to contribute a narrow response, so I'm not going to answer all of your question.

• Research reported by Andrea Ames quite a few years ago at a mini-conference at UBC's downtown campus, suggested that embedded assistance and usability are better than Help. She told the story of how she compared three different Help-delivery methods with/in a household financial software. Users don't perceive embeded assistance as a form of Help, and report that they were "merely using the software," rather than using the information that instructs and guides them through the software. When users are engaged with a problem, often, the last thing they want to do is disengage and start something else. For many users, starting the Help fits the category of "something else"—however illogical that may be. The last I heard, Andrea was working for IBM. By embedded assistance I'm referring not to labels and button names, but to text that appears directly in a user interface whose function is to orient, explain, instruct, and provide context.

• Lois Hawk reported on an involuntary response in the brain called looming-stimulus response. When something unexpectedly changes in your visual field—like a tiger—your brain responds as follows: 1) flush short-term memory, 2) release some adrenaline to prepare for action, and 3) do a visual rescan of the environment. You can probably imagine that if a pop-up also triggers this involuntary response, and therefore flushing the short-term memory of your users with your Help pop-ups, and increasing their stress, they're not going to be sure why they dislike the experience, but dislike it they will. This research paper is in the proceesings of the STC joint region 7 & 8 conference in Honolulu, in 2000 (I think that was the year). It's difficult to find a copy of it.

Answer 2

It can be tough to get people to read. Sometimes they'll assume they know what you want and will refuse to read the help. The obvious answer would be to make your app so simple that it requires no explanation. But it's not always that easy and it's something I've struggled with for a long time.

But in terms of context-specific help, I chose to make the help appear whenever you gain focus to a textbox. For example, the orange box below is only visible when the zip code textbox has focus...

This way, the user doesn't have to click an icon for the help to appear. It'll just appear naturally as they're filling out the app.

This doesn't work for everything, of course. It won't work for radio buttons or checkboxes so you'll have to invent your own mechanism for those. The little i information icons work well next to a question.

I'll try to answer some of your other questions...

whether (or when) to use popups, divs, or link to external pages

Nobody likes popups. If at all possible try to find an empty spot alongside each field where help can appear as pictured above. This way it's not covering anything up. Keep everything (including your help) as concise as possible while still getting the point across.

should the help entry be loaded on demand with AJAX (kinda sucks, you want the info right away) or preload it (causing tons of unnecessary traffic)

You'll have to weigh your options here based on how much help text you're dealing with. If you're using gzip compression anyway, it may not be a big deal to keep it all in the HTML.

Answer 3

I'm partial to tool tips or call out areas that are always visible that give basic instructions, and then link to more advanced contextual help. Tool tips tend to be on question marks or some such, but if lots are needed prefer tu use a simple call-out area that is in the initial design for this purpose.

The tool tip or call-out uses an ID to enable navigation to the correct help item. I don't open a new-window/tab/pop-up/div, but if they want advanced help, I take them to that page with a prominent link BACK that uses the screen ID and tooltip/callout ID to return them to the correct spot, keeping any forms populated.

Since it's advanced help, I still tend to fall back on the "RoboHelp" style of help, where there are links to related items and full help navigation. Since most of the applications I work on are authenticated with different levels of access/user types/role attributes, what's available to navigate to in the help looks at the Users token to decide what information to display.

Hope some of this is helpful an addressees most of your points.

Answer 4

When your application is focus on a specific topic and is full of acronyms/strange terms, users will know it's a focused app (that can give them some productivity if they learn it) and will want to engage in a learning experience. The problem is that this willing is just for the first-third encounter.

For first-usage you can ask the user if wants a guided tutorial. You can make this like a wizard, in steps that presents highlighted stuff around, or you can listen to what the user is clicking/focused on and provide help for the current element. IMO this is like a tutorial gaming experience, you learn the controls, you get the objective. The user should be able to quit anytime this tutorial, come back if he pleases and check not to see the tutorial invitation again. This experience should be provided for a beginner user.

For medium/advanced users I think acronyms and title/tooltip elements are just enough (that is if you have a clear IA and intuitive/consistent elements). Tooltips don't stay in user's way, but are there is the user ever needs help, without annoying. They should be styled pretty discrete, but still observable.

Answer 5

This is a link to use of live chat as a tool for online help, I hope this helps out https://www.experienceux.co.uk/ux-blog/2017/05/30/6-steps-to-delivering-first-class-live-chat-user-experience/

Summary of post:

1. Make Live Chat call-to-action easily visible/accessible (e.g. bottom right hand area of the website).

2. Draw more attention to the call-to-action by loading it after the rest of the page content (e.g. a couple of seconds later).

3. Help to overcome the ‘is this a real human?’ barrier by showing name and photo of person.

4. Make it easy for users to browse in parallel by loading the chat window in situ within the browser window, and allowing users to minimise it.

5. Reduce the need for users to learn new things by following design patterns of familiar messaging services like Facebook Messenger and WhatsApp.

6. Allow the web chat window to be minimize while still showing notification of new messages.