TPR9: Evolution of Form Design

Alex Kingman: We're going to talk about the evolution of form design today. So real quick, let me tell you what I mean by 'form design'. And we're talking about Web forms, OK? So in this basic form, an HTML form element, an input, anytime you're asking the user to input data, that's what we're talking about here. It can be complicated, a lot of pages, different inputs, it can be just a simple search or a status update, 'How you're doing?' That's what we're talking about today.

How many of you have built a form... designed a form? Awesome. Favorite part of your job?

[Laughter]

Alex Kingman: OK. Well, that's actually what I want to talk about today: the kind of stigma behind Web forms and how we think about them.

My name is Alex. I'm from Purdue. And when you talk about evolution, it's kind of easy to talk about the natural progression of things. Things getting better over time. And this is caused by a lot of different things.

In our industry, we recognize things like technology. Technology gets better, things get faster, devices get smaller, screens get bigger.

And also we're dealing with different form factors. Technology is changing this as well. And if we step back for just a second, Apple is a really good example for how style also makes things evolve... so the design, the aesthetics of objects.

And also, there's a culture that evolves as well, so these form factors are changing. We're using these things on different places, on the couch, on the bus. There's this whole culture that evolves with it.

When you're talking about natural progression, you have technology, style and culture. But there's one other really important thing I think we fail to think about that causes evolution, and that's the user's expectations.

So let this sink in for a second. This is really important.

The Web's changing a lot. Especially in the last five years, we've got social media, microblogging, all sorts of little widgets that we're playing with. It's changing the way we use the Web.

As that's happening, the user's expectations are changing. They're seeing the way the Web works and how it's changing, how things are getting easier, faster. And with that, there's an interesting thing that's happening. They start to expect that out of our designs.

And if you were in the HTML5 presentation just a second ago, you talk about geolocation, right? Really cool stuff. When we're using mobile devices, it just knows where we are. We don't have to type out our address anymore. This is an expectation shift. We have things that help us fill out forms. Auto-complete mechanisms.

So even a more recent example... Anybody recognize what this is? Google, right. They just changed to the instant search. So you start typing, and then boom, things show up immediately. Really cool, right? Gimmicky? Maybe, but cool. But there's a really interesting thing happening here. Oh, and as you type in more, more things begin to happen, more things show up.

There's a really interesting thing happening here, though. This is a personal example. When I first saw this, I thought, 'This is a total gimmick. Did Google really not have better time on their hands to do something else? Really?'

But as I was using it and using it... you guys are Web developers and designers, you spend a lot of time searching for stuff, right? Your search results, it is kind of faster. It happens quickly because you don't have to make that decision and submit. You can see the search results immediately. And Google is also finding this in their statistics that they're looking at. Search results are coming faster and more people are doing more searches in a smaller amount of time.

So this begs an interesting question: are users' expectations shifting so much that in the future they'll go to Yahoo, they'll type in their search query, and then... 'What went out? Is it broken?' I don't know. But it begs that kind of a question. That's what I'm talking about today when I talk about user expectation. It's changing.

And as our role as developers and designers, we need to keep this in mind. We need to make sure that our expectations for what we do, our code, our development, that it's in alignment with the users' expectations. And not only that, it could be a little bit greater. Let's push the curve here. We need to create new expectations. So it's really important.

The problem in form design, and especially in higher education, we have data all over the place. It's ridiculous. We have registration forms, student evaluations... There's forms everywhere.

And the problem is that when we get projects, we get really amped up on the project. We want to make this really slick, really well-designed. We want to think about our users. We want to think about the functionality that this thing is going to do. What are all the things in the back end that are going to drive this?

But when it comes time to actually get the data from the user, we just think it's good enough to throw up a form. I mean, we just want the data, right? Well, that's the problem. They're an afterthought. They're typically just OK.

And the problem with this is, when our users use the Web, they're typically consuming. They're reading, they're getting information, they're just chugging through pages and consuming.

But when they get to a form, a really interesting thing happens. It changes. It's almost opposite. All of a sudden, this machine, this terminal, this computer that they're sitting there interfacing with all of a sudden stops and asks them, 'Hey, how are you doing? What are you thinking about? Tell me about yourself.' This is a really interesting part of the process.

