The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Yes/No buttons in dialogs?

In chapter 6 of "User Interface Design for Prgrammers" Joel advocates an exit confirmation dialog:

Title:  Confirm Exit
Text:    Exit Now?
Buttons: Yes  No

Huh? It is definitly better than the prose text version, but I thought state of the art in usability was to replace the default text of buttons with something more meaningful, e.g.

Title:  Confirm Exit
Buttons: Exit  Don't Exit

Well, calling it state of the art may be a gross overstatement - I think this design was standard on Mac apps for many years.

After all the gadgets that are most dominant in the dialog are the buttons, so my cognitive load is higher.
Me: Click
System: Yes/No
Me: Yes/No WHAT?
    Ah, go to the text above, read it
    Ok, really want to exit, go back to the buttons

Even more apparent is the case of unsaved documents:
"Save" "Discard" is much better than "Do you want to save: Yes/No" which unfortunately is "Ok to loose your changes: Yes/No" in some other apps.
Stephen Friedrich Send private email
Wednesday, August 31, 2005
 
 
"Exit now?" isn't a mouthful. That's the problem. If you have six sentences with a yes/no question at the end then people will start to have a problem.
Colm O'Connor Send private email
Wednesday, August 31, 2005
 
 
One of the big things that leads to "yes/no" buttons is the lack of text choice for those buttons.

