This a transcript of the UIE Podcast "SpoolCast: Moving Beyond Static Forms with Luke Wroblewski" available at This podcast is brought to you by The UIE Web App Masters Tour, an inspiring, intensive two days with today's leading web app designers. Coming to San Diego, Minneapolis, Philadelphia and Seattle. See the Master, Topics and Dates at http://UIETour.com --- Jared Spool: Welcome everyone to another episode of the SpoolCast. I have with me today Luke Wroblewski. Luke, you may not know, is the chief design architect at Yahoo. He's also got a little consulting business, LukeW Ideation + Design. He has a fabulous blog called Functioning Form, and he is the author of "Web Form Design and Sightseeing: A Visual Approach to Web Visibility." He's going to be speaking at our UIE Web App Master's Tour that's starting in March in San Diego. Luke, you're a very busy guy. I'm glad you had time to come talk to us today. Luke Wroblewski: I was able to pencil you guys in. [laughter] Jared: Awesome. Awesome. Awesome. Thanks for joining us here. In putting together the materials for the Master's Tour, you talked about a website a good friend of ours, Jeremy Keith, had put together called Huffduffer. It's got a really interesting signup form that is different than anything else. I wanted to ask you about that form. Is that a direction that is good? The form is really neat in that it has these blank spaces that you fill in that aren't standard form spaces, but it's more of a narrative story, almost like a Mad Lib, if you know what one of those things are. Luke: Yeah. I was actually going to say, in order for people to visualize it, if you picture sort of like a paragraph with a couple of blank spaces in there for you to fill in, that's what the form looks like. It is a little reminiscent of Mad Libs, although you can't put arbitrary words in there. [laughs] The reason I like what Jeremy has done there is it's exemplary of two things I think really needs to happen with web forms online, and that actually are happening with web forms online, which is great. To sort of level set, my overall view of web forms is these are the things that make a lot of really important things on the web run: check-out, registration, communication, managing information, all this stuff. So that's one factor. And the other factor is they really have changed much over the years as such. They're these static, constrained input field where you type in an answer or you go hit a button, and then you get back a response that essentially grades you on well you did, right? You made errors here, you didn't make errors there. And for a really, really long - when I say really long time, I'm talking in Internet time. [laughs] 10 years or so on Internet time is a really long time. Form really didn't change much. So they're responsible for all these key things, but they're stuck in 1995 or 1996 kind of technology. Jeremy's example, and a lot of other examples that I'm actually really interested in talking with the Master's Tour audience about, are ways that people are pushing web forms forward. But they're doing so in ways that doesn't break the fundamental design considerations and constraints that forms have. What do I mean by that? Even though Jeremy's form on Huffduffer looks like a piece of narrative, Mad Libs-style prose, underneath the surface it's all real input fields. It uses what they call progressive enhancement, which is the JavaScript technique where you do this sort of real baseline HTML and then gradually layer more advanced functionality. So his form will work on a real old browser. It'll allow people to tab between the fields like they do on a regular form. It'll allow them to put their cursor into every field and type in there. It's coded in a way so that it actually has labels so screen readers can use it. It has a kind of primary action at the moment, that once you get through the whole thing you can submit. It does actual error checking, and so on and so forth. So even though it's this example of rethinking the format of a web forum, it's still keeping true to things that keep web forms work online. It's not breaking them, it's not forcing people to really shift their mindset. And I think that's a very interesting series of directions I'm seeing across the web and in many place. It's people building on what makes web forms tick, but using new rich technologies, new more interactive format, kind of maybe persuasive design, if you will, to make filling in those important web forms less painful. Jared: I think that's interesting, that there are some rules that forms have to follow, but at the same time, you still have a lot of freedom to present the form in a way that is new and potentially better for the purpose that Jeremy is trying to execute. It fits the style of the site and the theme. It keeps it simple and informal and makes it feel fun. But at the same time, it does all the things that forms need to do. Luke: Yeah, exactly. And it's kind of building on some of those expectations that people have built up over 10 years of forms working the way they work, and technology supporting forms the way it supports forms, not trying to break that. We've had technology for a long time that allows people to style web forms to look like kind of anything. Even though that could theoretically create a more interesting presentation, in many cases I've been a little bit opposed to over-styling what an input field looks like because you lose that visual affordance that people have in there heads that, "Oh, this is something I need to enter data into." Jared: Right, right, yeah. Luke: If you style it all blue and big red border, people don't know what it is. Whereas where they an input field that looks like a standard HTML input field, their first instinct is to go in there and start typing something. And actually I have many examples of this in action, but one that always sticks out in my head is when Yahoo launched a podcasting site, about four years ago, three and a half years ago. We had a directory page for the podcasts, and it would have the description about it, it would have a whole bunch of information about it, reviews, a listing of the episodes. But at the top of the page we had this input field that was open, which allowed people to tag that podcast episode with whatever terms they wanted. And because people saw that input field and it was towards the top of the page, they immediately thought "search field, " and they would run search queries in there. So people were tagging the podcasts with things they were searching for and not things related to the actual podcast. Again, it's that sort of muscle memory aspect of, "This looks like a search field because it's up at the top of the page and it looks like an input field. I know what that is. Let me just go ahead and start using it." Jared: Right. I remember a CEO of a jewelry and luxury goods site telling me that one of his board members told him that the board member's wife thought that the search on the site sucked. And he was really curious about the comment, because they hadn't implemented search quite yet. They didn't have that many products and they felt they could get by without it. He discovered that people were entering the search term into the email signup form, because again, it was up at the top of the screen and had a button to the right and looked like a search field. Even though if you looked closely, it was email signup. And when he went and looked at all the addressed that they had acquired, half of them were "Prada," "Prada shoes." [laughter] Luke: It sounds like they weren't doing any inline validation on that input field. Jared: No. No, they weren't. And apparently they weren't looking at their error messages from their email bounce-backs either. [laughter] Luke: It goes to show the power of this sort of existing behavior, right? And how people just sort of dig in and naturally go with what they expect things to do rather than taking the time to parse your interface, carefully read all your labels and help text, and then determine what to do. No, they're just going in there and getting going on behaviors they expect. The same is really true for web forms, right? Time and time again when we've put forms in the lab, I've seen a whole bunch of designs where people try to preface a web form with help texts or explanatory paragraphs of information that you need to know or things that you'll want to be aware of later, like what's required and what's not. And every single person, just about, skips over all that and goes to the first thing that looks like an input field and starts answering the questions. And from a design perspective, I always try and get our products to go with the flow. The analogy I always use is they're sort of like a train moving down the track. You can try getting that train to turn left or right because you want it to do something different or you want it to get somewhere else. Or you can try getting in front of that train, laying different track, or helping tune the engine or so on and so forth. But it's a really, really hard job to stop a train and move it in a different direction, right? It's much easier to lay track further up the road and get it to go where you want it to go by using its already existing inertia. And the forms are very much like that. People have this existing inertia. They go to that first input field. They start filling it in, and then they go down, down, down, down, down. They look for the first thing that seems like a big button that will say, "I'm finished, " and they hit it. And when you fight that flow -- when you fight that inertia -- you usually run into problems like we're talking about, right? Getting a whole bunch of [laughs] email addresses that you can't really do anything with. Jared: Yeah. It really intrigues me. It's interesting this theme is emerging because I was having a similar interview with Bill Scott, who's also speaking at the Master's Tour. And he was talking about drag and drop and how in a common drag and drop operation there are actually a minimum of like 16 discreet events that you have to code for. If you're going to implement drag and drop -- let people for instance drag a picture from one side of the application to the other on the screen -- you have to implement 16 different events with potentially up to five or six different elements of the display: the cursor, the thing you're dragging, the thing you're dragging to, the place you're dragging from, and the place you're dragging to. All of these have to visually show that this drag-and-drop operation happens. And when you break it down into its small little pieces, there's a lot of stuff going on there. But when you are using it, you don't think, "Well, wow! That just did 16 things in that 45 milliseconds." And I think web forms are very much the same way, that we use them and we don't think about the underlying subtleties and nuances that are coming through. But there's really a lot of stuff that's happening in that form. That's what design is all about. It's mastering those subtleties and nuances to, in essence, make them disappear so that the person can focus on whatever it is they're actually doing--whether it's sorting pictures from one side of the screen to the other or trying to sign up for the opportunity of a lifetime. Luke: Yeah, and [laughs] I like that use case. [laughter] Luke: Yeah. And actually the drag-and-drop example and all the different states you have to manage in there brings up a topic. I sort of jokingly said that your jewelry retailer should have been using inline validation. Inline validation is another one of these kind of new immediate-feedback techniques that's enabled through things like AJAX and dynamic web technologies that has a lot states to think through and has a lot of implications when you lay it out on a form. Basically what happens with inline validation is as you're entering an answer into an input field or just after you enter an answer, we give you feedback on whether that is going to be a valid input or not. Is that username available? Is that password secure enough? Is that actually a valid email address? To bring it back to the jewelry example. And many folks that implemented this stuff early on didn't think through all those different states. I don't know if there's 16, or I don't actually have a number on how many there are off the top of my head. But there's a number of things in there that you need to think through. Like people are usually hunt-and-peck typists, so they're looking down at their keyboard. So if a message that says "This is a valid input" shows up and then fades away, chances are by the time they look back up they haven't seen it. Jared: Right. Luke: And there's other things that happen, which I will talk about at the Master's Tour. When you have two fields that have to match, there's a number of states that those two fields can get into that you need to work through inside the form. So if I type one password in one field and another password in the other field, trying to get those to match with inline validation creates some challenges. And there's a series of things that you need to account for in the interaction design when you get into these rich interactions to your point exactly. Make it feel seamless. Make it feel like it's not really doing a whole lot. It's just helping you get through that form. Jared: Yeah, I was at a site the other day where I put in a password, and it was telling me that it wasn't strong enough. But I, just out of reflex, typed it in twice because it's the password I always use and then went back and changed it so it was stronger. But it kept telling me that the other one matched it even though I knew it didn't. But I couldn't see either of them, and it was crazy. You have these multiple field states, and keeping track of all that's actually really complicated. Luke: Yeah, exactly. One of the more common use cases is with the password stuff because you can't see what's in there, right? What we actually did on the Yahoo registration form is, if you went and changed your original password, we wipe out the second one because it can't match anymore, meaning it automatically puts you in an error state, so we just get rid of that error state for you. And that's exactly the kind of interaction design detail you need to think about and code to so that you don't get people who say, "OK. It looks like I'm done." [makes buzzing sound] "No, you made an error. We wiped out both your passwords because they need to be secure." Right? "Start totally over." That's not a very good experience. [laughs] Jared: Well, one of the things I think gets people in trouble is that they always tend to code for the happy path. And they don't think about, well, what mistakes might people make? And especially since you're coding error messages, and the whole point of the error message was to catch the mistake. They don't deal with that. On a banking site we were watching someone enter, they had phone numbers and social security numbers. And they cleverly broke the phone number and the social security number up into its chunks. And then you'd enter this right number of characters, and it would auto tab to the next chunk. But people who were used to tabbing because they'd done it on every other field would end up skipping a field. But then it got even worse, because as far as I could tell the Javascript on this particular site was keeping track of what field it thought you were in. So when you would go back and edit it and get to the last character, it would actually jump you ahead two fields because it had thought you were in other field that you weren't in because you'd gone back already. It was really confusing. [laughs] Luke: Yeah, that's almost an example of trying to be a little too smart, right? Jared: Exactly. Luke: Another example of some of these rich interactions that we're seeing pop up in web forms is this idea of input masks. So an input mask, instead of forcing somebody to fill in a specific phone number format by using input field affordances, which is what you described, right? Jared: Right. Luke: And breaking it up into these three discrete chunks, each of a specific length, or forcing people to input a specific format by writing out next to the field, "This must be a three-digit, three-digit, four-digit format." What they do is they accept flexible inputs. And when you type it in, it'll just insert the format into your input, kind of like how the iPhone - you're probably familiar with the iPhone example. You type in a phone number, it'll just automatically put it into the right format. Again, the subtlety matters here, because there's some implementations that start inserting the formatting as you're entering the phone number, which is really, really frustrating because it starts putting characters into what you're filling into the form. So it doesn't even give you a chance yet to answer the question before it's already inserting its own rules into how that question should be answered. Instead, which is what the iPhone does, it does that once somebody fills in that form. Then it'll add in and create that formatting when they're done providing the answer. Similarly, sometimes people do this with this inline validation of as people fill a form they tell them if it's wrong or right. So you'll start entering your email address, and for me that's "L." As soon as I enter the "L" it says, "This is not a valid email address." [laughs] And I know. I haven't even gotten a chance yet to answer the question and you're already giving me the red X. And so timing is also an important thing, and kind putting that information to people when and how they need it, as opposed to getting in their way when they're actually trying to do what you want them to do, which is answer these questions in a form. Jared: I think that these subtleties and nuances are really interesting, really because it allows us to get to that sort of secret layer of stuff that, for me at least, makes design really fun. I've always been intrigued, it's like figuring out how the clock moves its hand. Most people really don't think about it, but as designers we get to really get in deep and think about that hidden layer that's under there, and take it apart and dissemble it, then put it back together. And hopefully we've put it back together in such way that A) all the part still go together. Because there's an old saying that when you take something apart and put it back together, if you do that enough times eventually you'll have enough extra pieces to make a second one. [laughter] Jared: But assuming we do that and we get it right, it works. It's really hard, I think sometimes there's this almost disappointment out of people not noticing this really hard work that went into making it just so perfectly. Luke: Yeah. But there's ways to notice it on the business impact side. Another example of a really small detail is when you're asking people for a zip code, it turns out - with the numbers I've seen - about 2.5% of people who enter a zip code get wrong because the enter an "O" instead of a zero. Because those two keys are right next to each other on the keyboard and they look kind of the same. So 2.5% of all zip code inputs can be in a failed state because somebody enters an "O" instead of a zero. Jared: I wonder if that's also because of the way people talk about zip codes. My zip code is "O"-1-8-4-5. I don't actually ever say zero-1-8-4-5. Luke: So it could be that they're thinking that in their head and just gradually type it. But all you have to do in terms of the actual implementation of that feature, is, OK, if there's an "O, " it's probably a zero, and rationalize it. Or at least catch that error and get people to correct it. Again, inline validation can help there because another technique that has been spreading on the web is when you have in input field for postal code, if you type in the postal code it'll write to the form using Ajax the location where it thinks that postal code is at. So if I enter 9-5-1-2-4, it'll right there next to the input field write out "San Jose, California." And that might be a way to catch some of these errors of the zero versus the "O, " because it can turn the "O" into a zero and write out San Jose, California. If it thinks you got it wrong, it can correct it in there. Now there are some subtleties to that, because not every single zip code maps to a single city. But in many cases, you can get it relatively right. Jared: Another thing that's sort of happening right now is I'm seeing a lot of applications that let you use other forms to get data in, versus just a form on the website. One of the first ones I started using was a website called Remember the Milk. It's a little reminder service and I use it all the time, because it'll send me emails to remind me to do certain things on certain days. I was thrilled because I could, from my phone, email or text to the service something that I wanted it to remember for me, to remind me to pick something up or whatever it was. I could do that wherever I was. I didn't have to be on the website, on my machine on a website, typing it in. I didn't have to leave little notes for myself. Things like that are, I think, changing the way people use forms, don't you think? Luke: Yeah. I think it's another one these examples of reducing the pain of web forms. In this case not by utilizing necessarily rich technologies, but by utilizing where people already are and their already existing tasks. So chances are you've got your email on your phone, you've got your email on your desktop. You've got your phone with you in your pocket at all times, you can fire off a text message. When you start to leverage those existing productivity tools and contexts that people are using on a day-to-day basis -- multiple times a day -- you can essentially allow people to get things done that essentially they had to go to your site, fill in a form, hit a submit button, work through any errors, and what have you. I've actually seen a lot of products start to use some of those communication tools as starting points for important flows like registration. A couple examples of that, I'm sure you and probably everybody listening has gotten a connection email. Like, "Brian wants to connect with you on..." blank, blank, blank. Jared: Oh, yeah. Absolutely, yeah. Luke: So you get that kind of email and usually what happens is you say, OK, I want to connect with person, and you end up on a website with a registration form. It's says, OK, tell me your first name, your last name, your email address, repeat your email address, pick a password, and go. But when I get that email in my inbox, it knows my email address, right? It just sent me an email. It knows my first name and my last name. So what I've seen a lot of services do is when you click that "accept invite" link, you end up on a page that is essentially just a one-input field form. It says here's your name, here's your email address, just enter a password and go. So it really cuts down the pain of registering for this site by making a single input field rather than a full registration form. Jared: One of my favorites it's the website TripIt, where people can basically sign up for the form by just forwarding a trip itinerary. You get your conformation letter back from the airline saying when you're leaving and when you're coming back, and you just forward that email to their website, plans@tripit.com. If you don't have an account, it automatically creates one for your email address. Luke: Yeah, and your name and any other information it gets from your itinerary, right? Jared: Right. Luke: So it can get your frequent flyer from there, it can be anything that the travel provider puts in that email. It can sort of parse out and turn it into structured data for an account. Another example - and there more and more examples of this popping up on line - is Posterous, which is essentially like a mini-blog site. And the way that you get going on that is you send in an email of a picture or of a text or a link that you want to post up on your mini-blog. And it'll just create your blog for you, based on that email you sent or based on that picture you sent. So the starting experience there is, "Send us something and we'll create a blog post for you." And you can actually utilize the product from your mail client just from writing stuff up from inside of where you're already writing emails, where you're already writing notes and information and so on and so forth. Just send it over to them and you'll create blog posts. You don't even need to use their forms on the website to get that stuff going. Other products out there are using instant messaging for very similar things. And I think even Remember the Milk supports instant messaging and Twitter, other communication tools as mechanisms. I think of that as kind of the broader trend here, of utilizing existing communications channels or tools that have use right now, as a form of input for your web app, instead of forcing everybody to go to your web app to do all those things, usually through web forms. Another kind of popular means to get input is by actually creating a control into your web browser. There's a lot of sites that have a little bookmarklet or an extension for the web browser, and wherever you are on the web, when you're seeing something of interest or you go to something that wants you to take action, you can just take on that web browser to provide input into that web application, instead of going to that web application, cutting out the text from that page, or getting whatever information you actually wanted to provide as input. Jared: Now some of this leveraging standards that are already out there, like the OAuth ID standard that lets people authenticate who someone is without having to have separate passwords on every account. Luke: Yeah. I think there's been a lot of solutions that have tried to solve the sort of single sign-on problem. OpenID is definitely one of them. Microsoft Passport, I'm sure you remember that one early on. But the one that I think has been getting the most traction lately is Facebook Connect. And you literally have a whole bunch of web applications out there now that just bypass signup and give you a Facebook Connect button. And the reason they do that is, if you click that Facebook Connect button, you just fill in your password and then you have your name, your email address, your bio, your photo, and your list of friends that can be on that service. So pretty instantaneously, you're up and running. I just went through this experience on a new Q&A web application called Quora. Literally their first-time experience is you hit a button that says Facebook Connect, it shows you the picture, name, and email address you use. You say OK. And then I was taken to a page where I saw all my friends that were already on that site and what they were doing. Jared: That's interesting. Luke: Yeah, it was a great startup experience. I didn't have to go connect with people, I didn't start with any kind of blank slate. I didn't have to fill in -- the only input field I filled in was my Facebook password. It took me like half a second. Everything else just fell into place, and I was immediately up and running using that application, as if I had taken all those steps that most other web applications force you to go through. So using these kind of existing web services is kind of related to the previous theme we were talking about, of using those existing communication tools. But Facebook had 350 million people, right? People have filled in a full profile on there, they're connected to an average of 120 people on there. And Facebook is making that available for you to use. Why recreate the wheel? Take all this great inertia and lay some new tracks in front of that train instead of trying to route people onto a new train or turn it on the tracks. Build on what Facebook has created and use it to create what, I would say, is a really incredible first-time experience for people on your site. Jared: I think that there's a lot to that, and that the future is really going to be about not just asking how do we make these forms efficient from a "what's the right label" or way out. Do we use a pull-down for state, or a type-in field? But going beyond that and asking do we even need to ask for this information, or has the user already typed it in once? Can we just keep reusing it, even if they haven't typed it into our service? Luke: Yeah. The need for web forms isn't going to go away, per se. I basically wrote an entire book on how to optimize web forms using a lot of these new technologies, and getting into the detail and so on and so forth. But at the end of the day, it's still a web form. And we sort of owe it to our users to ask the question when we're designing a web form, does it have to be here? Do we need this? And the Facebook Connect example is a great thing. If you're building a social service that requires you to have people so you can see what they're up to and connect them and so on and so forth, requires you to have an identity and build a profile, I think it's a very viable conversation to have, "Should we just use Facebook Connect instead of putting people through all these forms on our site?" And a similar conversation with the communication tools. Should we just allow people to use email that they're already using to add information to our application or do we really need to create a whole bunch of forms on our site that force them to do it there? There are real conversations. There's a lot of examples in the market of making that stuff work, that can literally not just optimize web forms but get rid of them all together. Which I think is an even better end game, right? [laughs] Jared: Right. That's fascinating. This is going to be a great session at the Master's Tour. I'm very excited. The first one's going to be March 23-24 in San Diego. But we're going to four different cities. We're going to be in Seattle, Minneapolis, Philadelphia, and San Diego. You're going to be joining us for all four. I'm very excited about that. Luke: Yeah, I'm excited about touring the US with you guys. Jared: There you go. It's the bus ride from one city to the next that's going to be the best part. [laughter] Luke: Do we have a van? Jared: We do, we have a van. We actually got the original Scooby Doo van. Luke: Nice. [laughter] Jared: We had to spend a lot of time fumigating it. Luke: Yeah, that Shaggy.... [laughter] Jared: That's right. "Oh, Shaggy." Fabulous. Well, Luke, it's always a pleasure talking to you. It's going to be a fascinating session. People can find out more about your session at UIEtour.com, and find out what you're going to be speaking on there. And of course there'll be articles and this podcast, but they've already listened to that. There's absolutely no reason for them to listen to it again, I think. But they can share it with their friends. Thank you very much for joining us today. Luke: Thank you, Jared. Always a pleasure talking with you guys. Jared: And I want our audience for joining us. As always, than you for encouraging our behavior. Take care, we'll talk to you next time. --- Don't forget Stephen will join us at the UIE Web App Masters Tour. Find out more about the whole show at