Can you guys read the black? I apologize. You can? OK. Awesome.

So forms let users tell us how they think or what they're feeling. There's an opportunity here for human interaction. And this is where I'm talking about meeting expectations. Sites are beginning to do this. Users are expecting it.

When we talk about evolution, we've got to talk about cavemen. And I tried to find "Encino Man", but I apologize, I couldn't find it and I'm out of time.

The caveman. You've seen this scenario before. He's sleeping in his cave, and he travels out into the fields or the fjords or wherever he is, and he comes across an object he's unfamiliar with. What does he do to this object? What does he do? Smell it? That's fantastic.

Did I do that? Am I OK? All right.

Smell it? I like that. I like that. Yeah, well, he's probing it. He's trying to figure out, 'What the heck is this thing?' This example here, he's like, 'I'm going to poke it with a stick.'

So he's trying to find out if there's intelligence there. 'Is this thing going to bite me? Is it going to run off with my cavewoman? What's going to happen here?' So he's poking and prodding trying to find out what's behind it, what kind of an interaction he's going to have with this thing. Think of your forms in the same way.

This is an example of Mixable. It's a collaborative tool for our students where they can come in and it's kind of a social learning atmosphere where you can share, collaborate with documents, media types like images and videos, you can share files via Dropbox, we have podcasting on here, things like that.

So when a user comes to this site and they want to fill out their status, they're like poking with a stick. They're prodding. And then all of a sudden they paste a link to a YouTube video, and something starts to happen. 'There's sort of an intelligence here. Something's going on.' And then boom.

This is not new. We've seen this in Facebook. These are the kinds of interactions where our users are expecting now.

But not only did it understand that I was giving a link, it comprehended. It understood what I was trying to do. It took the next step for me. It gave me a thumbnail, it embedded a video in my page. It formatted the layout a little bit so it helps the user. It's a good experience. This is what I'm talking about about user expectation, when you need to meet that.

Why do we need to evolve? Because we don't want unsatisfied cavemen, basically. And please do not go back to your institutions and call your users 'cavemen'. At least don't attach that to me, please.

How do we evolve? As Web developers evolve, as we need to rise to the challenge, we need to... we're not just one-trick ponies anymore. We need to be the Renaissance developer. We need to wear many hats. It's easy to pool all these things into roles.

The first role I want to talk about today is the Navigator. The navigator's role is to help the user complete that form, help them through the form. So your Number 1 goal when you're filling out a form, or at least one of your most important goals, is to give the user that clear path to completion. You need to make it as just easy as possible for that user to glance at your form and understand the scope, what I'm dealing with here.

Here's an example. If any of you saw my posters from last year, do you remember the Spy Kit order form? It's just a fake example of a Spy Kit order form.

But here we have an example that has... look at your label alignments, look at your text inputs, look at where they're placed on the page. It's not all the same, and every section is a little bit different. We have helpful information.

But that's the same color, the same placement as everything else. Your eye has to bounce back and forth between all of this information to comprehend it. Sure, all of our data's here, all of our form inputs are here, but there's a lot going on in the user's brain to figure this out.

So that path to completion? It's a little muddy, so to speak. You have to think about it. You have to really figure it out.

What you need to do when you're building your forms is think about alignment. Think about placement. Think about how you treat your labels. Think about how you treat your inputs as opposed to everything else on that page.

This is just a quick example of moving, anchoring everything to the left side of the page. Now that's not going to be your answer in every case. Think about the form, think about the content, what you're trying to do. But here we've created that clear path to completion. We also have the 'Submit' button aligned in the left as well. These are the kinds of things you need to think about.

That example was large as well. There's also another issue there we need to talk about. This is a large form. In these cases, you might want to think about splitting the form up. And how you do that is think about the content you're asking about. Think about how to pool logical groupings together.

A lot of times you'll have things that ask for information about the user: what's your name, where you're from, birth date, so on and so forth. That's a logical grouping. Place those together. Place them on a separate page or a separate area.

A lot of things you're seeing now coming to the Web are accordion forms. This is something that you might see grouped together in an accordion.

