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

Archive for the ‘Uncategorized’ Category

New Feature: Edit and Create Manuals From Within doQer

Thursday, August 13th, 2009

Running the initial Beta trials of doQer hasn’t taken up all of our attention recently; we’ve also been working hard on adding a major new piece of functionality to the system. Whereas up until now users have only been able to put an existing manual into doQer, we’re now implementing the functionality required for users to actually edit their manuals from within doQer, and even create new manuals from scratch.

This capability represents a major piece of the jigsaw in making doQer a really useful application, and it has always been in our roadmap to implement, but it’s complex to achieve from a technical perspective. Embarking upon it, there were some key objectives that we wanted to achieve:

Version Control
It should be possible for users to revisit previous edits, compare, and revert to previous versions of the manual.

Easy Formatting
Writing the manual should not need extensive knowledge of a mark-up language. It should be easy, allowing users to put ideas down quickly to create a manual.

Media Manager
Uploading and including images in a manual must be easy and quick.

The more we thought about these requirements, the more it seemed that integrating a Wiki engine would do the trick. Wikis are flexible and powerful, and most importantly allow us to work with existing, stable code without reinvent the wheel!

Settling on a Wiki engine was difficult given the large number of options available. Luckily we found WikiMatrix, a really useful site that let’s you enter what you are looking for in a Wiki and then gives you a couple of options to try.

In the end we decided to go with DokuWiki:

DokuWiki is a standards compliant, simple to use Wiki, mainly aimed at creating documentation of any kind. It’s targeted at developer teams, workgroups and small companies. It has a simple but powerful syntax which makes sure the datafiles remain readable outside the Wiki and eases the creation of structured texts. All data is stored in plain text files – no database is required.

DokuWiki has all the features we need, and the syntax is perfect in it’s simplicity. The software is Open Source and lightweight, so we were able to modify it to integrate with doQer’s current features. It also keeps the manuals as text files, so from a development perspective it eases the difficulties of managing lots of database tables!

Once the new functionality is implemented, as well as allowing full authoring capabilities from within the browser, authors will benefit from complete version tracking that will enable them to see exactly what changes have been made to each document. It will even be possible to view older versions of the manual and compare differences. Basically, complete wiki-style version control will be available for every manual stored in doQer.

We’re really excited to be rolling out the new functionality. Beta trial participants will be seeing it very soon now…

The doQer Help Section: Eating Our Own Dog Food

Monday, July 13th, 2009

In parallel with the private beta testing that doQer is undergoing at the moment, we’re drafting out the “Help” text that will appear on the site to guide our users.

Of course, since doQer’s purpose is to host user manuals, all of the “Help” text will itself be contained in a user manual hosted on doQer. We’re eating our own dog food.

Making the manuals has actually been a very instructive process for us. As a developer it can be hard to put yourself in the shoes of the user, but using your own product for the purpose it’s indended, not just in a test scenario but on a real life project, really helps to identify areas for improvement.

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.

Suffice or Entice?

Tuesday, May 12th, 2009

The original idea for doQer was inspired, in part at least, by a fantastic blog post from Kathy Sierra, founder of the Creating Passionate Users blog, that contrasts how vendors treat their customers before the sale compared to after the money has changed hands.

Her juxtaposition between the glossy brochures handed out to “entice”, compared to the grey user manuals that merely “suffice”, starkly illustrates an outdated approach to the user experience that, as Kathy points out, vendors just can’t afford to take any more. Users are talking to each other after the sale, and discovering the opinions of others before they purchase. The quality of user manuals now influences pre-sale decisions more than ever before.

That’s why we’re building doQer: we want to help vendors provide a great user experience after the sale, by providing instructions in a variety of different formats so users can pick and choose how they access the information.

Kathy says “What if instead of seducing potential users to buy, we seduced existing users to learn? … Truly passionate users will evangelize to others”. That really encapsulates the value of doQer.

Meeting The Investors

Wednesday, May 6th, 2009

We had a great meeting with our investors, Gwendolyn Tan and Bernard Leong from Thymos Capital Partners, last night, and they were the first to try out our first ever prototype of the doQer application. It’s still very raw at the moment, but some of the core functionality is in place, and Bernard and Gwen were kind enough to “ooh” and “aah” in all the right places during our demo!

They were both very enthusiastic about it, and they’ve given us lots of good ideas for additional features and improvements that we’re working hard to implement now. They’re also very keen for us to get a prototype ready for initial launch so they can help us begin to look for some suitable trial users.

We’re speeding up development now, with the aim of getting a private beta release of the application out, and a first trial user on board, by the end of May. It’s going to be a big challenge!

Thanks for a great meeting Bernard and Gwen. We’re looking forward to showing you the live application soon!