Meaningful labels

I would make sure that you aren't constrained by javascript confirm boxes
before
trying to change ok/cancel, as these choices aren't configurable without
'fancy' coding.

>Somehow, before I started with my current employer, a decision was made
(arbitrarily) to use "OK/Cancel" buttons for everything they applied to,
regardless of whether or not something else, like "Apply" or "Save", would
offer more meaning.

This morning I was asked to present my case for why to avoid using the same
button labels in every case, and instead use something more meaningful when
it makes sense to do so. So, I have some ideas about what to say, but I
wanted to ping the list and see if anyone here has any hard research on the
subject, or has any interesting insights I might be able to share. Any ammo
is good ammo.

Thanks!

-r-
Susan Patrick
User Interface Designer
The Midland Company
(513) 947-6072

-----------------------------------------
CONFIDENTIALITY STATEMENT:
This e-mail transmission contains information that is intended to
be confidential. It is intended only for the addressee named
above. If you receive this e-mail in error, please do not read,
copy, or disseminate it. If you are not the intended recipient,
any disclosure, copying, distribution or use of the contents of
this information is prohibited. Please reply to the message
immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer
system. Your assistance in correcting this error is appreciated.

Susan,

I wish I had some evidentiary documentation at my fingertips to back
up what I am about to say, but at this moment I do not.

I think standards are great. I have spent enormous amounts of time
and money developing and implementing graphic and procedural
standards. But when they become rote and absolute they often become
less purposeful. Context is king, and if the standards do not make
sense, in the situation, they need to be changed, altered or challenged.

My 2 cents.

Mark

On Jul 10, 2006, at 2:42 PM, SPatrick at amig.com wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I would make sure that you aren't constrained by javascript confirm
> boxes
> before
> trying to change ok/cancel, as these choices aren't configurable
> without
> 'fancy' coding.
>
>> Somehow, before I started with my current employer, a decision was
>> made
> (arbitrarily) to use "OK/Cancel" buttons for everything they
> applied to,
> regardless of whether or not something else, like "Apply" or
> "Save", would
> offer more meaning.
>
> This morning I was asked to present my case for why to avoid using
> the same
> button labels in every case, and instead use something more
> meaningful when
> it makes sense to do so. So, I have some ideas about what to say,
> but I
> wanted to ping the list and see if anyone here has any hard
> research on the
> subject, or has any interesting insights I might be able to share.
> Any ammo
> is good ammo.
>
> Thanks!
>
>
> -r-
> Susan Patrick
> User Interface Designer
> The Midland Company
> (513) 947-6072
>
>
>
> -----------------------------------------
> CONFIDENTIALITY STATEMENT:
> This e-mail transmission contains information that is intended to
> be confidential. It is intended only for the addressee named
> above. If you receive this e-mail in error, please do not read,
> copy, or disseminate it. If you are not the intended recipient,
> any disclosure, copying, distribution or use of the contents of
> this information is prohibited. Please reply to the message
> immediately by informing the sender that the message was
> misdirected. After replying, please erase it from your computer
> system. Your assistance in correcting this error is appreciated.
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

"Any ammo is good ammo."

How about some heavy bullet-points molded at Microsoft?

Jack Moffett wrote: "One issue I've had with Okay/Cancel, and even more so
with Yes/No, is that you have to read the dialog to be sure of what you are
committing to."

True, and this truth is reflected in the recommendation for dialog boxes
from Vista UI Design Guidelines ( http://tinyurl.com/g9m3m *,* the
guidelines, incidentally, are very reasonable):

- "Use positive commit buttons that are specific responses to the main
instruction instead of generic labels (such as "OK"). Users should be able
to quickly grasp the options by reading the button text alone. Always start
commit button labels with a verb."