And then the other problem with that... so we're fixing things but we're adding new challenges, right? The other thing you need to think about is progress indicators. If you have split up your form and you now have three, four, or five pages, your user can get a little lost when they're traversing through that.

Keep them aware of where they're at. Let them know the scope and their position, so where they're at in their scope and how much more they have to go. This is taking away the fear of, 'This form is daunting. I have no idea where I'm at, where I'm going to end up.'

This is Signals. This is another example of an application that we did for Purdue. It's early intervention. Are you guys aware with that concept? It's looking at the student, assessing what the student is doing, their scores, their grades, their attendance, how many times they log into the system, and figuring out ahead of time if they're going to fail, and letting the instructor know. That's what Signal does.

And as you can imagine, it has a lot of data. The instructor has to put in a lot of data. So we split this up into six sections. What we've done along the top is we've outlined that with progress indicators.

And this does a couple things. Like I said, it shows us the scope. We know we have six steps. It shows us the current position. We've styled it a little bit differently. It looks highlighted. And you can also step backwards if you want to and you can also see where I have to go. And it looks a little differently. It's less apparent because we haven't actually been there yet. There's no data in there yet.

Lifeguard. Now for those of you that I promised there would be a Hasselhoff, here you go. I lived up to my word.

As the lifeguard, it's your duty to help people. Your users are going to make mistakes. But what we can do here is prevent them... so this is before the fact... prevent them before they submit that form to fix the errors. This saves us a lot of error results from the form. It gets rid of those ahead of time.

What I mean by that are things like help and tips. If you're asking for unfamiliar data or has a specific formatting, things like driver's license or you don't know off the top of your head or you don't remember the formatting, or there's something unique to your organization, you have a specific format that you wanted in, help and tips are generally a good idea.

But, again, this is not new to you guys. You know this. The thing that is hard to comprehend about it is to not overdo it and how you present these help and tips. That's what I want to talk about.

We had a site... this is PurduEBoard. It's a site for student organizations to share events and post things about what's going on in their organizations.

This is the form. This is the first form we had. Can you see issues with this form already? There's a lot of noise. Remember, path to completion. That's one of our goals here. Well, we've already failed, because the user has to comprehend, 'What's this? What's all this red text?' There's a lot going on.

So one of the things we can do is user-activated exposure. And that's just a fancy couple of words for letting the user decide when they want the help.

So what we've done is that big block at the top of the page, we've moved into an 'About Flyers' button. So if the user wants to see that information, they can click on it and then get that. It's an unobtrusive way to show that information. And when they're done, they can 'x' out and they're back to normal. What this does is it defers the noise. It moves it to a different point in the form.

Automatic inline exposure. A lot of the help isn't really relevant until you need it. So this is a 'just in time' methodology. For example, if you have an input that needs formatting, like we do here, when we set focus on that input element, then we show inline exposure of help and tips. And then when they're done, it disappears.

Again, saving noise, letting that path to completion be clear. These are the kinds of things that we're helping here clean up.

Your users will mess up, though. They'll get into trouble. And when they do that, you need to tell them, 'It's OK. You're going to be all right. You're going to recover.' You need to help them through that. So as the mentor, you need to display prominent and helpful errors.

Again, here's the Spy Kit order form. I filled this form out. I've hit 'Submit' and I'm still here. What happened?

Audience 1: [15:38 Unintelligible]

Alex Kingman: Where?

Audience 1: [15:40 Unintelligible]

Alex Kingman: Upper right?

Audience 1: [15:43 Unintelligible]

Alex Kingman: That just says 'For More Information'.

Audience 1: [15:45 Unintelligible]

Alex Kingman: Ah, there you go. See? We all had to comprehend this and figure this out. That's ridiculous.

Audience 2: [15:53 Unintelligible]

Alex Kingman: Exactly. So think about the styling of your form.

Anybody from an institution that has red in their colors? Yeah. Think about this. If your error messages are red and your institution is styling with red design, you might need to think about a different way to do this.

Again, we have help text over here that's also red. Not really a good idea in this scenario. I mean, it's not really connected. It's close to the label, but not really connected. There's some issues here. So make your error messages blatantly obvious. This is important. Your users mess up. Let them know.

