Bridging users & manuals creatively
Enter your email address above to be alerted when doQer goes live!

Posts Tagged ‘writing’

User Manuals In The New World

Wednesday, July 1st, 2009

Picture Credit: Flickr User peterme (http://www.flickr.com/photos/peterme/)

We’re not alone in thinking that user manuals are stuck in the past. Over on the “I’d Rather Be Writing” blog, technical writer Tom Johnson examines the widening gap between how user manuals are presented today, and how modern consumers chose to obtain information.

In short, manual publishers are still churning out 200-page tomes and help files that look, according to Tony Self of HyperWrite, “the same as they did 15 years ago”, while customers are consuming information as tweets, wall posts, RSS feeds and a thousand other forms of abbreviation.

I think he’s hit the nail on the head.

This is exactly what we’re trying to address with doQer, although Tom outlines the problem more succinctly than I ever could, and indeed his post has given us further food for thought on improvements and new features that we could add to doQer.

The way forward, according to Ellis Pratt of writing firm CherryLeaf, is for manual publishers to begin “managing the diversity of information”. That’s a message we’ve taken to heart, and is behind a number of new feature ideas we’re mulling over.

The first commenter on Tom’s post, Febio Cevasco, also suggests some more solutions, which we’re already implementing with doQer:


“Allow readers to embed comments and feedback in documentation, which should then be sent to the authors”

This is one of the key features of doQer that we’ve already implemented for every manual.

“Improve accessiblity. Default search options in CHM and PDF are pathetic if compared even to traditional fulltext search. There’s also often no way to tag content effectively beyond a hierarchy”

doQer uses manuals in an open format, and allows search and instant conversion into various formats.

Be more integrated with the product (in case of software).

This is a broad demand, but doQer certainly increases the potential for product integration. For example, software programs can link directly to relevant sections of information stored within doQer.

Tom Johnson replies that “regarding the ability to embed comments and feedback in documentation, I thought this would be a bigger hit than my experience has shown”, so it will be interesting to see how it pans out on doQer. Either way, Tom’s post, and the comments it elicited, has given us plenty to think about.

Picture Credit: Flickr user peterme.

“Made to Stick” User Manuals

Sunday, June 21st, 2009

Made To Stick You may have come across a book called “Made to Stick” by Chip and Dan Heath. It aims to teach readers how to communicate “ideas that stick”. That is, in the authors words, “what we can all do to make sure our own ideas register with others”.

Isn’t that exactly what we’re trying to do when we aim to create a great user instruction manual?

The idea of communicating a new concept concisely, in a way that others will remember it, is very applicable to manual writing.

Here’s one story, and accompanying analysis, from the book that particularly “stuck” with me, and contains a great lesson for manual writers:

In 1990, Elizabeth Newton earned a Ph.D. in psychology at Stanford by studying a simple game in which she assigned people to one of two roles: “tappers” or “listeners.” Tappers received a list of twenty-five well-known songs, such as “Happy Birthday to You” and “The Star- Spangled Banner.” Each tapper was asked to pick a song and tap out the rhythm to a listener (by knocking on a table). The listener’s job was to guess the song, based on the rhythm being tapped. (By the way, this experiment is fun to try at home if there’s a good “listener” candidate nearby.) The listener’s job in this game is quite difficult. Over the course of Newton’s experiment, 120 songs were tapped out. Listeners guessed only 2.5 percent of the songs: 3 out of 120.

But here’s what made the result worthy of a dissertation in psychology. Before the listeners guessed the name of the song, Newton asked the tappers to predict the odds that the listeners would guess correctly. They predicted that the odds were 50 percent.

The tappers got their message across 1 time in 40, but they thought they were getting their message across 1 time in 2. Why?

When a tapper taps, she is hearing the song in her head. Go ahead and try it for yourself-tap out “The Star-Spangled Banner.” It’s impossible to avoid hearing the tune in your head. Meanwhile, the listeners can’t hear that tune-all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code. In the experiment, tappers are flabbergasted at how hard the listeners seem to be working to pick up the tune. Isn’t the song obvious? The tappers’ expressions, when a listener guesses “Happy Birthday to You” for “The Star-Spangled Banner,” are priceless: How could you be so stupid?

It’s hard to be a tapper. The problem is that tappers have been given knowledge (the song title) that makes it impossible for them to imagine what it’s like to lack that knowledge. When they’re tapping, they can’t imagine what it’s like for the listeners to hear isolated taps rather than a song. This is the Curse of Knowledge. Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has “cursed” us. And it becomes difficult for us to share our knowledge with others, because we can’t readily re-create our listeners’ state of mind.

Sound familiar?

This is exactly how incomprehensible user manuals get written: the author is suffering from the “curse of knowledge”.

It’s particularly common when the engineer who made the product is the one tasked with writing the manual for it. An external technical writer can often be a better option simply because he or she is looking at the product with fresh eyes.

You’ll have to read the book to discover the six methods Chip and Dan suggest to counteract the curse of knowledge, but one tip that can fit into the space of a blog post is this: get an ignorant proof reader.

Not chronically ignorant, but just ignorant of your product. Someone who is in exactly the same position as the people who will be using your product manual. Ask them to read the manual and give you honest feedback on where it just doesn’t make sense.

And, of course, we must mention doQer here. doQer’s “User Commenting” gives you, as a manual publisher, an amazingly powerful tool to collect this kind of feedback. Users read your manual and tell you honestly where it falls short. Essentially, you’re crowd-sourcing the task of “ignorant proof reader”.

User feedback is a useful feature for consumers to help each other, but it’s also a great tool to help you create manuals full of ideas that are “made to stick”.

Manual Meltdown

Thursday, June 18th, 2009

I spent a morning (and afternoon) recently setting up a new wireless router kindly bequeathed by my neighbour: a futuristic-looking box with a few flashing lights down the side and some dangerous-looking spikes coming out of the top (the router, not the neighbour).

Connecting it to the phone line was fairly easy (following the time-honoured method of plugging each cable into whichever socket would fit). Connecting a laptop to the wireless network was not.

I didn’t have the user manual as it had been lost somewhere, or possibly burnt in frustration, by its previous owner. “No problem,” I thought, “I’ll just download it from the internet”. A good 20 minutes of searching unearthed the manual for a similar model lurking in the recesses of the manufacturer’s website.

In PDF format.

I went and made a cup of coffee while my aging internet connection (broadband would have been good, but I’d need the new router working for that) downloaded 28 megabytes worth of PDF file, containing the instructions I needed along with their Russian, Spanish and Swahili translation, none of which came in particularly useful.

Searching the document drew a blank - Acrobat seemed to think the manual was an image and couldn’t recognise the text to search it - so the rest of the morning was spent scrolling through the manual, skim-reading each page for a clue.

And the router was in the other room (I don’t have Wifi yet, remember?), so I had to keep running from computer to router box to press reset or check which light was flashing. OK, I could have printed the manual out, but that’s not very green, and besides, I don’t think my printer can cope with Russian characters.

In the end, the manual didn’t have the answer anyway, so in desperation I turned to online discussion groups, a disorganised, blind-alley-laden, wondering-aimless-narative-filled information source if ever there was one.

I found the answer eventually, and the internet connection is now, finally, working fine, but I can’t resist the temptation to blog about how doQer would really have helped in this situation:

For a start, doQer will provide quicker access to the section of the manual you need, without the long download time. It puts user manuals in a variety of different formats, and you can chose to view by section. A PDF version is available, and so is a browsable HTML one. It’ll also automatically format user manuals so that they’re easy to read on a handheld device. Hopefully running between rooms will no longer be necessary.

doQer can translate user manuals into a whole variety of different languages too, so you can choose the language you need rather than sifting through lots of incomprehensible sections.

And finally, user feedback in doQer allows you to submit questions, and read feedback from others. doQer users can insert questions right into the manual itself, which are immediately forwarded to the publisher. I could have submitted a question about the user manual, or perhaps even benefited from the experience of a previous user who’d been in the same boat, without resorting to those internet forums.

Where were you when I needed you doQer? Thankfully, we’re launching soon…

doQer is hiring!

Thursday, June 4th, 2009

We are looking for an HTML/CSS developer to help us convert PDF documents into standards-compliant HTML files for an exciting new web application.

We will provide an HTML template structure for you to follow, and a user manual in PDF format. You will convert the manual, either manually or using automated tools, into well-formatted HTML.

Applicants should:
- Be conversant in HTML and CSS
- Have experience working with HTML templates (please provide examples of previous work if possible)
- Posses good attention to detail

Interested applicants are welcome to e-mail us at jobs@doqer.com.

The Popular Manuals

Thursday, June 4th, 2009

User Manual

We want to upload a few existing user manuals to doQer, for products that are already on the market, so that we can begin showcasing the application’s capabilities.

It seemed a good idea to figure out which manuals people use most, so I did a quick Google search for a list of the most popular manuals. Unfortunately, such a list doesn’t seem to exist online (I guess not everyone is as obsessed with user manuals as we are here a doQer!).

A different approach was required. It seems to make sense to assume that the popular manuals would more or less correlate to top selling consumer electronic products, so I followed that path by looking at the most sold products from online shops and websites like Amazon.com, Shopper.com, and PriceGrabber.com. Much easier to find!

The top products were:

  • Apple iPod Touch
  • Apple iPod Nano
  • Asus Eee PC 1000HE
  • Canon PowerShot SD880 IS
  • Canon PowerShot SD890 IS
  • Garmin Nuvi 265WT
  • Nikon D90 Black
  • Samsung BD-P3600
  • Samsung LN52A650

Obviously we need to apply a bit of common sense as well to figure out which user manuals are going to be in demand from this product list - for example, perhaps an iPod Touch user interface is fairly self-explanatory, whereas maybe a Canon Powershot requires a bit more explanation. For that reason, we doing a bit of our filtering ourselves too to decide which manuals to feature first.

We’ve now chosen a couple of manuals to start a proof of concept trial and we’ll soon welcome to the first manuals in the doQer collection!

Bridging the Gap

Sunday, May 31st, 2009

Lack of product support is still a problem consumers encounter after purchasing a product. That’s an issue we want to address. doQer will provide the ability to place comments alongside product manuals, creating a portal where users can offer their feedback about a manual, and have all their questions answered by the product vendor.

Improving the communication between users and vendors is extremely beneficial to users because they can get their questions answered rapidly, ultimately creating a knowledge base for the community. What really drives doQer is the ability to give users reliable information by providing the opportunity for the actual product manufacturer to answer questions.

Product manufacturers will also take advantage of the ease of communication with their user base. They can quickly edit their manuals to clarify points, and gather feedback on the product they’ve released. Most importantly, doQer will allow manufacturers to build a good relationship with consumers by giving them an excellent customer experience.

Our aim does not stop at providing an accessible way for users to access their manuals. It goes beyond that, by bridging the existing gap between consumers and manufacturers.