Jared Spool: Hello everyone. Welcome to another episode of the SpoolCast. I am here today with Luke Wroblewski.
We are in a lovely salon in a hotel room in Minneapolis, getting ready for the Web App Masters Tour, but last week Luke did a fabulous UIE Virtual Seminar for us called Answered: Your Top Questions on Web Form Design, where he answered several of the questions that have come into his inbox over the years since he wrote his book on web form design. He did a fabulous job, and today is going to answer some of the questions that came up in that seminar. So this is sort of meta thing where he answers questions that came up from answering questions.
Anyway, Luke, how are you?
Luke Wroblewski: I'm doing well, very happy to be in the lovely city of Minneapolis.
Jared: Yes, we've had a wonderful time so far. Why don't you tell everyone what the questions that you answered the first round were?
Luke: So, as you mentioned, basically these were the questions I've heard most often from people when they kind of find out I have written up some research, and some insights into how to do web forms. Once that message kind of got out there, I started to get a lot of email in my inbox. What I did for the seminar is I literally went through my inbox, saw the questions that came up the most, and provided the best answers.
The research that I have access to, the insights I have access to provides for those most common questions. So I think we covered about six questions in-depth. The first one was, "How long should my form be?"
The answer there was 3.5 pages.
Luke: [laughter] I'm kidding, of course.
Jared: Yeah, it was 3.7. [laughter] It's precise, but not accurate.[laughter]
Luke: Just how I like my answers.
Luke: Then the second question we tackled was, "How do I deal with previous index actions on web forms, especially if I want to make sure that there is primary action, something that gets people through things successfully; and a secondary action, how do I deal with that if I'm dealing with this wizard, multi-page web form?"
We also talked about whether or not it's OK to use buttons and links inside of web forms. There were some concerns that links might not actually represent actions in forms. We discussed that.
We talked about managing international addresses in forms, and how do we deal with the different ways that we can actually capture international address information. We talked about the use of two-column layouts, whether or not there were challenges with that.
Last, but not least, we also talked about flexible inputs, and how do we deal with situations where we want people to answer questions in one or more ways that are actually accurate without forcing them with specific help tags, or specific input field affordances: how are ways that we can actually use rich interactions to allow people to ask certain questions in the way they feel is right versus the way a database has told them it must be.
Jared: Well, it was a super seminar, and I encourage anyone who missed it to go catch it, but there were a bunch of questions that came up during the session, some of which we didn't have a chance to answer, so I thought we'd take this time to answer some of them. So I'll just start right in. Now, there was a small contingent from Comcast that was listening in to our session, and they wanted to know if you could talk about field repetition, such as retyping passwords, and email addresses that's typically done, I guess, to somehow ensure that people type the right thing.
What have you found about that improving performance or not?
Luke: The data I've seen, especially around email addresses, that one to two percent of email addresses in web forms are misspelled, or entered incorrectly. I don't know if you've seen different numbers...
Jared: No. No, it sounds about right. It may be a little higher.
Luke: But definitely in the single digits. Probably depends on your audience and things like that, but it's a small amount of people. Most of the errors people have on things like email is a misspelling.
Those misspellings can usually be caught if people can actually see the inputs that they enter. If it's really crucial for you to make sure that you have very accurate email addresses because you're doing verification of identity through email, and you're allowing people to access things that you have to verify an identity for, then you may have enough of a concern that that one to two percent, or potentially single -digit percent is a big enough deal, but from what I've seen, if we just make the input fields a little more clear, and large even, that you can see what you're spelling, those errors go down. They go down far enough that you actually don't need that duplication.
Jared: So a nice big font in a field that's large enough to show the whole thing.
Luke: So you can actually see the [laughter] email address you enter.
Jared: What's crazy is these tiny little fields where you have a decent size email address, and it just scrolls off, and you can't see half of it.
Luke: Or the font size in there is so small that you can't even see what you typed in, so on and so forth.
Luke: That's one way of dealing with it: just make the thing visible, so people can catch misspellings. The other thing to do is to do a repetition, not as an input, as a question, but as an output. So I actually have something on the blog, which we can post maybe along with this podcast, that outlines a couple of solutions that Russ Unger, and a few other folks tried where they had you enter your input address at the beginning of the form, and then displayed it to you later on in the form.
Jared: Right, yeah, I saw that. That was Jonathan Kroll and Russ Unger who put that together -- the great Jonathan Kroll.
Luke: They had a couple different explorations there. I'm not sure that any of those are necessarily the holy grail of that approach, but if you don't want to insert it into the form, you can also do it on the, 'Acknowledgment,' page, or on the, 'Success,' page, whatever, just make it really big and clear: "We have sent an email to this address. Change this."
Most times, those pages don't actually give you the opportunity to change anything.
Jared: So that's the ...
Luke: The email is on the way, and forget it, you're done. You're on your own, whereas if you really make that kind of big and prominent, and to call out through visual hierarchy the email you just sent this important verification step to gives people another chance to see it and manage it. In terms of password, I have some real strong biases around password because I feel like the only people who benefit from these sort of strong password requirements are IT teams.
When you get through a web form, you'll encounter this password thing that says, "Must be a minimum of six characters; must include a number and a letter; must include the name of a foreign national living in Saudi Arabia from 1916 to 1928."
Luke: All these obscene requirements, and they force you to repeat that. Honestly, when you go through and repeat it because people have gone through this process of trying to come up with this crazy concoction, they tend to not remember what they put into that field. They added all this stuff to kind of get that password secure.
I think this is especially exacerbated when they have those little progress indicators that go from weak password to medium password to strong password. They do a lot to make you feel motivated to move it all the way to the end, so you end up adding random characters. [laughter]
Jared:[laughter] I wonder if the final end state is this is a password you'll never remember.
Luke: Which ultimately leads to less security. The goals of the IT group are actually not met because what do you do when you have this password you're likely not to remember? You take a little post-it note, you write it down, and you tape it to your monitor ...
Luke: ... which is the least secure thing you can possibly do. Not having that strong of an emphasis on security of passwords as defined by technical infrastructure and IT can go a long way to not having you repeat it, but once again, letting people see what they're doing can go a long way. So most password input fields use these bubbles where it's like pseudo security.
Jared: Exactly. Right. To stop over the shoulder folks. The worst ones, well, I guess it's a browser implementation, but the number of bubbles doesn't match the number of letters. You type in one letter, and somewhere between two and four bubbles show up. Then you type another one, and another two and four random number of bubbles.
You think you've typed this really long thing when you've only typed three things, and you're like "Oh, wait a second. I must have hit some extra characters in there."
Luke: I mean I really appreciate that because most of the time I'm logging into the website, there's a stranger standing behind me...
Jared: I've been meaning to talk to you about him. [laughter]
Luke: [laughter] So I really appreciate that extra security. The truth is, 99% of the time, or 99.9% of the time, there isn't somebody peeking over your shoulder as you're logging into a website.
Jared: Who is that dude standing over there?
Luke: So these things that are there to quote-unquote, "increase security," actually just make things harder for you because you can't see what you're putting in for your password. You can't remember it.
Jared: So what about a, 'Show Password,' button?
Luke: Yeah, I'm willing to go even further: make the default password shown, and give you an option to hide it if you want. Flip the mode. Make it open, large, and visible upfront.
Jared: So you have a, 'Is there a dude standing behind you?' check box. [laughter]
Luke: Yeah, nervous about somebody seeing this? Check this here.
Jared: Yeah, look behind you.
Luke: Logging on ...
Jared: Is it all clear?
Luke: ... on a big TV screen, in your living room with the whole family there? , Then check the little button.
Jared: It's like the old spy movies: Are we alone? [laughter]
Luke: Yeah. The frustrating thing is this convention's made its way.
Jared: Were you followed? [laughter]
Luke: ... to the mobile phone.
Jared: Right, yeah.
Luke: I have it right in front of my face. I can move it to the side. I can do whatever.
There is no way anybody is seeing it. On the mobile phone, it's even worse because the affordances you have for input are these small, touch keyboards, or they're these numerical keypads, where it's actually very hard to answer accurate input, especially if it has numbers, capital letters, symbols, and lowercase. So, you really want to see whether or not you've entered things incorrectly.
Luke: Going back to the original question, I think the field of repetition is sort of a crutch for these other kinds of issues. Many times, those issues are just the fact that people can't confirm that the answers they put into a form are valid or not.
Jared: I know we're going to get someone who tells us that you have to have the bubbles because the bubbles is part of the password-input field element that changes it to encrypted text when it sends it over the wire, and that if you don't do that, you're an evil person.
Luke: I have seen many implementations lately making further and further rounds that actually just expose it temporarily on the client side, and still can send it over encrypted. So with rich interactions inside the Web browser, right, you can just tap this thing or adjust this thing. There's no reason you can't send it over encrypted when you actually send it to the server, and display it to a person.
Jared: OK. So don't send us those emails. [laughter]
Luke: Or please do, and we'll have a great conversation about it.
Jared: What's the experience that you think makes the most sense now?
For a very long time, every single Web form, when you got to the bottom, there was two check boxes. One was checked, one was unchecked, and there was a button that led you to submit. So the first one that was checked by default was, 'I want to be subscribed to your newsletter. Please send me marketing materials.'
So it was really an awkward dance. Actually, many, many times, I've seen when I've looked at analytics on forms that the, Terms of Service,' check box trips people up, and leads to an error state. People miss it.
It's usually small. It's kind of obscure. It's unclear whether or not you actually have to hit it.
Me, who has written a book on Web form design, even when I go through some of these forms, I just miss it, and I forget to check it.
Jared: Well, it's usually in a weird place, and it's not clear that you're supposed to hit it.
Luke: Yeah, so I think a lot of people have this experience, where they forget to, or they don't see that thing, and don't check it. So what happens is then the form comes back with an error. If you had any kind of sensitive information, like a password, or a credit card number, or a credit card expiration number, or a credit card security code, all that stuff is wiped out.
Jared: Right, you have to enter it again.
Luke: You have to enter it all again.
Jared: And then remember to hit the button.
Luke:[laughter] Yeah, just because you forgot to do this little check box. So, in general, I don't think it's a great approach to force people to go and click that check box. Now, for years -- and this is the progress that I was talking about that we actually made at eBay.
For years, the lawyers said, "Oh, people have to explicitly take an action, and click on it to state that they agree with the terms of service."
Jared: Yeah, I think that makes a lot of sense. My father is a lawyer, and I've sit next to him, watching him use the computer, doing something, and we log into something, and he has to deal with a, 'Terms of Service'. He just automatically clicks it without reading anything on the screen. I said, "Hey, you just agreed to a contract without doing it. You're a lawyer; you're not supposed ..."
He says, "Ah, none of this stuff is enforceable anyways." [laughter]
Luke: Nice. So even less reason to have people explicitly click that check box.
Luke: That's really, really true. The vast, vast majority of people don't read that stuff. Even if they did have some interest in seeing it, and learning a bit about it, most of it's unparsable by the average -- your father is probably the exception to the rule.
Luke: I've seen some folks in the very older demographic who are relatively new to the Web. I think having the precedent from kind of the big companies like the eBays, the Googles, and the Yahoos of the world allowing you to not have to go through this explicit check box action, where you can just turn that button into the, 'Agree and Submit,' kind of action ...
Jared: That makes sense. Our friends over at LA Terrain asked if help links in forms increase completion rates, having those little links that say, 'Why are we asking you this?' or 'More information,' 'More info'.
Luke: Yeah, the simple answer there is if the question that pops into people's heads prevents them from completing the form, and you have a good answer that wouldn't prevent them from completing the form, then, yes, that would help you increase completion rates. I think I told a story during the virtual seminar related to this, which when I was at the IE summit event recently, there was a woman there who was presenting some conversion testing that they did in their sign-up form for this online foreclosure broker or someone. They tested a few versions of their form.
Basically, they had a form that, upfront, said, "Free: Get access to all the foreclosed homes in your area, so that you can get great deals on houses."
But when you got to the second page, it asked you for their credit card number. What happened was everybody would click back just to make sure it was really free. Then they would come back to that other page, and all their information had been wiped out, so that led to a pretty big falloff.
So what they did was right where they asked you for the credit card number, they put help text that said, "This site is absolutely free. We are just asking you for your credit card information to verify your identity. Click here if you want to learn more about it."
Jared: That was text right on the screen, though, right? That wasn't a link.
Luke: If I remember correctly, it was a link that said, "Why are we asking for this?"
Jared: Oh, yeah. OK.
Luke: On hover, it gave you..
Jared: On hover, OK.
Luke: ... links to the text, right there.
Jared: OK, well, that gets me to the Bizarre Voice question. The folks at Bizarre Voice wanted to know if it's better to have a link, or have it exposed on the form, or -- they didn't ask this -- or to hover it. Have you seen a variation of that that works better than others?
Luke: My kind of philosophy is that help text, adjacent and visible to where it's relevant, is usually the best thing.
Jared: Yeah, that makes sense.
Luke: But there are situations where you end up with way too much stuff. If your form starts looking like a, 'Terms of Service,' document [laughter] ...
Then there's things which are automatically triggered as people move through the form. Picking the right one is really a balance of how much help text you need. So when Intuit does their 1040=EZ form or something ...
Jared: I was just thinking that, yeah.
Luke: ... there's a lot of help text that you need. It's also a situation where people don't know necessarily that they need to know that information, so they surface it automatically. As you go through the form, when you get to, Address,' it says, 'This needs to be a current address. It needs to be where you lived in this-and-this year, and if it changed, you have to go fill this out.'
I'm not going to click a link to get that data because I ...
Luke: ... don't know that I need it. So they surface things automatically, whereas if you have a site or an application that's used by, say, data admins. They use it pretty frequently, and there's a couple different formats that they have to input stuff in. Most of the time, they know what they're doing.
Every once in a while, they need to remind themselves of the requirements of section 53 (b). Then that's more of a user activated thing, "Oh, show me the 53 (b) thing again. Oh, OK, I got it. Let me get back to my work."
Jared: OK. That makes sense. Mark wanted to know about the best practices for what you do after the form.
Do you put an acknowledgment? Do you have little dancing gerbils that tell you you've completed your form, congratulations?
Luke: Yeah, dancing gerbils. Next.
Luke:[laughter] No, I'm kidding. Usually, the best thing to do is to make sure what you do after the form is contextually relevant. So what happens many times is you fill in this form, then you clicked, 'Submit,' and they dropped you off on this page that says, "OK. Great. You're done," and that's it.
That's really all there is; it's just a success message, but if you were in the process of creating a blog post, or you were in the process of creating a comment on a page, it's much better to leave you on that page, show you where that comment hit, and kind of give you that success: either animation or message in context rather than putting you off on this dead end page. So I think that's kind of the first thing you should look for, is, "Can I just make people's actions and output in the form visible to them where it matters?"
If you can do that, that's kind of the best-case scenario. If you can't do that because there isn't really a place that information gets made visible, or it kicks off some kind of process that isn't part of the app, then you can give them a success page that makes it really clear about what happened, and in there, just make sure there's other things for them to do. Don't leave them with a dead end, right?
"OK. Now we've started this process. It's going to take 15 minutes," or whatever.
"In the meantime, you can check on the progress here. You can share this with your family, " whatever the things are that are appropriate.
Even when you do actions like that, sometimes it's better to put them in the context of where people started from. So if you started from a page about like, 'Set Up My Account,' you set up your account, it's going to the take 15 minutes or 15 days or whatever, maybe you can take them back to that account home page, and put this message on top of that...
Jared: That makes sense, yep.
Luke: ... rather than putting them into a separate link page who's only purpose in life is to say, "Congratulations."
Jared: Right, "Congratulations, you've now sent us data that we're going to take forever to do something with."
Luke: Yeah, "Bye."
Jared: "And someday we'll get back to you."
Luke: And that's not a great experience. I mean if you can follow on, and you can kind of keep people going, or give them something else to do.
Jared: Yeah, I'm thinking we need to go look at some of our forms. [laughter]
Luke:[laughter] I get that a lot. [laughter]
Jared:[laughter] OK. Well, along these lines, the folks at Expeditors put out an interesting problem out on the table. They wanted to know about conditionally required fields when you have an input that, based on another field, may or may not be required, which is interesting.
I was trying to think of an example of this. I recently saw a form; it was a survey form, and it was from American Express, and they wanted to know if I had any other cards I used for my business other than my American Express business card. The answer was, 'Yes,' or 'No,' and then there was an, 'Other,' field. Apparently, the form was coded up such that not only if I clicked, 'No," it still required that I fill in that, 'Other,' field.
I didn't know what I was supposed to put there, so I just put, 'N/A'. [laughter]
Luke: I mean therein lies the rub, right? You just nailed it. In all the testing we've done, I've seen it's sort of super, high-level, best practice that emerges is hide irrelevant form controls from people that don't need them.
So if there's stuff that you only need to fill in because you're this-and-this type of user because you answered a question this-and-this, but you don't make everybody else look at that stuff. They don't need to see it.
Jared: So if I say, "I want you to send me a message on my cell phone," that's when you ask me for the cell phone number; you don't put it in there. Is there an instance where you might want to let them optionally indicate a cell phone number for some reason, but it's only required sometimes? I don't know.
I've never seen that. I can't think of an instance.
Luke: First of all, if it's a form, and your primary objective is to have people complete it, and their primary objective is to get what happens when they complete it, why do you have optional fields? In the vast majority of cases, they're not necessary. There are a couple of situations where they're necessary, like you may have an address line two because you're getting it sent to work, whatever.
I'm not arguing against that, but there's so many web forms out there that just insert optional fields, so, "Just in case you wanted to fill in a couple more input fields, here, we've presented them for you. So feel free to have at it."
If there's stuff that they don't really need to fill in, and isn't relevant to the task, just get it out of there.
Jared: The other day, I came across this form that said, 'Asterisk fields are required,' and then underneath it was a single, 'Terms of Service,' agreement checkbox with an asterisk next to it.
Jared: That was the whole field. [laughter]
Luke: Some of the worst forms I ever encountered, continue to encounter, are within hotels to gain access to the Internet.
Jared: Oh, absolutely.
Luke: You'd think, after how many years now of having Internet access within hotels, they would standardize on something, but no, you have these things that have single radio buttons ...
Jared: That's right, yes, with no choices.
Luke: ... with no choices. You have things that single radio button, no actual submit button until you've clicked. Then the button appears.
Jared: That's right.
Luke: I recently saw one that was three radio buttons, two radio buttons, split up on the form, but they were all together radio buttons, divided by two paragraphs of text. The one that you just mentioned sounds like another...
Jared: Yeah, there was another one where this form came up, and you had to choose which options you wanted for which you had no choices, and the radio buttons were already chosen, but then there was a button in the upper right-hand corner that said, 'Welcome Message,' as if you were like, "Hmm, before I click this, I'd like to read the hotel's welcome message." [laughter]
Luke: Another one I saw recently was, 'Pick Your Plan,' and it had three different plans listed, and they were all zero dollars.
Jared:[laughter] That's right. That's right. None of them made sense, right? You had no ideas as to which one to choose.
Luke: We should circle back to the question. Conditionally required fields, there's an approach to solving this UI problem called selection dependent inputs. I actually published an article on UX Matters and we did some research, which is written up in my book about selection dependent inputs.
Jared: Oh good. Well, we can put a link to the article.
Luke: Basically, it turns out there's a number of different ways to handle that, especially when the things that are conditionally dependent on the first answer are a number of questions, instead of just a single question. If you're dealing with a single question, it's a lot easier. You can kind of just drop it below the form -- or below that question, as long as the form doesn't jump too much.
Once you get into kind of groups, you can do it at a different page; you can do it in sort of dynamic tabs. You can do it in all kinds of different ways. All of them have some pros and cons, so you're better off just kind of saying, "OK. Here's the pros and cons of each method. Based on what we're trying to do, this actually works best for us, and that's what we'll go with."
Jared: OK. Josh over at Dipers.com wanted to know if you had any data that's around this Mad Libs approach that has been all the rage on the web. You have a little data.
Luke: Yeah, I think it was actually the little data that I had that kicked off the ...
Jared: The rage, that's right. I think it was.
Luke: Basically, I was talking about this approach with someone, and Ron over at Vast.com said, "Hey, we've actually been testing this in our AB testing, in our bucket testing, and we found that the Mad Libs forms are performing really well for us."
They raised conversions really in substantial amounts. What we mean by, "Mad Libs forms," is kind of what you'd expect from thinking through kind of the kid's game, those of you that remember. Essentially, instead of an input field, you have a blank in a sentence or a paragraph of text where you fill in ...
Jared: I think the first person to seriously play with this was Jeremy Keith over at Huffduffer.com, right?
Luke: Yeah, I don't have the whole chronology. [laughter]
Jared: I think that was the first time I saw it...
Luke: Me too.
Jared: ... anywhere was at Huffduffer. His sign- up form, it basically says, 'My name is,' and has a blank, just like the children's book, except that you don't put expletives in.
Luke: Well, ironically, I don't know if he was familiar with Mad Libs.
Jared: No, I don't know if he was. I think that's an American thing, yeah.
Luke: Hence why we're trying to explain what that actually means. But anyway, so Ron and his team at Vast.com had done some testing on this. They actually saw that their conversion -- and Vast.com's implementation of this, this was like a, 'Contact the dealer about this car,' kind of form -- and they saw in their implementation, they had like a 25 to 40 percent sustained ...
Luke: ... conversion increase with going through the Mad Libs route versus the traditional form. He, when I talked to him, feels that the Mad Libs style is absolutely a critical part to it. Other people point out that they changed other things.
The meta-point to me, actually, there is that the Mad Lib style form forces you to change other things. It's just sort of inherent in doing that kind of design.
Jared: Yeah, I would think so.
Luke: So there are some people out that like, "Oh, I ran a click test," where they literally took their form, and just put paragraph text around it, and said, "Oh, this converts worse."
Well, yeah, you didn't really [laughter] use this methodology at all. All you did was make a regular form worse by breaking the alignment of the input fields. That doesn't go very well.
But when you actually take the time to think through it, I think Alt Press recently put out a Mad Lib style form that looks very nice.
Jared: Oh really?
Luke: A couple of other folks have done it. If you go through the process of actually trying to make the form more of a dialog, like Jeremy's ...
Jared: Right, at least have a limited number of fields on each form, should have five or six fields.
Luke: You're not setting up a bank account with this.
Jared: That's right, yeah, you're not doing your taxes this way.
Luke: No. No, no, no, not at all.
Jared: "And my income in 1997 was," "and I have blank dependents."
Luke: Although a lot of tax programs actually do do that when they move you to the interview mode.
Jared: That's true, yeah.
Luke: They do have sentences and they have an input field and insert the texts.
Jared: I've flashbacks to 10th grade math.
Luke: Jeremy's form, I think he feels it's successful from a qualitative perspective because he gets lots of people telling him they really like it, and they think it's great. But it's sort of like a welcome message blended with the form. That's why it's nice.
It's your first encounter with the website. This is something that I always talk about is you found this great website, you're all interested in it, and you're ready to get going, and the first thing they give you is 10 input fields to fill in.
Jared: Oh yeah, yeah. Yeah, when were you born?
Luke: Right. What's your household income? Enter this password.
Repeat this password. Tell us your email address. Repeat your email address. Agree to our terms of service.
Jared: Who was your fifth grade teacher?
Luke: Yes. Exactly, all of this stuff. So Jeremy's form in contrast to that was a welcome message plus a form.
"My name is," this. "I would like to use HuffDuffer. Here's how you can reach me," in this sort of narrative style. That's where I think it works well. It kind of forces you to rethink how to do it.
So if you just switch your form to a Mad Lib style form without going through that process, are you going to get 25 to 40 percent conversion increase? No -- a good chance you're actually going to get less conversion.
That's just my perspective, but if you actually go through the process, and it's appropriate to what you're trying to do, it's a, 'Welcome,' message, or it's kind of like in Vast.com, it's a letter to the dealer. I mean that's literally what it is. You're sending a note to the dealer saying "I'm interested in this car. Can you please tell me more? Here's how to contact me."
In that case, it could be a positive thing, and it maybe makes things a little bit less intimidating for people, so on and so forth.
Jared: So our last question came in, and it was, does the size of the field box affect whether people complete the form or not? I guess there's lots of different ways, right? So email addresses where the field box is shorter than your average email address, or a name field is probably going to affect it negatively.
Luke: I think there's two things you can look at when you think about the size of the input field. One is the affordances, so making sure that something like a zip code, and I think it has, what, six characters?
Jared: A U.S. ZIP code is five plus four, right? So it's nine, but some people put a hyphen in there so then you got 10.
Luke: So not making that thing three characters wide is probably going to help with conversion because you can't see the other stuff that's in it. So that's one way that you can is just making sure that the forms you give people matches the expectations of the input. If you're asking somebody for the phone number field, don't make it five characters long because they can't fit it in and see it.
Jared: More important, it's going to reduce errors, too, right?
Jared: Because if you can see the whole thing, you're less likely to not correct mistakes, or ...
Luke: Mm-hmm. That sort of cycles us back to the first question we talked about with the field repetition, which is, A, make sure that the input field is big enough, so you can see your input. Then, B, and this is sort of this whole Web 2.0 form, try and make everything bigger, on the one hand, it's a stylistic kind of thing that a lot of people like to poke fun at, but on the other hand, making all the input fields bigger means you can actually see what you entered, which means you can reduce error rates a little bit more, and maybe increase completion rates.
Jared: Absolutely. I've seen so many usability tests where people who weren't trained in touch typing are looking at their fingers when they're typing, so they're just pecking away looking at the keyboard. Then they look up, and if part of the field is now gone because it scrolled away, there's no way they're going to detect a mistake.
Luke: Yes, and if the font is too small, they might miss a mistake.
Luke: They can't see all the letters, and so on and so forth. So I think it does help in that regard. The other part of it with the affordances is it helps give people a sense of the kind of answer they should put in.
If you're asking people a question, and you put a big text area of 20 rows and it's 50 characters long, people are going to make the assumption that they should put a lot in. If you ask them that same question, and you make it 10 characters and one row wide, then people are going to give you a shorter answer. So setting the right kind of expectations about what kind of input you want through the field size can actually help as well.
Make sure that what people think in their head aligns with what you're asking them. So I've seen a couple forms where the input field length is arbitrary, and people interpret it as a clue, like "OK. Wait, my answer is only three letters long, but this is a 20 character. Am I doing this wrong? Am I ... "
Jared: Exactly. Yeah, right.
Luke: So they're second-guessing themselves, and they put in more stuff.
Jared: Yep. Yeah, I've seen that.
Luke: So you got to be careful not to make people over-think what they're going to do based on the way you kind of size those input fields on those forms as well.
Jared: So it's better to have the right size fields, and have them not align perfectly on both sides...
Luke: Oh, yeah, definitely.
Jared: ...than to have all your fields geometrically aligned, so your two letter state code has a 50- character field.
Luke: Exactly. There are a lot of times when people size all the input fields the exact same length for aesthetic reasons.
Jared: Right. Because it fits the grid.
Luke: Then you get stuff that doesn't fit, and you have stuff that barely takes up any room, and all of it feels weird and ...
Jared: It does.
Luke: ... it causes errors. My favorite example of the field size thing is Nintendo Wii, of all products. This fun, super -- I don't want to use the word intuitive, but easy- to- pick- up kind of gaming system relative to the other gaming systems.
Jared: Yes, it's very easy to learn in a lot of ways.
Luke: Mm-hmm. When they released these straps. because they were letting people throw the remotes, the Wii remotes ...
Jared: Yeah, into the TVs. Yeah.
Luke: ... so they had a form that you had to fill in to get the strap. This was one of the most heinous web forms I've ever seen in my life, a complete mismatch from the Wii brand. The learning curve on this form was higher than the learning curve on the Wii system.
Jared:[laughter] In other words, you can master Wii bowling before you would get through this form.
Luke: Yes, exactly. You definitely could. But one of the fields they asked you was the serial number for your Wii unit. They had two paragraphs of text explaining how to find it, but the input field was eight characters long, and the serial number was 11 characters long.
So you could never see the whole serial number you were entering. You would only see kind of the front end of it or the back end of it. It was just a nightmare.
I ended up submitting that form three times just trying to get the serial number.
Luke: You know how serial numbers are, right?
Luke: These numbers and letters.
Jared: Yeah, and they're 16 characters long.
Luke: You can't parse them, and it's all smooshed together. Bad example, bad Nintendo Wii -- like the bowling game, though.
Jared: Right. [laughter] It's a good bowling game. All forms should be as easy as the bowling game.
Luke: I think we can end with that. [laughter]
Jared:[laughter] Excellent. Well, Luke, thank you very much. For those of you at home listening to this, in your car or at the gym, or wherever it is you listen to our podcast, I want to thank you again, of course.
You can hear Luke talk about forms at great length in his virtual seminar, Answered: Your Top Questions on Web Form Design, which we recorded just a little while back. He's also speaking at our Web App Master's Tour. I'm sure we'll have him at other events.
Thank you Luke.
Luke: Thank you.
Jared: Thanks to everyone for listening and, of course, thank you for encouraging our behavior. Until next time, take care.