Can you spot the two apostrophes in the following: Tomato's, 3/$1. (Ye Gods; what have I just done?)
The first one is easy: it's the plural apostrophe, used by increasing numbers of semi-literates to form plurals. (What I've never understood is how the sign could say "Tomato's, 3/$1" and then follow it with "Cucumbers, 4/$1". Why does one have an apostrophe and not the other? Wish I knew the rules for the plural apostrophe. Wish I knew if those were good prices for produce.)
Did you find the second apostrophe? Well, I won't keep you guessing. It's "Ye Gods". Apostrophe is the term for talking to something absent, dead, or nonhuman, addressed as if it were present, alive, human, and able to respond. "Ring out o bells" is apostrophe, as is "Hi-o Silver, away", and (to paraphrase Hamlet) "O program, program, failing damnéd program". Now that I think about it, since your document addresses the user, and the user is unconscious from reading it, your entire manual is an example of apostrophe.
Somewhat in the same vein is prosopopoeia, the introduction of an imagined speaker or the personification of some abstraction or inanimate object. "If this program could speak, we could get it to testify against the programmers." [I've often wondered: if debugging is the act of getting bugs out of programs, is programming the act of getting bugs into them?]
As long as I've mentioned personification, it means attributing human characteristics to non-human things (such as Homer's "rosy-fingered dawn" or the more recent "this program is out to get me!").
Should you use apostrophe and personification in your manuals? Do you have to ask? There are several good reasons why you should: (1) it makes your documents more interesting (and, as I keep trying to pound home, the more interesting the document, the longer the customer will stay awake), (2) it annoys the Evil Editing Police (which is reason enough for doing it), and (3) there's a good chance that the programs you're writing about really are sentient and evil. It's therefore best to cover all the bases. It probably couldn't hurt to subtly suggest that, prior to installation, the customer pray to the program (which is, of course, apostrophe) and sacrifice a goat on the keyboard (which is, of course, just plain messy).
Just for sanity's sake, instead of stating what the program did, every once in a while you might want to state what the program tried to do or wanted to do or even needed to do. Discuss its aspirations, its hopes, its dreams. This helps to create the warm and fuzzy idea that the program is as human and fallible as the customer. Wouldn't you relate better if an information message read "Hold your horses, you think it's easy juggling all these bits? You try it for a day and we'll talk."?
From the above you can infer that my belief is to use any oddball device to get and keep the customer's attention. As long as I've mentioned it, infer and imply were first used by Sir Thomas More in the 16th century (and he was therefore the first to confuse them). Mercifully, they were used interchangeably until just after World War I. That era spawned worldwide economic disaster, a flu epidemic that killed at least 20 million people worldwide, dadaism, and someone thinking that it would be nifty to enforce a distinction between "infer" and "imply"; draw your own conclusions. ("You infer from what I imply" is correct, if anyone other than the Evil Editing Police still cares.) You would think that it would be a good thing to have both words, but since most people constantly confuse them, you're actually in the minority if you understand their use. Therefore, they are otiose (serve no useful purpose) and should be avoided at all costs. Look, how often do I tell you not to do something? When I do, listen; it's for a good reason. In this case you'd be using terms that few either use correctly or care about.
Once again, have pity on the Poor Bewildered Customer. You may think that you're being elegant and erudite, but in your quest to impress, you may have made things worse. Remember the times that you've sat down at your home computer to install a new program. How important was it to you at that point (you, the Big-Time Tech Writer) how nicely phrased the manual was? Did you go through it to see if they used any "big words"? Did you care how evident it was that each chapter was written by a different person? Did you try to pick out all their corporate standards? Or maybe, just maybe, you were so interested in getting the product to work that none of that mattered at all! Of course it didn't matter. You wanted a simple, easy-to-read, easy-to-understand manual (and a product that was so well constructed that you didn't really need the manual anyway). That's what our customers want. That's what we ought to give them.