In 1967 this was futuristic fiction: in 1993, few of us escape the experience of a computer going wrong. Crashes, lost files and incomprehensible commands are enough to drive anyone into the dark arts, but the incantations of the manual only heighten the mystery.
Computer manuals are forbidding things which, for all the good they do, could often just as well be in the runes of the ancient mages. It is often difficult to imagine what sort of creatures write the things; computer scientists in white coats, perhaps, or long-haired pentacle-wearing hippies scribbling spells and charms by candlelight. Whatever they are, they rarely win Pulitzers; technical writing tends to the dry and didactic.
This is exacerbated by arcane vocabulary - the hippies, it is safe to assume, are experts in computers and the software they are writing about. They have lived and breathed it for months, in close communion with the programmers. For them, phrases like 'memory allocation' and 'extended error' are in everyday use and deserve, they feel, scant comment when written down. It is difficult for them to think on the level of the neophyte, the person still unsure why floppy disks are square and hard and for whom the word 'port' still conjures up thoughts of gout or Southampton.
This problem is compounded by Windows and other graphical user interfaces. While you can usually make a stab at looking up 'file header' in the index, it is harder to know where to start with a hieroglyphic icon.
There is an art to using a computer manual. Whatever you do, do not skip the first few chapters - if the writers feel the urge to explain their particular arcana, this is where they will do it. The end of the book is also worth reading with care; there will be stuff in appendices which you will need but will not appear in the index. Each manual works by its own rules as to whether error messages and the like appear sprinkled throughout the body of the text or are grouped together in an appendix or separate chapter.
There may be a tutorial. Although you may quail at an hour spent writing a letter about widgets - the traditional word processor example - you will at least learn what all the main features are called in the manual.
Since computer handbooks read like textbooks, try treating them as such. Reading techniques painfully learned for exams will earn their keep if you really have to bone up on some software. Most manuals cover their products by grouping similar functions together; this makes manageable areas to learn about.
If things do not go as the manual suggets they should, remember it is just as possible for the manual to be wrong as for the software. Handbooks are often written merely as an addendum by the software producers and consequently checked and tested less. There is a school of thought which says that manuals should be written and finished before a line of software has been produced. Few companies have this discipline, though, and often compound last-minute modifications in their programs or hardware by hastily written and badly checked changes to the handbooks.
In particular, any example programs or macros in a manual are prone to errors - these go through more stages in the production of the manual than the text does and are rarely checked with the same thoroughness.
Late updates are often included as a file on the program disk or in the help screens built into the software. If your manual stands mute on a subject, try the help key. If all else fails and the manual really is a poorly designed, mis-indexed, cryptic mishmash written by a programmer whose hexadecimal arithmetic is better than his English, try a book shop. A large industry has grown up around publications that put right the sins of the official manuals; most major programs and a surprising number of minor ones have got a selection of books devoted to them. It might seem painful to spend yet more money on a difficult program, but a good book written in a style that appeals will be worth the hours it saves.
Things are getting better. Although the latest manuals issued with Microsoft or Lotus products may still have the charm and style of a car repair handbook, they are logically organised and produced after long consultation with real users. Multi-volume manuals, normally split into books for the beginner, the normal user and the expert, also help ease a new user through the various stages of competence.
Further down the corporate scale, however, the old style of occult writing remains popular - the smaller the company and the more specialised the software, the greater the chance of getting a slab of incomprehensible technospeak.
For some reason, computer hardware is particularly prone to this and there are manuals for Japanese printers that still defy the best efforts of highly trained linguists. It is often wise to give in gracefully at the first sign of resistance from a hardware handbook, especially one for a PC-compatible add-on. Even adding another serial port for a mouse can involve setting base register addresses and IRQ lines, things which would induce most people to go and lie down in a darkened room.
When you buy hardware add-ons, make sure you can get support from the people who sold it to you. Failing that, find your local popularly acclaimed computer expert. Most companies have one somewhere. Only as the last resort, or perhaps to while away a wet Sunday, try using the manual.
It all boils down to your love of puzzles. If you can do the Independent crossword, you may relish the lateral thinking needed to sort out your woes. If, like me, you would rather get on with things, the most understandable and useful part will be the telephone number printed beneath the manufacturer's address on the back cover of the manual. You will not even have to open it.
IndyBest product reviews are unbiased, independent advice you can trust. On some occasions, we earn revenue if you click the links and buy the products, but we never allow this to bias our coverage. The reviews are compiled through a mix of expert opinion and real-world testingReuse content