In our applications in our websites, what we have is a lot of text. It's just the name of the game. 'Content is king,' right? We have a lot of text. Your error messages probably shouldn't be just text.

Make them stand apart with things like imagery, color, white space. Put them near the top of the page. Let your user see these. Make them obvious. And also, at the same time, don't only give them that message but show them where the error occurred.

Again, going back to Signals application. What we do is we highlight the row that they messed up with. Right there. And we've also given it a little icon of a flag. So imagery, color, different coloring of the font down there: these are things you can do to help those errors stand out.

Remember, our users have different expectations now. Things are a lot easier. We need to meet that.

This one's good. This is a fun one. Now, this is the geeky one. How does this stuff actually happen? How does it get made? It's all about the markup. And what I mean by 'markup' is HTML, CSS, the actual code of the front page.

This was mentioned in an earlier presentation, Mobile Design CSS. This is great stuff. CSS Reset is created by Eric Meyer. Anyone using this now? That is nearly not enough hands. This is really important.

Everybody knows we deal with cross-browser issues. Every browser does it differently. They think the other one is doing it wrong, right? 

Like, an H1 tag in Firefox won't look like an H1 tag in IE6. And then sometimes stuff in IE6 doesn't look like IE7. I don't understand that. But there's a problem there. And what CSS Reset attempts to do... it's your baseline. This is the first styles that you use. And what it does is it brings everything down to a baseline. So it takes your margins, sets them to zero, takes your font sizes, changes them to the same thing. Everything is brought down to that baseline.

And the idea is what you do from that point forward is all progressive. You add to that baseline, and you've got all your browsers styling the same way. So it's going to help you out a lot. So please start here with your styles.

I'm going to talk a little bit about a few HTML text. These are so important when we're dealing with forms, but the problem is a lot of people don't use them. We just don't. We just use our inputs, and we might have headers around them. That's it.

These exist for a reason. They're semantic. They have meaning. Field sets and legends: they go together. What field sets do is they...

Remember earlier I was talking about grouping similar information, like personal information, things like that? That would be long well in a field set. That's what it does. It groups similar information together. And the legend goes with that field set and defines what that field set is about.

This is really important for a few things. Visually, it's helpful, and for accessibility reasons like screen readers. They'll know that everything in this field set belongs to this legend. They're all similar items. Really important stuff.

Labels. So important. I think most of you probably understand the reason for labels. You're associating a title with an input. You're describing it. What is that input? And I apologize again for the text here. What a lot of people don't know about labels is how to associate them.

If you've been to websites that have a bunch of radio buttons and check boxes, the problem with those, it's a small click area. You have to get the cursor just right. And if you have any sort of impairment, it might be really difficult for you to click check boxes, click radio buttons.

So another thing labels can do with associations is not only define that input but also increase the click area, so if you've been to websites where you can click on the label and it will select the check box. This is very helpful.

And you can do that in two ways. I'll explain this for those who can't see it. 'The Four Attributes'. So right here I have label. Four equals username. And what it does is it ties to the ID of the input; not the name, the ID. That's one way to associate it. The other way is just to completely wrap the label around the input. That will also work as well.

And just quickly to mention about all these, if you start using these HTML tags, you'll also notice that this gives you more leverage when you're designing, when you're styling with CSS. You have more things to point at. You no longer have to add classes to things like, say, 'This is my personal info title of H3'. You don't have to do that because you don't have the legend to do that. And you can point to those items and style them differently.

You can also add classes to your field set if you want to design each field set a little bit differently, maybe as different types of data, and you want to align the inputs to the left or to the top. It's different. So you can do this with CSS now. Makes it a little bit easier.

Buttons. So 'Save', 'Submit', 'Next', 'Back,' 'Cancel', these sort of things, treat them right. Don't just think of them as buttons and that's good enough, because that's not the case.

Have you ever been on a form where you're just blazing through this thing and you're click and 'Save', you're click and 'Next', and all of a sudden something happens and you realize, 'Whoops, I just clicked the cancel,' instead. It happens. And a lot of times, this happens because we're not thinking about that experience, of just that moment of clicking that button.

