html5

Working With HTML5 Forms

html5I’m going to start a series of tutorials over the next weeks and months about HTML5. A lot of web developers are not leveraging HTML5 for a variety of reasons. We have been so trained over the past decade to embrace XHTML 1.0 that we’ve avoided the new DOCTYPE as something new that needs to be learned.

The good news is, XHTML is still valid in HTML5. The better news is now you have much more fun toys to play with.

Admittedly, I was one of those people who delayed jumping on the HTML5 bandwagon. In the past few months, however, that has changed. This series of articles will hopefully help the web developer to rethink how they develop on the web. Much of the stuff I’m about to talk about does not require a lot of extra heavy lifting.

Use the Correct DOCTYPE

Just as a remedial exercise of laying out the premise, your HTML must have the correct DOCTYPE. In XHTML 1.0/1.1, the first line of the HTML page had to be something along these lines

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

That’s relatively confusing, huh? Makes you want to go drink spoiled milk with lumpy crud in it just because it’s tasty, right?

To declare a web page as HTML5, you do the same thing you did with the old 1990s era HTML4, before the web embarked on the XHTML idea of doing work. HTML5 is, essentially, a reset to HTML4 with all kinds of additional goodness. You simply start a web document with:

<!DOCTYPE html>

A lot easier, right? Heck, you can type that in your sleep once you’ve typed it enough (I know you already do that with your drivers license and credit card numbers).

Form Field Types

With all that remedial knowledge in play, let’s take a look at HTML5 forms. The importance of this might be lost if the only thing you think about, when building HTML pages, are computer browsers. But if you recognize we live in a mobile world, you own an Android or iPhone and have tried to do any kind of form filling on those devices, then you might start to realize the importance of field types.

In XHTML, you might have a form that looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<form action="" method="post">
    <label for="name">Full Name:
        <input type="text" name="name" id="name" />
    </label>

    <label for="phone">Phone Number:
        <input type="text" name="phone" id="phone" />
    </label>

    <label for="email">Email Address:
        <input type="text" name="email" id="email" />
    </label>

    <label for="website">Web URL:
        <input type="text" name="website" id="website" />
    </label>
</form>

In XHTML, we didn’t have a lot of field types. We had text (which everything above is), hidden, password (*’s entered in the input), checkboxes and radio buttons. You could add other types of inputs (That don’t use the <input> tag and include <select> and <textarea>.

This works in HTML5 too, but you’re limited by one default keyboard – which is fine, but fairly bland and not at all contextual.

What would happen if we changed that form to use different field types? HTML5 support a bunch. The four fields above can more sematically have the following types, in order: text, tel, email, url.

Watch what happens on the iPhone when the HTML looks like this (Android is similar):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<form action="" method="post">
    <label for="name">Full Name:
        <input type="text" name="name" id="name" />
    </label>

    <label for="phone">Phone Number:
        <input type="tel" name="phone" id="phone" />
    </label>

    <label for="email">Email Address:
        <input type="email" name="email" id="email" />
    </label>

    <label for="website">Web URL:
        <input type="url" name="website" id="website" />
    </label>
</form>

For a standard text field, your keyboard will look like this:

iOS "text" field
iOS “text” field

For a phone number, using the tel type:
iOS "tel" field
iOS “tel” field

For an email address, using the email type:
iOS "email" field
iOS “email” field

And for a URL field using the url type:
iOS "url" field
iOS “url” field

There are, of course, other field types that I’m not going to go into too much here. But to whet your appetite, there is a color type that attaches to a color picker. There’s a date type that binds to a date picker. There’s even a range type which binds to a slider picker.

Important: Not all browsers support all types. In the event that a browser does not support a specific type, it falls back to standard text type and you can bind other external Javascript to make the same functionality happen.

Reference: All HTML5 field types with browser support.

Form Field Placeholder

Another useful feature is the placeholder. In XHTML, we might have a form that looks like this:

1
2
3
<form action="" method="post">
    <input type="search" name="search" id="search" value="Search for your term" />
</form>

This would create a simple field that would be pre-populated with “Search for your term”. From a usability standpoint, when a user brings that field into focus, the text is supposed to disappear and allow the typing of a search term. If nothing is typed and the focus is switched to a different element, then that phrase should re-appear.

XHTML Placeholder Text
XHTML Placeholder Text

You can’t do this without a little Javascript help (I like jQuery for this) – which is outside the scope of this article. But in HTML5, you only have to add placeholder="Search for your term". Different browsers handle this slightly different, but they all insert some dummy text that can be replaced by the user’s own input.

1
2
3
<form action="" method="post">
    <input type="text" name="search" id="search" placeholder="Search for your term" />
</form>
HTML5 Placeholder Attribute
On iOS, the Placeholder attribute plays light grey text in the field that is replaced as the user types.

Form Field Validation

Validation is such a tedious thing for developers. You can do all kinds of ugly things to make sure fields that are required actually have a value or that a field meets a certain criteria (for instance, a zip code field having 5 numeric characters to match the U.S. format).

In terms of requiring a field, it’s as simple as adding required to the input tag. In HTML5, you don’t have to have an explicit value for an attribute as you do in XHTML. You can if you want, type <input type="text" name="zip" required="required" /> but this is a habit that does not need muscle exercise. Just use:

1
2
3
4
<form action="" method="post">
    <input type="text" name="zip" required />
    <input type="submit" />
</form>

Firefox "Required" Error Bubble
Firefox “Required” Error Bubble
Chrome "Required" Error Bubble
Chrome “Required” Error Bubble
Browsers handle this differently but they all pop up a notice if the field isn’t populated on submission. On the right, you’ll see how Chrome and Firefox handle this respectively.

Let’s validate that zip code field, though, because this is where HTML5 really shines.

Using the pattern attribute, you can designate a regular expression to match formatting needs. If we want to limit the zip field to 5 numbers (most simplistic example – it could also have a potential extra dash and 4 numbers too), you might use this HTML:

1
2
3
4
<form action="" method="post">
    <input type="text" name="zip" required pattern="\d{5}" />
    <input type="submit" />
</form>

You can find a list of helpful regexes at html5pattern.com.

Summary

There’s a lot more we could get into here, but the point of this exercise is to prove that it doesn’t take much to start using HTML5 in development. Doing so will also push the boundaries of what has been more commonly possible and the barrier to entry is so low that I struggle to find a reason why HTML5 should not be used more commonly.

I’ll have more of these in the days and weeks to come so stay tuned, subscribe to the RSS feed and, as always, if you’re interested in hiring me for a full time gig or contract basis, please reach out to me. I am actively looking.

Read More

What's the Point?

The Most Expensive Question

The most expensive question you can ask a consultant is, “What else do you recommend?”

This seems like a simple thing. At least if you’re a consultant. Potential clients approach you and they know they need something done. They may have a good idea of what that something is and they may even be able to provide a wish list of things to get done. However, for all that preparedness they ruin it all for their budget by asking, “What else do you recommend?”

Now some consultants do business this way. They are paid to help the client understand their needs and map out a solution. However, understand that this is a very expensive proposition in most cases. Hours of meetings and calls and emails exchanged back and forth can go into defining the scope, as we call it.

What's the Point?
Image by skipnclick on Flickr

We’ll usually approach the client with open ended questions to get a high level view of the client project.

  • What are you trying to accomplish?
  • What is your ideal end result?
  • What problems are you trying to solve?

Once I get a broad picture of the project, I can schedule conference calls with relevant parties to discuss each answer to each question. This is for the purpose of defining the details. Each call could take an hour or more and might span more than one call. This is all billable.

At the end of these series of calls/meetings, we still might have a bunch of email exchanging to do. This is even before we begin doing actual work. You can easily rack up thousands of dollars during this process.

The next phase of the project involves deliverables. Having defined all the scope details, the project probably goes on Basecamp or some similar project management service. Most consultants have a “floor” that is a minimum threshhold. I know people who will not work on projects below $50k. Others won’t work below $25k.

At this point, if the client is still not mentally committed to a path, there can be a lot of potential for “Scope creep”. That is, when the scope of the project slowly expands to incorporate other areas not defined in the agreed upon scope. Good consultants see this coming and can either agree to it pro-bono (bad policy), agree to it as an added service/feature (billable) or convince the client the idea is bad (it might be).

Scope creep is rarely good for the client, though. You’re definitely going to get billed for it when working with most consultants.

Bringing this full circle, however, you can mitigate your costs when dealing with consultants by having a really firm idea as to what and why you want to do from a high level. Leave the details to the consultant to work out, but strategically know where you’re going. If you can define the scope (wireframes are always helpful), you can lessen your cost even more.

The more we as consultants have to do, the more you’ll pay. We don’t mind helping, but if money is an issue, be careful and come prepared.

And for God’s sake, don’t ask “What else do you recommend?” We can make a mint off that question.

Read More