SUMMARY: What do we call this button?

["Newman, Sarah" <snewman -at- bechtel -dot- com>]

I'd like to thank the many helpful folks who made suggestions (both on list
and off) regarding what we should call this "button to the right of the
field with an ellipsis (...) on it" that brings up a list to select from.

Responses were mixed as to what to call it:

ellipsis button (4)
button to the right of the field (1)
list button (2)
"..." button -- dots or graphic only, perhaps with special formatting (8) 
Browse button (2)
make the programmers change the user interface (4)
just document it once in an "how to use this interface" section (2)
lookup button (1)

The major consensus among the responders is too include a visual
representation of the button--either a screenshot or the "...". 

Changing the user interface is not workable, at least at this time (this is
ver. 8.6 and we're on a tight deadline). In any case, we've already won a
major battle--we're doing a major, major overhaul of the manual to include
step-by-step procedures, more descriptive headings, etc.

Our compromise is to call it the list button, but include a screenshot of
the button each time.

By the way, we can't just explain it once and be done with it because the
documentation is accessed primarily as context-sensitive help for each
screen.

I've included clips from the responses below, grouped according to their
vote. Thanks again to all who responded.

Sarah Newman
Technical Writing Group
Bechtel
(713) 235-3352
(281) 240-9111


hi, sarah. we have the same button, and we call it the Ellipses button.


My first thought is this: if you call it the ellipsis button, make sure that
your readers know what "ellipsis" means (for example: insert an image of the
screen and call out the various field names and buttons on it prior to the
procedures).

I have run into situations where I thought there was a good chance that the
reader might be confused and decided to simply insert the button image next
to the word "Click" rather than using long drawn out verbal explanations. 


I tend to agree with Sharon that buttons are called by their name, but most
buttons have a better name. That or an icon that looks like the button would
be preferable. 

I vote vehemently _against_ the option "list" button, unless you can make
them label the button "List..." I'd take "the Ellipsis button" before I'd
agree to "list" button. In fact, ellipsis button isn't that bad, in my
opinion.

There's something about "list button" that just doesn't feel right. I think
part of it is that there is no such thing as a "list" button (though there
certainly could be a "List" button). When I hear "list," I expect to hear
"box" next. When I hear "button," it's jarring.

I must admit that I liked three dot button. It's certainly accurate.


I'd call it the ellipsis button; and on first reference in any given major
section, I'd type it like this:

"click the ellipsis (...) button."
You could also do what one person said and add "to the right of the xxx
field," on first reference in any given section, to make darn sure they know
which one to click.

Lots of people don't know what the word ellipsis means, but they will learn!

You can't call it a list button because people who know Windows, when they
hear "list," think of drop-down list boxes, which are shown with a black
down-arrow. Wrong image.



----------------------------------------------------------------------------
------------------------------
I had to hold my head when I read the reference to the "three-dot button".  

Has this former employee been hunted down and been taught NOT to be cute?  I
have many of these "buttons" and refer instead to the "button to the right
of the field" and then "choose the appropriate item from the resulting
list".  I've also seen these buttons referred to as "the ellipsis to the
right of the field"  This IS an ellipsis, it means click me and I'll show
you something more which is what ellipses are meant to show you, from my
humble understanding.
----------------------------------------------------------------------------
----------------------------

it get again to the old question about the users. Ellipsis is a term 
which may not be so common, except for people with certain background.

The suggestion from the developers is actually accurate, and also 
appears to me as the most understandable one. You might compare with 
the terminology guides published by the operating environment 
manufacturer.

In any case, it might be useful to have an introductory section where 
you do explain the basics of use of the program, and also the 
terminology you are using.


Depending on yr audience, "ellipses" might be too complicated.

I had the same situation in an application. What I did was describe certain
common buttons (the Calendar button, the More/List button [ellipses[ and a
few
others that I forget now) in an up-front section that described general
navigation (including the 'desktop', list windows, vcr buttons, field
buttons,
etc, with images of the 'thingie'). I think I called the button the List
button.
In procedure text I think I wrote something like "Enter a name, or use the
List
button to select from a list of pre-defined names".


----------------------------------------------------------------------------
-------------------------------

 kinda like "three dot button" for colloquial use, but in text, you could
call it by its label:

Click the "..." button to continue.

If you don't want to use the quote marks, it'll look a little weird,
admittedly.  You could use a different font for the button name, or perhaps
you could put a box around the button-name text.


I've seen this called both "the ellipsis button" and "the Browse button." We
liked neither term and now simply insert an image of the button in the text:
"Click the [...] button," where '[...]' equals an imported .gif file image
of the button in question. Not an option if your style guide doesn't allow
for it, but that's our solution, for what it's worth. (We do the same for
the "down arrow" on "drop down lists.") 


The software I'm documenting has a similar button in a couple of the
windows. I've just been calling it the ... button, with the ... in bold,
consistent with the other button names. Not an elegant solution, but
there's no question what it refers to. However, in a 250-page document I
refer to this button only once or twice. If I had to use it frequently,
I would give it a name.


We have the same button in one of our proprietary apps.  We document buttons
without the name on it (such as this "ellipsis" button) by inserting the
graphic of that button, instead of giving it a name, in the sentence. For
example, "Click on the (...) button to access a list," (where (...) is the
actual button graphic). 

Of course most users probably won't know what an ellipsis is,
so that's a confusing name. But "list button" is equally confusiing,
since there is no such named button. Why not just call it what is is,
namely, "Click the ... button to the right of the field"


So what _is_ the solution? Use a screenshot of the button. This removes all
the cognitive load on the reader by presenting an image that exactly
resembles what they're going to see and seek on the screen. You also avoid
having to define things, edit rigorously to make the naming consistent
throughout a 1000-page manual, and provide a central repository for the
definitions that forgetful readers can consult when they consult the manual
for the one time per year they actually open it.

I would show a picture of the button or call it a Browse button.


Our software uses this button in several places, too. In some, it's truly a
"browse" button; in others, it opens up some kind of dialog box where
additional detail can be added.

We document all button names by placing them in square brackets:

Click the [OK] button.

This makes it very easy to document the mystery button. I usually say
something like:

Click the [...] button next the the Wazamajig field.


If the programmer can't or won't change the button, then a callout to the
button in an accompanying screen shot -- something like "this is the button
referred to in step X" -- might be appropriate.



----------------------------------------------------------------------------
-----------------------------

Technically, it is a Browse button. It is supposed to be used (by the MS
standard for UI) when there is not room for a button labeled Browse.
Generally, refer to buttons by their function. Ellipse is not really a
function. Knowing that it is an Ellipse button does not help the user tie it
to an action. And it helps the user to be able to tie it to an action.

We call it the Browse button and show a picture in the margin, unless we are
writing for programmers - in that case, we simply call it the Browse button.
They get it.


I've called it the "browse button" in the past.

----------------------------------------------------------------------------
------------------------------

Tell the idiot programmers to rename the button List ...  It's about 10
seconds of their time.

Nobody other than programmers EVER knows what the ellipsis by itself means.
Programs that have it usually have high annoyance factors from typical end
users.


Why not rename the button to something the users will understand?
Documentation cannot cure a bad interface no matter how accurately you
describe it.  Push for usability in the design, and accuracy of
documentation is much easier to achieve.

Given that the ellipses button may mean different things in different
functions within the same application, users will grow increasingly annoyed
by trying to remember what it means in THIS function, and do they really
need to use it this time.

The real estate required to change it to something users can understand is
negligible.  If that's the only issue preventing the developers from
changing it, then in all likelihood there are even more significant problems
with the UI than the name of a button.

Well, how about re-defining the underlying issue: that the program design is
clunky and non-standard (I am assuming we're talking about a Windows program
here) and mkes users do too much work. If we're talking about an exclusive
selection, that is, when a user would select one and only one value, then to
click a button (typically called the Browse button), select an item (which
may include scrolling), then click an OK button, is too many steps.

Windows has interface widgets designed specifically for this purpose. For
doing what you describe, you should be using either a combo box or a
drop-down combo box. (For descriptions of these, see pp. 183-4 of "Microsoft
Windows User Experience," ISBN 0735605661.)

Combo boxes have labels. So your instruction would be along the lines of:

1. In the <label> box, type a value or select one from the [drop-down] list.

Make the software simpler, more understandable, and easier to use based on
existing widgets designed specifically for the task, and your documentation
work will not only be easier, but you won't have these naming issues.


If the real estate is that cramped, they have a problem. If it is a 
Browse button, it should say that. There are buttons that have the 
label and the ellipsis. Guess what they are called?

The real solution is for the programmers to consider that an ellipsis 
does not mean "Browse" .  In your specific example it is displaying a 
list of items. Perhaps they need to use a combo-box or drop-down list.
This is really a problem with the interface, not with the 
description. Unless the list is a list of punctuation marks.


But... why do our conversations about labeling/documenting screen items seem
always to turn into discussions about the design of the interface? We're
tech writers, and not all of us are blessed enough to have programmers who
accept our input and suggestions. Yes, it would be great if the [...] button
could say "Browse" instead. But it doesn't. And the poor person who asked
for suggestions probably doesn't have the leeway to have this changed. If
she did, she probably wouldn't have asked for our help!

I look at this as just one of the (great) challenges of our profession. In a
previous job, I documented microsoft products for training programs. It's
not like I could call up Bill and say, "I hate the dot-dot-dot you put on
that button. Would you please just change it because it's too hard for me to
write about it?" So you find a way to make the documentation work. You don't
gripe that "It's not my fault the docs are hard to read -- it's only because
the interface is difficult to understand!"
--------------------------------------


I'm wondering why you need to document such specific steps each and every
time.  You said you have numerous such fields.  So perhaps a section
documenting HOW to use the interface, including these  fields, is needed.
Then when you are documenting a specific screen, you can just say "fill in
the value."  This has the added advantage of being easy to update should the
programmers come to their senses and create a better GUI.

-------------------------------------------

We call that button the lookup button. I'm guessing that what you're doing
is selecting a value from a master database table to put in a "child"
database table. If that's the case, then we call it a lookup button because
it looks up the master table. For example, if you have a form that has a
shift at the top and you want to list all the employees that work that
shift, you use the lookup button to see a list of all employees in the
employee table.

In some of our programs, the developers have started creating a button that
actually has the word Lookup on it. It's nice, but it does take up a lot
more space.

You probably have a chapter near the front of the manual explaining basic
functions that are similar throughout the book. Explain how to use lookup
tables in that chapter. There will always be people who won't read that
chapter and who won't use the index when they want to find out what the
lookup button is, but tech support would have entirely too much time on
their hands if we could find a way to help those users. :)


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learn how to develop HTML-based Help with Macromedia Dreamweaver!
Dec. 7-8, 2000, Orlando, FL -- $100 discount for STC members.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Your web site localized into 32 languages? Maybe not now, but sooner than 
you think. Download ForeignExchange's FREE paper, "3 steps to successful 
translation management" at http://www.fxtrans.com/3steps.html?tw.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.