What we've done in Signals is... you saw that there's a lot of steps in this form, right? We have 'Back', we have 'Cancel', we have 'Next'.

And what we've done is, in the application, we have the style around things that are activating or enabling or saving. They're green. They're lit up like a traffic signal. What we've done here is we've made the action, like the progressive action, with that same style. So the user already has this association in their brain if they've been using the app for a little bit.

And what we've done to the other two is treated them differently. They're not your progressive selection. These do something different. We're going to go backwards or we're going to cancel. And 'Cancel' looks a lot different. It's red. It's got a big 'X' next to it.

It's OK in cases like this to make your users slow down just a bit, because this is an important decision point. You want them to think about it and you want them to make sure they're hitting the right button.

Now, label alignment is a really cool topic. We could talk about just this for a long time, but for time case, I'm going to try to just cover the top points.

There's a really interesting study done by an Italian guy, Matteo Penzo. He did eyetracking study on different types of label alignments, so how does the user look at this form and travel through it if it's styled a different way.

I'm going to talk about two: top-aligned and left-aligned. And what I mean by top-aligned is just right on top of the label. You've got label, input, label, input. And what they found was this was the fastest. Users would complete the form the quickest when doing this.

They suggested that this was a good thing for familiar data, so things you've filled out a million times: your personal contact information, your name, your phone number, things like this. This is probably good for that. We can send them through the form quickest.

It does require more vertical space, though, so if that's a problem in your design, it might be a consideration when you're deciding which way to go.

Another good point to talk about is it's good for localization. If you're in an institution where you're doing a lot of different languages and you're going to be changing the language of your form, this allows the label to expand and contract as the words naturally get bigger or smaller.

Left-aligned labels. These were the next fastest. A little bit slower, but the next best in their case studies. They suggested it's good when the data is a little more unfamiliar. Again, I'm talking about maybe it's a good time to make the users slow down and think about what they're doing. This might be a good approach. If it's unfamiliar data, if you want them to realize that this is a little different than what they've been filling out, this might be a good thing.

There is a less clear association between the label and the field, because as your eye looks at it, you have to go back and forth matching up the labels to their inputs. But also it requires less vertical space, so if that's a problem, this might be a good thing for you.

Again, the best practices, kind of a sum-up. For fast completion times and familiar data, top-aligned is a good thing. There's also a little consideration here about mobile design. I will talk about that in a little bit. For unfamiliar data, and if vertical space is a problem, you might want to think about left-aligned labels.

It's also really important to think about your form as whole when you're doing this. Depending on how you're laying it out, you might want to think about not changing this up a lot. If you do, you better have a really good reason for it. Again, path to completion. Remember this. You want to make it obvious.

The Forward-Thinker. I get really excited about this stuff. This is cool. So HTML5 input types. If you guys just sat through the HTML5 presentation, it's fantastic, and one of the things that is left to talk about HTML5 is new input types.

So we're used to 'input type=text', 'input type=password'. HTML5 brings with it 13 new types. And some of these are in use right now.

And it's important to know... again, if you didn't attend HTML5, this spec is open and it's changing. It's not going to be done for a long time. As new browsers come out, they support more of this.

And I just want to make sure everybody understands, this stuff could change. So it's really important to think about what I'm telling you today, but also keep checking with the spec. Keep checking with the browsers that you support. Keep this in mind as you go forward.

So what does this mean? On the iPhone, you get context-aware keyboards. This is so cool. So you're filling out forms, right? It's a pain in the butt to flip the keyboard over to numbers. It's a pain in the butt to go get the symbol, that hash... you ever done the hash tag? You have to not only go to the number tray but you've got to flip it. Horrible, right?

What this does is it tells the iPhone, 'I'm taking in a number here, so don't bother with the alphabet keyboard. I want the number keyboard.' And it understands this and it does this for you. So cool. So cool.

URL gives you a slash and a dotcom, email gives you an @ symbol and a dot. Things that you're going to natively use for that input.

Context-aware widgets. So this is going to the desktop on your desktop browsers, and a lot of these examples come from Web kit-based browsers, so Chrome, Safari. Opera is also another one that does a lot of this stuff.