Do not show the guidelines themselves to your employer, Robert, since within
the same section one of the illustrations (* *http://tinyurl.com/ldudc )
appears to contradict the recommendation. Oh, well...

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On 7/10/06, Robert Hoekman, Jr. <rhoekmanjr at gmail.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Somehow, before I started with my current employer, a decision was made
> (arbitrarily) to use "OK/Cancel" buttons for everything they applied to,
> regardless of whether or not something else, like "Apply" or "Save", would
> offer more meaning.
>
> This morning I was asked to present my case for why to avoid using the
> same
> button labels in every case, and instead use something more meaningful
> when
> it makes sense to do so. So, I have some ideas about what to say, but I
> wanted to ping the list and see if anyone here has any hard research on
> the
> subject, or has any interesting insights I might be able to share. Any
> ammo
> is good ammo.
>
> Thanks!
>
> -r-
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

Robert Hoekman, Jr. wrote:

> I'm with you on this one. I err on the side of standards,
> but rely on what Mark Hurst calls "intelligent inconsistency"
> so the standards don't take over even when it doesn't
> make sense.

I prefer Emerson's phrasing.
"A foolish consistency is the hobgoblin of little minds."

. . .

One of my favorite examples of the problem with generic labels is at
my local Albertson's. The credit card reader there asks for
confirmation of the total amount. It asks in the form of a "yes/no"
question, but there aren't any yes or no buttons. There's a green
button that's labeled "apply," and some exasperated cashier has
finally written "Yes" on it with a sharpie. I smile every time I
see that.

Yes or no questions should have yes or no answers. Match the buttons
to the dialog. And if you can't control the button labels, you
should write for the constraint of whatever the buttons say.

Like everything, you can go too far with this principle. BBEdit had a
global find and replace, and after you got everything set up, the
confirmation button just said "Do it". They've changed that now.

I have never seen a use of "Okay/Cancel" that I consider generally
coherent. Cancel what? the transaction? the submission of the data?
The error (and what does *that* mean)? Unless the test defines "Press
Cancel to void all entries and return to the beginning" or similar,
it doesn't have meaning except in the tech world.

There are way too many times when either "cancel" or "okay" means
"I've read this message. Let's move on now." And there are almost no
cases in which that could not be the meaning of the button.

"Okay" suffers from similar inspecifity. What is "Okay"? the data as
entered (in which case, "cancel" is not the opposite...Perhaps "Void"
would be)? To proceed from the point where the message appeared with
everything as is?

Step outside of the technical construct when creating such messages
and ask yourselves questions like "Cancel what?" "Okay what?" What
does this apply to? what is the result of this selection and is this
the most direct way of expressing it? We all still suffer from the
"Abort/Kill/Delete" problem to some extent.

If it means massive reprogramming to make the buttons read
differently...tough. How many errors are acceptable because you chose
to be lazy?

kt

> - "Use positive commit buttons that are specific responses to the main
> instruction instead of generic labels (such as "OK"). Users should be able
> to quickly grasp the options by reading the button text alone. Always start
> commit button labels with a verb."

No Research on the subject, but I still find the Mac HIG (Human Interface
Guidelines) a good resource:

"Button Names

Whenever possible, name a button with a verb that describes the action that it
performs. Button names should be limited to one word whenever possible. You
should never use more than three words for a button name. Use the caps/lowercase
style of capitalization for button names. In general, this means that you
capitalize every word except articles (a, an, the), coordinating conjunctions
(for example, and, or), and prepositions of three or fewer letters. You also
capitalize the first and last words of the name; since button names should
seldom be more than two words, almost all words in button names should be
capitalized. The specific rules for this type of capitalization appear in detail
in the Apple Publications Style Guide.

...

Buttons usually cause instant actions, described by the name of the button. ...

A user typically reads the text in a dialog box until it becomes familiar and
then relies on visual cues, such as button names or positions, to respond. Names
such as Save, Quit, and Erase Disk allow users to identify and click the correct
button quickly. These words are often more clear and precise than names such as
OK, Yes, and No. If the action can't be condensed into a word or two, OK and
Cancel or Yes and No may serve the purpose. If you use these generic words, be
sure to phrase the wording in the dialog box so that the action the button
initiates is clear. Figure 7-3 shows a dialog box with appropriate OK and Cancel
buttons."

http://developer.apple.com/documentation/mac/HIGuidelines/HIGuidelines-146.html#HEADING146-15
(available in pdf too, page 207)

Gil.

Robert Hoekman, Jr. escreveu (10.07.06 14:29):
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Somehow, before I started with my current employer, a decision was made
> (arbitrarily) to use "OK/Cancel" buttons for everything they applied to,
> regardless of whether or not something else, like "Apply" or "Save", would
> offer more meaning.
>
> This morning I was asked to present my case for why to avoid using the same
> button labels in every case, and instead use something more meaningful when
> it makes sense to do so. So, I have some ideas about what to say, but I
> wanted to ping the list and see if anyone here has any hard research on the
> subject, or has any interesting insights I might be able to share. Any ammo
> is good ammo.
>
> Thanks!

When I was 10 years old, I had a friend named Mary. She had 5 sisters
named Mary. They all had different middle names, but you can imagine
the confusion wrought by consistency.

I am now living around many non-English speakers and am constantly
frustrated by the way they press "Okay" for every single dialog box
that comes up. I cannot tell you how much has been lost due to
"consistency." Alan Cooper always says something like "Consistency is
not a virtue."

It's so much better to have buttons that are meaningful than
consistent. Take it from my friend Mary.

Tori

there are dhtml:

http://support.vx.com/test/pravintestarea/customalert.htm
http://slayeroffice.com/code/custom_alert/

On 7/11/06, Sebi Tauciuc <stauciuc a gmail.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> By the way, does anybody know where to find this 'fancy coding' to configure
> javascript confirm boxes?

--
Baldo - baldus a gmail.com
www.sanbaldo.com

So what were your results to this religious argument??? How did the meeting go?

My answer is at
http://www.usabilityinstitute.com/beforeandafter/ButtonWording.htm

The interface to Poser (unrelated sample at
http://www.e-frontier.com/imagecatalogue/customimageview/3678 )
answered Oleh's "discard" problem similarly, with buttons entitled Save/Don't Save/Cancel. Despite a breathtaking elegance to its interface, it solved this age-old problem with inelegant, explicit, direct, verbose words. It might have been what inspired my entry to UI work.

-Jack

>From: "jackbellis.com" <jackbellis at hotmail.com>

>C) there is some imagined expectation that a powerful machine could be used
>without reading words? (This third item is not meant to be facetious.) Or
>maybe it's not a deliberately imagined thing... maybe it's just an
>undeniable practice and the consequences are what they are? Sort of makes me
>think of Homer Simpson at that nuclear reactor control panel.

We did a usability test of our in-process product a couple weeks ago and saw examples of this. In one case, a user had done a search in her library for a particular item, which returned no results (correctly), and a message was put up in the library view saying that no results were found. All well and good.

She then tried to add more content to her library, but when she checked the library, she found that the content was not there. (We had retained the search key in use, so until she added that item of content, she was SOL.) Repeatedly, she added content, checked the view, saw nothing, figured something was wrong, added more content, and so on.

At no time did she stop to read (or perhaps notice) the message which would have cued her in to what was going on. While you can argue that we shold have cleared the search key or made the message bigger or used color and animation to attract her attention, some of the blame still falls to the user: there was message text in the middle of the big blank library view and she never stopped to read it, nor did she ever stop to figure out why her library add efforts were failing. She apparently figured (a) anything going wrong was her fault, (b) it was up to her to figure out what the problem was and how to fix it, that she could not depend on anything but her own wits, and (c) doing the same thing over and over again would eventually make it "stick". (And possibly (d) she was told it was beta software with some quirks and bugs, so manye this was one of them.)

I see it with friends who are barely computer literate trying to use the likes of Yahoo! Groups and Yahoo! Mail, too. Even though there is a big red string in front of them, they don't read it, they don't look for any feedback at all.

-- Jim Drew
Seattle, WA

But Robert, ambiguous dialog boxes are part of window's charm! ;-)

On Jul 12, 2006, at 11:17 AM, Robert Hoekman, Jr. wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I haven't had a meeting about it - but I did send my case up the
> chain.
>
> In your example (
> http://www.usabilityinstitute.com/beforeandafter/ButtonWording.htm), I
> probably would have avoided the words "these jobs" and "now".
>
> - Start printing
> - Pause printing
> - Do not print
>
> And I'm not sure what "pause" means in this case. How will I get
> back to it
> later on? Will it start printing later if I leave it alone?
>
> Just a thought ...
>
> -r-
>
>
>
> On 7/12/06, jackbellis.com <jackbellis at hotmail.com> wrote:
>>
>> [Please voluntarily trim replies to include only relevant quoted
>> material.]
>>
>> So what were your results to this religious argument??? How did the
>> meeting go?
>>
>> My answer is at
>> http://www.usabilityinstitute.com/beforeandafter/ButtonWording.htm
>>
>> The interface to Poser (unrelated sample at
>> http://www.e-frontier.com/imagecatalogue/customimageview/3678 )
>> answered Oleh's "discard" problem similarly, with buttons entitled
>> Save/Don't Save/Cancel. Despite a breathtaking elegance to its
>> interface, it
>> solved this age-old problem with inelegant, explicit, direct,
>> verbose words.
>> It might have been what inspired my entry to UI work.
>>
>> -Jack
>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> List Guidelines ............ http://listguide.ixda.org/
>> List Help .................. http://listhelp.ixda.org/
>> (Un)Subscription Options ... http://subscription-options.ixda.org/
>> Announcements List ......... http://subscribe-announce.ixda.org/
>> Questions .................. lists at ixda.org
>> Home ....................... http://ixda.org/
>> Resource Library ........... http://resources.ixda.org
>>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

Jim,
Any chance you could post a screen capture or low-fidelity likeness? I'd
like to discuss this more but don't want to make entirely mistaken
presumptions. (I prefer to stop at "very mistaken.")
Thanks, Jack
----- Original Message -----
From: "Jim Drew" <cfmdesigns at earthlink.net>

> We did a usability test of our in-process product a couple weeks ago and
saw examples of this. In one case, a user had done a search in her library
for a particular item, which returned no results (correctly), and a message
was put up in the library view saying that no results were found. All well
and good.
>
> She then tried to add more content to her library, but when she checked
the library, she found that the content was not there. (We had retained the
search key in use, so until she added that item of content, she was SOL.)
Repeatedly, she added content, checked the view, saw nothing, figured
something was wrong, added more content, and so on.
>
>

Jim,
Thanks for taking the time to do this. At the minimum, your posted image
clarifies that there are no hidden issues in the search itself so it wasn't
wasted time.

When abstracted one level to the matter of "whose responsibility is it, "
this is a crucial Ix issue, to me at least. I also suspect that my position
on this matter will be an answer to an urelated post, "IxD Advice for
Developers," from Dan, who wants to know... "3. What are the biggest pet
peeves of IxD's regarding developers that I can try to avoid?" If one user
does something "stupid," perhaps it's the user's problem. If multiple users
do the same "stupid" thing, and your competitors are able to solve their
problem... then don't spend too much time saying it's the user's fault or
you'll be out of business. Thus one of my biggest pet peeves: until all
remedies have been exhaused, don't blame problems on users, despite how
frustrating the behavior appears.

Example: I've been lobbying for embedded help for years. I edited some into
my own team's system. When I had a problem, I myself didn't read the
embedded explanation right on the screen... the explanation
that I myself wrote!!! Moral: mental models are a hundred times stronger
than the flimsy paper on which kludges and workarounds are explained... it's
like Kevlar against cotton thread. Your user had an expectation. You either
need to change the expectation or fortify the tools that combat it. Yes, you
might have to use the intrusive techniques you mentioned, but I still don't
have enough information to be sure.

In your case, a classic one at least partially of subtle, retained,
constraining criteria, I believe that many users fall into this trap. I know
the answer is more than one, because you've documented one, and I have had
the same problem myself. Have you ever used a system that had poor labeling
on a folder filter? (I think it was Microsoft's source control system that
labeled its persistent filter as if it were an momentary search.) Sooner or
later you wonder where all your files went.

But more importantly, I wonder if there might be a contributing factor
regarding the library. I can't be sure what's happening in the following:

>She then tried to add more content to her library, but when she
checked
> >the library, she found that the content was not there.

I'm picturing that the user clicks on a control to Add Content to Library,
and the search is the vehicle for seeking and specifiying the content to
add. Or there's a button, Add Content to Library, after doing the search.
Yes, the user might be oblivious to the "There were no results..." message,
but I have to wonder if the relationship between the "add" function and the
"what I'm adding" is not strong enough. Is it possible that the order
of operation is exactly opposite in her mind? That is, she thinks a button
starts a process, whereas in your actual system it uses prior results and
ends a process?

Is the problem possibly that your query constraints are not explicitly
reflected in the
search results listing (a long-standing Neilsen recommendation, I think:
"Results for only items where WIDGETS less than
3"). You've alluded to these types of solutions but I'm not convinced
they're dismissable. Would the addition of a modal dialog, upon adding
empty results, represent in your mind R&D's subservience to the pitiful
masses?

At a more abstract level, would code that detects and responds to the same
action n times (three?) in a row be too much to ask one of these days? I
call such a level, whether detecting too frequent or too rare usage, a
"coach" model.

Thanks for hearing me out. It's my job description to resist presuming that
the problem is a user who won't read. (Now I suppose you're going to pull
some big "Emily Littella*" on me and say, she forgot to turn on her
computer.)

- Jack

* '70's allusion to a character who, after a monstrous rant due to poor
hearing, always was reduced to saying "never mind."

----- Original Message -----
From: "Jim Drew / CFM Designs" <cfmdesigns at earthlink.net>
To: <discuss at interactiondesigners.com>
Sent: Friday, July 14, 2006 1:33 AM
Subject: Re: [IxDA Discuss] Meaningful labels

> Not sure it's really of any use, having trimmed or cut every
> identifying bit of text and graphics from the image, but here you go.
>
> This pane would be about 2/3 of the app window-- the right 3/4 and
> the bottom 3/4. As you can see, pretty empty of any content when the
> "no results" message shows. While there are any number of ways

"jackbellis.com" <jackbellis at hotmail.com> writes:

>When abstracted one level to the matter of "whose responsibility is it, "
>this is a crucial Ix issue, to me at least.

In the end, it's like what I tell people when I teach couples
dancing: if the follow messes up, it's the leader's fault, because
the follow only did what the leader told them to.

Ultimately, the "responsibility" for this failure -- for fixing it --
falls on the software makers. It's the user's "fault" that she
didn't read or process the state properly, but it's our
responsibility to recognize that and make sure it's easier for her to
process it or that she doesn't end up in that state to begin with.

>But more importantly, I wonder if there might be a contributing factor
>regarding the library. I can't be sure what's happening in the following:
>
> > >She then tried to add more content to her library,
>but when she checked
> > >the library, she found that the content was not there.
>
>I'm picturing that the user clicks on a control to Add Content to Library,
>and the search is the vehicle for seeking and specifiying the content to
>add.

Sort of. There are (similar, yet with differences) search fields in
both the user's library and in the content repository, with "Add"
buttons in the repository.

>Yes, the user might be oblivious to the "There were no results..." message,
>but I have to wonder if the relationship between the "add" function and the
>"what I'm adding" is not strong enough. Is it possible that the order
>of operation is exactly opposite in her mind? That is, she thinks a button
>starts a process, whereas in your actual system it uses prior results and
>ends a process?

I'm not sure I follow, but I don't think that's the case. Here, it
was that the previous library search was retained until manually
cleared, and the user forgot that she had criteria in use.

>Is the problem possibly that your query constraints are not explicitly
>reflected in the search results listing (a long-standing Neilsen
>recommendation, I think:
>"Results for only items where WIDGETS less than 3").

Hmm, that's an interesting idea. Right now, the user has to read the
message and then find the search box to find out why there are no
results.

>At a more abstract level, would code that detects and responds to the same
>action n times (three?) in a row be too much to ask one of these days? I
>call such a level, whether detecting too frequent or too rare usage, a
>"coach" model.

That's something I've advocated for in a few situations. Rather than
requiring the user to click a DNSA box to stop an educative alert
from showing, do that for them after a few rounds of seeing it.
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA cfmdesigns at earthlink.net
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 6/27)
(Subject: Riding the Vertical Broomstick)