The Livetyping Blog

  • Forms—The Complete Guide—Part 2: Input Types

    Forms are one of the most important parts of any site or app—they are the most common way for our users to give us the information that we need to help them do what they want to do.

    But in many instances, we design forms statically, often as wireframes. But so often, what makes or breaks a form is what it's like to interact with it. When the user clicks on a particular radio button, some additional inputs appear. How does that happen? More importantly, does the user understand what just happened?

    Things like this are next to impossible to explore using static deliverables. But with a prototype of a form, it's easy. And with a prototype form made in HTML, you can make it look and behave exactly like the real thing. Which means that once you've validated it with users, you can be sure that it can be implemented so that the appearance and feel are just the same.

    This series does not try to explain what your form should contain, how the fields should be grouped and laid out, where to put primary and secondary buttons, and so on. There are lots of great resources out there that do that already. (Like Luke's and Caroline and Gerry's books. Or Justin's article.)

    No. What this series does is give you the how. You've already figured out what you think your form should contain and how it should behave. These posts will give you everything you need to know to make a prototype of your form in HTML, something that looks, works, and feels like the real thing. Which you can then use for usability testing, for getting stakeholder buy-in, and as a living specification for developers.

    In the first post in this series, I showed you how to lay out a form and align the labels the way you want, using HTML and Foundation.

    In this post, I'll show you the different types of inputs available to you and how to use them.

    To make the most of this post, I strongly encourage you to get your hands dirty by actually typing in the examples and then opening them in your browser to see how they look and work. From personal experience, this gets it into your brain, into your fingers, much better than just copying and pasting.

    Input types

    There are several different HTML elements that are used in forms. Buttons get their own element (<button>), as do drop-down lists (<select> and <option>), and multi-line text inputs (<textarea>).

    But most form elements are the <input> element, with a type attribute that specifies what kind of input it is.

    Let's look at them one by one.

    If you're following along and actually typing this stuff in, you need to set up a new Foundation project, open up its index.html file, and delete all the sample content (see this post to find out how).

    Then add an empty <form> element and the necessary Foundation layout elements.

    Once you've got that set up, you can just add each example within the <fieldset> tags, after the <legend> element.

    Note: In the code samples below, you'll notice that all the <input> elements have both a name and an id. Why is this? It's because you need the id to be able to identify individual HTML elements (to style them with CSS, etc.). But for a real form, you need name so that the data that gets sent to the server will be labeled correctly. These aren't proper forms, they're just prototypes. But it's good to do it properly from the start. So the rule of thumb is: for <input>s, use both id and name, and give them both the same value. (An exception is radio buttons—I explain why they're different below.)

    Text and its variants


    Input of type text

    An <input> of type text is just a simple input field. There are no restrictions on what the user can type in it (though there are attributes that you can add to do things like limit the length of the field's contents—see below).


    Input of type password

    An <input> of type password behaves exactly the same as a text input, except that whatever you type in it is obscured.


    Input of type email

    An <input> of type email is the same as a text input, except that on phones and tablets, the keyboard that is displayed has @ and dot keys as standard—you don't have to go digging for them:

    It also gives you validation for free. If you enter something other than a valid email address and then submit the form, the browser will do something like this:

    Input of type email, invalid

    (This is true for desktop browsers anyway. Most mobile browsers don't do this yet.)


    Input of type url

    The url <input> type is similar to email, except here you get a keyboard layout with slash and dot keys (and maybe others, such as .com).

    Again, desktop browsers validate these automatically:

    Input of type url, invalid

    Phone number

    Input of type tel

    The tel <input> type, as we saw in the previous post, gives you a phone keypad on smartphones:


    Input of type number

    The number <input> type doesn't restrict what you can type, but on smartphones (the iPhone, at least), you get the regular keyboard, switched to numbers-and-symbols mode:

    Different desktop browsers render this input differently. In IE and Firefox, it looks the same as a text input, but in Chrome and Safari, it gets spinner controls for increasing and decreasing the value:

    Input of type number on Chrome/Safari

    You can set minimum and/or maximum values, and a step size. These affect the behavior of those spinner controls.



    Input plus datalist, empty


    Input plus datalist, typing

    You can use an <input> with a list attribute paired with a <datalist> element to get something that is kind of a cross between a text input and a drop-down list. As you type in the input, a dropdown list shows you matching options. You can click on an option or use the arrow keys and Enter to select.

    Other types

    There are a number of other <input> types that were introduced with HTML5, but most of them are not widely supported yet. These include color and various date and time inputs, such as date, time, datetime, datetime-local, week, and month.

    For now, you're better off using things like the jQuery Datepicker.

    The rest


    Input of type checkbox

    If you give an <input> a type of checkbox, you get a checkbox. These usually have their label to the right. For checkboxes, the for attribute is particularly important—it makes the label clickable—clicking it is just like clicking the checkbox itself. Adding the checked attribute (which doesn't take an argument) makes the checkbox checked when the page loads. For a prototype it doesn't really matter, but a checkbox in a real form must have a value attribute.

    Radio buttons

    Input of type radio

    Like checkboxes, with <input>s of type radio, the label usually comes after the input. And for and checked work the same here too. Here though, be sure to give all the radio buttons in a group the same name attribute—this tells the browser that they belong together, and that only one can be selected at a time. Again, like with checkboxes, every radio button must have a value.


    Input of type range

    An <input> of type range gives you a slider. Like with number, you can specify a minimum, maximum, and step values. But this control is not hugely useful on its own—if precision is not an issue, you can probably get away with just adding text before and after the <input> to show the maximum and minimum values. But in most cases, you'll probably want to provide some sort of feedback so the user knows what value they have selected.

    This is not difficult. It requires a tiny bit of Javascript, but you'll see in a minute that it's really no big deal. We just need to take the existing bit of HTML and add an <output> element to show the value. And we add an oninput attribute to the <input> to tell it what to do when its value changes.

    In this version, the <input> and <output> elements are in separate columns, and I've given the <input> a width of 100% so it will stretch to fill its column:

    Input of type range, improved

    The little bit of Javascript that is the value of oninput just sets the value of the output (range_value.value) to the value of the input (range_input.value). (range_value is the <output>'s ID, and range_input is the <input>'s ID. Adding the dot and value just means “the value of the value attribute of the element with this ID.”)

    Drop-down lists

    Closed: Input of type select, closed

    Open: Input of type select, open

    Drop-down lists are not <input> elements—they are made up of a <select> element containing a number of <option> elements.

    This is fairly straightforward. One thing I've added here though is the first <option>—it prompts the user what to do, but is not actually an option they can select. (The selected attribute means it is what is displayed in the closed dropdown before the user interacts with it.)

    Without this option, "Option 1" would be selected by default. Usually we don't want anything to be selected by default.



    A <textarea> is like a text <input>, except it lets you enter multiple lines of text. Like all the text-like <input>s, its width is 100% of the column that it's in.

    As for height, there are two ways to set this. One way is to set the height in CSS (or directly on the element by adding a style attribute). The other way is to use the rows attribute, like I'm doing here. This makes the <textarea> tall enough to fit six lines of text.

    (The style="height: auto;" attribute is to get around a bug in Foundation. If you set the height to a specific value instead of using rows, you won't need this.)



    Most forms have buttons that you have to click to send the information you've entered to the server. Some also have a button for a secondary action, to cancel out or to reset the form (though some argue that such secondary actions are usually a bad idea).

    Here, the buttons are <input>s of type submit and button. (submit is a special kind of button for submitting a form.) The right place to put these is after the closing </fieldset> tag.

    The Submit button gets a class of button to make it into a nice-looking Foundation button, while the Cancel button also gets a class of secondary to make it visually less prominent.

    Foundation also lets you use the <a> element for making buttons—just give it a class of button. It also lets you do stuff like make buttons smaller, give them rounded corners, and so on, just by adding classes.

    Other clever Foundation stuff

    Foundation lets you do some clever things that the standard HTML elements don't let you do.

    For example, you can combine an input with a label to get something like this:

    URL input with prefix

    You can see the code for that here.

    You can also combine an input with a button to get this:

    Text input with postfix button

    The code for that one is here.

    Important attributes

    I mentioned a few attributes along the way, like id and name, checked for checkboxes and radio buttons, min, max, and step for number and range type inputs, and so on. But there are some others that you need to know about:


    Browsers try to help us by automatically filling in form fields for us when they can. But sometimes this is not appropriate, for example, for sensitive information such as bank account and credit card numbers (and even passwords in certain cases, though beware of being annoying with this one).

    Setting autocomplete to off for an input tells the browser not to fill it in automatically.


    On each page, you can give one (and only one) form control the autofocus attribute. This field will get focus when the page loads, so the user can start interacting with it without having to click in it or tab to it.


    A disabled input

    A control with the disabled attribute gets greyed out and you can't interact with it. This may be because it's not relevant unless some other control has a particular value. (For example, if your form has a "How did you hear about us" section with radio buttons, the last one might be "Other", with a text input so the user can type something that's not in your list. It makes sense to make this input disabled unless "Other" is selected. I'll cover this sort of thing in more depth in a subsequent post.)


    Text-type inputs (text, email, url, tel, etc.) can have a maxlength attribute. This lets you specify the maximum length in characters. Most browsers won't let you type any more once you hit the limit. This is handy for things like phone numbers, which can't be longer than a certain number of digits.


    The <select> element and <input>s of type email (also of type file, for uploading files, which I haven't covered here) can take the multiple attribute. This lets you select multiple items in a dropdown or specify multiple email addresses, respectively.

    A drop-down list with multiple selection

    Notice how the <select> is displayed differently when multiple selection is enabled.


    pattern tells the browser what an acceptable value looks like. I'll cover this in a subsequent post when I talk about validation.


    The placeholder attribute

    The placeholder attribute puts hint text inside the <input> (or <textarea>), to give the user an idea of what they need to type. It disappears when you click in the <input>. Some sites use it to indicate which fields are mandatory and which are optional.

    IMPORTANT: Do NOT use this instead of a <label>. It is very bad from both accessibility and usability points of view.


    The required attribute means that a field is mandatory. It doesn't change its appearance (an asterisk doesn't magically appear next to its label), but if you submit the form without filling it in, you'll get a helpful message:

    The required attribute


    The tabindex attribute (which has a numerical value) determines the order in which controls get focus when the user presses the Tab key.

    If you're doing something weird with your form layout such that the inputs are in a different order on the screen than in the page source, you should use the tabindex attribute to make sure that focus jumps to the right input when the user tabs between them.

    Special considerations

    On phones and tablets, there are additional challenges that we face. How often have you come to sign in or register at a site on your phone and seen something like this?

    Inappropriate use of autocorrect and autocapitalize

    On, as I'm typing in the User ID field in the login form, my phone is automatically capitalizing the first letter and wants to correct what I'm typing to words it has in its dictionary. So now I have to tap the little "x" to dismiss autocorrect, and go back and change the capital "M" to a lowercase one. Grrr.

    For fields like this, there are two attributes that we can add to turn off this antisocial behavior: autocorrect and autocapitalize.

    They both take the same values: on and off. By default, they are on.


    Hopefully you now have a pretty good idea of the building blocks that you can use to create your prototype forms.

    In the next post, I'll show you how to group inputs into logical (and less overwhelming-looking) groups and how to provide help to users while they are filling in the form.

    This was originally published on Boxes & Arrows on 25 March 2014.

    This is really just the tip of the iceberg when it comes to what you can do with HTML prototyping. Livetyping, my HTML prototyping course for UXers, will teach you how to do tons more things like this, including more form stuff, drag and drop, animation, and more. You should check it out.

    And if you like stuff like this, you should sign up for my newsletter:

    Sign up and get a free sample lesson by email

  • iOS-style Buttons

    So I got a bee in my bonnet about the buttons on iOS 7 that change color when you tap them. You know, like the ones on the screen unlock keypad and the phone dialer.

    iOS unlock keypad

    I love the way that they are animated: the color change happens almost instantaneously when you tap, but the fade out happens more slowly.

    I figured this should be doable in HTML/CSS too (with a bit of jQuery to help). So here is the result (in Foundation, of course). (It's in a frame—you can scroll it.)

    (Or view the example not in an <iframe>.)

    I think it works pretty well.

    The standard button is light colored, for use on dark backgrounds. There is a dark class that makes the button darker, which is good for lighter backgrounds.

    And just like Foundation's built-in buttons (shown above for comparison purposes), adding the disabled class makes the button appear disabled.

    I haven't gone the whole hog and made matching classes for all the different Foundation buttons (different sizes, rounded corners, different colors, etc.)

    If you want to use it yourself or just try to figure out how it works, you can take a look at the source or view it on GitHub.

    I'd love to hear your thoughts and any questions you might have. Ping me on Twitter: @martinpolley

    And if you're interested in how to steal/copy other people's ideas, I'll be explaining how in an upcoming post. (If the idea makes you feel a bit uneasy, think about it like this: copying is how good ideas spread.)

    Make sure you don't miss it—sign up for my newsletter over there on the right.

  • Forms—The Compleat Guide—Part 1: Layout and Alignment

    UPDATED 21 Jan 2013: After some nice folks pointed out that my examples were a bit lacking in the accessibility department, I added for attributes to associate labels with inputs, fieldset and legend instead of a regular title, and added an explanation of why labels inside inputs are really not a good idea.

    UPDATED 30 Jan 2013: I added a section to explain how to take advantage of responsive design to rearrange the form depending on the screen size (right-aligned labels on big screens, top-aligned labels on small ones).

    Forms can be tricky. They are one of the most important parts of any site, but they are easy to get wrong. There are so many things to think about:

    • What information do we actually need from the user?
    • Which are the right input types to use?
    • Is that true for mobile too?
    • What should the different inputs be called?
    • How should they be grouped?
    • What should the titles of the groups be?
    • Do we need help text?
    • Where does it go?
    • When should we show it?
    • Do all of the inputs need to be visible all the time?
    • How and when should we validate?
    • How should we highlight errors?

    And so on and so on.

    This series of posts doesn't answer all these questions for you. There are lots of great resources out there that already do that. (Like Luke's book. Or Justin's article.)

    No. What this series does is give you the how.

    How to do what though? How to prototype a form in HTML, so that you can put something together that looks, works, and feels like the real thing. Which you can then use for usability testing, for getting stakeholder buy-in, and as a living specification for developers.

    You know how you want to lay out your form. This shows you how.

    You've decided that right-aligned labels are right for this form. This series explains how to do that.

    You know that when the user enters something invalid, you want a message at the top of the form and to highlight the problem input. There's a post that's got you covered.


    If you've read any of my previous posts, you'll know I'm a fan of Foundation, Zurb's front-end framework. Its responsive grid makes laying out pages a cinch. And the same is true for forms.

    I'm not going to explain how to download Foundation and set up a project. You can refer back to this post for that. I'm going to assume you've got a project set up and are sitting in front of a text editor with index.html (from Foundation) open, the default content deleted, and ready to start adding your own stuff. (I'm using Foundation 5.0.2, the latest version at the time of writing.)

    So let's say you're designing a form where the user enters their shipping address. You want it to look like this:

    Layout sketch

    No worries! All we need to do is add a <div> that has the Foundation row class for each row of the form, and for the row that has two inputs, we just add a <div> with the right number of Foundation columns for each input. Add this to index.html:

    Which comes out looking like this (this is embedded, and you can scroll it):

    Open in a new tab

    OK, what did I do here?

    This is a form, so we've got a <form> element wrapping everything else. Inside this, there's a <div> of class row. In Foundation, you have rows that contain columns.

    Then there's another nested <div> with a class of large-8 small-centered columns. All this does is squish the form down a bit horizontally. It's not necessary at all, but without it the form is really wide.

    Next we've got a <fieldset>, which groups the form items together, and a <legend> that gives the group of elements a title.

    After that we've got the actual meat of the form: <input> elements and their <label>s. Each such pair is just a <label> element immediately followed by an <input>. This stacks them one above the other. (A bit later, we'll see how to do left- and right-aligned labels.)

    Notice that each <input> has an id, and that its <label> has a for attribute with the same value. This is important for accessibility—it tells screen readers what belongs to what so it can read things out correctly.

    Most of these pairs are wrapped in <div>s with a class of small-12 columns. This tells Foundation to make them twelve columns wide. (The Foundation grid is based on twelve columns, so this means it takes up the full available width. And because Foundation is mobile-first, we use small-12, which applies to both small and large screens, then if we want to do something different on large screens, we add a large- class as well. Here we don't, so small- is all we need.)

    The only row that isn't like this is the one containing our State/province and Postcode/zip <input>s. Here, we've got two <div>s, one eight columns wide (small-8 columns), and one four wide (small-4 columns). You can divide the space up whichever way you like, but the number of columns mustn't be more than twelve. It can be less, but then you'd have a gap on the right. (Try it and see.)

    All the <input>s have a type of text, because they are for entering text. Except for the phone number <input>, which has a type of tel. In desktop browsers, this works exactly the same as a text input, but on mobile devices, you'll get a phone keypad instead of the normal keyboard:

    Input of type tel on an iPhone

    If you open this up in a browser, you'll see the layout is just how we want it. And if you make the browser window narrower, the layout is maintained.

    If you want the layout to change on small screens so that all the fields are full-width, change the classes for those two columns from small-8 and small-4 to large-8 and large-4:

    That tells Foundation only to make them side-by-side columns on large screens. On small screens, they'll be stacked one above the other. Check it out here. (Opens in a new tab.)

    Label Alignment

    Let's reuse the layout example to play around with the alignment of the labels. There are several different options for label placement.


    Top-aligned label


    Left-aligned label


    Labels inside inputs (which lots of folks agree are a bad idea):

    Label inside input

    The form already uses top-aligned labels. So how do we do the others?

    Simple, we just use Foundation columns again. Let's start off with left-aligned labels.

    Left-aligned labels

    We just need to change our markup to look like this:

    All I've done here is put two columns in each row instead of one as it was before. I've given the labels two columns width and the inputs ten columns. And where we had two columns before for State/province and Postcode/zip, now we have four: two for the labels and two for the inputs.

    Note that I've added the align class to the labels. This is a Foundation class that makes the labels line up vertically with the inputs. (Try removing it and see what happens. It's not pretty.)

    Here's what it looks like now:

    Open in a new tab

    Right-aligned labels

    To make the labels right-aligned, all we need to do is add the right class to each label:

    Which looks like this:

    Open in a new tab

    Responsive jiggery-pokery

    It’s all very well having a form that looks just the way you want on a big screen, but using the exact same layout on a small screen doesn’t always work. (Try opening the last example on your phone—it looks rubbish.)

    We can use Foundation’s responsive grid to make it work better on small screens. In that last example, we used the small- classes to set the width of the labels and inputs. That means that this is the way we want them to look on small screens and anything bigger than that.

    If we change small- to large-, what will happen is that we will get this layout (labels and inputs on the same line) only on large screens (i.e., above 1024 pixels wide). On smaller screens, the labels will be above the inputs, just like in the first example. Try it yourself and see what happens when you shrink the width of the browser window.

    The width at which it jumps from an all-on-one-line layout to a stacked layout is a bit too wide though—the side-by-side layout works just fine on tablet-sized screens as well as desktop-sized ones.

    So what we need to do is use medium- instead of large-. This means that for medium (tablets) and large (desktop) screens, we get the right-aligned labels (or left-aligned, if that’s what you want), and on small (phone) screens, the labels are top-aligned.

    But if our labels started out right-aligned, they stay right-aligned even on small screens. And that’s just wrong:

    Right aligned - just not right!

    Foundation doesn’t give us a way to handle this, but if we dig a little under its responsive skin, we can make things work the way we want.

    Responsive designs use CSS media queries to rearrange their layouts depending on the screen width. All we need to do is add one media query to our CSS to make it all better.

    Create a file called form.css and save it in your project’s css folder. Add this to the new file:

    And somewhere inside between the <head> tags in index.html, add this line:

    This CSS rule looks a bit intimidating, but all it says is this: if the width of the browser viewport (i.e., the width of the content area of the browser window) is 640 pixels or less, apply this rule.

    And the rule that gets applied in this case says to align the label text left and to float it left as well. (Originally <label> was floated right and its text was right-aligned.)

    Why 640 pixels? Because that is the width (the “breakpoint”) at which Foundation changes the page layout for elements that have a medium- class. (There's another one at 1024 pixels for large-.)

    This is how it looks:


    Responsive form - medium/large


    Responsive form - small

    Open it up in a new tab and see how it behaves when you change the width of your browser window.

    Labels inside inputs

    To put the labels inside the inputs, let's just take our first alignment example and remove the labels. Then for each input, we'll add a placeholder attribute that contain the label text:

    Here's how that looks:

    Open in a new tab

    It's nice and clean, but once you start typing in an input, the label disappears, which can be problematic. And the lack of labels is a real problem from an accessibility perspective—screen readers typically don’t read placeholders like they do labels.

    What lots of sites do is have regular labels and use the placeholder attribute to show you the kind of thing you're meant to enter in each input. Freckle, the time-tracking app, does this to good effect:

    Freckle signup form


    That will do for now, I think. In the next post, I'll be showing you how to group inputs. I'll also show you all the different types of inputs that you can use.

    Make sure you get it by subscribing to the feed. Or better still, by signing up for my newsletter below.

    This is really just the tip of the iceberg when it comes to what you can do with HTML prototyping. Livetyping, my HTML prototyping course for UXers, will teach you how to do tons more things like this, including more form stuff, drag and drop, animation, and more. You should check it out.

    And if you like stuff like this, you should sign up for my newsletter:

    Sign up and get a free sample lesson by email

  • The Four Minute Prototype: Adding Interactivity

    In my last post, I showed you how to prototype a fairly simple web page (with responsiveness baked in!). This time, I'm going to show you how to add some interactive stuff to the page.

    What we're going to do is to take our existing, static page and add a contact request form. What's interactive about a form though? Well, this one will use the selection-dependent inputs pattern—it will have a drop-down list where you can choose how you want to be contacted, and the form changes depending on what you select.

    Where the form will live

    The first thing we need to do is to add a new <div> with the right Foundation classes to hold the form. We want to put it in that right column, right above the ads. Currently, that piece of HTML looks like this:

    The way we've set it up is so that the ads get hidden when we're on a small (smartphone-sized) screen. But we don't want our form to get hidden. What we need to do is nest another Foundation row/column structure in here so that we have two rows (each of which takes up all 12 of the available columns).

    And we move the hide-for-small class from the container (large-3 columns) <div> to the row that contains the ads:

    If you open this up in your browser you'll see the placeholder text above the ads:

    Placeholder text, desktop size

    And if you resize the window down to smartphone width, you'll see that the ads disappear but the placeholder text doesn't:

    Placeholder text, phone size

    So far, so good.

    Now we can get on with the actual work—adding the form. First, let's replace that placeholder paragraph (the one in the <p> tags) with some introductory text. And right after that, we'll throw in a drop-down (a <select> element containing <option> elements) that lets the user choose how they want to be contacted.

    Notice that I've wrapped the <select> in a <form> with a class of custom. This tells Foundation to use its own styling for the select instead of the standard look. This means it matches the other form elements we're going to be adding.

    And there's also a horizontal rule (<hr/>) to separate the form from the ads:

    We also need a bit of CSS:

    The first rule here styles the "Contact me via…" label that is the first item in the drop-down. (If you look in the HTML, you'll see that the first <option> has a class, which is what we use in this rule.) This fake option means that nothing is selected by default. Which is A Good Thing.

    The second rule just adds a bit of top padding to the intro text.

    If you open it in a browser now, you'll see we have a drop-down list with the right options:

    Non-functional drop-down

    But it doesn't do anything yet. The next thing we need to do is add the forms. We actually need three forms, but we'll make it so that only one is visible at any one time. So right after the <select>, add the first form, like this:

    This is just a <form> element containing a bunch of <label>s and <input>s. A few things to note though:

    • The <form> has a class of hbd. We'll be adding a CSS rule in a minute to hide this by default. (And soon, we'll add a little bit of Javascript to show the right form depending on what you select in the drop-down.)
    • The first two <input>s have a type of email. On the desktop, this is exactly the same as an <input> with a type of text. But on iOS (and Android too, I believe), when you tap on the <input>, you get an email-specific keyboard layout, with @ and period keys, but no space bar.
    • The last two <input>s are the Submit and Cancel buttons. The first one has a type of submit. This is a special kind of button that tells the browser to send the contents of the form to the server. Here, it's just a prototype—we're not sending anything anywhere. But it's better to do it the "right" way.
    • The buttons have classes to give them the right size (small) and to indicate which one is the primary action and which one is secondary (secondary for Cancel). And I've used Foundation's column classes to make them (together) the same width as the <input>s. And I've made the primary action button a bit wider than the secondary one.

    Which looks like this:

    Email form

    Now let's add the other two forms. Add this right after the form we just added:

    These are pretty similar to the first form, except for a couple of things:

    • These both have a class of custom. Without this, the <select> wouldn't get the nice Foundation styling.
    • In both forms, the phone number <input> gets a type of tel. Like the email <input> we saw before, this changes the keyboard layout on mobile, this time to a numeric keypad.
    • I've used the names of the mobile providers where I live for the SMS form. If you like, you can use your local providers instead.

    But now if you look at the page, all three forms are visible. Let's add some CSS to hide them all:

    This rule applies to elements with that hbd class, which we added to all three forms. Now if you check the page, you shouldn't see any forms.

    The only thing left to do now is add a little tiny bit of Javascript to show the right form when you select something in the drop-down. First we need to create a file to contain our Javascript and link to from index.html.

    Just like we did with the CSS file back when we were first creating the page, create a new file called 4min.js and save it in the js directory. Now add a second <script> element right after the existing one that pulls in the Foundation Javascript file, down towards the bottom of index.html so that it looks like this:

    Now in 4min.js, add this:

    This says "when the page finishes loading, run whatever code is inside the curly braces."

    So let's add some code in there to do what we want:

    This binds an event handler to the <select> with an ID of contact_select. It does a what to the what now?!?

    That's just fancy programmer-speak for "It tells jQuery* to watch the <select>, and when its value changes, to do something." (The value of the select changes when we select one of the options.)

    * jQuery is a library built on top of Javascript that makes lots of things much easier than trying to do them ourselves with just Javascript.

    (The bit between the slashes and asterisks is a comment. It's a good idea to include comments like this, so that other people can figure your code out, and so you can remember what it does when you come back to it later.)

    So what do we want it to do when the value changes? Well, that depends on what we select. A Javascript switch statement is perfect for this—it lets you specify what happens for a limited number of alternatives:

    Here, $(this) just means the element that the handler function applies to (the <select>). And val() is a function that tells us its value. The period in the middle says "For the thing before the period ($(this), the <select>), call this function that belongs to it (val()).

    Now we need to tell it what to do for each of the options. Let's start with email:

    This new bit says "If the value (that val() gave us) is 'email', find the element with an ID of email_opts, and show it (i.e., make it visible). Next, find the element with an ID of phone_opts and hide it. And the same for the one with an ID of sms_opts."

    Now we just do the same for the other two possible values:

    For each one, we just show the form we want and hide the others. Notice that we've also got a fourth case here called default.

    This is for when none of the others apply. Here, that only happens if the user clicks the "fake" "Contact me via…" option. If that happens, we just hide all three forms.

    And that's all there is to it. You can see the finished example here.

    If we wanted to flesh it out a bit more, we could wire up the buttons to actually do something. When the user clicks "Submit", we could hide the dropdown and the forms and replace them with a thank-you message. And maybe "Cancel" could clear the form. (More likely, we'd get rid of it altogether.)

    This is really just the tip of the iceberg when it comes to what you can do with HTML, CSS, and Javascript. Livetyping, my HTML prototyping course for UXers, will teach you how to do tons more things like this, including more form stuff (highlighting invalid values, for example), drag and drop, animation, and more. You should check it out.

    And if you like stuff like this, you should sign up for my newsletter:

    Sign up and get a free sample lesson by email

Page 1 / 6 »

Buy Livetyping

For you

Buy now: $249

For your team (up to ten people)

Buy now: $999

Get a free sample lesson by email

Buy Livetyping

For you

Buy now: $249

For your team (up to ten people)

Buy now: $999

Sign up for the newsletter and get all the code samples from the course for free!