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.
I'll bite for a part of this discussion... How is UI design different
from tech writing? For the sake of argument, let's assume a GUI can be
self-documenting, which means that whatever you might want to do can be
done from the GUI without ever resorting to some other documentation.
Two questions come immediately to mind:
WHAT can I do?
WHY didn't it work the way I expected?
The first question wants a product overview. What I hope to get at the
end of "experiencing" that information is a model that I can refer to
whenever I plan my "user experience" session. If my only access to the
overview "experience" comes from the "user experience", I see a
bootstrap problem. Unless, of course, the "user experience" includes a
prominent excursion named "user experience overview experience" or some
such - in which case the experience has just morphed into documentation.
The second question can be handled by a "troubleshooting experience",
but those experiences aren't always what they're cracked up to be.
Basically, they only work if you can break the experience down to a
discrete decision tree, with a leaf for every possibility. That can
work for some experiences, but with today's software experiences we
quickly enter a level of complexity that makes such trees too costly to
grow, and perhaps inefficient on a disk space per problem resolution
metric. At some point the user needs to experience some reference
material such as system requirements, the names of config files, the
contents of config files, etc.
My fear with the trend toward experience as opposed to information is
theoretical and practical. Theoretically speaking, the essence of
language is to condense experience into codes that we can easily
transmit. Software wouldn't exist without language. It seems strange
to me that we're trying to convert software into experience and minimize
the use of language. An example... Farmer Jones puts up an electric
fence. How do the sheep learn about the electric fence? Each one must
"experience" it. Either that, or the sheep notice that one sheep did
experience it and consequently avoids the damned thing, so they follow
suit in sheepish ignorance. Farmer Jones' kids are better off. Billy
pees on the fence and receives an experience. He then *tells* his
siblings about it, thus giving them information they can use to decide
for themselves what to do. They may even take advantage of that
information, without ever "experiencing" it. For example, they might
tell Uncle Bob to pee on the fence as a practical joke. Information is
power... something sheep are unlikely to experience.
My practical concern is simple - all that stuff really does need to be
documented. You can bet that it will be, but it will be harder (and
more expensive) to get the information, the more we quite literally
obscure it from the user via "experience". That's my beef with Windows
at the moment. It doesn't always do what I expect. Why? Go ask an
expert. If I want to learn for myself, I have to deal with MS
University. The trend in the next round of Windows will only remove me
further from the information I actually need. Bummer. I'll add that
Windows "won" over UNIX because everybody said UNIX was too
complicated. I'm experiencing sardonic chuckles as I write this.
(While you may not exerience the same, I feel its useful to codify my
experience via the above statement, and share it with you.)
On the plus side... If the experience of experience pays off, then
users won't need procedural docs. That means we can look forward to
other information in whatever docs are produced. If we can only
convince companies to release that documentation to the general user,
things will have a rosy side. Personally, I'm rather sick and tired of
the "procedural information" mantra.
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
