Design Considerations

We've compiled a list of design consideration as a checklist for when you build your site.

Image Resizing

Header and other images within a mobile internet site need to be automatically resized to fit the width of the handset. mobileelements' Media Adapter to provide this functionality. It is recommended that images provided to the Media Adapter are at least 640px wide. This is due to the common upper limit on screen width resolution is about 320px (some handsets can be higher, but are less common in the market). We use 640px to future proof for new handsets.

Image Format

Certain handsets may only be able to render images of specific formats. For example, the Motorola T720g can render GIFs and some Bitmaps, however JPEGs, PNGs and TIFFs will simply fail. Again, the MediaAdapter takes care of this issue for you. Images will automatically be reformatted to the best format for the device. It is recommended that images provided to the Media Adapter are in JPEG or PNG format, as JPEG has the smallest file size which means it will be downloaded by the device the fastest, and PNG is a lossless format, so image quality is at its best.

Font Resizing

Fonts within a mobile internet site also need to be automatically resized to the best fit for the handset. This is where the Css Adapter comes in. As the documentation describes, it works by reading a CSS file and changing any "font-size" properties to the best fit font size based on the handset database information. It is recommended that standard body font size is set to 12px explicitly. This is the most common best fit handset font size.

Font Styling

As with image formatting, fonts too need to be styled in a manner to allow for maximum handset compatibility. Firstly, font sizing through CSS can be carried out by describing the font size by a pixel height (12px), percent height (150%), relative height (1.5em) or a text based value (x-large). It is recommended that the body or default font-size is described using pixel height, and all other fonts are described using relative height. This is due to maximum handset reach and compatibility with the Css Adapter. Secondly, font family (which font to use) support is different across different handsets. It is recommended that designers stick to standard fonts that are typically shipped with Windows. For font use within logos, it is recommended to display these as an image, instead of text.

Columns - Tables vs Divs

Support for both table layout and div tags with CSS aligning is very poor. This is a prime example of how difficult automatically adjusting for different handsets is for some design considerations. For a solution to this issue, it is recommended to contain mobile site layout designs to a single column. This column can still contain text alignment, but even this is poorly supported (for example, the handset with the highest amount of worldwide sales ever, the Motorola V3 series, still does not support aligned text entirely).

CSS Formating

95% of mobile internet capable handsets in the market currently support CSS in at least a limited set. As mentioned above however, even something as simple text alignment has limited support. It is recommended that CSS for formatting should be used for simple functions only, such as font size, font alignment, colors, padding and margins.

Background Images

As mentioned above, background image support is still moderate in today's mobile market. However, background color is well supported. It is recommended that designers only use background color behind the site's body or text sections, and not background images.

Animated GIFs

Animated GIF support is also moderate in today's mobile market. 5th Finger's "ImageSizer" dynamically resized animated gifs successfully. Unsupported handsets will only show the first frame of the animation. It is recommended that designers bare this in mind while designing mobile site animations, and make the first frame contain the most information.

Javascript

Javascript support varies widely at the moment. While devices like the iPhone or the G1 support the latest javascript, including XHR objects, they still only represent a small amount of mobile internet users. It is recommended that the mobile sites be developed as if no javascript is available at all.

Forms - images for form submission buttons

Input forms are supported by every mobile internet capable handset on the market. However one important capability in modern web sites is generally considered unavailable, that is javascript. This means that a lot of functionality needs to be reconsidered. For forms, images as submit buttons rely on javascript to submit the form. This means that submit buttons will only work on the mobile internet site using standard input submit buttons. It is recommended that the mobile site is designed with this restriction in mind.

Forms - dynamic drop down boxes

Dynamic drop down boxes are typically populated using javascript, and as stated above, javascript support is poor. To achieve dynamic drop downs, it is recommended that the drop downs are put on seperate pages with form submissions used to update the drop down on the server side.
Most phones also provide an easy way to navigate long select inputs. So don't be scared to contain too many select options.

Input Validation

In conventional web sites, javascript is also used for input validation and, mentioned above, javascript should be considered unavailable on the mobile web. Basic input validation is achieved using a different mechanism on the mobile web. Most handsets in the market support the CSS property "-wap-input format", which takes in a string similar to BNF to describe the expected input format for the text input box. It is recommended that input validation using "-wap-input-format" is considered by designers of mobile web forms. More information about its capabilities can be found at http://www.openmobilealliance.org/tech/affiliates/wap/wap-239-wcss-20011026-a.pdf (Section 19.2).

Redirection

Client side redirection on the mobile web is intermittent. Some handsets work, some show simple a blank screen, and others will prompt the user that the page is trying to redirect, or even show a link. It is recommended that instead of client side redirection, developers should use server side redirection (or server side includes) wherever possible.

Bullet Images

In typical lists (ul elements), it is often desired to use images for bullets. It is recommended that instead of lists, users just use standard line breaks for image lists, since the css support for "list-item-style" varies across devices.
Also, while we should typically resize all images on a page, bullets should not be resized. Since they are usually in line with font height, it is recommended to keep them at 12px high, and not pass them through the Media Adapter.

Page Size Limits

Although 3G is becoming more and more prevalent, current GPRS rates still make the user wait quite some time for pages to be downloaded. Page sizes should be under 10K per page including css, but excluding images.

Access Keys

Taken from w3c
In general, it cannot be assumed that input methods which consists of a (full) keyboard and a pointing device such as mouse are available in mobile devices. It is desirable that description for efficient use of input methods on mobile devices are provided in contents.
From this viewpoint, assigning access keys via "accesskey" attribute (for A, AREA, BUTTON, INPUT, LABEL, LEGEND and TEXTAREA elements) will be effective when it is available. This may improve accessibility of links or form related operations.
But the use of "accesskey" attribute needs careful consideration.

• In many mobile devices, available keys are limited. It cannot be assumed that all keys in "full" keyboards are available.
• Available keys differ among mobile devices. For example, cell phones will usually have "0"-"9", "*" and "#" keys, but the same assumption cannot be applied for most pagers or mobile game machines.
• There may be some mobile devices that cannot use "accesskey" attribute at all. For example, devices only for voice browsing will not use access "keys". Content authors should not rely on access keys for navigation.