Help Menu Quality: Sub-Optimal?
April 28, 2006 8:00 AM Subscribe
Is it just me, or do Help menus typically suck? Why do they suck so badly?
It seems to me that developing a good Help system is as important a part of software development as coding. If the user can't figure it out, what good is it?
Example: Put on your naive user hat, go into Excel, and use the Help system to find out how to subtract.
If others agree that they suck, is this a Microsoft-specific problem? Do Apple Help menus suck?
Do others get as ANGRY and ENRAGED as I do when they're trying to figure something out and the Help menus suck?
It seems to me that developing a good Help system is as important a part of software development as coding. If the user can't figure it out, what good is it?
Example: Put on your naive user hat, go into Excel, and use the Help system to find out how to subtract.
If others agree that they suck, is this a Microsoft-specific problem? Do Apple Help menus suck?
Do others get as ANGRY and ENRAGED as I do when they're trying to figure something out and the Help menus suck?
I use both. Apple help sucks just as much as Microsoft's. And, no, it's not because things are easier to do on a Mac.
I tend to use Google as my universal application help.
Applications should use a user-contributed wiki for help, with some sort of measure to prevent someone from changing all the answers to "fdisk."
I think they suck so badly because they're written by experts for morons. They don't work for those of us that are fluent enough to figure most things out on our own but occasionally need to look something up.
posted by bondcliff at 8:17 AM on April 28, 2006
I tend to use Google as my universal application help.
Applications should use a user-contributed wiki for help, with some sort of measure to prevent someone from changing all the answers to "fdisk."
I think they suck so badly because they're written by experts for morons. They don't work for those of us that are fluent enough to figure most things out on our own but occasionally need to look something up.
posted by bondcliff at 8:17 AM on April 28, 2006
Documentation is always an afterthought in the process of developing software.
posted by knave at 8:25 AM on April 28, 2006
posted by knave at 8:25 AM on April 28, 2006
In a lot of cases, at least in my experience (which is not in web-based stuff, but in financial-services software and HR stuff) the help is one of the last things developed and is generally not developed in tandem with the application, so the help is generally thought of, if at all, at the very end and is thus skeletonized and finished slapdash (if at all) in order to meet the release date of the product.
I think they suck so badly because they're written by experts for morons.
Yes and no. Again, this is just from my experience, but help files are, as you say, either written by experts for morons, or written by training/documentation staff using input from experts; the training staff is not at the technical level of the experts, so things are inevitably lost in the translation, and "big issues" which are easy to understand are the ones that get the most attention.
I second the use of Google for widely-used applications; just today, as an example, I had to turn caret browsing off in Firefox but I didn't know that's what I had to do. Because "caret browsing" did not exist in the FF documentation that I could find, I had to Google "cursor on web page" to find the term "caret browsing" and subsequently discover how to turn it off.
posted by pdb at 8:25 AM on April 28, 2006
I think they suck so badly because they're written by experts for morons.
Yes and no. Again, this is just from my experience, but help files are, as you say, either written by experts for morons, or written by training/documentation staff using input from experts; the training staff is not at the technical level of the experts, so things are inevitably lost in the translation, and "big issues" which are easy to understand are the ones that get the most attention.
I second the use of Google for widely-used applications; just today, as an example, I had to turn caret browsing off in Firefox but I didn't know that's what I had to do. Because "caret browsing" did not exist in the FF documentation that I could find, I had to Google "cursor on web page" to find the term "caret browsing" and subsequently discover how to turn it off.
posted by pdb at 8:25 AM on April 28, 2006
Response by poster: Smackfu, it looks like they have made improvements. In Excel 2000, which is what I have, the answer to the question you typed is much more obscure :)
posted by lisaj32 at 8:29 AM on April 28, 2006
posted by lisaj32 at 8:29 AM on April 28, 2006
Response by poster: I have to wonder whether software publishers are aware of this problem.
posted by lisaj32 at 8:31 AM on April 28, 2006
posted by lisaj32 at 8:31 AM on April 28, 2006
Put on your naive user hat...
And therein lies the problem. Documentation and Help systems, beyond being an afterthought, are usually implemented by developers. Their entire perspective is completely different from what an end-user's would be. End users aren't morons (generally). They are simply people who haven't lived and breathed the nuts and bolts of the application for months on end. Nor should they be expected to be.
posted by Thorzdad at 8:38 AM on April 28, 2006
And therein lies the problem. Documentation and Help systems, beyond being an afterthought, are usually implemented by developers. Their entire perspective is completely different from what an end-user's would be. End users aren't morons (generally). They are simply people who haven't lived and breathed the nuts and bolts of the application for months on end. Nor should they be expected to be.
posted by Thorzdad at 8:38 AM on April 28, 2006
The basic problem is that it's hard for the application to know what the user wants help with. Software developers seem to be making progress with this in some cases—treating it as a Hard Problem and actually putting in the effort required to solve it—but it remains tricky.
A major problem:
1. Help systems tend to fail more on edge cases—they occur less (if at all) in testing and so are not documented or documented poorly. Such tidbits are not well-organized in the documentation, and so are harder to locate if they do exist.
1. Edge cases tend to be particularly frustrating for users. These go beyond simply not knowing of, or how to find/use/configure an option; this is the realm of Weird Thing, the realm of WTF. The problems are harder to describe, hence harder to search for, and, see above, the documentation may not even exist.
The product of these two vectors is a foul, foul mood.
User-fed wikis or other such knowledge bases are good. Google is helpful—that is where I generally find answers to edge case questions. Broader internal help databases are good, too, but require a lot of quality QA/testing/writing to generate. Better searching and organization of help databases is good. Improvements in contextual help menus is good.
posted by cortex at 8:41 AM on April 28, 2006
A major problem:
1. Help systems tend to fail more on edge cases—they occur less (if at all) in testing and so are not documented or documented poorly. Such tidbits are not well-organized in the documentation, and so are harder to locate if they do exist.
1. Edge cases tend to be particularly frustrating for users. These go beyond simply not knowing of, or how to find/use/configure an option; this is the realm of Weird Thing, the realm of WTF. The problems are harder to describe, hence harder to search for, and, see above, the documentation may not even exist.
The product of these two vectors is a foul, foul mood.
User-fed wikis or other such knowledge bases are good. Google is helpful—that is where I generally find answers to edge case questions. Broader internal help databases are good, too, but require a lot of quality QA/testing/writing to generate. Better searching and organization of help databases is good. Improvements in contextual help menus is good.
posted by cortex at 8:41 AM on April 28, 2006
1. and 2., that should have been. Is there a <sigh> tag?
posted by cortex at 8:42 AM on April 28, 2006
posted by cortex at 8:42 AM on April 28, 2006
Documentation and Help systems, beyond being an afterthought, are usually implemented by developers.
No, they're usually done by technical writers, who should know better.
posted by cmonkey at 8:44 AM on April 28, 2006
No, they're usually done by technical writers, who should know better.
posted by cmonkey at 8:44 AM on April 28, 2006
Yes, software publishers are aware of the problem. Here is a short list of the kinds of typical problems plaguing documentation projects:
1. Documentation is expensive. Nobody wants to pay for it.
2. Documentation projects are chronically understaffed. See #1.
3. There is no consensus about what makes an "expert" technical writer. Frauds and incompetents outnumber experts.
4. Experts are expensive. See #1.
5. Software projects are never "feature complete" or "frozen" when they say they are. Docs are always playing catch-up.
6. When content is localized, it takes a lot of lead time. This causes problems because of #4.
7. It's hard to write politically correct, technically correct, localizable, and understandable to all versions of common man.
8. Developers don't have time to help out the documentation people.
9. There is never an accurate spec, and often times no consensus on what the software is supposed to do.
10. Nobody wants to read the help anyway. The modern concept behind usability design is to make the docs irrelevant. This is expensive (see #1) and lags development (see #4)
11. It's hard to target one audience for documentation for a product like Excel, which has hundreds of millions of users. People do understand the concept of audience analysis, but it's hard to analyze a large and fragmented audience. Sorry it didn't help you, but it may help the majority of users.
12. It's hard to get real live customers testing the help for usability. (it's hard enough to get decent usability testing for software, multiply by ten for docs). If testing is available, it's expensive. See #1.
13. Tools for developing documentation generally suck. If they don't suck, they're expensive and require a lot of customization. See #1.
14. For companies like Microsoft, which have an obligation to document all features no matter how obscure lest the company be judged anti-competitive, the time is spent just in feature coverage, not in improving the most frequently used pieces of documentation.
15. There aren't good tools to figure out which bits of documentation are most frequently used, anyway.
16. The marketing people see docs as a marketing tool. The developers see docs as a feature list. Neither of these visions help users, but these visions have a great influence on the kind of docs produced.
I'll stop now, I could go on forever, but you get the idea.
posted by crazycanuck at 8:52 AM on April 28, 2006 [2 favorites]
1. Documentation is expensive. Nobody wants to pay for it.
2. Documentation projects are chronically understaffed. See #1.
3. There is no consensus about what makes an "expert" technical writer. Frauds and incompetents outnumber experts.
4. Experts are expensive. See #1.
5. Software projects are never "feature complete" or "frozen" when they say they are. Docs are always playing catch-up.
6. When content is localized, it takes a lot of lead time. This causes problems because of #4.
7. It's hard to write politically correct, technically correct, localizable, and understandable to all versions of common man.
8. Developers don't have time to help out the documentation people.
9. There is never an accurate spec, and often times no consensus on what the software is supposed to do.
10. Nobody wants to read the help anyway. The modern concept behind usability design is to make the docs irrelevant. This is expensive (see #1) and lags development (see #4)
11. It's hard to target one audience for documentation for a product like Excel, which has hundreds of millions of users. People do understand the concept of audience analysis, but it's hard to analyze a large and fragmented audience. Sorry it didn't help you, but it may help the majority of users.
12. It's hard to get real live customers testing the help for usability. (it's hard enough to get decent usability testing for software, multiply by ten for docs). If testing is available, it's expensive. See #1.
13. Tools for developing documentation generally suck. If they don't suck, they're expensive and require a lot of customization. See #1.
14. For companies like Microsoft, which have an obligation to document all features no matter how obscure lest the company be judged anti-competitive, the time is spent just in feature coverage, not in improving the most frequently used pieces of documentation.
15. There aren't good tools to figure out which bits of documentation are most frequently used, anyway.
16. The marketing people see docs as a marketing tool. The developers see docs as a feature list. Neither of these visions help users, but these visions have a great influence on the kind of docs produced.
I'll stop now, I could go on forever, but you get the idea.
posted by crazycanuck at 8:52 AM on April 28, 2006 [2 favorites]
sorry, when i cross-referenced to #4 above, it should read #5. Which leads to the following addendum:
17. There isn't enough time for proper editing (developmental and copy editing) and quality assurance when working against a deadline.
posted by crazycanuck at 9:06 AM on April 28, 2006
17. There isn't enough time for proper editing (developmental and copy editing) and quality assurance when working against a deadline.
posted by crazycanuck at 9:06 AM on April 28, 2006
I find the Microsoft Office help systems to be pretty good usually. YMMV.
posted by grouse at 9:20 AM on April 28, 2006
posted by grouse at 9:20 AM on April 28, 2006
If it wasn't for how good helpfiles generally are, I wouldn't know nearly as much as I do about many of the programs I've used.
However, I don't know anyone else that actually reads them. Infact I know so many people that simply don't read anything properly, from helpfiles, to fields in application forms, and then get annoyed when they can't do what they want to do, or fill something in wrong (I'm no stranger to this myself though).
I guess it's simply human nature to want something now, with the least amount of exertion. Though I'm sure that there must be some way of making it easier for the average human being to understand his/her software better.
posted by iamcrispy at 9:40 AM on April 28, 2006
However, I don't know anyone else that actually reads them. Infact I know so many people that simply don't read anything properly, from helpfiles, to fields in application forms, and then get annoyed when they can't do what they want to do, or fill something in wrong (I'm no stranger to this myself though).
I guess it's simply human nature to want something now, with the least amount of exertion. Though I'm sure that there must be some way of making it easier for the average human being to understand his/her software better.
posted by iamcrispy at 9:40 AM on April 28, 2006
There are many problems, but one that seems to occur a lot is the problem of terminology. A novice Excel user I know needed the VLOOKUP command (but didn't know it) in order to associate data from one table with another. If I used "lookup data" in the help, it found the right answer right away since I know that is what developers call that type of operation. This user was using terms like "find", "database", and "get " which are perfectly fine English synonyms, but didn't get the help files he needed. So in order to use most programs help files it is often necessary to minimally learn the terminology that the developers use.
I find the Office help files fairly useful (although second in importance to Google groups), but that is because I know the terminology. Most novice users can never seem to find what they want.
Actually, Google groups (or the web in general) can be great for novice users because if they are thinking of the problem using certain terms, someone else has probably asked the question that way.
posted by Tallguy at 10:21 AM on April 28, 2006
I was involved in software development (including one project where I wrote some of the help ... gah!) I'm currently teaching an MS Office class at a junior college, where I deal with users.
From the development perspective, it's very difficult to write a help system that will be useful to EVERYONE in your intended user demographic. Issues that seem incredibly basic are given short shrift, despite the fact that many users may be encountering your software in their first exposure to a computer (common with Office products, and is the situation for one of my current students.)
Also, the help system writer, be they expert or not, tends to see the help system as a whole entity with a beginning and end and an internal structure, not as the fragmented little bits that a user tends to see. Who reads the manual, or the help from start to end?
Another issue I've seen is when more than one person is working on the help system, it can be difficult to maintain a consistent "voice". Thus some topics end up nicely documented, and others less so.
posted by SuperSquirrel at 10:44 AM on April 28, 2006
From the development perspective, it's very difficult to write a help system that will be useful to EVERYONE in your intended user demographic. Issues that seem incredibly basic are given short shrift, despite the fact that many users may be encountering your software in their first exposure to a computer (common with Office products, and is the situation for one of my current students.)
Also, the help system writer, be they expert or not, tends to see the help system as a whole entity with a beginning and end and an internal structure, not as the fragmented little bits that a user tends to see. Who reads the manual, or the help from start to end?
Another issue I've seen is when more than one person is working on the help system, it can be difficult to maintain a consistent "voice". Thus some topics end up nicely documented, and others less so.
posted by SuperSquirrel at 10:44 AM on April 28, 2006
Response by poster: cmonkey: what are bug reports and how does one file them? because, clearly, it DOES :)
posted by lisaj32 at 11:47 AM on April 28, 2006
posted by lisaj32 at 11:47 AM on April 28, 2006
Back when I was a technical writer the help files were the last things I did - I wrote the paper manual (this was a long time ago) while the software was being developed. And frequently had to make up information about how it worked, since chronically mismanaged projects had no clear specs or plan... but I'll save that for therapy. Once the software was done (typically midnight of the last possible day it could be done, according to whatever external crisis was driving us that week), the developers would hand it over to me and I would make up some random shit to put in the help file while my boss stood over me and asked when he could start duplicating discs.
posted by selfmedicating at 11:56 AM on April 28, 2006
posted by selfmedicating at 11:56 AM on April 28, 2006
Response by poster: grouse: YMMV? sorry, don't know that one.
posted by lisaj32 at 11:56 AM on April 28, 2006
posted by lisaj32 at 11:56 AM on April 28, 2006
Response by poster: Part of the reason I get ANGRY and ENRAGED may be that by the time I've resorted to reading the Help file, I've done every common-sense and/or intuitive thing I can think of to solve the problem WITHOUT reading the Help file. I don't think anyone WANTS to read the Help file--it's more of a last resort. But when I have to resort to it, I expect to find the answer I need.
posted by lisaj32 at 12:03 PM on April 28, 2006
posted by lisaj32 at 12:03 PM on April 28, 2006
No, they're usually done by technical writers, who should know better.
Yes, you're right, and I apologize. The last place I worked, the "technical writers" were pulled from the development crew whenever it was decided that, perhaps, some documentation should be done. Thus my knee-jerk lumping of the two.
posted by Thorzdad at 12:45 PM on April 28, 2006
Yes, you're right, and I apologize. The last place I worked, the "technical writers" were pulled from the development crew whenever it was decided that, perhaps, some documentation should be done. Thus my knee-jerk lumping of the two.
posted by Thorzdad at 12:45 PM on April 28, 2006
1) I once had a teacher who suggested that, as future software developers, we write (or get written) the help/documentation first, then use that as a design document. I still like that idea.
2) I usually have the most success with new software if I actually read (or at least skim) all the documentation before I start using it. If I then run across something odd I want to do, I've at least been exposed to the terminology the program uses. Also, reading the documentation from start to finish gives me an idea of the range/scope of things that can be done, that the software expect you to do, so I'm less likely to go off on a crazy angle all unknowing. If I know I'm pushing the software in a new direction, then it's OK that it takes a while to figure out.
posted by amtho at 1:25 PM on April 28, 2006
2) I usually have the most success with new software if I actually read (or at least skim) all the documentation before I start using it. If I then run across something odd I want to do, I've at least been exposed to the terminology the program uses. Also, reading the documentation from start to finish gives me an idea of the range/scope of things that can be done, that the software expect you to do, so I'm less likely to go off on a crazy angle all unknowing. If I know I'm pushing the software in a new direction, then it's OK that it takes a while to figure out.
posted by amtho at 1:25 PM on April 28, 2006
Everything that crazycanuck wrote is gospel truth, especially this:
The marketing people see docs as a marketing tool. The developers see docs as a feature list. Neither of these visions help users, but these visions have a great influence on the kind of docs produced.
A good tech writer with enough time to do a proper job (that's like his or her having a unicorn to ride to work on, you understand) can go and ask the developers questions like "When or why would the user want this feature?" and trim the marketing sales-pitches out.
I have found Microsoft's Help files among the worst - when they're not just a list of features ("You can make a mailing list!") they are obscure. Lately, they seem to default to some "wizard" or other that doesn't produce the desired result.
posted by Kirth Gerson at 1:52 PM on April 28, 2006
The marketing people see docs as a marketing tool. The developers see docs as a feature list. Neither of these visions help users, but these visions have a great influence on the kind of docs produced.
A good tech writer with enough time to do a proper job (that's like his or her having a unicorn to ride to work on, you understand) can go and ask the developers questions like "When or why would the user want this feature?" and trim the marketing sales-pitches out.
I have found Microsoft's Help files among the worst - when they're not just a list of features ("You can make a mailing list!") they are obscure. Lately, they seem to default to some "wizard" or other that doesn't produce the desired result.
posted by Kirth Gerson at 1:52 PM on April 28, 2006
I don't have any other advice about why, but I should notes that the Adobe help is usually pretty good across the board.
For some reason, the Windows calculator help has no entry for the % button (or anything resembling the word "percent").
posted by Caviar at 4:21 PM on April 28, 2006
For some reason, the Windows calculator help has no entry for the % button (or anything resembling the word "percent").
posted by Caviar at 4:21 PM on April 28, 2006
This thread is closed to new comments.
Subtract numbers
Type =10-5 in a cell to display the result 5.
So that works well enough.
The Apple help system is really bad, and it doesn't look like they have put any effort into it since the initial 10.0 release.
posted by smackfu at 8:11 AM on April 28, 2006