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.
Dick Margulis wrote:
> Would that it were that easy, Lou. Sure, if you and I have control over
> the UI design, it can be. But on a Web page with thirty or forty
> controls in four or five graphically distinct styles each in a different
> area of the page and arrayed differently from the others--not to mention
> a bunch of promotional graphics--it is not at all obvious what the
> program is telling the user, let alone asking.
Right, Dick, you can't use "ask" and "answer" when that's not what's
happening. I'm only talking about interacting with desktop apps,
and I'm saying that it doesn't matter that something "popped", that
it's a "box", that certain hand motions are involved, that you have
to "click" in a textarea to give it focus before you start typing,
etc. 99% know that stuff, and the 1% have big problems to sort out
before our product or docs will benefit them, so why even get into it?
The GoDaddy page? Can't do it in a narrative, cuz it's non-linear.
Screenshot, overlay numbered reference points, describe the
reference points below or in the margins. Linear operation within
this UI to describe? Crop and zoom the affected screen areas --
including the reference points -- and trace through the steps. Or
just use the reference numbers without a custom visual.
Only way to overcome visual noise is with better visuals that filter
the noise.
But returning to dialog-type operations, I'm saying the big solution
to bloated description and translation issues is to assume that
common UI metaphors are understood -- because they are, already --
and just leave all that crap out. A car's owner manual doesn't
document what road signs mean, or how to pump gas or renew your
license. They're prerequisites to using the thing, sure, but you
have to acquire them elsewhere. Adding that stuff to the manual
won't sell more cars or better satisfy owners, just make it harder
to find the dipstick. I just wanna find the dipstick.
Same for application software interfaces. GUI metaphors are owned
by the OS / desktop environment, not our app. Knowledge of them is
a prerequisite, same as literacy, hardware, power-up, BIOS load, OS
boot, etc.
What percentage of users benefits from our trying to teach not only
our interface but the larger MS Windows interface in each breath?
What percentage is slowed or distracted by this? On balance, which
approach is more beneficial to sales and satisfaction? Which
approach produces more collateral costs, like pretzel language and
l10n friction?
And that's just for consumers. The more technical the audience, the
wackier it is to reduce every screen event to narrative.
Hey, nothing's perfect, I'm just saying that the most overlooked
editorial option is to cut the knot. There will come a day when "In
the dialog box that appears [blah, blah] click the OK button or
press ENTER" is quaint. How will we know that day is here? Maybe,
for many applications, it is already.
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
