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.
Subject:RE: 40 buttons on one screen From:"Kathleen" <keamac -at- cox -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 5 May 2005 23:28:52 -0700
I've had to explain complex screens a couple of times in user manuals.
Maybe you can adapt some of what I did to fit your needs (in fact, some
sounds similar to your ideas):
1. Using a main section/chapter subhead, show the main screen shot in
all its glory and give a brief introduction to it, saying X number of
different sections control x functions, explained in the following
subsections (maybe links?). If possible, group the buttons according to
related actions/controls and give the groups names, making them up if
necessary. With any luck the developer will give the buttons names that
help group them. Mention the names in the summary.
2. Use subsections (links) named for the groups, accompany each
subsection with a screen shot of that group, explaining where it is in
the whole (e.g., lower left) and explaining each component. Some of the
groups I ended up with were large, some small, but it helped keep the
information in front of people--couldn't expect them to remember it
otherwise.
One way to approach this in an online format would be to use dropdown
boxes or popups(?depending on your program) for the screen shots, so you
could cram more together if necessary.
Don't know what the timeline is, but I've found that if I can get
everything structured and complete minimally partial explanations of all
the components, it isn't so bad when they change the buttons and their
actions, so long as they're maintaining some similarity of functions.
Screenshots are pretty easy to redo, though the reformatting and editing
of the explanation does add up.
Good luck, I'll be interested in hearing what you do.
Kathleen
-----Original Message-----
From: Ashok Gopal
Okay, the heading is a slight exaggeration--but only slight.
I have to write the online help for an application which essentially
consists of one main screen with a bewildering number of buttons, boxes
and
lists for a host of functions. Context-sensitive help will make the
user's
life a a lot easier, but the application developer says it does not have
the
time and resources for context-sensitive help. Nor does it have the time
for
a printed manual (where one can put the "all in one screen" over a
doublespread and insert callouts for each list and button, explaining
briefly what each is for, with references like "see chapter 3 for more
information"). It wants online help (yesterday) and nothing else.
My problems are as follows:
1. The "all in one" screen looks frighteningly complex--even to me. How
do I
reduce "screen fright" in online help? Using a screen capture of the
whole
screen is not viable--it would have to be used same size for anything to
be
legible. I could have a part-by-part introduction of the screen, with
topics
like "Overview of the top right corner of the screen" , which of course
sounds very dumb. Is there a smart/obvious way to reduce "screen
fright" in
these circumstances?
2. Every time I describe how a task is to be done, I have to start with
something like "In the bottom left corner of the screen, click...". I
could
insert a slightly enlarged image of this corner and have a red arrow
pointing at the specific part the user should be looking at, but the
practical difficulty is that screen layouts haven't yet been frozen. Any
other options to consider at this stage?
Is there a totally different way to approach this problem?
(The application is going to be used by people of the level of
"operators"
who will simply perform tasks they have been asked to do. They are
already
doing these tasks, but they are using different applications for
different
tasks. Now all those applications have got squeezed into this one
application with a mega-complex screen. I can of course join everyone
else
in mocking the design, but that won't help me earn my money.)
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: 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- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.