In all versions of VB (and in C#), you can choose the standard buttons... but you can't assign your own text to them.

So programmers have learned to word their messages to fit the "yes/no" pattern instead of writing proper dialog boxes.

All the programmers I know don't bother designing their own message box class.  I do know many developers who have though... :)
Eric D. Burdo Send private email
Wednesday, August 31, 2005
 
 
That's because the book is "UI Design for programmers" - take a look at books about UI design for designers where these types of things are handled correctly.
IxD
Wednesday, August 31, 2005
 
 
I agree with Yes / No for buttons as long as the dialog asks the *right* and simple questions. I personally find software offering options like Ethereal does bothering.

===
Save capture file before starting a new capture?

If you start a new capture without saving, your current capture data will be discarded.

Save | Continue Without Saving | Cancel
===

People do not like reading dialogs. If the program forces them to read by changing simple yes-no, yes-no-cancel options to their own custom options, expert users will not like the program more.

My version would sound like this:

===
Previously captured data will be lost without saving.

Continue without saving?

Yes | No
===

It is also matter of platform culture, I think. Windows prefers simple yes-no questions, other platforms may have different preferences.
pb Send private email
Wednesday, August 31, 2005
 
 
I strongly (as a user) prefer meaningful answers on buttons.


here's what I try to do when possible:


Title:  Install trials
Text:  Would you like to install the trial version of MyProgram?

Button:  YES, install trial.  NO, maybe later.

This way, they don't have to read anything but the title (for context) and the buttons.

this is especially helpful with LONG dialog boxes that explain things.
Mr. Analogy {uISV} Send private email
Wednesday, August 31, 2005
 
 
Eric: "All the programmers I know don't bother designing their own message box class."

Unfortunately, many programmers I know design their own message box, which breaks features like copying the error message with CTRL-C, have i18n problems and so on. An excellent example of this is Delphi's MessageDlg().
pb Send private email
Wednesday, August 31, 2005
 
 
PB,

Your option with YES/NO buttons requires MORE reading, b/c they need to read the QUESTION *and* the buttons.

The original option lets them just read the buttons. (That's more of an experienced user sort of thing).

Ideally, the action would also be REVERSIBLE (prime tenet of usability) so users can move quickly and only slow down if things don't work right.
Mr. Analogy {uISV} Send private email
Wednesday, August 31, 2005
 
 
I disagree for two reasons.

First, I do not know what the heck the program wants me to save, so I have to read both the buttons *and* the text.

Secondly, as an expert user, I get used with the standard button sets. Making me thinking by non-standard buttons slows me down and hey, I want to use the software now*!. It is like non-standard widgets, which I have to *discover* to learn how they work. I already know how standard widgets work, do not make me learn another set.

Don't get me wrong, I believe there is place for innovation and I don't have any problems with the example you provided (if not a standard Windows dialog), but you should respect your users hard learned knowledge. A software like Ethereal is definitely for experts, who already know their platform and breaking platform boundaries (even when they are "stupid") is like pissing off the users.

* Ethereal asks this question before starting a new capture. If I don't want to mess with the rather poor filter editor dialog, I have to prepare for the monitoring and start network activity immediately before starting the capture, otherwise I get too much data. A dialog which makes me stop when I am in a hurry is bothering.
pb Send private email
Wednesday, August 31, 2005
 
 
To illustrate the non-standard button set problem, think of the VCL controls. They are not very descriptive, but we all got used with them. > is play, || is pause, square is stop, red filled circle is record. Maybe we could come up with a better set, but nobody would like them. I had a cassette deck in the past which used a different set of signs and I found it really bothering. Of course, maybe it's just me.
pb Send private email
Wednesday, August 31, 2005
 
 
PB, one of the things I've learned is that you never let a user shoot themselves in the foot by accident.  You don't indicate which in your original Yes/No question (Close without saving?) is the default button, but presumably it is "yes."

You'll end up with some really pissed off users this way.  I'd phrase the question, "Save changes as you exit?"  Yes (default) / No.

This way, if the user has their mouse set to go to the default button and they just click it, or they just hit Enter, they haven't lost their work - they have saved it, which is probably what they wanted to do.
Karl Perry Send private email
Wednesday, August 31, 2005
 
 
> but you should respect your users hard learned knowledge.

Unfortunately, there's a time when nerds whining about wanting to read entire dialogs conflicts with actual users wanting to be more productive and less stressed.

Sorry, but your love of yes/no questions conflicts with normal people's love of understandable things.

The fact that users have learned to endure por software doesn't make it good or respectable - it just means we have to deal with whiny crybabies who fear change when things are made easier to use.


The arrogance of "I'm an expert user, those beginners are just dummies" is one of the least admirable traits of the average computer programmer as well. Sure, you would marry a computer if you could, but we're freaks compared to the people who pay or salaries.


But, if it helps, the entire dialog is retarded anyway - losing data because someone misunderstands a dialog (even if it's a yes/no without a triple-negative question) is unacceptable.

These dialogs started out because computers were slow and limited. They still exist because programmers don't want to do anything better than what they've been doing all along.

Wednesday, August 31, 2005
 
 
"In chapter 6 of "User Interface Design for Prgrammers" Joel advocates an exit confirmation dialog:

Title:  Confirm Exit
Text:    Exit Now?
Buttons: Yes  No"

As I recall, he didn't "advocate" this, exactly; he just said that

"Exit now?"

was better than something like

"You have chosen to exit.  This will cause you to leave the program.  If your changes are not saved, they will be lost.  Are you absolutely positively sure you want to exit?"

I don't think he was saying that you ought to have an Exit confirmation, nor that the buttons ought to be Yes/No, but merely that _that_ would be better than a loooooong message.

Incidentally, in VB .NET, since you now have the ShowDialog method on forms, and you can assign a DialogResult property on buttons, there's really not much reason anymore not to have buttons that say things like "Save" and "Don't Save" instead of "Yes" and "No."  Making a custom dialog with custom buttons is only maybe 5% harder than using MessageBox.Show.
Kyralessa Send private email
Wednesday, August 31, 2005
 
 
Kyralessa, good point. Thanks for the clarification. However, the question of Yes/No vs. non-standard button text is still an interesting one in and of itself. I suspect this is an issue that everyone who cares about these sorts of things has a unique take on. It seems to come down to personal preference for the most part (true even if you survey the target user community exclusively and leave programmers and designers out of it, I suspect), which makes it silly to dispute. That said, I feel compelled to be silly and dispute Stephen’s premise....

My knee-jerk reaction was that it just didn’t feel right, but I had to think hard about why. This is what I could come up with:

2 of the cornerstones of the “state of the art in usability” are simplicity and consistency. Dialog boxes serve a dual  purpose: 1) convey a message, 2) provide a choice of action in response to the message (optional but extremely common).

The most crucial component of a dialog box is its message, which needs to be concise and unambiguous (simplicity requirement). When a dialog box interrupts my workflow, I know the first thing I need to do is consume its message, so visual dominance and consistency in how dialogs present messages is extremely important to my interest of dispatching them and getting on with the work I’m focused on.

Distributing a message across 2 or more controls impedes its consumption. Instead of being able to “snap” visually to where I expect the message to be, I need to scan multiple visual elements distributed across the dialog in order to interpret its entire meaning. I disagree with Stephen’s assertion that buttons are visually dominant; I tend to process most content top-down, so to me the message appears BEFORE the buttons, and is processed as such.


As Colm pointed out, there are also practical limitations to confining messages exclusively within the boundaries of buttons. Sometimes (probably often enough) even concise messaging calls for more than 5-6 words. Another interesting - albeit subtle – point is that when you bind the message to the response mechanism (buttons in this case), you risk promoting an unintentional response bias. For example, a “Don’t Save” button is larger and therefore easier to accidentally click on than a “Save” button, which probably contradicts the desired default choice – ok I guess you can standardize the button sizes and add padding to the “Save” button... I’m sure if I were smarter I could come up with a much better argument for not tying the message to the response controls.

OK, so let’s focus on the response. In the case of the Yes/No approach, we have a simple and consistent response paradigm. Once I’ve consumed the message, I assess my options instantly because they’re always (mostly) the same. In the case of Yes/No, I already know that Yes appears before No, and that typing ‘Y’ indicates an affirmative response, whereas ‘N’ indicates a negative response (remember, shortcuts are an important usability device. Violate button text consistency and kiss shortcuts goodbye).

It occurs to me that, from a psychological standpoint,  there’s value to separating out request before response in some way, because that follows how humans process requests. Ask me a question, give me a sec to process it, THEN give me the opportunity to respond. An interface that conforms to MY (human) way of thinking inherently benefits the simplicity agenda.

In summary, since the message varies, the best you can do is present it prominently and position it consistently. As far as the response is concerned, you can achieve a near-consistent experience (given that 9x% of prompts are Yes/No) by generalizing the input controls that represent an acceptable response across all dialogs.

Oh man... I feel silly.
Hans M Meyer Send private email
Wednesday, August 31, 2005
 
 
Karl:

"one of the things I've learned is that you never let a user shoot themselves in the foot by accident."

I fully agree.

"You don't indicate which in your original Yes/No question (Close without saving?) is the default button, but presumably it is "yes."

Although the dialog was not asking this question, the default answer would be definitely "No" on exit. I frequently rely on programs to ask if I want to save changes on exit and usually I hit Enter. I guess I am not alone.

"I'd phrase the question, "Save changes as you exit?"  Yes (default) / No". This version is better than mine, even more brief, yet informative.
pb
Thursday, September 01, 2005
 
 
Anonymous poster:

"Unfortunately, there's a time when nerd whining about wanting to read entire dialogs conflicts with actual users wanting to be more productive and less stressed."

You got me wrong I think. There is no problem with dialogs, when used at reasonable time and place and when your users need it. My preference is rich user interface, which briefly explains things when possible, but thinking of this and dialogs as necessary bad helps to avoid overuse. Work with users is not black and white, actually balance has to be found.

"The arrogance of "I'm an expert user, those beginners are just dummies" is one of the least admirable traits of the average computer programmer as well."

Agreed.

"But, if it helps, the entire dialog is retarded anyway - losing data because someone misunderstands a dialog (even if it's a yes/no without a triple-negative question) is unacceptable."

Also agreed, IMO this dialog indicates a design problem -- why I cannot have multiple captures opened at the same time? It would make using the software easier.

"Sure, you would marry a computer if you could [...]"

I am not fully convinced that trying to offend the other party in a discussion for having a different opinion is the most effective way to prove our point.
pb
Thursday, September 01, 2005
 
 
Compare these two dialogs (one is a real dialog from Firefox):

Confirm Close
---
You are about to close 2 open tabs. Are you sure you want to continue?

[checkbox] Warn me when I attempt to close multiple tabs

[Close tabs] [Cancel]
---

Confirm Close
---
Close tabs and exit?

[Yes] [No]
---

If you already know the gist of the warning (but not the exact wording), which dialog requires less reading?

If you think you know the exact text of the warning, but you are wrong, with which dialog are you less likely to make a mistake?

If you have no idea what's going on, which dialog more clearly explains the situation?

I think the answers to those questions show why I prefer descriptive button labels.
masharpe
Thursday, September 01, 2005
 
 
masharpe, see responses below.....


> Compare these two dialogs (one is a real dialog from Firefox):
>
> Confirm Close
> ---
> You are about to close 2 open tabs. Are you sure you want to continue?
>
> [checkbox] Warn me when I attempt to close multiple tabs
>
> [Close tabs] [Cancel]
> ---
>
> Confirm Close
> ---
> Close tabs and exit?
>
> [Yes] [No]
> ---
>
> If you already know the gist of the warning (but not the exact wording), which dialog requires less reading?

Definitely the Yes/No one. After using Firefox for a few days, the average user will be in this position of “knowing the gist of the warning”, so they will anticipate the dialog and appreciate an efficient way to dispatch the it going forward.

> If you think you know the exact text of the warning, but you are wrong, with which dialog are you less likely to make a mistake?

I do see that the latter example is more error prone for users that ignore the dialog’s message. A concise message like “Close tabs and exit?”, on the other hand, is quicker to digest than the former and more likely to be processed correctly. OK, yes, I definitely see your point that “Close Tabs” is more explicit than “Yes” and therefore ‘safer’, but it seems like this paradigm reinforces the a habit of ignoring a dialog’s main message and therefore maximizing the incidence of being wrong about “the exact text of the warning”.

> If you have no idea what's going on, which dialog more clearly explains the situation?

If you have no idea what’s going on, the first dialog makes more sense, yes. But that’s because of the difference in warning text, NOT the use of “Close Tabs” instead of “Yes”. If I am learning the product, I will take the time to read either dialog carefully. The latter seems more intuitive to me personally since the choices (“yes” or “no”) directly answer the question being asked (“do this?”), which is not true for the former example. I’m sure other people process this differently... that would be an interesting focus group to assemble.

Aaaaanyway, for this type of user, I agree it makes sense to trade off speed/familiarity/consistency for clarify, since a new user has no expectations here and is not focusing on expediency.

So this begs the question of what type of user your interface should target. If you have to make a choice between ‘selling’ a new user on the product (spell everything out clearly) vs. retaining existing users (make it efficient), which way makes more sense economically? I’m not sure I know the answer but it’s an interesting question.

> I think the answers to those questions show why I prefer descriptive button labels.
Hans M Meyer Send private email
Thursday, September 01, 2005
 
 
Here is the solution I came up with for File..Close confirmation in the next version of GraphPad Prism (scientific graphing and stats). It keeys the familiar yes/no of other programs, yet is more clear:

---------------
You changed #filenaname# since you {opened}{last saved}  it #N# hours ago.

Do you want to save these changes?

[Yes]  [No, discard the changes]  [Cancel]
--------------
Harvey Motulsky Send private email
Saturday, September 03, 2005
 
 
Hans, "Close" becomes as easy to read as "Yes" without the ambiguity.

Anyway, here's an example of really bad text. Paraphrased a bit, I've seen a confirmation system which does something like this:

Email: 
 Please click this link to Confirm or Deny that it was you who requested this thing.

Web page (from link above):
 Please confirm:
 [Cancel]  [Do it]

Drive me up the wall--my brain sees the letter C from Confirm and goes for Cancel.

(The actual wording is very long, too, which is bad like Joel mentions; if it was just Cancel it'd be more obvious though still wrong)
mb Send private email
Saturday, September 03, 2005
 
 
The original intention of action buttons (and, to my mind the best way of using them) is to inform the computer to take an action, thus the labels on the buttons should always be verbs. The fact is that a question followed by "Yes/No" or "OK/Cancel" has two issues; one, it forces the user, expert or not, to read the question unless they want to do something unexpected and two, it loads the question for the inexperienced user. Compare:

Exit Program
------------

I'm going to exit the program now. This means that I will delete all of your data unless you stop me. Do you dare disagree?

[Yes] [No] [Help, I'm scared]


Exiting Program
---------------

You have unsaved data in this application.

In future:
(*) Ask me about unsaved data before exiting.
( ) Discard unsaved data without asking
( ) Save unsaved data without asking

[Save data] [Discard data] [Don't Exit] [Get Help]

The user can get the gist of the requirements from the buttons alone, which is where their eyes will be drawn first by the contrast, bordering etc. An intermediate user recognises the situation by the buttons, confirming their expectations, and responds accordingly. A novice user doesn't feel pressured into one answer or the other and the true expert can choose never to see this warning again. Allow your applications to grow with your users and they will love you for it.
Paul Brown Send private email
Monday, September 05, 2005
 
 
One thing I still do not agree with is "Do not make the user read". If so, do not have a message box in the first place! If you feel that a message box is required, then make sure the user reads it!

I make sure that I always include a setting to never display confirmation message boxes and store the chosen action. With that on, naturally the default is off, an experienced user gets to see only error messages and that is non-negotiable.
KayJay Send private email
Tuesday, September 06, 2005
 
 
Based on that assumption, dialogs are always evil because users never read.  (This is, of course, true.)

Still, if a user has to read something, making it as simple and painless as possible is important, and if the consequences of clicking on a button are apparant from the label on the button and nothing else, the amount of reading and thinking required is being minimized.

Tuesday, September 06, 2005
 
 
Most dialog texts are in English, and guess what a lot of people don't speak english, or don't speak it all that well.
this is another reason to keeps those messages as short and simpel as possible. They will recignize those recuring words as Save, Exit.

Messages like "You are about to exit, do you want to save your changes ?" are, in my opinion, a big no-no.
Eventhough it is short, it is to long. The user probable knows that he wanted to exit, so just ask "Save ?" Even people that don't speak english (well) will understand what it means. And people that do will probably also read it. Try it, you will mostly always read those first few words of a messagebox, no matter how long the text is. So keep you message short and to the point. Your not trying to win a writing contest.
Tuy
Thursday, September 08, 2005
 
 
I think we are overlooking our natural tendency (at least mine from using computers excessively) to assume that the affirmative is on the left, and the negative is on the right. So, it doesn't matter so much whether you put Yes/No or "Yes Save Changes"/"Discard Changes", as long as the affirmative is on the left and the negative is on the right.  This is also true of Ok/Cancel groups, OK left, Cancel right.  I can't think of a default dialog box that isn't arranged in this manner.

There is one screen in my day job project that has a "notes" button on the right where the cancel should be.  I click that damn button at least twice a day when I am actually trying to "close" the window.  I am sure that users are going to do the same.  When we don't have fundamental changes to make in the program we are going to fix it. 

So, really, people who use computers a lot are just going to assume that the left is the affirm (go/do it/yes/save/etc.) and the right is the negate (No/Stop/Cancel/Close/etc).  I don't even see the text of the button, nor do I see the text of the dialog box at this point, since I have seen the same box 1,000,000 times (since nobody writes their own boxes). 

In my own personal software I have tried to get the user's attention by putting a HUGE graphic next to the text.  It is red in some cases as well, Americans can deal with red so it gets their attention.  In other cases, I just autocomplete the correct (aka safe) action or the user, things like saving a file fall here.  Why wouldn't you want to save the file?  A hard drive is so cheap now that not saving the file seems foolish.  Further, now that we have several desktop search tools (Google is the one I use) I can go back through the hundreds or thousands of random files I have saved very quickly to find that one note I left myself about that obscure subject I was needlessly expounding on.
Joshua Volz Send private email
Friday, September 09, 2005
 
 
Joshua, great point about affirmative/negative order. Humans (which includes end users, I guess :]) cant help sensing patterns and making assumptions about future observations to match those patterns. The affirmative/negative order of buttons in dialogs is an assumption I've been operating under for years, but was never aware of until you pointed it out. I'm sure there's many more such examples, and it would seem that successful usability recognizes and reinforces the usage patterns that users tend to naturally extract and maintains loyalty to them through consistent implementation. This lends support to the idea that UI designers are commonly in a better position to define what a user needs than users themselves are, since many of the assumptions users make are completely subconscious.

Another great point you raise is the use of graphics - a fantastic device for establishing explicit patterns that are instantly recognizable. It would be nice if there were more standardization for glyphs that represent common user interaction so we could reduce/eliminate the text that's necessary to explain common prompts. Until then, applying prominent customized graphics in dialogs is still better than the overly generic and limited set of icons MS has for their dialogs (critical, info, question, etc).

Hans
Hans M Meyer Send private email
Friday, September 09, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz