Slashdot Mirror
RTFM? How To Write a Manual Worth Reading
An anonymous reader writes with a link to Rich Bowen's insightful, detail laden piece at Opensource.com about improving documentation: Have you noticed that the more frequently a particular open source community tells you to RTFM, the worse the FM is likely to be? I've been contemplating this for years, and have concluded that this is because patience and empathy are the basis of good documentation, much as they are the basis for being a decent person. What's the best example you know of for open-source documentation? How about the worst?
Make it conversational as well as informative. You don't have to write a novel or make it into a drama play, but at least do something to help illustrate a bit more than some short and often mis-communicated list of what the options do. In technical speak? No problem: less man page, more info page (speaking of which, an actual info page would be a nice thing to have for a few of the projects out there, eh?)
Quo usque tandem abutere, Nimbus, patientia nostra?
Coders they got. Projects whose "documentation" consists of anything more than a technical list of bugfixes they don't.
OSS needs to realize that well-written documentation is just as important as well-written code.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
I was able to teach myself Pascal and C++ with the quality online Documentation in the Old DOS Borland Developer tools.
There are levels to the documentation.
Theoretical: Why is it here.
Actual: What does it do
Physical: working examples.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
10% of people want to write documentation without getting paid to
FTFY. Everyone on an OSS project wants the front-line job of coding (and are even willing to do it for free). No one wants to be the guy doing the hard, less cool but no less essential, job of writing the docs.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
What I've learned from decades of reading professionally-written manuals can be summed up in two steps:
The first step in writing a good manual is to have a very weak grasp of the language used by your target audience. It is important to use many grammatical and spelling errors, just to make sure the reader stays on their toes and pays attention. Research has also shown that users do not like to read manuals that use advanced vocabulary or complex grammatical structures.
The second step is to manage the density of information on the pages properly. A piece of paper is pretty large, and so are most screens, so a lot of information can be included on a single pane of view. It is important to make the most of this space and convey as much information as possible, as densely as possible. The more information a user can see without having to turn pages, the better. Use of separating devices, indications, and other correlative marks should be avoided, as it takes away from space that can be used for more information. They also can cause there to be more whitespace on a page, which should be avoided at all costs.
So years ago I was in varying positions at an ISP, but regardless of title "head tech" pretty much applied. We kept getting kids right out of high school that claimed to know computers well but had never used a command line, didn't know what an IRQ was etc.. As this was the Windows 95/98 era and this was a dial-up ISP some manuals had to be written.
I of course wrote them.
I made flow charts for email troubleshooting (I hated Visio so I used a graphical editor instead), I had grids for IRQ/Address settings, I had step by steps for undoing AOL I.P. stack sabotage (how many of you remember that?) Fact was I wrote really good documentation that anyone from teenager to adult could use to troubleshoot the "normal" day to day issues a worker at an ISP faces without making a condescending script. If you used it for reference it was an answer key, if you read every word you often would know why that problem occurred. I'm of the belief understanding an issue is always better than just knowing what the fix is.
Long story short - the documents leaked out of the company. On the north side of town there was a help-desk outsourcing company that tended to have a lot of employee migration with our own - in both directions. A buddy of mine went to work at a different ISP and saw my documents turn up there with my name replaced on the credit line (he knew I wrote them - he watched and knew the marks I put in things that were dead giveaways it was my stuff).
I no longer worked at the old company and was still finding out about my documents leaking all over the damned place. I decided to put the documentation GPL on the things and throw them out on my webserver. If figured if I put them out on the web myself then there was a verifiable copy out in the wild, it would shine a light on the plagiarizers, and I was hoping to maybe get offered jobs or something. Later I was criticized with "that really should have been Creative Commons". Fuck you, I did this before Creative Commons even existed.
My web server and the backups were physically stolen from my home, but there's still an archive. To this day I still write in the "explain it, don't step it" method.
Turns out lots of places want idiot guides and don't care to understand.
The preceding post was not a Slashvertisement.
I am already happy when the author has read http://www.xkcd.com/1343/ and some early manpages of sudoers (imho the worst, by far).
Todays "sudoers" manpage has already been cleaned up a lot and is still a horrible read. But in the past it was something like "the relevant configuration is a hierarchical list of geometrical weighted values. Each one represents a position in a list relative to its anchor". And yes, that was just a weird way of saying "/etc/sudoers contains configuration keywords with options".
Overall I had the impression the author was a sociopath showing off his mathematical skills while keeping the core knowledge unavailable to others.
"Life is short and in most cases it ends with death." Sir Sinclair
The problem with a lot of documentation is that they aren't written from a user's perspective - they are written by people who wrote the software, and know what to do. Letting go of your design assumptions is almost impossible.
I have long felt that the first draft of documentation must not be written by the person who wrote it; you have to allow your users to "send" you the first draft (either through email questions/screenshots/etc.). Then you realize how many assumptions you made that are non-obvious to your users.
Obviously, this isn't really practical for OSS - you might not be able to pay for usability testing and feedback. Which is why I prefer to include screen shots in documentation as much as possible. Also, I try to follow this basic formula for documentation: What (what is the user trying to do - make it clear what this section of the documentation address), How (how can the user achiever her goals), Why (this is where you might, if you choose, try to explain a design/implementation philosophy - it comes third, so that someone who doesn't care doesn't skip the entire section. Clarity and brevity are important.).
This is the principle I follow for user stories as well - create an end-to-end user workflow (which is basically just many small What/How/Why sections tied together).