If you have 'input type=number', now you get a little number incrementor, a little click thing. And you have a slider for 'type=range'. This is really cool.

And keep in mind, this is native to the browser. This is not Javascript or front-end trickery here. This is the browser rendering this. This is really cool.

Time, it gives you another little clicker. Week, month, date, time, things like this, they give you calendars now that are native to the browser.

And one of the first things you might be thinking is, 'This is awesome, but these are kind of lame. I want to make them a little prettier.' You can still do that. Use Javascript. You can override what the browser is going to do for you. But this is really cool for people that don't want to take that extra step. It's already doing it for you. This is really, really cool.

Opera. They're doing some cool things. They're taking it a step forward. And not only are they allowing 'type=email', but they're validating it for you. Again, keep in mind, this is not Javascript. This is the browser. It's doing it natively.

So when I fill out this form and I hit that 'Submit' button, before it submits, Opera will stop me and tell me that steve@apple is not a valid email address. It validates URLs.

Now this is not a type. This is an attribute. And I want to call special attention to this. 'Required'. Not much explanation here. Now we can tell the browser what's required. Very cool. And again, if you want to use Javascript override and do something differently, you can. You can still do that.

So if these 13 types aren't enough for you, if you have a specific format, Opera's got your back here, too. You can give a regular expression to define what that number should look like via the pattern attribute. Really cool. This is huge. I mean, you can basically do anything a regular special wants to do, right? So the Opera then stops the submission and it tells you that this is not correct.

More attributes now. Placeholder and autofocus. Not much explanation here. They're self-explanatory. You can have a placeholder in your input. And when you click on that input, it goes away. Autofocus, when you load the page, the cursor's automatically focused on the specific input. Really cool stuff.

So this is great. But I know you're thinking, 'OK, can I use this? What are the problems? What are the other things I've got to think about? It's not going to work for everybody, right?'

We develop for HighEd users, so we're dealing with a lot of, well, crappy browsers. Does anybody see the little Easter egg in here? I don't know. What is it, Steve? Anyone?

Audience 3: It's a mosaic.

Alex Kingman: Yes! Nice. Whoa, that really got long. Sorry. That's nice. Oh yeah, I put that in there for you, man. That's good.

The important thing to note here is, don't worry. In the HTML5, this is a great presentation. He talked a lot about how... do you guys remember the stat? It was like '85% of the Web doesn't validate'? There was a stat, it was really interesting. So moving away from XHTML and just saying this is an OK thing.

Don't worry here. Browsers that don't recognize it, like 'type=email', 'type=URL', they'll fall back to type text. It will still be an input. Your user can still input text, and then your server side validation and URL using server side validation. No one's nodding. Do we need to do another presentation about this?

[Laughter]

Alex Kingman: Jason, you'd be good for that one. Maybe next year.

You can still do those sorts of things. And for those browsers that do support it, they will render a different... like a calendar pop-up for date/time, things like that. Unknown attributes will be ignored. So placeholder, autofocus, these things, they'll be ignored. The input form will still work.

If you're on IE6 and it doesn't know what 'type=email' is, that type will just default to text. So what you can do is check for 'type=text' now on that element. If that exists, then you know it doesn't support it. And you can roll your own solution with Javascript or jQuery UI, something that you like to use.

Placeholder and autofocus. Kind of a similar situation. You're creating an element in the DOM, and then all you're doing is trying to return that attribute. And what happens is, these won't naturally be blank, but it exists in the DOM so it will return true, if it supports it. If it doesn't, then you can roll your own again.

And if you need help with this, he had some examples in his presentation as well about Modernizr. These will help you do this. Makes it really easy to update.

Whoa, hello.

Mobile forms. Again, a fun topic. I want to talk a little bit about people's ideas about forms on phones, and filling those forms out.

Jakob Nielsen, usability expert, been around for a long time. Like Mr. Usability, next to Steve Krug, of course. But he says designing for mobile is hard. A book from O'Reilly, "Mobile Web Design and Development", says general rule of thumb is to just avoid it completely. Limit the use of forms on mobile devices.

