Home Computer: What they say may not be what they mean: Interpreting the manuals can be an art in itself. Rupert Goodwins delves into the dark arts of technical writing and finds the most useful information on the back cover
Your support helps us to tell the story
From reproductive rights to climate change to Big Tech, The Independent is on the ground when the story is developing. Whether it's investigating the financials of Elon Musk's pro-Trump PAC or producing our latest documentary, 'The A Word', which shines a light on the American women fighting for reproductive rights, we know how important it is to parse out the facts from the messaging.
At such a critical moment in US history, we need reporters on the ground. Your donation allows us to keep sending journalists to speak to both sides of the story.
The Independent is trusted by Americans across the entire political spectrum. And unlike many other quality news outlets, we choose not to lock Americans out of our reporting and analysis with paywalls. We believe quality journalism should be available to everyone, paid for by those who can afford it.
Your support makes all the difference.ARTHUR C CLARKE foretold the nature of computer manuals when he wrote that any sufficiently advanced technology was indistinguishable from magic. His books are full of high-tech machines that behave in magical ways, the most famous being Hal, the computer from 2001 that - in the best tradition of demonic summoning - goes out of control and turns on its masters.
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.