Buttons and Boxes and Forms
Comments: 43
Aaron Swartz made an interesting point in a comment about buttons and their appearance. He said:
[Don’t] put a “Clear Info” button where it looks like a submit button!
I’d like to use this as an opportunity to clear up some remaining ambivalence I have about the comment form layout. I’m hoping our collective brain can (yet again) do some thinking for me. Uh… for us, I mean. If you don’t mind getting hung up on user interface minutiae, click through below to open this particular can of worms. This gets long and rambly.
One problem with button appearance is that you can style buttons all you want in CSS yet some browsers won’t display the buttons as you intended, using standard system widgets instead. Chimera is one such browser (the following screenshots come from Chimera so you can see what I mean. The images have been reduced in size slightly, so forgive the fuzziness). This doesn’t have a lot to do with Aaron’s point, though, as even in the CSS I’ve styled the “Clear info” button to look similar to the “Preview” and “Submit” buttons.
Before we look at why I did this, we should step back for a moment and look at some larger issues that arise from the default Movable Type comment form layout.
Figure 1. The default MT comment form layout
Above you can see the default layout for MT comment forms. There are a couple of immediately apparent grouping problems with this layout – which, I have to say, come as something of a surprise in a system as well-designed as MT. (I’ll assume you’ve all read your Tufte and your Tognazzini and won’t spend time defining terms, which should be obvious anyway.)
First, there’s the position of the “Remember info?” checkbox. To what does it apply? You could be forgiven for thinking that checking this box somehow remembers the text you enter in the Comment box in addition to your personal details because the checkbox is located beneath the comment box.
The checkbox is not grouped with the items on which it operates.
The second problem lies with the fact the remember-personal-details mechanism is a two-part thing: there’s a checkbox to remember and a button to forget (we’ll look at why there are two different interface widgets rather than their both being checkboxes or buttons in a minute). Not only is the “Remember info?” checkbox not grouped with its applicable items, it’s not grouped with its “Forget” counterpart.
The two parts of a single mechanism are separated by a row of three other unrelated buttons.
Incidentally, this row of three buttons (“CANCEL,” “PREVIEW” and “POST”) are fraught with problems of their own. There’s no spatial separation between the destructive item (Cancel, the clicking of which erases data) and the non-destructive items (Preview and Post). There’s no visual separation between the three buttons: the labels are all written in capitals, in the same style of text, and no colouring is used to differentiate them (colour should never be used as the sole indicator of difference, while we’re on the subject).
Additionally, the three buttons are somewhat overwhelmed by the “FORGET PERSONAL INFORMATION” button, which is by itself longer than the entire row of buttons above it. Visual prominence is given to the least important item in the group (and the grouping itself is not entirely logical).
I tried to overcome these problems in my comment layout form.
Figure 2. Antipixel’s comment layout form
The first thing I want to mention here, in a polite nod to Tufte, is that the data-density of this form is better than the default. The big square of white space to the right of the name, e-mail and URL fields is now used for something. The same functionality exists in a smaller space. La-di-dah.
More importantly is that the remember mechanism is now grouped not only with the items on which it operates but with itself. Yes, there’s a light grey divider between the personal detail fields and the remember mechanism, but I don’t think this creates a separation because (a) the horizontal adjacency is a strong grouping cue and (b) the divider runs the vertical length of the operated-upon elements rather than just the height of the remember mechanism. It could be viewed as acting as a kind of bracket that shows what will be remembered (am I stretching things here?).
At the bottom of the form, the button confusion has been reduced because of the removal of the Cancel item (I consider it unnecessary) and the different typographical treatment of the Preview and Post buttons.
There’s plenty of room for improvement, though. The “Remember info?” label could better read “Remember personal details?” This would make it explicitly clear what was being remembered. The “Clear info” button could also be more explicitly labeled, on the button itself or like so:
Figure 3. A better “Clear info” approach
This brings us back to the question of why the two parts of the remember mechanism are represented by different widgets: a checkbox and a button. The answer lies in the code.
The way the MT template is coded (specifically the JavaScript) necessitates the use of two different widgets. The checkbox sets an option which does not take effect until the form is submitted. The “Clear info” button submits an immediate effect, clearing the cookie which stores the remembered values whether the form is submitted or not. While this mechanism could be better, I don’t think this is terribly confusing. The interface elements themselves (checkbox and button) provide clues (admittedly to the initiated) as to what’s going on.
And now, by turns, we’re back at Aaron’s point; that the “Clear info” button looks too much like a submit button. The first answer (too facetious for my liking) is that that’s because it is a submit button. Of course it could be styled differently in the CSS but as we’ve seen there’s no guarantee that this differentiation will be visible to the reader. The exigencies of the code, however, dictate that it be a button and not something else, so we’re stuck with it (unless you want to go rewriting the mechanism). So, what to do?
First, label the button explicitly. Yes, my labelling could be better, but I’m not convinced that “Clear info” is easily mistaken for a submit button (when the point of the next paragraph is taken into consideration). Even if it’s clicked in anticipation of a comment being posted, it’s only very mildly destructive: you’ll need to enter at least your name again, but your comment text will still be there.
Second, use grouping to separate logical elements and functionality (the remember mechanism) within larger structures (the comment submission form). Context plays a part here and needs to be managed through grouping: what does “Clear info” mean in the context of a section of a form related to remembering info? It seems if not obvious then close enough to obvious not to lose sleep over.
Third, use what people know. The vast majority of forms follow a similar pattern where the action buttons (submit, clear, reset, whatever) are the last elements in the form. So it is with mine. A submit button placed above the main text entry area in the document flow would be unusual – unusual enough, I’d hope, to give you pause and make you look at it a little more carefully than you otherwise might.
I thought that the combination of these conventions represented an improvement on the default form layout, but Aaron’s comment set me thinking. If you’ve read this far, I can only thank you and assume you’re as interested in this stuff as I am. I’d love to hear your thoughts on the matter, which you can provide using the form below. Watch out for those buttons!
•••
Posted to MetaStuff • 2002.11.15 (Fri) • 18:38
Comments
Posted by tomas 2002.11.15, 21:01
I don’t see how it in any way can be confused with a submit-button, that is, a button that submits the content of the form to a receiving end. Just the position of it, above the textarea is an obvious sign that it is not ment to submit the form.
Personally though, I don’t really care about the clear-info functionality at all. People who suspect I’ll use their personal information in some horrendous way that only cookies can make possible best not leave a comment at all.
And, lastly, if I’m not mistaking the “clear info” button fires a javascript, something that can be done in a plethora of ways, for instance with a link.
Posted by jh 2002.11.15, 21:19
Tomas, we’ve got to stop meeting like this! Seems every time you post here is to correct me on something stupid. ;-)
You’re perfectly right about the “Clear info” button — it doesn’t have to be a button at all. I was thinking of the checkbox when I wrote that (misleading) paragraph above. It could easily be a link (which isn’t a bad suggestion at all and would certainly remove any confusion).
Thanks (yet again!).
Posted by nick 2002.11.15, 21:32
i think i see where you’re coming from — enough for me to plan on being heavily influenced by your design (again) as soon as i stop being lazy. i always hated that big “forget info” button. and i think tomas’s suggestion of using something other than a button isn’t a bad idea. i think the big button makes the function look more important than it actually is, since very few people use it. just a link or whatever would make it a little less distracting and/or confusing than a big honkin’ button. yes.
Posted by victor 2002.11.15, 22:04
I agree completely with you. I have been wanting to change the comments template for a long time, once I decide how I want the comments to appear. Meanwhile, can we steal this UI?
Posted by Jeff 2002.11.15, 22:49
You know, I’ve always been a little confused by the Remember Info and Clear Info button. Question: if you check this, doesn’t it just leave a cookie on your own computer, rather than the blog owner’s system?
Also, I’d say “Remember Personal Info” and “Clear [or Erase] Personal Info.” I’d also have a link to explain what this is (often a “?” is used as a link).
Posted by jh 2002.11.16, 01:25
Nick — With your permission, I think we have to start using the phrase BHB syndrome (big honkin’ button syndrome).
Victor — By all means, steal away (and thanks for asking).
Jeff — It sets a cookie that contains the values you enter in the name, e-mail and URL fields. When you return to the site (specifically an individual archive page) the cookie is read and a script fills in the fields with their ‘remembered’ values. Nothing happens on the server at all.
I’ve implemented one and a half of your suggestions. The label should now read “Remember personal info?” and the “Clear info” button now says “Forget info.” I don’t want to make it say something long like “Forget personal info” because then we’re contracting BHB syndrome again. This is yet more bolstering for Tomas’s idea that it could be a link rather than a button.
Your idea about the ‘help’ link is good. I’m playing with putting a capsule explanation beneath the mechanism itself, but there’s not a lot of space to play with and I’m worried about chart-junk, to borrow a Tufte-ism. The worry I have about the question mark approach is that it leads the reader off to another page (unless you have a little pop-up appear, which I wouldn’t want to do).
Posted by resonance 2002.11.16, 01:33
I’ve changed the checkbox to a button with no ill consequences. I just tested it, and it works fine (whew!).
Sadly, I forgot to incorporate this change onto my main website, etherfarm, when I redesigned it but here’s a link to a group blog I run, Thalamus, which uses “remember me” and “forget me” buttons.
Any and all are welcome to lift the code (I don’t recall it being a major hack or anything…)
Posted by resonance 2002.11.16, 01:44
I forgot to mention that I’ve filled the space to the top and the right of the input fields (where you have “remember personal info”) with my disclaimer box on my main site. It used to line up much more elegantly, but I had to make some changes due to IE6 and for people who don’t have the font TrebuchetMS.
I agree with Tomas, though; those visitors who are wary enough of cookies to want to use the “clear info” button probably manage their cookie files manually. In other words, I don’t know that the clear info button is necessary (or even useful).
Posted by Kevin 2002.11.16, 02:17
Given the simplicity of the task (posting a comment), I think the “Forget Info” button is not needed. How about this: If the cookie(s) exist, prefill the form and pre-check the “Remember me” checkbox. If the “Remember me” box is unchecked when the comment is posted, reset the cookie at that time. I think the usefulness of resetting the form fields are outweighed by the potential confusion of the “Forget Info” button. You really shouldn’t need a help screen for this simple form.
Posted by Jeff 2002.11.16, 04:04
Jeremy, I understand your concerns. The reason I suggested “Forget personal Info” is that it makes it clear what info you want the system to forget-in the same way you made it clear what the Remember link means. I think we’re all in agreement that our target audience is of the novice variety (at least that’s what I would assume). In that case, then, airing on the side of clarity would be important.
Now, you could change the checkbox button to two radio buttons: OK and FORGET. That actually would be more economical in terms of space.
Posted by Mike 2002.11.16, 08:09
Why not just put a little question mark image next to the “forget info” button. When clicked it will open a window explaining what it does.
Posted by Scott 2002.11.16, 09:21
When coding my last layout I agonised for ages on this one particular point and at one stage thought of providing the ‘post’ and ‘preview’ buttons only.
Then I remembered some reader feedback on the previous design where I did leave out the ‘forget info’ options totally, and the readers wanted to know why I left this option out. I dare say this point is pure laziness on people’s part and also our propensity to love pressing buttons. What’s wrong with typing your own info out?
Are all these options provided by Moveable Type option overkill? More than likely not, you have to provide everything so the user can pick and choose what they want.
When I arrived here I had a huge sense of de ja vu, as I had just written a post on this very subject, however in a different sense. A good alternative to coding the button with CSS is using images, however is this possible using form elements? I havent seen an example anywhere yet.
Great post though Jeremey.
Posted by Chad 2002.11.16, 16:07
Scott, forms can use images for the buttons. But, MT doesn’t like them at all, to the point where it breaks the comments form all together. I’m not really sure why it does it, but I’ve read on the support forums about it and ran into the problem personally as well.
As for the original topic, I think Kevin has a good idea. Less clutter and in a sense, unchecking something to forget you seems reasonable. If someone can hack up the javascript to do that, I’d love to have the code.
Posted by vis10n 2002.11.17, 02:24
resonance, et al:
First off, let me say to everyone that moving the info controls up above the text entry area is genius… it’s funny how good design can often be accomplished by just pulling back from the creation process.
: )
Okay… now, for the problem: I think we’re missing the point a bit, here, folks.
There are a number of situations where the remember/forget info functionality comes into play, but it seems we’re only talking about one or two of them:
USER A has a couple of different handles. USER A wants the site to remember their handle (for sake of discussion, a handle is any combination of data used to describe a user), so that they don’t have to. They don’t care how the site remembers the handle… just that it does. So USER A knows to check “remember me”-type boxes on sites that offer them. USER A gets miffed that when they’re at a friend’s place, and sites they often visit don’t remember the handle.
USER B knows enough about cookies to be worried about them, but not enough to have a cookie management device/schema. USER B just makes sure that the “remember me”-type boxes are un-checked. If they’ve forgotten, they notice the next time they come around that the site “remembers” them and they tell the site to “forget” them.
USER C knows enough about cookies to be leery… and has a cookie management device/schema. USER C doesn’t care about any of the buttons except for the post and preview.
USER D is USER A’s friend. USER D, like USER A, has a bunch of handles… and is really getting tired of USER A telling the site to “remember” him, meanwhile “forgetting” USER D.
So. I think I’ve covered the bases… and now the question is how can we best accommodate the most scenarios?
The site never really remembers anything, but is just using cookies, cookies that only reside on the computer where they were set; not moving about with the user. We can’t do anything about that… and unless the user wants to use something like Orangatango’s VirtualBrowser to remotely manage cookies and the like, the user will just have to deal with it.
Now that that is out of the way, we can tackle the other problems… without having to completely abandon current paradigms, and without having to write a manual.
With that in mind, it would seem to me that what we really need is a way to set a cookie, and a way to clear pre-filled fields without disturbing the cookie. Perhaps there should also be a way of erasing a cookie, but I have to admit that erasing a cookie is probably the least important thing… and folks set on doing it, probably have a way to do it outside of MT.
My suggestions are holistic, but attempt to address a couple of issues:
The “remember me” command (or whatever replaces it) should be the only thing to fiddle with the cookie.
The “forget me” command should be done away with, or at the very least be supplemented by a hierarchically more important “clear” command, which just clears the handle entry but doesn’t touch the cookie.
There should be some way of knowing whether a cookie already exists.
If a cookie is to be overwritten, there should be some type of warning. Of course, the warning shouldn’t rely on the user understanding what a cookie is to be effective.
TITLE attributes should be used liberally to give hints.
That’s about it.
Hopefully it’s been a positive contribution to the conversation.
Posted by John Gruber 2002.11.18, 05:09
I don’t think a checkbox should ever be labeled “OK”. The label itself should describe what the checkbox applies to. Just use “Remember personal info” as the checkbox label (no question mark).
And why use all-caps for the “Post” button?
Posted by vis10n 2002.11.19, 02:20
Um. The bottom part of the e-mail entry and the entire URL entry is whited-out; can’t see it at all… though I can tab to it. (Mac OS9x IE5x)
Posted by jh 2002.11.19, 11:01
Vis10n — Should be fixed. What is it with me and dumb mistakes recently…?
I took your advice and made sure that title attributes are present. They should have been there from the get-go but this was an oversight.
Kevin’s suggestion is a good one. I’m not sure there’s a simpler way to do it (and simple is good). It requires rescripting the mechanism rather than just rearranging existing parts from what I can see (an “onUnCheck” handler would be nice but there isn’t one).
The radio button approach I’m trying now attempts to present this ‘binary switch’ functionality, but can’t do it as clearly. By the way, the radio buttons work like this: for fist time visitors or repeat visitors without the cookie, neither button should be selected. Clicking “Yes” sets the cookie and the button should be checked on subsequent visits (if already filled in fields aren’t enough of a reminder). Clicking “No” immediately clears the cookie and the fields (it has no effect if the cookie hasn’t already been set).
Taking John Gruber’s point into account (it’s worth remembering), the buttons could be better labelled. The question “Remember personal info?” should be turned into a ‘section heading’ (i.e., a statement) and the buttons could read “Remember” & “Forget” (or somesuch).
Posted by Kevin 2002.11.20, 06:30
Nice changes. The only thing I’d add is to make the “No” checked by default even on a blank form where there is no cookie, so the user knows that the personal info will not be saved if they don’t make a choice.
Also something else to consider: The immediate destructive action of clicking on “No” is not apparent by just looking at the form. A user might fill out the entire form, click No to make sure that her personal info isn’t saved, and find that the fields have been reset - something which she wouldn’t expect. Since you can’t predict the order in which the fields will be filled out, you might consider moving the function resetting the cookie to the onClick of the preview/post button, because you know that’s the last thing that the user will click when using the form. Of course you would lose the functionality of resetting the form fields, but I think that only complex forms really need a reset function.
Posted by vis10n 2002.11.20, 09:20
Yup. Fixed.
Thanks!
As for the cookie thing. I think that giving folks the option of clearing the fields without dinking with the cookie is a winner as some folks may not want to change the cookie.
In this case the “NO” response to “Remember personal info?” shouldn’t clear a cookie.
But I think we may be beating a dead horse: the way it is now is superior to the way it was… and it may not be possible to improve upon.
Posted by jh 2002.11.21, 00:06
I have to start by apologising for not managing my time well enough recently to respond to the points that are being raised here with the attention they deserve. Some good thinking material is being supplied, and I’m grateful.
I love talking about things like this, and it’s applicable way beyond the storm in a teacup that is the MT comment form (as always, it’s the storm I’m interested in, not the teacup).
Turns out I’d preempted Kevin’s suggestion about the No button being checked by default, and I tried to alter a script that someone on the MT support board supplied to this effect. The original script checks the Yes button (or box) if the cookie has been set. Here it is:
<script type=”text/javascript”> <!— document.forms[0].email.value = getCookie(“mtcmtmail”); document.forms[0].author.value = getCookie(“mtcmtauth”); document.forms[0].url.value = getCookie(“mtcmthome”); if (getCookie(“mtcmtauth”)) { document.forms[0].bakecookie[0].checked = true; } //—> </script>
Doesn’t that “if” clause cry out for an “else” (whereby the No box would be checked if the cookie wasn’t detected)? Yes, it does, but damned if I could get it to work. I fooled around with it for a while but no permutation of “else” I came up with seemed to work, and I haven;t had time to hunker down with the Rhino book and dig up the correct syntax (which I’m guessing is my weak point).
In case you haven’t noticed, I know just enough JavaScript to be a menace. If anyone can append that “else” clause to this script, I’d be very grateful.
By the way, if you want to use any of the changes I’ve made to the comment form, please help yourselves.
Posted by Anon. 2002.11.21, 05:08
if (getCookie(“mtcmtauth”)) { document.forms[0].bakecookie[0].checked = true; } else { document.forms[0].bakecookie[1].checked = true; }
Check out the book Javascript: The Definitive Guide from O’reilly. The only Javascript reference I’ve needed.
Posted by jh 2002.11.21, 10:37
Thank you for the missing piece! Seems to be working fine.
I don’t know about everyone else, but I’m thinking that the comment form is just about where I want it to be.
Kevin — I think this latest addition solves the problem you mentioned above [The immediate destructive action of clicking on “No” is not apparent by just looking at the form]. For consistency’s sake, the action of the “Yes” button should probably be moved to onClick of the button (rather than the default onSubmit of the form itself).
This would set the cookie immediately. Readers would only notice if they’ve set their browsers to warn of cookies being baked (“The site Antipixel wants to set a cookie. Do you want to allow it?” or however the message goes). As it stands, this message appears (if it’s going to appear at all) when the form is submitted — i.e., at a different moment to the action that initiated it (not good).
Posted by tamaracks 2003.01.28, 14:04
Has anyone raised the possibility that enabling the user to forget info without submitting a comment might be a good idea? The button does that, but it seems that a check or radio button solution does not so far. I could have misread, however.
Of course, one could also say that the user wouldn’t know that there was a cookie unless they’d visited the comment section and in that case, one would assume that they were going to make a comment anyway.
Posted by tamaracks 2003.01.28, 14:09
Okay, upon rereading, it seems that the radio button solution used here does clear without submitting, so my last comment only applies to the check box solution discussed.
Sounds like you found the best way under the circumstances. :)
Posted by Jason 2003.01.30, 02:23
I think this is a great discussion. One thing I noticed, though: I had no cookie set, clicked the “Yes” radio button and then the “No” radio button and got an error, line 374.
Posted by girlie 2003.02.02, 08:44
I also get an error when clicking the “No” radio button:
“Object doesn’t support this property or method.”
Posted by Bill Kearney 2003.02.04, 08:36
I dislike it. The URL field IS NOT WIDE ENOUGH.
If your browser remembers input form field names the drop-down list becomes quite long. It’d help quite a bit to have a ‘side=”50”’ or something added to it.
This would make moving the prefs box up a problem. The prefs button(s) could just as easily be placed just beneath this box. To the left of the [preview] [post] button.
Invoking Tufte and Tog seems gratituous. The old style has it’s flaws and does need improving. But grafting them up in with the form posting data seems almost as inappropriate. But if it can be done whilst allowing for wider input boxes them I see no real trouble with it.
Posted by jh 2003.02.04, 10:51
Jason — I can’t duplicate the error you saw. Not sure where that’s coming from — sorry!
girlie — Not sure what’s going on with that error, either. Hard to tell without browser info.
Bill Kearney — Good point about the width of the input fields. They could definitely be wider. I’ll try to rework this.
> Invoking Tufte and Tog seems gratituous.
Yes, it was a bit. In the original post it made slightly more sense, but this was lost as I edited out a mess of details & references. I probably left their names in thinking that people are more likely to listen to them than they are to me, which is just poor writing.
Posted by Jason 2003.02.08, 02:45
Here’s the error and some more details:
“A Runtime Error has occurred. Do you wish to Debug?
Line: 405 Error: Object doesn’t support this property or method”
Running Win98, MSIE 6.0.2600.0000
I’ll try to duplicate it at home under XP later.
Posted by Jason 2003.02.08, 15:35
WinXP: same error.
Posted by Su 2003.02.08, 21:39
I’m getting this error also. On my pages and yours, IE6/WinXP. I copied the form code directly from your pages. The error box always says it occured at character 1 of the line that generates the two radio buttons(not that the system’s guesses about these things are too often useful).
Posted by Erik 2003.02.11, 21:20
Took some time to get the script working, I do get an error in Win IE though. Oh, and Mac IE displays the radio-buttons all wrong (on my page), and I can’t find the error….grrr…
Oh, and a tip: In the text below, I’ve given example code instead of just telling people to do it themselves.
Posted by Joshua Kaufman 2003.02.15, 03:18
When there are only two choices and they are Yes and No, a single checkbox is the best way to go. Using radio buttons for a Yes/No choice is a waste of HTML.
Posted by Foreman 2004.06.11, 06:03
http://www.fatwarfare.com phentermine
Posted by AS 2004.08.02, 14:16
AS
Posted by hi 2004.08.02, 14:17
hi
Posted by Clean hard disk 2004.08.26, 08:54
The old style has it’s flaws and does need improving. But grafting them up in with the form posting data seems almost as inappropriate.
Posted by Gede 2004.10.18, 14:38
rumahmedia, multi solution house rumahmedia a multimedia design house. We were born to create from nothing into something.
Posted by Amity 2004.11.08, 16:08
I’ve implemented one and a half of your suggestions. The label should now read “Remember personal info?” and the “Clear info” button now says “Forget info.” I don’t want to make it say something long like “Forget personal info” because then we’re contracting BHB syndrome again. This is yet more bolstering for Tomas’s idea that it could be a link rather than a button.
Posted by Monistat 2004.11.16, 14:27
monistat I agree monistat
Posted by Locadora DVD 2005.04.06, 05:27
I’ve implemented one and a half of your suggestions. The label should now read “Remember personal info?” and the “Clear info” button now says “Forget info.” I don’t want to make it say something long like “Forget personal info” because then we’re contracting BHB syndrome again. This is yet more bolstering for Tomas’s idea that it could be a link rather than a button.
Posted by Semillas Marihuana 2005.09.18, 16:32
Trying to make a web every browser render well is impossible. The point is IE explorer and FireFox. If you see your page correctly in both of them is enough.
Posted by Funny Videos 2005.10.06, 08:21
hmm
Comments have been closed for this entry.
Send This Story to an Enemy
• • •
