10 Ways to Please Us, the Customers

NYT published this list. I thought the ones below might ring a bell to all you tech writers out there:

II. Thou shalt hire native English speakers to translate thine instruction manual. "When the camera focus is not so possible, hold the shutter button vaguely until the beeping tone is heard." Is that really how your company wants to address customers?

Talk about New Math. You'll spend millions of dollars developing some breakthrough gizmo, but won't spring for somebody to rewrite your manual in proper English? I know some high schoolers who'd do the job for $50 and 10 free ring tones.



VI. Thou shalt not hide from thy customers. If you've designed your product properly and provided a decent manual in English, you ought to have nothing to hide; there should be very little reason to worry that we, the masses, will jam your phone lines asking for help.

Thanks King!

Read More

Top Ten Documentation Heuristics by Vesa Purho

"For example, people working on a rooftop installing some hardware would not necessarily be delighted with nice multimedia CD-ROMs but prefer a laminated quick reference card."

That statement pretty much sums it up for me. Read on!

1. Match between documentation and the real world

The documentation should speak the users' language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.



2. Match between documentation and the product

The forms, screens, manuals, and online helps system should match so that the same terminology is used in all of them. This may contradict with "Match between the documentation and real world" if the interface uses strange terminology.



3. Purposeful documentation

If the documentation set contains several documents, the purpose of each type of document should be clear, as well as the intended use. The media of the documentation must be purposeful so that users get what they need. For example, people working on a rooftop installing some hardware would not necessarily be delighted with nice multimedia CD-ROMs but prefer a laminated quick reference card.



4. Support for different users

The documentation should support users with different levels of knowledge on the domain as well as those assigned different tasks in the domain. Any unnecessary information for a specific user must be hidden from other users or be easily overlooked. Quick reference information for expert users should be available.



5. Effective information design

Information must be presented in a way that it is easily found and understood by the users. Short lines and paragraphs are easier to read. Graphics, tables, and lists are easy to scan and read, and appropriately used to support the information need the user has. Unnecessary graphics only slow the reading and the download time of web-based documentation. Write instructions in imperative form and address the user directly using active sentences.



6. Support for various methods for searching Information

Documentation should support people with different strategies for finding information: some search through the table of contents, some use the index, some browse, and some use searches (in electronic documentation). The index should contain users' own terminology as well as system terms, terms from international standards, and those used by competitors. The layout of documentation should support browsing so that beginnings of new chapters and important warnings and notes are easily picked up.



7. Task orientation

Instructional documentation should be structured around the users' job tasks, that is, tasks that are independent of the tools used. The job tasks remain the same although the tools may change. For example, the job task "baking bread" remains the same although the baker may do it all by hand or using latest state-of-the-art tools. This reduces the need to restructure the documentation when the product is changed. The tasks should be approximately at the same level of granularity throughout the documentation



8. Troubleshooting

The documentation should contain a troubleshooting section giving users guidance for common problem situations and how to analyze rare situations. All documentation related to errors must be easily accessible.



9. Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. If the product has several documents, they should be consistent in their structure and the information in different documents should be designed so that no unnecessary overlapping exists. Follow platform conventions when creating the help system. Be sure that the terminology is consistent throughout the documentation suite.



10. Help on using documentation

If the documentation set is large, provide instructions on intended use, and how it is going to be updated (if separate updates are delivered).

[Source: Heuristic Inspections for Documentation – 10 Recommended Documentation Heuristics by by Vesa Purho, Nokia]

Read More

Engrish!

Read More

MS Office 12 to Support PDF

Microsoft has announced that it will introduce PDF (Portable Document Format) support in its forthcoming version of Office, code-named "Office 12", scheduled for release in the second half of 2006.



Reportedly, the PDF format will be integrated in MS Word, Excel, Publisher, PowerPoint and InfoPath among other applications. Microsoft maintains that the inclusion of PDF in Office 12, will further broaden the appeal of the program.



Microsoft says that it is adding the "save to PDF" feature, with a view towards satisfying users who want to share documents with people, including those who don't have MS Office.

Read more on TechTree

Read More

Aah?

The other day a couple of my colleagues were discussing about the bad habit of adding the ‘aah’ sound while phrasing a question. I don’t know if it is bad; but it sure will give ulcers to the purists.
Take for example how ‘are you coming with us?’ is brutally hacked to a single word question: coming-aah?
Or, the totally new form of exclamation: ‘Yes-aaah?’ that roughly translates to ‘don’t tell me it is true!’  
Or the usual friendly enquiry ‘you ate-aah?’ that is the equivalent of ‘did you have your lunch?’
The ‘aah’ sound is widely used—especially in interrogative phrases— in Tamil and Telugu:
‘Saapteengalaah?’ (Did you eat? - Tamil)
‘Varreengalaah?’ (Are you going with us? – Tamil)
‘Baavunnaaraah?’ (How are you? – Telugu)
‘Bon-chesaraah?’ (Have you eaten? – Telugu)

And we south Indians use the same construction even while conversing in English. I think it is a unique fusion of two different linguistic rhythms. The purists may scoff at it, but I enjoy using it and listening to others use it.
You like it-aah?

Read More

Tech writer or DTP Expert?

I saw these requirements for a technical writer opening on one of those ‘Urgent-wanted tech writers’ mails:

• HTML programming, Javascript
• Microsoft Office suite (Word, PowerPoint, Excel), Microsoft FrontPage
• Macromedia Dreamweaver
• Macromedia Flash
• Adobe Photoshop, Adobe ImageReady, Adobe PageMaker, Adobe Acrobat,
• RoboHelp
• Microsoft Visio

I wonder why they left out C, C++, Java, and VisualBasic? Why, why? When will they learn to tell a writer from a DTP professional? What has Flash got to do with a tech writer’s job? Javascript for heaven’s sake!

Read More

A brand name gone wrong

"Did you know that Heroin was originally a brand name for cough syrup? In 1874, German scientists developed a formula for a painkiller that they thought would be less addictive than morphine. They simply added two acetyls to morphine to synthesize diacetylmorphine.

Heinrich Dreser, the head of Bayer drug development tried it on animals and humans. He, also, tried it on himself, which may have been the problem. He was very pleased with the results and decided it was a good treatment for many ailments especially respiratory ones like bronchitis, asthma and tuberculosis." Read more on Free Enterprise Land

Read More