usable web forms vs the default button
Web
Two common properties of today's usable destop envrionments are the placement and ordering of action buttons in their dialog and other utility windows. The buttons are laid out so that the default or common action is placed in the bottom right-hand corner of the window and any additional buttons, including the "Cancel" button, are laid out to the left of the default action. I am assuming a English-style left-to-right writing direction here, of course. For languages with a right-to-left writing direction the same principal applies, but in the other direction.
This is in contrast to the button ordering used by today's most common desktop environment, which places the default button on the left and any cancel buttons to the right, still in the bottom right corner of the window. The problem with this is that after scanning through the window, the user's eye comes to rest in the bottom right corner and is looking at the Cancel button, instead of the default action as it would in a usable desktop environment.
So I place of the default button in a web form also should be in the bottom right-hand corner, with any additional buttons placed to the left. This works well until you need a form with more than one submit button. As HTML does not specify any method for defining the default action for a form, most common browsers guess which one to use when you press Enter in a web form: the first submit button. When laying out your buttons properly, this will be the Cancel button, or something else, but it won't be the default button you want. Needless to say, this behaviour isn't terribly helpful if you're trying to build usable forms.
Happily, there is a workaround that degrades nicely: the CSS Level 2 direction property. This property affects the direction the browser lays out content inside an element. By default it is set to left-to-right, the direction most western (Roman? Well, English at least) languages follow. By setting the direction property to rtl we can swap the direction the element's contents is laid out. Here's an example using the default ltr direction:
And again, but with
direction: rtl; set:
Nifty, hey? Because the order of the buttons in the document hasn't changed the "Default" button is still the default button used for form submission, but now it is the right-most button, as it should be. And the diehard users of that most-common desktop evironment who complain about the ordering can have the button how they like it with a user stylesheet, if they really need to.
The HTML used for this example is:
<p class="submit-bar">
<input type="submit" value="Default">
<input type="submit" value="Cancel">
<input type="submit" value="Additional 1">
</p>The CSS is:
p.submit-bar {
direction: rtl;
}If you're wondering why the button labels are also not reversed so they look something like tluafeD, it's because we haven't also reversed the direction of the text, just the direction elements are laid out in. This can be done if you want using the bidi-override property. Also, the reason I used the CSS direction property rather than using the HTML dir attribute or bdo element is because this really is a style-only change and a bit of a kluge at that. It doesn't have anything to do with the actual writing direction of the content.
There are a few problems I can see using this method. Clearly it won't work in older browsers, but at least it does degrade nicely for them; they will display the buttons in document-order and the first submit button will still be used as the default. Also, I don't know how this will interact with HTML pages that are using a right-to-left language.
In the end it's a bit of a kluge, but when it works it works well enough and makes your web forms much more usable. Rock!
Comments
This is all very well, and the premise could be true for forms with only one button. Come to the end of the text, there it is on the right.
But I'd argue that When you've been reading English, and you come to the bottom of the text, your eye does what it does at the end of every preceding line. It does a carriage return as well as a line feed, if you'll forgive the horrible metaphor - and continues to scan to the *left-hand* side of the bottom line. It keeps reading, because there's another row of information coming.
Do you feel more natural reading this paragraph
m'I ?gniht ymrow gnol a ekil tuo dial s'ti nehw
not sure I do.
Having said all that, the rtl thing is cool :)
Posted by: Joel on February 11, 2005 08:50 PM
Assumptions are everything.
All form element positioning is a kludge.
Position your divs but keep their render order: kludge
height span hacks: kludge
css direction: kludge, but neater.
Forms with one button don't need these hacks.
I disagree with Joel re : carriage returns. Information is not all the same (it's just not that simple) and interfaces which take said approach are ... kludgy.
AH.
Posted by: Anonymous Howard on February 14, 2005 02:01 PM
One day I'll write something with a GUI too =)
Posted by: Joel on February 14, 2005 09:15 PM
What's your definition of a GUI?
Posted by: Anonymous Howard on February 15, 2005 07:42 AM
If you can click on it to make it do stuff, it's definitely a GUI. If it cares about positioning bits of itself in space, it's probably a GUI too.
I wasn't really thinking about categories of information, I guess... I was following Mike's thread about what your eyes do. But as implied, I'm probably the least qualified person imaginable to be talking about stuff like that.
Posted by: Joel on February 15, 2005 08:23 PM
Joel, dude. I think either you're missing the point or your browser rendered the buttons with the text in reverse. If the latter, then wow, I'm impressed; that's one broken browser.
If the former, then consider that when you get to the end of the form/window/whatever there generally isn't anything else to read, so you're not going to do the implicit CR and keep going. You're going to stop on the last button. If you have multiple buttons, then that last button should be something useful rather than something less so like "Reset" or "Cancel" - it should be the default action. This also makes multi-button UIs consistent with single-button UIs; the default action is always in that location.
Mr Howard (if that is your real name), you're right; we should have something like XUL box-oriented layout or Swing layout managers for web forms rather than having to use a document-oriented layout mechanism... but here we are.
Anyway, what's teh beef with multiple submit buttons? How would I let users either preview or submit a comment on this page (assuming the world wasn't populated with asshole spammers that make such a nicety impractical)?
Posted by: Mike on February 15, 2005 08:50 PM
aperkah
Posted by: linda on April 6, 2005 08:20 PM
Great Post. I was looking for an answer to just this.
Works Great.
Posted by: Smith on June 23, 2005 04:17 AM
Opera renders the text inside the buttons aligned to the right.
Posted by: Smith on June 23, 2005 04:21 AM
Oh, that is disappointing. Which Opera version/platform?
Posted by: Mike on June 23, 2005 09:42 AM
Unfortunately your initial assumption is wrong (at least in my experience). The default button is usually the left-most of the set of buttons.
Take for example:
[OK] [Cancel] - OK is the default
Are you sure? [Yes] [No] - Yes is the default
I can't think of a single scenario when the default is on the right hand edge...
Posted by: Jon on November 17, 2005 02:16 AM
Jon, for LTR languages, having the default action button on the left is usual for Windows and probably other desktop environments. It is not for Mac OS X and GNOME, however.
A lot of usability research has gone into the latter two and it was found that having the default action for a dialog located right-most is actually the better position. This is where it is always located on a Mac or if you use GNOME.
Why is that the better order?
For one reason, it is the position where the eye comes to a stop after scanning a dialog. If you order the buttons "Ok" then "Cancel", the user ends up looking at "Cancel" and they must then go looking for and hit "Ok".
For another, it provides a consistent location for the default action when there is more than one button involved. With one button, the default is right-most. With two, it has moved one place to the left. With three, do you put the default in the middle to remain consistent with the two-button case or push it further out to the left, making it even harder to find and hit?
Windows got it correct having the buttons right-aligned in their dialogs, but fumbled the button order, which is a shame.
Posted by: Mike on November 17, 2005 10:32 AM
Add a Comment