40 buttons on one screen?

Subject: 40 buttons on one screen?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 06 May 2005 08:32:21 -0400


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.



References:
40 buttons on one screen: From: Ashok Gopal

Previous by Author: "Community" or "user" generated documentation?
Next by Author: How evil is copy-and-paste?
Previous by Thread: RE: 40 buttons on one screen
Next by Thread: RE: 40 Buttons on one screen


What this post helpful? Share it with friends and colleagues:


Sponsored Ads