Mobile site testing overview (Mobilizing websites with responsive design and HTML5 part 9)

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

After your mobile site starts look complete in a development browser (e.g. desktop Firefox+Firebug combo) then it is time to begin testing it in actual mobile browsers. This blog post gives you introduction and some general tips for mobile browser testing. Each platform (iOS, Android, others) are dealt separately in the future blog posts, so don’t forget to follow.

1. The micro battle field of browser vendors

Like with desktop where you test your site across browsers you need to test the mobile site in different mobile browsers. The testing is important because mobile browsers use different browser engines and different engine versions. Thus, sometimes output differences are expected and you need to iron out the ugliest issues.

The major mobile browser engines are WebKit on Safari/Android, Opera (Presto) and Firefox (Gecko). You luckily could say that mobile Internet Explorer’s market share is so minor that you might want to bother for it currently. Microsoft is constantly improving its mobile browser, but currently it is not in a state to match the competition in feature wise and we’ll look forward to see what Windows Phone 8 will give us.

There exist two popular after market browser (Opera Mini, Firefox Mobile) with their own engines. Opera Mini is a thin client browser and special considerations with e.g. Javascript interaction must be followed to make the sites behave well. Firefox Mobile can be installed on Android devices. There exist several “browsers” in app stores for iOS and Android, but they are simply wrappers around the native operating system WebKit component and do not contribute significantly to HTML rendering bits. Opera Mini, being the most popular mobile browser in the world by “shipped devices” count is preferred in developing countries due to capability to run low end phones, or anything having CPU and battery power. Don’t forget to test on these also.

The good news are that if the mobile browser support CSS3 media queries, as used in the mobilization strategy of this tutorial, then they are likely to have very good support for HTML5, CSS3 and other modern goodies. The fixing and workaround work found during the testing is usually less than what it takes to make the site run older Internet Explorer.

If you need to define compatibility list of browsers e.g. for an offer I recommend use this jQuery Mobile mobile browser grading table. It gives you an overview how “good” mobile browsers are.

2. Accessing different mobile browsers on devices and simulators

If you aren’t a mobile developer you might not have access to a real test device repository. Luckily, the simulators by the mobile vendor themselves are pretty good nowadays and you don’t need to be physically able to access the every device out there.

It is desirable to minimally have one iOS and/or one Android device for testing. If you are targeting popular iOS devices (iPhone, iPad) it’s pretty hard to get around the fact that you need to get a Mac. Apple tools are only for Apple computers, like Microsoft mobile tools are only for the latest Windows 7.

There exist generic remote testing services for mobile phones, but they often are costly and not a substitute for the real thing.

3. No shortcuts to testing happiness

Warning: Do not use browser+<iframe>-based “mobile simulator” or whatever crap web search throws on you.

These so called simulators are usually pitiful attempts to grab web traffic for ad money without actually adding any value to testing. Running <iframe> based simulator in your web browser is simply the same as opening the page in your desktop web browser directly, with the window size shrink.

Shortening URLs

Typing on the mobile devices is cumbersome. Use URL shortening services like to shorten your test page URLs, so you can type them in faster on touch screen or keypad.

4. Desktop web browser testing

If you need to alter HTML code or main CSS when mobilizing a legacy website you still want to see that your HTML changes did not introduce issues on the desktop browsers, especially older and problematic Internet Explorers. Here are some desktop testing resources, but I’d hope to hear of more pointers and services so please comment.

5. Internet Explorer virtual machines

How to automatize the installation all Internet Explorers on OSX and Linux using VirtualBox and one liner shell script.

6. Remote page rendering services

Please refer to this Smashing Magazine article for list of cross browsing testing tools.

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Zoom-on-rotate fix for WebKit mobile browsers (Mobilizing websites with responsive design and HTML5 part 8)

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

After adding meta viewport tag for your mobile site its width is properly formatted for mobile browsers. However, there exists a common glitch you should be aware of.

On iOS devices, and on some Android devices, the mobile browser re-zooms the web page when the device orientation changes. The browser applies heuristics and try to determine a new zoom level after the rotation, but sometimes the result is not desirable. When you rotate from the portrait mode to the landscape mode, the page zooms in too much.

