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.

Jquery sparkline does not work when loading remote HTML content

To speed the load time for a page on my site I use jquery to load a remote page that contains usage statistics and a usage chart.

By allowing the primary page to load first - and then loading the stats content separately I was able to dramatically reduce the primary page load time - improving user experience.

The page's initial design loaded the stats content in line and displayed one of the elements using sparkline.js:

class="sparkline" data-values="1,2,3"

The problem was that when I loaded this content using:
$(document).ready(function(){ $("#people-list").load("stats-source.asp");
The sparkline js wasn't applying to the remotely loaded content. The solution was to fire the sparkline JS again after the content was loaded: <script> $(document).ready(function(){ $( "#stats" ).load( "stats-source.asp", function() { // alert( "Load was performed." ); $('.sparkline').each(function(){ var $box = $(this).closest('.infobox'); var barColor = !$box.hasClass('infobox-dark') ? $box.css('color') : '#FFF'; $(this).sparkline('html', {tagValuesAttribute:'data-values', type: 'bar', barColor: barColor , chartRangeMin:$(this).data('min') || 0} ); }); }); }); </script>
By applying the sparkline js function after successful load, the sparkline appeared just fine on the HTML loaded sparkline data.
Happy coding.

Using jquery form with TinyMCE - form content does not submit

After struggling mightily with this problem I finally found the solution courtesy of Jerome Jaglale. TinyMCE is creating (behind the scenes) an iFrame to actually contain the human visible HTML rendered content. Unfortunately the form when submitted via JQuery Form sees on 'real' textarea - making it impossible to submit the HTML friendly user visible content. The solution was simply to add this line just after the form is assigned:

// bind form using 'ajaxForm'

$('form.form-horizontal').ajaxForm(options); 

//now update the 'real textarea' with the TinyMCE rendered content
$('form').bind('form-pre-serialize', function(e) {
    tinyMCE.triggerSave();
});

Worked like a charm! Original Post: http://jeromejaglale.com/doc/javascript/tinymce_jquery_ajax_form