Who’s afraid of the big bad help?
Despite having used Inkscape for years, I learned a lot more about it while writing a guide to vector graphics. Why? Among other things, I finally read the Inkscape manual. After all, why read when you can jump in and draw, discovering the features in the process?
In turns out that typical users—people using software to do their job—rely on a similar strategy. In 1987, John Carroll and Mary Beth Rosson described what they called “the paradox of the active user”—the fact that, due to being focused on the end-product and unwilling to waste time, people avoided the very documentation that would have helped them be more productive in the long run.
Studies show: this is exactly what users don't do.
Instead of reading the manual, users tried to apply their previous knowledge, used trial and error, and sometimes asked others for help. If they did start reading, they wanted to try out the features right away, skimmed and used heuristic reasoning to jump to conclusions. Presumably, this gave them better chances of quick progress on real tasks, but it also resulted in higher risks and a failure to take advantage of useful functions.
Later studies (e.g., Grayling 1998, Novick & Ward 2006) confirmed that looking up help topics is often users’ last resort, and highlighted specific issues that make help less attractive, which can be divided into two classes.
- Insufficient usefulness:
- missing information
- content that doesn’t answer the right questions
- too basic or too complex explanations
- uncertainty and missing help topics in the “no man’s land” between software
- Insufficient convenience:
- no obvious and easy to use mechanism for accessing relevant help
- navigation and searching difficulties, including mismatched vocabulary between users and developers
- long, hard-to-scan text
- help windows or pop-ups interfering with work
In the process of searching for a solution, people frequently switched between recalling their previous experience, studying the interface and trying things out, and searching or asking for help (Andrade, Bean & Novick 2009).
To address these issues and adapt the help system to users’ exploratory learning strategy, help usability researchers developed new designs and recommendations, which will be the focus of my next post.
References
Andrade, O. D., Bean, N. & Novick, D. G. (2009). The macro-structure of use of help. In Proceedings of the 27th ACM international conference on Design of communication (SIGDOC ’09), 143-150.
Carroll, J.M. and Rosson, M.B. (1987). The paradox of the active user. In J.M. Carroll (Ed.), Interfacing Thought: Cognitive Aspects of Human-Computer Interaction.
Grayling, T. (1998). Fear and loathing of the Help Menu: A usability test of online help. Technical Communication, 45, 2.
Novick, D. G., & Ward, K. (2006). Why don’t people read the manual? In Proceedings of the 24th Annual ACM International Conference on Design of Communication (SIGDOC ’06), 11-18.
GNOME thoughts
I think the current GNOME users are more likely to use some form of help or documentation than “typical” users. After all, most of the subjects in these studies were users working with systems running Windows and whatever productivity software their employer chose to install, possibly not interested in spending any of their free time anywhere near a computer.
Many people choose free software because they enjoy learning and tinkering, understanding the system and using the best methods, in contrast with the end-product focus of Carroll’s “active user”. In addition, the sense of community that free software projects encourage can counteract the feelings of alienation and helplessness that some new users experience with computers. And, of course, users of the command line learn to favor help over trial and error :)
However, since GNOME’s target audience is wider than its current user base, it makes sense to aim for more universal usability, including a help system that even the help-phobic would love.
On the less bright side, since free software is made by different developers and communities, the overall documentation experience can be quite uneven. For instance, here’s what you get by pressing F1 in different windows on my system (Ubuntu 10.04 Lucid Lynx):
- Nautilus, Empathy, desktop (no window) – the appropriate table of contents in yelp
- Blender, Pidgin – the manual in the default browser
- Liferea, Zim – the manual in the application itself
- OpenOffice, Gimp – the context-appropriate page in the app’s own help system
- Inkscape, Network manager – nothing (although the help does exist and can be accessed by other means)
- Lokalize, BasKet Note Pads (KDE apps) – an error message
In most cases, you do end up with decent documentation on your screen. But it feels like a bit of a gamble, which might prevent you from relying on help as a matter of course.
Nita's Blog 
lol the big bad help…
Personally I’m bothered by the mess that == FOSS documentation. For example; in firefox there is no built in help; so you get thrown to a website (what if I can’t get onto a website and I have work offline checked, but am too new to realize that :P?)
/rant off :D
btw +1 on your ideas :)
Actually, I press F1 and I end up with what seems to be an endless system lock-up of disk activity. I realize that it’s probably the help system being loaded from disk, but frankly I end up just killing the application and restarting it. One minor point to address would be to make sure the basic help system and the front page for any particular application gets pulled into memory along with the application itself.
But overall yes, the problem is that people just don’t read manuals. They don’t read help. They don’t even read on-screen on-line pointers, preferring to follow their own internal models of how things work rather than accurate descriptions, even when those internal models are obviously out of sync with reality.
How to solve it? No clue. Just make it obvious enough that reality and the users model is out of sync, I guess. Once nothing fits, then people are ready to look for help – or quit in disgust.
Ah yes, the loading time. I’m happy to report that it’s been fixed in GNOME 3! With that convenience hurdle removed, hopefully more people will give help a chance.
Actually, the research results are pretty good for certain kinds of help. And the new Gnome docs already follow some of the best practices. But I’m not yet sure how realistic it would be to implement other, more radical ideas (like integrated hints with progressive disclosure) in Gnome.
No, it hasn’t been fixed. Right now ( Fedora 15), a simple thing like opening terminal, missing ctrl+F1 and pressing “F1” instead, causes a lack of focus (BAD), repeatedly hitting F1 cause yelp to crash _hard_ and also generate useless abrt warnings ( basically, filling my disk with core dumps)
The size of your crash is 1 164 673 082 bytes, but the retrace server only accepts crashes smaller or equal to 1073741824 bytes.
…. Right. This isn’t useful. https://bugzilla.redhat.com/show_bug.cgi?id=699990 for details.
Next up. People are _used_ to help files sucking majorly. When you approach a system, and by default you expect that the help function or help pointer will only give you “no tip” or “no help for this”, you end up with a user that is trained that help is unhelpful.
Moving on from that, many of the active productivity tips are nowhere near usable. Keyboard shortcuts are mostly missing in all manuals, FAQ/ How do I has _never_ existed in the help files.
Further onwards, There’s no help-system that works for Gnome-shell. Major new piece of software, and you cannot use “F1” anywhere. Alt+f2, f1 = Nothing. Super-key, F1, Nothing.
So, once again, people are taught to expect that help will not be helpful. In the rare cases where help is helpful (gedit) It’s severely lacking in “useful”.
Basic questions like “how do I spell check a danish file on my system” are left unanswered. ( Nothing there on how to find the languages) . More advanced questions like “How do I change the syntax highlighting/add another script” are nowhere to be found. Note that referring to external links for this would very well be enough, but as it is, google is always faster than the help system.
And that’s problematic.
First off, thanks for the thoughtful comments on the content and trustworthiness of help. These are all things that help writers and developers think about, and it’s great to hear concrete requests for improvement.
But something is definitely wrong on your system. When you hit F1 in the shell, you’re supposed to get a nice overview of Gnome help, which includes an introduction to Gnome shell. Have you tried reporting this?
I’m never afraid of the help files, the problem for me is there usually isn’t one. Manual writing seems to be a last thought for open source devs.
I don’t have BasKet here, but pressing F1 in Lokalize I get the “Lokalize Handbook” opened in the KDE documentation system. What was the error message you got? Did you report a bug?
Is that in GNOME or KDE?
Perhaps it’s my own fault for weeding out any KDE packages I wasn’t using at the time. I remember being annoyed at KDE apps requiring so much KDE infrastructure (like KNotify) a few years ago. I’ll look into it someday.