40 buttons on one screen?

[Geoff Hart <ghart -at- videotron -dot- ca>]

Ashok Gopal reports: <<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.>>

In my professional opinion (graduate course in soil science and plant 
physiology), that's male bovine fecal material, and while it's good for 
crop growth, it's not so great for software. <g>

With just about any modern interface design tool, you can revise the 
entire interface for a simple dialog box in 15 minutes flat, plus bind 
in help context IDs at a rate of about 10 seconds per button--and 
that's if your developers are morons. I've sat with busy programmers 
and done exactly this kind of interface surgery. It's not rocket 
science, it doesn't take any significant time, it ends up saving the 
developers more time than it costs them by an order of magnitude 
(design once instead of 10 times), and the benefits to the user are 
obvious.

<<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.>>

Have you suggested that they outsource the project to North America? 
<gdrlh>

<<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.>>

It's still the best solution. The way you do it is as follows: First, 
figure out logical groupings for the buttons, usually based on the 
user's task. (Break complex tasks into subtasks if necessary.) Second, 
open the screenshot in Photoshop or some other bitmap editor. Third, 
highlight the buttons in one functional group and de-emphasize the 
remainder of the screenshot. I've done this by selecting those buttons, 
inverting the selection (so that all the rest of the bitmap apart from 
those buttons is now selected), then reducing the color intensity by 
50%--in effect, greying out the background. The goal is to make the 
"background" sufficiently visible that it provides useful context 
(e.g., where the buttons are) while making the buttons fully visible.

The final step: Turn the resulting bitmap into an image map, with each 
button clickable to produce the corresponding help topic. Repeat as 
necessary for each group of buttons.

<<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.>>

Use the same approach, only smarter: the "top right corner of the 
screen" is probably grouped based on some functionality. Name that 
functionality (e.g., "Activating the self-destruct"), then use the 
bitmap described above to visually define what you mean by that name. 
You then have a simple heading: "Activating the self-destruct", and can 
refer to all buttons in that context without mentioning the context 
again.

<<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...>>

One very effective form of documentation involves the screenshot (or 
more appropriately, just the highlighted parts that you're currently 
talking about) surrounded by the instructions. Provide callouts (text 
plus pointers) such as "click here to select the X option" for all the 
buttons in a given procedure. Now, number your callouts to indicate the 
correct order in which to do that procedure. Last step: rearrange the 
callouts around the screen until they fall into logical order (e.g., 
clockwise from the top left, from top to bottom along the right or left 
side of the screenshot, etc.). You're done. Move on.

<<...but the practical difficulty is that screen layouts haven't yet 
been frozen.>>

Good. Remind the client that this is the case, and point out that it's 
trivial to freeze the interface now by redesigning it to your specs, so 
they can ignore the interface from this point onwards and concentrate 
on the code that makes that interface work. Programmers have a 
genetic-level aversion to accepting this advice, but Alan Cooper has 
demonstrated repeatedly that the developers don't know what they're 
talking about.

In my experience, programmers have often (not always) been quite 
willing to design the interface once (with my help) rather than 10 
times (blundering along on their own) so they can use their scant 
remaining supply of time to focus on the really important things: 
coding and debugging. Win-win situation, folks.

<<(The application is going to be used by people of the level of 
"operators"... Now all those applications have got squeezed into this 
one application with a mega-complex screen.>>

Ask the project manager what each mistake made by a user will cost that 
user's company. Ask the project manager what their legal liability is 
when these mistakes are made. Ask the project manager what happens when 
the users revolt and move to another company's product. Ask them why 
they're not prepared to spend 30 minutes over the entire product 
development life cycle (thousands of hours) to solve these problems.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
www.geoff-hart.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.