Re: Documenting the user interface

Subject: Re: Documenting the user interface
From: "Mike Starr" <mike -at- writestarr -dot- com>
To: "Combs, Richard" <richard -dot- combs -at- Polycom -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 11 Jan 2007 21:07:45 -0600

If a large manual is poorly structured, poorly organized and doesn't have a decent table of contents and index, then you're right... the user's would have to wade through a lot of stuff to find what they need. However a well-done manual makes it easy for the user to find the information he/she needs.

You seem to have little respect for the users and believe they must be innately timid, passive and dependent, yet you advocate that they learn how to use products by exploring and experimentation? I don't want to waste their time. I want them to be able to use the product and if they have a question I want them to be able to look it up quickly and get back to work, not get off on some experimental tangent.

I don't create thorough documentation because I want to cover my ass or to keep myself busy... I create it because I want the users to have everything they need to use the product with as little inconvenience as possible. I have no patience for time wasters and CYA approaches.

Do a little experiment for me...

Start up Microsoft Word, choose the Tools>>Options menu item, then click the Compatibility tab. Scroll down the list and explain to me the differences between "Suppress extra line spacing at top of page", "Suppress extra line spacing at top of page like Word 5.x for the Mac" and "Suppress extra line spacing at top of page like WordPerfect 5.x". This is vital information... there's no way I can make an informed choice without an understanding of what the difference between these options is. It's not in the documentation. It's been this way at least as far back as Word 97. WTF?? And by your standards, I can waste a half a day carefully examining the impact of these three choices (alone or in combination... they're not mutually exclusive) and that's a good approach to documentation, right??
--
Mike Starr WriteStarr Information Services
Technical Writer - Online Help Developer - Website developer
Graphic Designer - Desktop Publisher - MS Office Expert
Phone: (262) 694-1028 - Tollfree: (877) 892-1028 - Fax:(262) 697-6334
Email: mike -at- writestarr -dot- com - Web: http://www.writestarr.com

----- Original Message -----
From: "Combs, Richard" <richard -dot- combs -at- Polycom -dot- com>
To: "Mike Starr" <mike -at- writestarr -dot- com>; <techwr-l -at- lists -dot- techwr-l -dot- com>
Sent: Thursday, January 11, 2007 9:46 AM
Subject: RE: Documenting the user interface

Mike Starr wrote:

However, to leave users twisting in the wind, resorting to
"exploring and learning", because there is no reference
documentation is unconscionable.
Every button, checkbox, radio button, drop-down list box,
etc. in a user interface needs to be explained somewhere in
the documentation set. Not only that but it must be easy for
the user to find that explanation when he/she needs it.

Every etc. needs to be explained, or users twist in the wind? Nonsense.
That approach leads to at least two bad consequences:

-- Almost no one uses that 400-page manual because they get sick of
wading through
useless information like "The First Name field is where you enter the
user's first, or given, name. The maximum length is 30 characters. The
valid characters are the letters a through z, A through Z, ..."

-- The minority of users who actually _do_ use a manual like that have
their innate timidity, passivity, and dependency reinforced, instead of
being encouraged to become active participants in the learning process.
Then, the tiniest mismatch between the interface and the hand-holding
documentation upon which they've come to depend throws them for a loop.

Admittedly, "Know your audience!" applies, and there are products and
audiences that call for a very thorough, newbie-oriented approach. But
90% of the time, this is over-documenting. People do it because it keeps
them busy, it's a CYA thing, and it's easier than the difficult process
of determining what's really important and how best to present it.

"It's my opinion and it's very true."

Richard


------
Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
------
rgcombs AT gmailDOTcom
303-777-0436
------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WebWorks ePublisher Pro for Word features support for every major Help format plus PDF, HTML and more. Flexible, precise, and efficient content delivery. Try it today! http://www.webworks.com/techwr-l

Create HTML or Microsoft Word content and convert to Help file formats or printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.


References:
RE: Documenting the user interface: From: Combs, Richard

Previous by Author: Re: Documenting the user interface
Next by Author: RE: Documenting the user interface
Previous by Thread: RE: Documenting the user interface
Next by Thread: RE: Documenting the user interface


What this post helpful? Share it with friends and colleagues:


Sponsored Ads