Mobile web page development
If you have to develop web pages for mobile phones you'll soon find out that developing mobile web pages is a far cry from what you thought it'd be. Don't believe the promises. Creating web pages for mobile phones is like developing web pages for all versions of Internet Explorer.
Why mobile web development is a challenge
The resons mobile page development is so challenging are:
- Mobile phones use many more browser engines than web browsers (Opera, OpenWave, Netfront and proprietary ones)
- Mobile phones come in many different screen widths (120, 160, 200, 240, 280, 320, 340 pixels or more)
- The phones' default font size may vary
- Mobile phone browser engines use a subset of the HTML/CSS specification
- New browser engines appear every couple of months
- Nothing replaces real-life handset testing
These reasons are pretty self-explanatory. Needless to say that the different browser engines can render the same code differently as well. Welcome to the mobile world.
Best practices for mobile page development
I have found that mobile page web developers have to go back to 1990s-style web development practices in order to overcome the challenges above. I have tested the techniques below and found they work best across handsets. If you know another one, shoot me an email!
Use tables for styling
Don't even try to style forms or graphics next to multi-line paragraphs without using tables. To tame mobile phones tables are the most reliable option.
Example: Icon next to multi-line paragraph
<table>
<tr>
<td><img src="path/to/icon" width="x" height="y" alt="Descriptive alt text" /> </td>
<td>
<p><a href="#">Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos.
Etiam urna purus, dapibus non, auctor eu.</a></p>
<p><a href="#">More</a></p>
</td>
</tr>
</table>
Note the non-breaking space just after the image: This ensures that there is always at least on space between the image and the text. Some mobile phone handsets ignore all whitespace here which might look ugly.
Don't use lists
Some mobile phones (esp. by Motorola) apply a default padding to unordered and ordered lists which is not changeable by CSS. This requires either special treatment in the backend or - to my mind the simpler solution - a manual generation of any lists. So instead of a <ul> or <ol> tag, create the lists in your backend or by hand.
<p>1. First ordered list item</p> <p>2. Second ordered list item</p> <p>3. Third ordered list item</p> <p>4. Fourth ordered list item</p> <p>5. Fifth ordered list item</p>
Avoid drop-down controls
If you use a drop-down control on a 'real' web page you are done in three clicks: click the control, scroll to the entry, click the entry. Mobile phones offer solutions which vary a lot, sometimes requiring many more clicks: click the control (new window opens), click as many times as you need to scroll, click entry (new window closes).
To make this experience as painless to users as possible I advise you to avoid drop-downs wherever you can.
- Replace drop-downs for just two options with radio buttons
- Replace drop-downs for more options which do not affect a form result by simple paragraphs
- If you need to use drop-downs, place the most likely or common option on the top or preselect it
Forms on mobile pages
Forms are the most complicated part of a mobile web page, not because they are so hard to code but because mobile phones render them so differently. I've seen handsets which automatically transform any drop-down list into a super-wide drop-down list of radio-buttons, and there's almost nothing you can do about it (Sony Ericsson).
Here are some tips on how to tame forms for mobile phone pages:
- Use an invisible display table to align and group form controls
- Always wrap the form's display table with the <form> tag (see example below)
- Make all spaces in labels non-breakable. Otherwise some mobiles wrap them even if they have enough space to display them on a single line
- Add another non-breaking space at the end of the widest label to push the second column (which contains the form controls) away from the labels
- Always use the 'size' attribute to control the text input's width. Modify it according to the handset's display width
- Always use an id attribute on text inputs because you need to style its background colour for Motorola handsets (these phones do not display the input when it's not active)
- When you have a link text next to a form control, separate all words with non-breaking spaces except at places where you want them to break. These breaks are required for some phones with smaller screen sizes
- Tame Sony Ericsson's super-wide drop-down radio button list by specifying a width for the form wrapping the table
Example:
<form id="sampleForm" action="...">
<table>
<tr>
<th><label for="firstControl">Sample label:</label></th>
<td>
<input id="firstControl" size="4" name="firstControl" type="text" /><br />
<a href="#">This is a link</a>
</td>
</tr>
<tr>
<th><label for="secondControl">Long label name :</label></th>
<td>
<input id="secondControl" size="4" name="secondControl" type="text" />
</td>
</tr>
</table>
</form>
Be prepared to compromise
You can spend hours in mobile page testing. And when you come across handest number 25 and you have to tweak some CSS rule, how would you know that the previous 24 handsets still render the same?
So at some point you must compromise, accept wrapping labels or default fonts which are too large. The variety of handsets, browsers and screen sizes is just too big. If your client has ever done some testing themselves they'll understand.
How to test mobile web pages
To test mobile web pages nothing beats the test with physical phones. But if you want to do a preliminary test, Opera is a good browser. Click View | Small Screen or hit Shift-F11 to display web pages encoded with the attribute media="handheld" in the style sheet link. Unlinke Firefox, Opera stays in this mode after you hit refresh.
Optimise your handset testing
You will have to go through a lot of handsets to test your mobile web pages. Hence it makes sense to upload your pages to a web address which is as short as possible because you'll have to input this address into every handset.
Upload to an address like 'www.mydomain.com/t/i.xhtml' which you would normally create as 'www.mydomain.com/test/index.xhtml'. The first solution saves you a couple of characters and many more clicks.
The file 'i.xhmtl' then contains links to all pages you test. This way you just need to specify this single file and can reach all your pages from there and use the 'back' function of the phone to go back to the list.
Happy? Do you have feedback? Shoot me an email!