In our case, the project client specifically requested to disable this little feature if possible, as it was irritating the test users on iPad devices.

This can be worked around by resetting the viewport with Javascript after the orientation changes.

An example code going into HTML <head> section:


    Don't break scale on iPad rotate.

    By default iPad re-zooms the page when the device orientation changes.
    The heuristics here do not work always; our page got zoomed in
    though it should be max zoomed out.

    This snippet fixes the situation so that you can still zoom in, but when
    the device is rotated the scale is restored.

<script type="text/javascript">
(function(doc) {

    var addEvent = 'addEventListener',
        type = 'gesturestart',
        qsa = 'querySelectorAll',
        scales = [1, 1],
        meta = qsa in doc ? doc[qsa]('meta[name=viewport]') : [];

    function fix() {
        meta.content = 'width=device-width,minimum-scale=' + scales[0] + ',maximum-scale=' + scales[1];
        doc.removeEventListener(type, fix, true);

    if ((meta = meta[meta.length - 1]) && addEvent in doc) {
        scales = [.25, 1.6];
        doc[addEvent](type, fix, true);


Please edit the scales part of the code for the desired min and max scaling level.

Note: Dynamic viewport manipulation is badly supported on older Android devices and contains many pitfalls.

1. More info

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Improving mobile site form usability with HTML5 (Mobilizing websites with responsive design and HTML5 part 7)

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

It is cumbersome to enter any longer input on mobile devices with “thumb typing”.

For better mobile user experience you want to optimize form inputs to have minimal amount of presses.  Also, the form layout might need adjustments to cope with the smaller screen size and harder-to-read text.

In the case we describe in this tutorial, we use mobile.css to override the default desktop form styles so that the form renders and acts better on small screens and touch devices.

1. Making forms more mobile friendly

Some useful mobile enhancements include

  • Make text bigger: Text and <input> field default size is bigger, so that you don’t need to zoom in to read the label.
  • Use fixed width font on input fields: Fixed width fonts, like Courier, are cleaner for reading narrow letters, like i,1,l on small input fields. It may look ugly, but it’s minor usability win.
  • Only one column of form elements: There is only one column on <input> and no <form> elements are horizontally on the same row, so that there is as much as possible horizontal text line length to be consumed for <input> fields. Exception: make sure that checkbox control + label still remain on the same row.
  • Expand controls to full screen width: easier to hit with touch and there is enough space to read the input field values
  • More padding and margin for form controls to help touch input by avoiding accidentally presses
  • Use field type specific HTML5 inputs: more below
  • Use Javascript to enhance form input logic: e.g. automatically choose sane defaults based on other field values or submit the form when it’s completed, so that the user spends less time to enter the data on the form
  • Use geolocation to pre-fill address fields and filter out lists of unnecessary choices

Here are some example mobile.css styles which we used for mobilizing forms desktop forms:

 * Form fixes

/* Only one input per row */
select, input, button {
   display: block;
   margin-bottom: 1em;
   max-width: 80%;
   font-size: 120%;

/* Follow the size of input elements */
label {
   font-size: 120%;

/* Checkbox is still inline */
input[type=checkbox] {
    display: inline;

How forms looked before fix:

How forms looked after the fix:

2. Short-cutting unnecessary user choices

In our project we also applied a Javascript snippet which will automatically submit the form when the final <select> input choice has been made. Thus, the user does not need to pan around to press the form submit button unnecessarily: this way we decrease the amount of presses needed to proceed with the form.

The Javascript code for the form autosubmission:

<script type="text/javascript">

  // Automatically push form forward when the selection has been
  // made in the selection list
  function onSelect() {
     var form = document.getElementById("IdPList");

     if(form) {

  // Bind select event handler
  function init() {
 var select;

     // Remember selection permanently and bypass the WAYF service from now on.
     select = document.getElementById("select-idp");

     if(select) {
         select.addEventListener("change", onSelect);

     // Select: In order to access the resource you must authenticate yourself.
     select = document.getElementById("userIdPSelection");

     if(select) {
         select.addEventListener("change", onSelect);

  //window.addEventListener("DOMContentLoaded", init);
  window.addEventListener("load", init);

3. HTML5 <input> element enhancements

It is also recommended to convert <input type=text> fields for HTML5 specific versions. Note that this change is backward compatible, as the legacy browsers will fallback to normal text input. Even big sites like are already using HTML5 inputs. With specific HTML5 input types a mobile browser can open a field type specific touch keyboard. E.g. if you are asking for a phone number the opened keyboard is phone keypad instead of QWERTY touch keyboard.

Different <input> types already exists for

  • Telephone number
  • Email
  • IP address
  • URL
  • Number
  • Search
  • Time
  • Native autocomplete
  • etc.

4. Geolocation

You can use HTML5 geolocation API to determine the city / address of the user and pre-fill form values based on this. This is handy e.g. on a use cases like where the user is selecting city to choose a movie theaters.

5. jQuery Mobile

jQuery Mobile is a theming framework for mobile sites. It includes some touch friendly Javascript widgets to enhance existing mobile experience. However there widgets are more theming side of the things and the necessary user interaction can be reached even without jQuery Mobile.

6. File submissions

iOS devices, like iPhone and iPad, do not support <input type=file> file submissions (iOS 5.0). Android devices do and other mobile phones as well. However, the user experience of selecting files on these devices is not great and you might want to create an app instead.

7. More information


\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Resizing images in responsive mobile design (Mobilizing websites with responsive design and HTML5 part 6)

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

When you change your layout dynamically you need to re-fit media elements to match the new layout dimensions. There exist three basic techniques dealing with images in responsive designs

  • Resizing images using CSS only  – in this case the clients download the full image payload regardless of the image size and image visible sizes are adjusted using CSS styles
  • Co-operative image resizer on the front end web server: when HTML is written from a template the image tags are written in such a way that <img src> attribute points to a resized image. The resizer rewrites image to match the vrowser screen dimensions. This is done e.g. in Web and Mobile for Plone CMS.
  • Independent image resizer on the front end web server: Javascript + server-side stub component is used to resize the images. The server-side component does not depend on the rest of the front-end server system, thus making the front end code less complex. A client-side Javascript scans HTML DOM tree for <img> tags and rewrites <img src> to go through the resizer. For example Adaptive Images (below) is this kind of a solution. Alternatively, an independent image resizer can be a part of the middleware stack (e.g. WSGI in Python)

In this blog post we mostly discuss about the simplest approach: resizing images using CSS only.

1. Resizing images using pure CSS

If your responsive layout includes images, as contentish or style elements, they might not work well with small screens as is. You can fix the situation by resizing the images dynamically with CSS.

In our example case the page has only one image: the site logo. If viewed in a mobile browser using desktop CSS the logo might be too small or too large. Thus

  • We remove any hard-coded width and height values for the <img> in HTML
  • We apply CSS style for the image width where the image takes width from the screen width as percents, but still has max-width set in pixels so that tablet devices with more screen estate don’t scale the image too much

Related CSS:

/* Logo must not appear too large on mobile */
#portal-logo img {
   width: 33%;
   max-width: 180px;

Before fix:

After fix:

2. Server-side image resizing solutions

You can also resize images dynamically on the server-side, so that mobile browsers load the reduced size version, saving the precious mobile bandwidth. However, this adds additional server-side component to the mix, increasing the complexity of the solution and especially when dealing with legacy sites consider whether the improved user experience is enough to balance this trade-off.

Also, the dynamic image resizer component is easily subject to denial of service attack because the HTTP responses it serve are usually slow and computationally intensive. If you decide to use one of these components be sure you are aware of these implications.

You don’t need to change the server-side generated HTML to achieve the dynamic images sizes. There exist a technology neutral solutions relying on the client-side Javascript and additional serve-side proxy component.

Adaptive Images is one of server-side image resizing solutions based on Javascript and minimal server-side PHP script. It operates in independent manner and adheres the contemporary best practices of HTML5 and responsive web designs.

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+