There's this general stigma behind forms on mobile devices. And understandably so. Keyboards are tiny, screens are tiny. It's a pain in the butt. Well, this is where it gets really interesting. There are more than 150 active Facebook users that are accessing through their mobile devices. And these guys are twice as active as the other users. What do you do in Facebook? You're filling out a form. You're giving your status updates.

Yelp, just over 25% of their searches were done through the iPhone. And then all other smartphones combined, they have two million unique visitors in 30 days. Twitter, 46%, half of the active Twitter users make mobile a regular part of their experience.

We don't really need to talk about this much. I mean, people are using mobile phones even with this stigma that forms are bad and we should avoid them. So what's happening here is the evolution of technology and culture, they don't really care. Just people do it. It's happening right now. People are using forms on mobile devices more.

So we might not want to be scared of this. We might want to think about more creative ways. How can we do this and meet our users' expectation? Again, remember, we're trying to rise to meet our users' expectations now.

We have tools that help us do this, thankfully. Field-zooming. If you've used mobile phones, I'm sure you've tapped on a field and the phone zooms in for you, right? This is an example of our back channel tool for the student in the classroom on their mobile device. You tap on the text field and it zooms in.

Now, there's important things to think about here. The phone's helping you out a little bit, but you need to be aware of a few things. Do you see a problem with this screenshot?

Audience 4: [35:41 Unintelligible]

Alex Kingman: What's that?

Audience 5: [35:43 Unintelligible]

We talked about label alignment. Mobile devices, you might want to think about top-aligning your labels. It's just something to think about.

Pop-up and compound menus. In my email client that I use on the Web, I'm sure a lot of you do the same thing, I've organized my email into folders. But I have a lot of folders. I have a lot. And when I go there to sort through that folder, it's drop-down menu.

When I hit that thing, that drop-down menu expands the entire screen, and then it has little arrows on it. The drop-down menu itself already on a desktop is not the best widget for forms. Already we're behind. On a mobile device, it's even worse.

We have compound menus for data that's logically grouped together. We have these, well, drop-downs kind of, these compound menus that are all of them together in one menu, so we're no longer having to click-select, click-select, click-select. It's all together. So think about that as you're designing for mobile devices.

Geolocation. I don't really need to go in-depth here. It just does it for you. It figures this out. Think about this when you're designing. We can use this on desktop browsers as well if your browser supports it.

Voice input for the Android. This is fantastic. When you're filling out input fields, the keyboard rollup comes with a little microphone. You can click on that and speak into the form. This is huge. They've made it even easier. If you just swipe the keyboard, it will initiate voice mode as well.

It's got a long way to go. It's kind of new. But you can take pictures of things and it knows what you're trying to do. It knows you're looking at a landmark and it gives you interesting information about that landmark. You can take pictures of text and have it translated for you. This is really cool stuff.

And we're going to see a big shift here pretty soon as more people use this kind of technology. So be thinking about this as you're developing applications.

Unnecessary inputs, get rid of them. If you can defer it, if it's not important until later, defer it. You can get rid of it entirely. Because the important thing to think about is, every time you ask a question, they have to think about, they have to parse it, they have to formulate an answer. Actually, I was... And then they have to input. There's a lot of things that go through their head when they get a question. So it's really important to think about each question vigilantly.

And this is not just for mobile phones. This is for all forms, really.

My last one is Mr. Personality. This is actually my favorite one, and I have very limited time so I'll just try to sum up here.

The problem with forms is that they're forms. They're naturally just boring. It takes work. So what we're doing here is giving it a personality, making it an experience. Think about it from a design perspective. How can we not only get data efficiently, but how can we make this a good experience for the user?

Remember, we're trying to make this a more human interaction. So communication. It's an interaction.

This is Huffduffer. Registration for this site. They took an interesting stab at it. They did like a 'Mad Lib' style. Do you guys remember Mad Libs from being a kid? Remember putting poop and fart in all the columns? This is what happens. They've taken this approach. And what they've done is they've kept this field, this personality, through their whole site. So it's not just the registration form.

Give your applications a voice. Make it more human. Make it a better experience.

This is Kontain, sign form for Kontain. Not only is it visually interesting, they've put a lot of thought into designing each input area.

