TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
We might be able to get to the "why" of software if we had access to use cases. Some companies do them, but they seldom filter down to tech writers. Further, some of the companies that do use cases don't do them well, mmore's the pity.
I've been researching Agile documentation, and one of the tenets is that developers (and presumably marketers) sit down early in the process with CUSTOMERS to develop brief "user stories." These are brief use cases--they have to fit on the equivalent of a 3" x 5" card--each of which says what a real-world user wants the software to do...AND...lists the acceptance criteria; that is, how will they know that the software actually does meet the request. And writers do have access to these user stories.
Interesting, eh!
Marguerite
--- On Tue, 10/27/09, Janoff, Steve <Steve -dot- Janoff2 -at- Teradata -dot- com> wrote:
From: Janoff, Steve <Steve -dot- Janoff2 -at- Teradata -dot- com>
Subject: RE: Click X, or click the X button?
To: "Chris Despopoulos" <despopoulos_chriss -at- yahoo -dot- com>, techwr-l -at- lists -dot- techwr-l -dot- com
Date: Tuesday, October 27, 2009, 9:35 PM
Very provocative post, Chris. Been thinking about this off and on all
day.
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
app.
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.
Steve
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.
[SNIP...]
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.
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. http://www.doctohelp.com/SuperPages/Webcasts/
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! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as mkrupp128 -at- yahoo -dot- com -dot-
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. http://www.doctohelp.com/SuperPages/Webcasts/
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! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
