Responsive web design and form fields

Love them or hate them, entry forms and form fields are a part of life. Sign up, registration, log in, purchase, update, contact us... the variety of forms we encounter online today are endless.

As the prevalence of online forms increases, so do the variety of devices people are using to view and complete online forms. From desktop devices to iPhones, iPads, Android devices and Wii browsers it is becoming increasingly important to ensure that online forms can be easily completed from any device.

I was reminded once again of the importance of multi-device testing when developing forms and form fields  last month when testing (just prior to launch...) a simple online comment submission form. The page we had developed had a fixed footer which was 'glued' to the bottom of the web page so visitors would always have access to important site links while they were browsing the site.

<screen shot 802 quits>

When testing an entry form from desktops this footer served as a nice graphical element and didn't interfere with the entry process. The problem was that when viewed on an iPad or iPhone, clicking on the text area entry element caused the entry pad to appear behind the fixed footer - rendering it impossible to complete the form. If we hadn't tested our form on an iPad we would have never discovered this bug.

After sorting out this issue (we simply modified the footer on the form page to be at the end of the page as opposed to fixed to the bottom of the window) I began searching for best practices for form field management across multiple devices. Creating a truly responsive and multi-device optimized form turns out to be quite challenging and is a topic for multiple blog posts.

For starters I want to focus on a single type of form field - date entry. Developers typically use some sort of JavaScript based date picker to 'enhance' the user experience by spawning a graphical calender on click (see example below).

The problem is that when this same code is used on a mobile device you end up seeing:

Clicking on the date field causes both the calendar graphic AND the input type pad on the iPhone to appear - rending them both unusable.

There are several possible solutions - ranging from complex to easy.

The complex and ideal solution is to take advantage of the fact that all mobile devices can now read HTML5 form field types - like date.

Creating an entry field for this example would use code something like:
<input type="date" name="pickme">
Clicking on a form field coded like this on an iPhone or iPad would cause the native date picker function to appear on the iPhone - giving you a nice input experience like this:

The problem is that not all browsers understand an entry field of type "date" so you have to allow for both HTML5 friendly browsers and those that aren't. This requires using some more Javascript wizardy and writing a function to cause either the native date picker or our fancy graphical date picker to appear depending on the device.

It turns out there is another simpler solution. We can simply add the "readonly" attribute to the example we first encountered. Adding this attribute makes the iPhone keypad stay hidden, while the graphical calendar appears.

The result is shown below:

Because I like my graphical date picker better than the native iPhone date picker, this is my preferred solution.

Next time you are using your iPad or iPhone to enter dates (hotel reservations or airline bookings are my favorite test cases) pay attention to the behavior of the date fields. You'll immediately be able to tell if the developers were thinking responsive when they put together the code.

Next topic - optimized number entry fields.

Happy coding.

1 comment:

  1. Great post I would like to thank you for the efforts you have made in writing this interesting and knowledgeable article. responsive web development