Telerik blogs

I think it's entirely fair to say that one of the least enjoyable activities on a web page is filling out a form. What's your name? Day Time Phone Number? Evening Phone Number? Work Phone Number? Mobile Phone Number? Who has that many phone numbers anyway?!

Forms Are Traumatic

Forms always represent some amount of suffering for everyone involved - both developer and user. Nobody escapes unscathed.

The Developer's Plight: Validation

For developers, forms represent one of the most complex challenges in web development. On the surface, they seem really simple: collect some required data from the user. In reality, they represent the mixture of UI and very complex logic that we refer to simply as "validation".

Consider what's involved in validating someone's birthdate.

  • Is the field empty?
  • Is the value a valid date?
  • What's the minimum age for filling out this form? Are we going to accept a birthdate that makes someone an infant?
  • Conversly, will we accept values that make someone father time? What do you do if someone decides they were born in 1776?

That's just one field. Your form may have a dozen. If you are collecting a lot of data (i.e. employment application, income tax return), you will be building quite possibly the most complex of applications that a developer can be asked to create.

The User's Plight: Fear Of Commitment

For the user, a form represents a formal (no pun intended) commitment of their time and energy in a very labor intensive process. It's not very likely that a user will land on your site hoping you will ask them to please "fill this out".

The situation gets even bleaker on mobile thanks to tiny screens. Forms are already a tedious task and mobile requires someone to complete that same task on an exponentially reduced scale, with the keyboard obscuring half the screen. This is the breeding ground for something I like to call "Form Fury".

Form Fury

Form Fury is similar to "Road Rage" and is when your form only succeeds in making a user bail on your site whilst dropping explitives. You have one shot at getting the user to complete your form, so make it count. Here are 4 ways you can eliminate Form Fury.

1. All Fields Should Be Required Fields

No user has every looked at a form and said "I really wish there were more fields for me to fill out". If you don't need the data, then don't ask for it.

Consider this form from a very popular company's website.

You won't know it until you hit submit, but out of all of those fields on the top third of that form, the only required ones are:

  • Title
  • First Name
  • Last Name
  • Gender
  • DOB
  • Address
  • City
  • State
  • Home Phone
  • Email

That's a total of 10 out of 19 fields. That means nearly half of this form is unecessary.

Of course, there are always extenuating circumstances requiring you to offer optional fields to the user. You may have legal requirements or other valid justification. However, a good rule of thumb is to give the user the shortest and quickest route to successful form completion, and that means eliminating any optional fields.

2. Use Positive Reinforcement

As developers, we tend to think of validation as being only negative. Bright red errors with exclamation points. Remember getting that paper back in school all marked up in red ink? That's not an enjoyable way to receive criticism.

It's time to rethink the validation feedback loop.

What if forms focused on telling you what you did right? I was filling out a form the other night and I noticed that as I entered a value, the form validated it and gave me a green checkmark letting me know that the value was legit.

Getting immediate feedback let me know that I didn't just waste my time filling in a value that the form was going to clear out after validation failed. Positive reinforcement boosts confidence and encourages users to complete the form.

3. Be 100% Sure The Form Is Correct Before Submit

One of the frustrating things about validation is that you have to do it twice: once on the client and once on the server. However, there are only two types of people who should ever hit your server validation:

  1. People without JavaScript
  2. Hackers (in the bad sense of the word)

For most of us, this means nobody.

While many fields are easily if not verbosely validated on the client, some rules can only be validated by the backend system. For instance, you may have a registration system that has a unique constraint on email addresses. The only way to know if the value the user entered is available is to check for it on the server. You don't have to submit the form to do that.

Ajax is a wonderful invention of modern man and is perfectly suited for this task. When a user enters a value that needs server validation, go ahead and do that validation when the fields blurs via a simple HTTP GET in the background.

Try the form below. The system requires the Username and Email values to be unique in the system. Try entering testuser as the Username or testuser@testuser.com as the Password.

This is just being a good steward of your user's time. If you don't do the validation for them while they are filling out the form, you are asking them to take on the burden of the work by submitting the form so they can find out that they did it wrong.

4. Use Input Types Carefully

Too often I visit forms on my mobile device and they ask for an email address, but the @ symbol is nowhere to be found on my keyboard. Remember that browsers will use a text type input anyway if they don't support the input type so you have nothing to lose!

On the desktop, we largely ignore input types and fallback to widgets instead. Input type support has been shoddy, and where it is implemented, it's usually not very attractive. Have a look at a date picker in Chrome compared to a widget date picker.

I don't know about you, but I have never been a fan of browser styles. I know that with some CSS I can style the Chrome Date Picker, but I would rather use my widget which already looks good.

Now look at the native picker on my iPhone.

On iOS, the story is flipped! I want the native date picker, not the widget. So how do we make these two world live in harmony?

When using Kendo UI Widgets, we can use Brandon Satrom's excellent Forms Pollyfill.

Using A Forms Pollyfill

The Forms Pollyfill will by default use native controls for input types where they are supported and will pollyfill with Kendo UI JavaScript widgets where they are not. If you want to always use widgets, it will automatically match input types to the proper corresponding widget, even if the browser natively supports the input type.

The pollyfill also allows you to specify that you always want to use native mobile widgets where supported. This combination allows you to get widgets on your desktop forms, and native controls on mobile.

Oh HTML Form; Your Name Is Pain

But it doesn't have to be - at least for your user. Granted, many of the things here are going to require more work on your part, and we've already established that forms are not terribly easy to build. However, having a form that is minimal, accurate and gives encouraging feedback will go a long way towards improving the number of users who just land on your form and roll their eyes, vs the number who end up your database.

You can download a GPLv3 copy of Kendo UI and grab the Forms Pollyfill from GitHub.


Burke Holland is the Director of Developer Relations at Telerik
About the Author

Burke Holland

Burke Holland is a web developer living in Nashville, TN and was the Director of Developer Relations at Progress. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke worked for Progress as a Developer Advocate focusing on Kendo UI.

Comments

Comments are disabled in preview mode.