You don't design an input area. Come on! But it's an interesting experience. Like you almost want to fill this out. I don't even know what the site does and I want to fill this out.

[Laughter]

Alex Kingman: It's fun! And they take it an extra step. When you go to the next page, they've split up a large form here. Remember back? A simple radio of male and female is now fun because you get little icons there. And they've taken drop-downs, which are boring as heck, they've modified them and made them a widget. It's like a little thing that it almost has a tactile feel to it. I want to press these buttons. There's a personality here. This is really important.

Again, don't just create forms. Create experiences. You want to rise to meet your users' expectations. They have new expectations of the Web now and of your input forms.

That's all I have. Just quickly, if you guys want to find out anything more about what we're doing at Purdue, our studio site has a lot of our information about Mixable, about Hotseat, about Signals. We have a new project coming out soon. You can go there to find out more information.

And if you want to learn more about it today, my colleague Steve Heady is representing Purdue and presenting on reputation systems, and not only that as how we're using them for classroom tools. It's a really engaging presentation. I highly recommend it.

Do you guys have any questions? Do I have time for questions? I got one of these. So if you have one of these questions, I can take them now.

Oh, I thought this was a really interesting evolutionary... I had nowhere to fit this in the presentation, so...

[Laughter]

Alex Kingman: ... I just thought I'd put it here if we had more time. Yes.

Audience 6: So right now, Opera is the only one that's doing the browser validation?

Alex Kingman: Validation. Yes. And that's why I said it's really important. Keep checking. Because this is going to happen more and more. Just the obvious benefits of this are huge. More browsers will be doing this. Yeah, keep checking.

Audience 7: I have a question about form design.

Alex Kingman: Sure!

Audience 7: My pet peeve, I type really fast, I'm filling out a form, I type in the name of my town, and then I have to stop, pick up my mouse or go to the keypad and scroll down a long list of places.

Alex Kingman: Right. There's a couple problems there.

Audience 7: Why do they do that?

Alex Kingman: Because we just don't know any better. I mean, that's the whole idea of this presentation. I'm trying to make people think about forms that it's not just forms anymore. You make them experiences. So filling out your address, Geolocation, browsers are supporting this now.

I was on... what was I using... Chrome, and it knew... gosh, what was I doing? I can't remember. I think I might have been looking for pizza or something. Domino's was it? But it knew where I was. I didn't have to type this in. So it not only eliminates that process of inputting the form...

Audience 7: It knew your address?

Alex Kingman: Yeah. You've got to let it. It will ask you. It always asks you. But, yeah, Geolocation features in HTML5 do this. So, thinking of these tools as we move forward, we can start to eliminate these painful processes and make the experience more enjoyable.

Audience 7: But I mean, even typing in the two letters. I mean, who doesn't know the two letters that are their state?

Alex Kingman: Right. Just eliminate it entirely, I say. Yeah.

Audience 8: In a list of countries, where do you put the United States?

Alex Kingman: Oh, that's a huge one! Don't you love the ones that put it at the top?

Audience 9: [43:42 Unintelligible]

Alex Kingman: I love it. See, again, Geolocation, just eliminate it altogether. And think about your audience. Everything has its own... There's no blanket statement here, but think about your audience. If you know a lot of your users will be from the U.S., maybe put it at the top. You know, it depends.

Yeah.

I saw one more hand go up somewhere. Is it a fakeout?

Audience 11: We should do a survey about that.

Alex Kingman: Doing for what?

Audience 11: Where you put the state...

Alex Kingman: The state? Yeah.

Audience 11: [44:15 Unintelligible]

Alex Kingman: Hey, again, make it fun. Give it personality. Why not give them a map? Let them pick it on a map. Make that map interesting.

Audience 12: [44:33 Unintelligible]

Alex Kingman: A flag. See? There's things you can do here. It depends on the personality of your application. Is your application fun? Is it ornery? I mean, seriously, think about these things. You want to give your apps a voice. Make them fun for the user. Make it more human.

Audience 13: [44:48 Unintelligible]

Alex Kingman: It could alienate a lot of users, though.

I'm just playing devil's advocate. I agree with you. Yeah.

Thanks, everybody. I appreciate it. Thank you.

[Applause]