38

I guess the answer is probably "just be consistent" but if not I could use some fodder for arguments for and against.

Here's the scenario

  1. A dialog box with a list of things to choose
  2. Something needs to be chosen in order for the next screen to do something
  3. If nothing is chosen nothing is done.
  4. There is an OK and a Cancel button on the bottom of the box

enter image description here

If you select nothing and hit OK, should you get a box saying "Please select something" or just act as if nothing happened?

Improve this question
13
  • 28
    As several have mentioned, 'OK' is not a typical label for performing an action other than dismissing a modal. Since you are updating the state of the app here, I think 'save' or 'update' would be a much more meaningful label.
    – DA01
    Mar 19, 2013 at 22:02
  • 4
    If this is the first time using the program, the user might have assumed that clicking OK without selecting would mean transfer everything listed in the box. So not doing anything might lead the user to think that the program is broken.
    – Lie Ryan
    Mar 20, 2013 at 3:29
  • 1
    @DA01 I'd actually disagree, 'OK' is normally used as a final 'Apply + Close' type button... Think of the Windows Control Panel dialogs. 'Cancel' would be the one that doesn't do anything.
    – Rudi Visser
    Mar 20, 2013 at 9:08
  • 1
    @RudiVisser that's what I had in mind when I asked this. If you don't do anything on windows control panels, OK doesn't do anything. Maybe I'm mixing metaphors.
    – Peter Turner
    Mar 20, 2013 at 13:39
  • 1
    OK = Confirm. So if there is nothing to confirm, or it is unclear what you are actually confirming, then 'OK' would not be a good word to use. This is easily remedied by adding text somewhere (title of window, text in dialog...etc.) to is describing what you are confirming.
    – Populus
    Mar 20, 2013 at 16:02

11 Answers 11

Reset to default
122

In this specific case I would disable the "OK" button, if nothing is selected, then it's more clear that you can't do "OK" until something is selected.

Improve this answer
5
  • 1
    Hey, that's a good idea, we should do that everywhere in our program. The real reason I even cared about this was because I like how Delphi handles modalresult. I don't even have to program an event handler for the OK button. (saves me 2 lines of code)
    – Peter Turner
    Mar 19, 2013 at 20:15
  • 10
    When I do this, I always also leave an indication on the form as to why "ok" is disabled. Something along the lines of a red, bolded label just above the buttons saying "Please select an item or items to <verb>"
    – BlueRaja - Danny Pflughoeft
    Mar 20, 2013 at 2:55
  • 16
    @PeterTurner Basing your UI-choices on LoC is pretty bad advise. Almost always put your users first, and they seldomly care how much LoC your project has.
    – k0pernikus
    Mar 20, 2013 at 5:10
  • Agree with @k0pernikus, specially if you are going to ask for advice on a "User Experience" forum (and this is not sarcasm of any kind).
    – Jcl
    Mar 20, 2013 at 7:35
  • 8
    I'd also change the label on the button from OK to <verb>
    – Svish
    Mar 20, 2013 at 11:10
51

I'm sure we can find a better button label than "Ok". What about telling the user what he or she's accomplishing?

Examples "Save", "Add", etc.

As per Samuel post, keeping the button de-activated until an option is selected would be a good practice too, unless adding a specific criteria is not mandatory.

Improve this answer
3
  • I dunno, OK is pretty spot on. But I guess "Select" would work. Then I'd be hard pressed not to say "nothing selected"
    – Peter Turner
    Mar 19, 2013 at 20:18
  • 7
    +1 It sounds like the user is explicitly updating information. This is not what OK buttons are for. It definitely should likely be a SAVE button.
    – DA01
    Mar 19, 2013 at 22:01
  • In that case, I agree that "Ok" is acceptable, but still not best!
    – SuperFluxx
    Mar 19, 2013 at 22:33
8

Clicking OK with out a selection will do something...Confuse your users.

There are a few things you can do:

  • As suggested, disable "OK" until a selection is made.
  • Also mentioned. Is "OK" meaningful enough? Can the action be described better?
  • Frame the dialog box better: I don't know what "Transfer In Words" is. Can it be "Select a Transfer Item" or something more directorial?
  • If it's just one selection, why have an extra click? Why not just let the selection close the dialog box?

My final position: An "OK" alone can do nothing (AKA close the box). if it's combined with a cancel, consider UX improvements to prevent it.

Improve this answer
2
  • 2
    Regarding your 4th bullet point, is it really OK to only have the selection close the dialog box? It's definitely not OK if you've got a multi select thing going on. (transfer in words has a very clear and specific meaning for our program, but you're right that's a good suggestion in general)
    – Peter Turner
    Mar 19, 2013 at 21:34
  • Definitely! Particularly if the dialog box is framed as the necessary action to perform. The cancel or "X" remains as a way to back out. Picture it like this: Step 1:You have ap rompt on screen 1 to "pick a transfer". Step 2: List of choices is offered in the pop up framed in a box that directs user to "Select a transfer". User clicks one, it goes to the next screen. User Clicks Cancel the box disappears. Efficient and understandable. One less click in this world! YAY
    – Itumac
    Mar 19, 2013 at 23:18
