RE: Click X, or click the X button?

Subject: RE: Click X, or click the X button?
From: "Janoff, Steve" <Steve -dot- Janoff2 -at- Teradata -dot- com>
To: "Chris Despopoulos" <despopoulos_chriss -at- yahoo -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Tue, 27 Oct 2009 21:35:04 -0400

Very provocative post, Chris. Been thinking about this off and on all

What you're really talking about is reverse-engineering the engineer's
thought process.

The company starts out with an idea for a software product, with the
product having a goal and a purpose. Then the developer turns that idea
into software.

But the real question, as you suggest, is not how to use the software or
even how to perform a particular task but what is the software for?
What was this stuff originally designed to do? And that will give you a
hint about what the different features do.

So it's very provocative to ask, What is a dialog box? What is its
purpose? As a tech writer I can tell you how it works (old school), and
I can even tell you, step by step, how to perform a particular task with
it (assuming, let's say, that the dialog box performs a task of moderate
complexity). But that doesn't tell *why* you want to perform the task.

My own experience as a tech writer has often been that I have to
document something before I really understand why I would want to use
it. Especially if it's highly specialized or technical. And then over
a period of documenting parts of the total product, maybe at some point
the original purpose comes through in an "Aha" moment.

But you're really asking what's the purpose of software? Or maybe
what's the purpose of an interface?

The idea comes to mind of a coffee-vending machine. You push buttons to
select your beverage and have it dispensed by the machine. The very
same thing can be accomplished (the selection part, that is) with a
software GUI -- a dialog box. You select all the particulars of your
coffee or hot chocolate or whatever, and then an actual machine
dispenses it. The software merely takes your order (and conveys it to
the machine).

So I guess machines replaced humans, at least in the order-taking
process, and now software can replace machines (and people). I mean,
you can probably do all your ordering at Starbucks from a touch-screen.
Wouldn't be nearly as much fun, but probably faster.

I don't know, I guess we get so focused on how to use software that we
don't get a chance to think as much about why we use it, or a particular

Cool stuff -- thanks for posting, keep it up. Your recent rant, earlier
in this thread, was one of the best things I've read in a while.


PS - I know there are already touch screens for ordering and there are
vending machines with GUI interfaces. That's a preemptive hip-check for
anybody who wants to bag on me about such nonsense. There *are* such
people on Techwhirl. :) To all such people I say, chomp on your
teething ring and think about, "What's the purpose of MS Word?" :)

-----Original Message-----
From: techwr-l-bounces+steve -dot- janoff2=teradata -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+steve -dot- janoff2=teradata -dot- com -at- lists -dot- techwr-l -dot- com]
On Behalf Of Chris Despopoulos
Sent: Tuesday, October 27, 2009 4:53 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: Click X, or click the X button?

No argument here, Janice. Just more reason to cut the cr*p and make
sure the documentation is worth reading. If users trust you to provide
meaningful content that doesn't waste their time, you limit the urge to
skim. And if you organize the presentation so they can categorize what's
on the page and get to it immediately, so much the better. That's not
skimming, it's ordering the content. I'm specifically thinking about
presenting dialog box options as tables or lists, with option name
followed by effect. You can think of a dialog box as a command in a
programming language -- the options are arguments where control type
takes the role of arg data type or command flag. Why does a dialog box
need more than:
* Synopsis (including gotchas, tips, and warnings)
* Result (analogous to function return val, or output)
* Inputs
* Error states (usually unnecessary because alerts self-document errors)

Then a "task" becomes something like...
To configure your frazbot, set the following dialog boxes in the
following order:
* <link>Hinkey</link> dialog, to specify which hinkies will run during
frazbot initialization
* <link>Dinky</link> dialog, to assign the persistent hinky to the
frazbot dinky state
* etc.

The *level* of task orientation jumps to a different electron orbit
(releasing photons? light bulbs turning on?), and people can model how
they approach the software as a whole, not how they approach a morass of
individual tasks centered around which dialog box controls to modify.

If you have dialogs that serve multiple purposes (quite likely), then
your "task step" expands to describe how to use the dialog for that
special situation. But I maintain that keeping the task at a higher
level makes it easier to distinguish when and how to use the same dialog
for different results.

I'm not saying that readers aren't going to skim anyway, just that I
don't think that calling out GUI items to encourage them to do so is a
good idea.
I'd prefer not to lead them astray by implying that they can just
merrily click items and press buttons without reading any explanatory
information - sometimes such behavior causes inescapable consequences so
going back to the docs afterward to find out what they did is not always
a solution.

-- Janice

Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices.

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

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 for more resources and info.

Please move off-topic discussions to the Chat list, at:

Re: Click X, or click the X button?: From: Chris Despopoulos

Previous by Author: RE: suggestions for naming a UI element
Next by Author: RE: TECHWR-L Digest, Vol 48, Issue 25
Previous by Thread: Re: Click X, or click the X button?
Next by Thread: RE: Click X, or click the X button?

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

Sponsored Ads

Sponsored Ads