Slashdot Mirror
RTFM = Read the Funny Manual?
coronaride writes: "This article over on Wired discusses the issue near and dear to every sysadmin and support tech's heart. I, myself, never read any manuals that accompany the products I buy (but when does cheese-whiz really need instructions anyways?) unless something majorly goes wrong! The article talks about how some countries, including Japan, try to spice up their product manuals in order to entice the users to read them. Is this just too much work for our lazy American manufacturers to do?"
Apple have been inserting funny stuff in their manuals for ages. And they are the only manuals I've read and enjoyed :)
This page intentionally left blank.
Heh, there's a feature in Lightwave where you can make a model of a hand, then apply bones to it so you can manipulate the fingers. In the illustration, they showed how you could take all the bones in the fingers (except the forefinger) and rotate them simultaneously, causing the hand to point.
There was a tiny caption under it that said "this isn't the finger that was raised when they showed this to me."
"Derp de derp."
Randal Schwartz's first O'Reilly Programming in Perl was also fun, for the humor placed in it, which keeps the student amused rather than dry, clinical and boring, which IMHO the 2nd edition was.
Some people view humor as a distraction in documents, perhaps so, if the humor gets in the way of getting the information across. I try to put some humor into sample data and documents, but usually it takes someone with special knowledge to notice (i.e. an address for J. T. Kirk, 1701 Enterprise Place) or silly things to fill in space in an example form, like creating combinations of funny words randomly to fill out the space in a new P.O. form. (BTW, programming in PCL sucks!)
It also seems to make the job of writing documentation a bit easier.
A feeling of having made the same mistake before: Deja Foobar
"We have noticed that if a manual said, 'Do not ever do this,' we would then get many calls from people who had broken their machines by doing just that," Esposito said. "They read the documentation and took offense to its tone so they had an argument with the product."
I found this to be an amusing story. However, the best way to deal with the whole manual issue is to design your product better. You know how you're not supposed to remove a game cartridge while you're playing? If you look at the SNES and the GameBoy, you are physically prevented from removing the cartridge because the power switch moves a piece that blocks the exit of the cartridge.
I realize this won't work in every situation, but the solution of 'we need to get people to read the manuals!' isn't going to go very far.
Getting back to the SNES example, I read the manual before playing the machine. Heck, I'm an expert on it! I used to sell them! Despite my detailed knowledge of how the machine works and the consequences of pulling the cartridge out while it's on, I'm still aware of the power switch blocking exit of the cartridge. Why? One day, a friend of mine came over with a new game I had been waiting for for ages. In a rush to pop this game in, I gave the cartridge in the machine a pretty good tug. Fortunately, it didn't give though. The safety feature of the SNES prevented me from making a 'wandering mind' mistake.
In cases like that, you could know the product inside out and still make bone-headed mistakes like that. Fortunately for me, Nintendo was smart enough to anticipate that I might make a mistake like that and design it so it's not easy to do.
"Derp de derp."
Many years ago (1986) I worked on a project that required us to create "Flow Charts" of our software design. In times past, I'd used the time-honored "flow chart template" (a piece of plastic with specialized shapes cut out of it) and while I didn't actually like it, it got the job done.
On this project, however, we were provided with a piece of software (Easyflow) to accomplish the same goal, but without the need to put pencil to paper. Instead, we used the software so we could fiddle endlessly with the design before committing a single pin to paper (yes, children, this was in the days when the dot-matrix printer ruled, before laser printers came free in your breakfast cereal).
Easyflow's Bloodthirsty License Agreement was the first hint that the user manual would be an interesting read.
IIRC, there were also 2 entry points to the manual proper, worded somthing like this:
Ah, the good old days.
In walking, just walk. In sitting, just sit. Above all, don't wobble.
-- Yun-Men
I remember a few years back (ok 5 or 6) I skimed the manual for a piece of internal software my company had created and found a note that basicly read, if you've gotten to this point fax in this form and we will send you a copy of Myst. Ever since I've at least skimmed them.
Never could pass up the opertunity for free stuff.
You didn't RTFA, did you? The article was all about the various cultural differences. For example, when translating for an Italian market, it was said that you should never just flat-out say what to do. Instead, suggest around it (apparently, Italians are stubborn and don't like being told what to do). Hungarians like instructions on how to fix things, some images and phrases that are benign in one culture are offensive in another, and so on.
Personally, I agree with you that a manual should be clear, concise, and just plain useful. And that's how most good manuals are in the States. That's not necessarily true around the world, and that was the whole point of the article.
I have a Prime manual from the early 1980s that has a long running joke in it.
It is a manual for a version of "runoff", which is used for formatting documents. The examples given in the book are for a restraunt chain that servers "frog burgers". There are a whole bunch of Cthulhu references throughout.
I need to scan some of them and post them to the net. Pretty funny.
Another example is in the error return values in GLIBC. Included are EIEIO and EGREGIOUS and other bogus errors.
Unfortunatly all traces of humor are removed from manuals, not due to burn out or other causes, but because Corporate America sees them as "Not Profesional".
Funny documentation and Easter Eggs are both a causualty of the War on Fun.
"Trademarks are the heraldry of the new feudalism."
Example:
:-)
I may not remember it 100% verbatim, but that was the gist of it. Honest truth. (And it was otherwise a very dense and serious book.)
Once, just to see if anybody noticed, I included this notice on the last page of some internal-only documentation:
"This page inadvertently left blank."
I don't think anybody caught it.