7

Since the Okay button takes the user to the next screen, it is incorrectly named. It should be called Next (and a well-designed wizard also has a Back button on screens other than the first).

Okay generally means "complete the action implied by this dialog and dismiss it" which is not applicable here.

The proper way to handle incomplete input is to show, but disable the Next button whenever the form is in an incomplete state. This is done by "greying out", or whatever is consistent with the UI conventions of the platform.

A well-designed screen of this type will have an event handler for every single keystroke event, and other events, so that it can update the button's state instantly.

For instance, if all that remains for completion is to fill in one mandatory field, and a character is typed into that field, the button should instantly become enabled. And if that character is erased, the button should instantly disable.

If you want to inform the user that he or she must complete the form before the Next button will activate (it's not necessarily obvious to everyone), the modern way is to provide a tooltip. If the pointer is hovered over the disabled Next button, a tooltip can pop up with the explanatory text.

Dialog boxes are annoying. Imagine if locked doors popped up dialog boxes instead of simply providing the feedback of not yielding to moderate force. "Error! You cannot get into this car because it is locked. And, guess what, right now you cannot put in the key even if you have it because you first have to dismiss this modal dialog. That'll teach you to jiggle locked door handles!"

Improve this answer
3

There's a technique known as "progressive disclosure" which states (very broadly) that users don't need to be shown what they can't yet act upon... in your case, that further actions aren't available until options are chosen.

Without knowing more, In this instance, you'd be best placed to offer your list with an instruction: "Please select x before continuing" etc - at which point you can reveal an 'ok' button --or-- make your 'ok' button clickable.

Improve this answer
2

Based on the screenshot provided I would say a very important detail to provide the user is a little direction such as telling them to make a selection, given at the top of the dialog box. Without the direction it may take the user a couple seconds to figure out what they have to do. Which means if you disable the OK button the user may still try and click the button but without any feedback.

I don't think having the button enabled is a bad thing as long as you give the user some feedback, just like what we do for form validation, the submit button is always enabled and if you try to click the button without completing every task first we display an error asking the user to complete the task.

Improve this answer
2

This looks to me like a description of wizard behavior. If so, your interface should have buttons "Next" and "Back" (where appropriate) in place of the "OK" button, and the "Cancel" button should stay. Then it will make sense to enable the "Next" button if the user has selected entries from the table and the process can advance further, or to disable it in case of no selection. The "Cancel" button serves when the user wants to stop the process associated with this wizard.

Improve this answer
2

Ok button must always do something.

It really depends on content of second dialog and purpose of selected items.

Eg.: "Download these N items" or "Download this item" or "Select some items to continue" [disabled] would clarify meaning of that action.

If user should not be bothered too long with this action I would go with one word "Choose" or "Select". Anything longer should users autopilot stop for a second so he can read it.

In case this dialog is just a quick check before next step even "Ok" should be fine.

Improve this answer
2

Doing nothing when nothing has been selected and the user has clicks OK does not seem like a good solution for the user.

In the example provided there is no indication the user has to select anything. This combined with the fact that there is no feedback on the 'incorrect' usage of the OK button could cause problems.

As an improvement I would do the following:

  • Add a title or sentence indicating what the user has to do / what is happening in this dialog: e.g. "Select items to transfer".
    • It is always good to inform users reduntantly about what they are doing: they might have accidentally clicked a link / button.
  • Use a descriptive text instead of OK, so that users will now what the effect of the action is even without reading the title or sentence: e.g. "Transfer". This ensures the user will be less likely to be surprised (dissatisfied) with the outcome.
  • Disable the Transfer button until the user has selected a minimum of one item. You cannot transfer nothing.
Improve this answer
1

No. It can't, because that's counter-intuitive. Why? Because there needs to be a reason for it to be present to begin with.

You have a Window Title, a list of sorts and a couple of buttons.

What you want is for the user to see that and select something in the list, then indicate that the selection process has been completed.

Here's what I would do:

  1. Have only the title and the list visible. No buttons.
  2. Change the title to "Choose [whatever]" (if they don't want to, they can always click the red 'X')
  3. Once something is selected, display the "OK" button. Maybe rename it to "Continue" to indicate that the user is about to move on to the next step in the process.
Improve this answer
0

OK should always select something to process.

  1. Have OK and Close buttons
  2. First item should be highlighted by default
  3. If user does not want to select anything, he clicks Close button
  4. If user clicks OK button, whatever is highlighted is picked for processing

This makes it simple and clean

Improve this answer
2
  • 1
    I would disagree with you here. If you're always having the first item highlighted by default and enabling the OK button then that means the user could very likely hit OK and have confirmed the 'default' item as their choice without actually having consciously chosen it. Yes, that might be clean and simple but I am not sure that's what the user actually wants.
    – JonW ♦
    Mar 20, 2013 at 11:59
  • If user is provided with OK button and he is clicking OK means that he is cautious of the fact that he is OK with the value that is highlighted. If not, he should/would click Close button.
    – rags
    Mar 20, 2013 at 12:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.