I'm surprised Fitts' law hasn't come up. While not exactly the same domain as Fitts (minimize the need for fine motor control for a potentially gross action by placing the active area at the end of a gross movement, e.g. pointing to the edge of the screen) it would seem that gaze would be easier to fix on the edge or corner of a dialog, rather than somewhere in the interior.
Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
71–80 of 83 posts
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#72How did we end up with OK/Cancel in the first place? When I run into an OK/Cancel box (usually on a web page using the generic built-in confirm()), it often feels to me like the meaning would be far more clear if the options were "yes" or "no", no matter which order they're displayed. Is there a UI 'best practice' reason OK/cancel "won" over yes/no?
I'm sure the Macintosh wasn't the first to go with OK/Cancel, but an interesting anecdote none the less about why "OK" won out over "Do It" http://folklore.org/StoryView.py?project=Macintosh&story...
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#73I'm surprised Fitts' law hasn't come up. While not exactly the same domain as Fitts (minimize the need for fine motor control for a potentially gross action by placing the active area at the end of a gross movement, e.g. pointing to the edge of the screen) it would seem that gaze would be easier to fix on the edge or corner of a dialog, rather than somewhere in the interior.
The article does rather skip over that and starts by assuming that regardless of ordering you're aligning your buttons to the right of the dialog.
You could go with OK/Cancel and left align the buttons so it's easier to find the OK button.
Windows seems to go with OK/Cancel right aligned, which would be a little odd given the point you made.
I guess the use of whitespace to visually group the buttons makes it easy enough to find the button group and from there you read them left to right.
Would definitely be a interesting study to see the relative effects of aligning things to borders and visual grouping through use of whitespace.
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#74Earlier quoted context omitted.
That statement in the article is just wrong. A knowledgeable and experienced designer should be an experienced scientist who uses user testing to confirm rationalizations.
Yep. Testing 41 shades of blue gave Google products really nice designs.
Just because you're testing doesn't mean you're testing the right things.
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#75I disagree that OK/cancel are backwards. Placing OK on the left makes it a more deliberate choice. Thus the system can be more confident the user consciously chose OK, as it takes a smidge more effort to get there. OK/Cancel dialogs are (unfortunately) very common, it's very easy for users to become numb to them and just click whatever it takes for them to go away. For similar reasons, Mac OS Classic placed the trash…
I don't understand why putting "OK" first makes it a more deliberate choice. Why does it take more effort to get there? If a numb user's objective is to make it go away as quickly as possible they will become trained to where the "OK" button is and click it without reading anything else.
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#76Earlier quoted context omitted.
In most of the world, though, it's Brake/Gas. And I personally prefer Cancel/OK because I usually want to click OK and my right thumb happens to be on the right side of the screen.
That just because if you had gas in the middle it would be uncomfortable for long drives. It's the same reason the clutch is on the side as well, not in them middle. I suppose you could swap the cluch and gas (leaving brake in the middle) - but clutch comes first, then gas, so the convention of first on the left is realized.
There was a Top Gear episode that looked at the history of the location of the pedals, and tried to find the first auto that laid them out the way we are used to today.
What was shocking is the enormous variety before then. Just about any of our familiar controls (including some others before we really got a good transmission system) could be on any of your 4 limbs.
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#77Earlier quoted context omitted.
You don't have to find it. Few people do. People read through the buttons from left to right. The thing is, when dialog buttons use standardized vocabulary (ok, cancel, yes, no) you don't have to read the other button, you just assume it says the opposite of the first button. So I'd like the OP to provide some proof of this three scan pattern. I think that happens on a Mac where the buttons are labeled with verbs. Wh…
You've missed out some steps. 1) Read first couple of words of dialog box 2) Make decision if yes: 3a) Find OK button 4a) Click OK button if no: 3b) Find Cancel button 4b) Click Cancel button vs. 1) Read primary action button 2) Make decision if yes: 3a) Click button if no: 3b) Find Cancel button 4b) Click Cancel button If all you're doing is hunting for the verb in the dialog box rather than reading all the text (pe…
Even though people know the primary action is the rightmost button, they can't help but stop on other elements because of that top-down left-right scanning that's ingrained in most people of the world. There's simply no better position that the very top left corner!
Another important distinction here is that I should not receive surprise dialog boxes as often as I currently do! Yet sooooo many apps throw unnecessary dialog boxes at you! Your step 2 "make decision" has happened before the dialog box appeared. It happened when I pressed the delete button on that file.
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#78Earlier quoted context omitted.
You've missed out some steps. 1) Read first couple of words of dialog box 2) Make decision if yes: 3a) Find OK button 4a) Click OK button if no: 3b) Find Cancel button 4b) Click Cancel button vs. 1) Read primary action button 2) Make decision if yes: 3a) Click button if no: 3b) Find Cancel button 4b) Click Cancel button If all you're doing is hunting for the verb in the dialog box rather than reading all the text (pe…
Even though people know the primary action is the rightmost button, they can't help but stop on other elements because of that top-down left-right scanning that's ingrained in most people of the world. There's simply no better position that the very top left corner! Another important distinction here is that I should not receive surprise dialog boxes as often as I currently do! Yet sooooo many apps throw unnecessary…
Whether step 2 is actually step 0 or not doesn't really matter. It has the same impact on both scenarios.
People only read strictly top down left to right (or right to left) if all other things are equal.
I don't know about you, but I've never been able to predict where the top left corner of the dialog will be to start reading. My eye is always instantly drawn to the big blue button that describes what will happen when I press it :)
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#79Users will look at all of their options before they choose which action to take.
Nope.
Re: Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
#80Ok and Cancel are the wrong button labels anyway. The Apple HIG say that buttons should be labeled with verbs that signify the action taken. For example, Cancel/No/Yes becomes "Don't Quit" "Don't Save" "Save". Much more intuitive, and it gives additional reason to put the positive button last: users should be encouraged to read all the options available before deciding—and can get the gist by reading just the buttons…
Save this document before quitting? ----------------------------------- Save this document before quitting?
Although, I've always preferred the Apple system of "Destructive"......"Neutral".."Constructive"
So that destructive operations are on the far left, isolated from non-destructive operations on the far right.
Yielding,
[Don't Save] [Cancel] [Save]
[Close] [Minimize/Shade] [Zoom]