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: what to call a button From:Nancy Hickman <nhickman -at- GVI -dot- NET> Date:Wed, 29 Jul 1998 15:29:35 -0500
First of all, congratulations on going the extra mile in taking care of
the user. It's a shame that the vendor doesn't do the same, especially
when the fix is a trivial change to a string or two strings. I wish most
interface problems could be so easily fixed!
Instead of calling the button a particular name, consider using an image
of the button inline with your text, which sounds like what the vendor
decided to do. On first glance, this approach is the best. Your
discussion will coorespond with what the user sees, and he or she should
be able to match up what you are discussing.
You can't ignore the conflicting graphic/text information to the user,
but if you use a term, it is better to mention the name shown on the
image that users will click, rather than the tooltip or status bar line,
which they do not click.
While you are using a consistent term, you could also create a side note
in the margins of the manual to explain how the tooltip/status
information will appear on the tool in this exceptional case. If you are
creating on-line doc, create a very brief note, and place the note on
every page near the first sentence where you discuss the button. You
need to do this labor, because you cannot count on users reading your
on-line doc in any sequence.
If you use a "/" or slash format, users will probably be able to figure
it out (they may think it odd, though), especially if you can establish
a convention throughout your documentation. However, this convention
will be strangely repetitive, because in most cases, the name written on
the button and the tooltip will match.
-- Nancy Hickman
Sharon Burton wrote:
>
> I am documenting a product that the client bought from another company with
> the limitation that they can only extend the product. They cannot change
> what exists.
>
> One of the things that exists is a button that is a picture of a stop sign
> or a green light, depending on the state of other things. The tiny little
> text (really tiny) on the buttons say Stop for the stop sign and Go for the
> green light. The problem is that the tooltip says Run for the green light,
> as does the text in the status bar. When the button is mentioned in the
> text, it always has a picture of the actual button next to it.
>
> What to do? Is it the Run/Stop button or is it the Go/Stop button? Do we go
> with the tiny text or the tooltip? I prefer the tooltip and status bar
> because all the other (and there are a lot) buttons are identified this way.
> The programmers want Go/Stop since that is what the buttons say.
>
> Changing the interface is not an option.
>
> Opinions?
>
> sharon
>