Global Authoring Practices for the Mobile Web

1. Challenges of Mobile Development

• Small screens
• Limited input capabilities
• Limited processor power and memory
• Limited bandwidth
1. Baseline
Devices which meet baseline requirements or above will support the following features:
XHTML MP 1.0
Support for XHTML Mobile Profile 1.0.
GIF and JPEG
Support for GIF and JPEG image formats.
256 colors
Color device with support for a minimum of 256 colors.
120x120 screen
120x120 pixel screen or larger.
At least 10 Kilobyte of content
Device can manage at least 10Kb of combined mark-up, graphics and CSS content.
Basic support for Tables
two columns tables are supported. no 'rowspan' and 'colspan' support required.
Picture and Link on the same Line
Device can display a picture and a link on the same line.
9.6 Kbps Minimal Bandwidth
Device and network support at least 9.6 Kbps bandwith.

2. Practices
The practices will be split into two groups: development and usability:
• Development relates to practices of technical nature mostly related to the XHTML-MP
mark-up.
• Usability relates to user-perception of the application and are mostly agnostic of the
mark-up adopted.
1.1Development
Validation of XHTML MP

XMLLint is a useful utility to check a page XML validity through a command-line

tool.

HTML tags and attributes (for example, cell padding and cell spacing for XHTML
tables) can deliver graphically accurate renderings in ways that are not
achievable through CSS (through the padding and spacing properties, for
example), mainly because of poor CSS support in mini browsers. This behavior
 can be observed also in mini browsers running on high-end devices.
While the usage of extra XHTML attributes will make an XHTML-MP page non-
valid, opting for non-valid, but effective, mark-up may be preferable in some
cases.
Making sure that a page is well-formed is still recommended, since well-formed
XHTML-MP mark-up is less likely to cause troubles than invalid XHTML-MP.

Testing Applications

Test an application on at least 5 different microbrowsers

Acquire at least 5 devices for development and testing, where each device has
one of the following browsers: Nokia WAP Browser series 40, Openwave Mobile
Browser version 6 or greater, SonyEricsson (Teleca), Netfront, Opera for
Symbian.
The list above is minimalist in nature. More robust testing could include one or
more of the following microbrowsers: Motorola Mobile Browser 2 or grater,
Microsoft Mobile Explorer, Nokia Series 60, Safari for Nokia. In addition, there are
devices such as the BlackBerrys or Palm OS-based devices which have browsers
of their own.

MIME type

Use the application/vnd.wap.xhtml+xml MIME Type

One of the disadvantages of this MIME type is that it prevents developers from
previewing the applications in some regular web browsers (notably Microsoft
Internet Explorer up to version 7). On the other hand, the text/html MIME type
fools some devices into believing that it is a regular page they need to render.
This may get them to apply heuristics that conflict with the intentions of the
author.

MIMETRICK-

<%
String acceptHeader = request.getHeader("accept");

if (acceptHeader.indexOf("application/vnd.wap.xhtml+xml") != -1)
response.setContentType("application/vnd.wap.xhtml+xml");
else if (acceptHeader.indexOf("application/xhtml+xml") != -1)
response.setContentType("application/xhtml+xml");
else
response.setContentType("text/html");
%>

The above trick may not be optimal for recent BlackBerry devices. Those devices
will claim to support all the HTML-related MIME-types in the accept: header, thus
inducing a application/vnd.wap.xhtml+xml type. Unfortunately, this MIME type
(as well as application/xhtml+xml) will cause the BlackBerry to ignore tables and
CSS, which would otherwise be rendered normally with text/html. It should also
be observed that RIM devices often depend on extra proprietary proxies
 deployed at operators. This means that the same devices may have different
capabilities with different operators. For example, BlackBerrys from legacy
Nextel (USA) are WML-only.

Little or No CSS

Only use simple in-line CSS or none.

Keep styling information to a minimum and do not change the color of links.
Using WCSS for input masks is a good idea because it will degrade gracefully on
all known browsers.
Advanced CSS constructs such as media queries should be avoided: Only a few
browsers support Media Queries acceptably (notably, recent versions of the
Opera browser). In addition, pages based on Media Query hardly degrade
gracefully on non-supporting devices. Microbrowsers typically end up
downloading large graphics, which, in the author's intentions, was not meant to
be delivered to a mobile device.

Minimizing the number of pictures

Keep the number of images in a page down.

The number of external images greatly affects the loading and rendering times
for a page. For this reason, a balance needs to be found between the number of
pictures used for visual purposes and the page rendering time.
Many devices will not enable softkeys nor return control to the user until the
page is fully loaded and rendered. This will make it impossible for users to
invoke browser functions (notably, backward navigation) for a frustratingly long
time.

Providing the right encoding for content.

Use UTF-8 encoding or better for non-english content.

The encoding can be specified this way:

<?xml version="1.0" encoding="UTF-8"?>

Looking at the "accept-charset" may work in identifying supported charsets on

some devices. For example (SonyEricsson W810i):

accept-charset = utf-8, utf-16, iso-8859-1, iso-10646-ucs-2, Shift_JIS, Big5,*

Beware of Colors

Do not try to color links. Avoid background pictures.

Setting the background to blue and using CSS to color links white will result in
unreadable black labels against a blue background on a wide range of devices.
Avoiding background images and colored links is the safest choice to make sure
that content is usable across a wide array of devices.
If no color info and no background are specified, devices will resort to default
 colors, which are typically very readable.
Background colors may be OK only as long as authors stick to light hints of color.
Developers should also avoid styling 'visited' and 'active' hyperlinks as follows:

a {color:#0000FF;}

a:hover {color:#0000FF;}

a:link {color:#0000FF;}

a:visited {color:#0000FF;}

a:active {color:#0000FF;}

Some devices may highlight selected links by inverting link color and
background color, effectively hiding the label of the currently selected link in
case the above CSS is applied.

Avoid too much vertical white space

Avoid adding vertical white space in a page.

Code like the following is not unusual on poorly designed mobile sites:

<br/>

--<br/>

<br/>

While this code may have a nice visual appeal on some devices, it will cause the
problem described above. Using the XHTML-MP <hr/> is a better option.

3.2 Usability
Order of Menus (most important choices first)

Place the most specific menu items in the top positions of menus.

One open question is who defines the importance of each item in the first place.
This choice may be about letting users choose through usability tests.

Access Keys

Use the 'accesskey' attribute to implement keyboard accelerators on menus.

The use of the accesskey attribute allows users to activate a link by pressing (or
press-holding) a number key on the numeric keypad, thus avoiding the need to
click several times to select the link.
In menus, access keys allow experienced users of the service to reach the
information they need faster by memorizing the numeric combination that will
take them where they wish.

The following XHTML-MP construct will deliver a numbered menu on all baseline
devices or superior. Numbers are guaranteed to be displayed only once and
 items will be selectable by 'pressing' the accompanying number.
'Pressing' may mean simply pressing or 'pressing and holding' (Nokia devices).

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"

"http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>

<title>Contacts - R</title>

</head>

<body>

<p>

Pick contact:

<ol>

<li><a href="contact.jsp?id=32" accesskey="1">Ramona</a></li>

<li><a href="contact.jsp?id=45" accesskey="2">Robert</a></li>

<li><a href="contact.jsp?id=21" accesskey="3">Romeo</a></li>

<li><a href="contact.jsp?id=17" accesskey="4">Ronan</a></li>

</ol>

</p>

</body>

</html>

Navigation Mechanism: Home/back link at the end

Provide consistently used links to navigate inside the application.

Add navigation links at the end of each page. At a minimum, a link labelled
'Home' (or the equivalent in the user's language) should be present.
There can be exceptions to this rule in case of confirmation requests ("Really
Delete? yes|no") or other situation in which the user shouldn't be distracted from
the task he or she is performing.

No Navigation bars at the top

Avoid navigation bars at the top of the page.

 This practice may not apply in case of higher-end devices. In those cases, large
screens, the possibility to have smaller fonts for navigation links and the
availability of a four-ways rocker (clicking past the navigation bar just requires
one extra click) can make the presence of a navigation bar acceptable.
Navigation bars may optionally be inserted at the top for high-end devices.
In these cases, it may also make sense to place 'bread-crumb' navigation (for ex:
Home >Hardware >Chainsaws) or page numbers ( page 3 of 10 ) to navigate
through large amounts of text, similarly to what is seen on web pages.

Avoid unnecessary links

Avoid repeating links such as 'Help','About','FAQ' in every page.

Most users do not access on-line help even when available on desktop
applications. Virtually all mobile users will stay away from a link that labelled
'Help' or 'About'. Success can be achieved by making the application intuitive to
use. Not cluttering the page with unnecessary links is a step in the right
direction.

Avoid splash screens

Avoid first pages made to be skipped.

Avoid so-called 'splash-screens'. Make sure that the first page the user receives
has links to activate the main functionalities of the site.

Add a meaningful page title

Provide a short but descriptive page title.

Some devices will truncate title strings longer than 8-10 characters. For this
reason, it is probably a good idea to keep the title short.

Concise and Clear Language

Use clear, short and concise terms and sentences.

The number of words should be reduced in every possible way. Using the label
"Age:" is a better choice than "Please enter your age here:". Another example
could be to avoid words like "Entertainment" when one can simply say "Fun".

Different media means different user experience

Do not serve a website to a mobile device and do not serve a mobile site to a
web browser.

A popular approach is to advertise one URL ("http://organization-name.com")

and look for hints in each HTTP request to understand the nature of the client:
requests coming from mobile devices are redirected to the mobile site, while
request from web clients are redirected to the web site.

Adopting short URLs

Adopt a short URL for site entry point(s).

 Sites such as Tinyurl.com allow everyone to define short URL as a free service.
Commercial organization may pay for an equally short, but more memorable,
URL.

Cache Management

Do not disable caching (unless low page lifetime is part of actual business
model).

The exact caching model is part of the business model of the application.
Browsing an email inbox may require nothing short than total disabling of any
caching. Weather forecast may live with a couple of hours caching. Yet again,
advertisement and banners may pose additional requirements on caching. These
requirements may clash with the service usability.
Things are complicated by the fact that some microbrowsers allow fine grained
control of the cache by respecting Time-To-Live (TTL) directives, while others
only respond to a somewhat brutal use of META tags.
Two techniques are provided: completing disabling the cache and a somewhat
softer reset that will preserve the usability of backward navigation (back button).

Disabling caching completely

Different microbrowsers (and microbrowser/gateway combinations) react in
different ways to different META-tags and HTTP headers.
The following set of headers has been proven to work on a wide range of devices
to disable caching for the page:

Expires: Mon, 26 Jul 1997 05:00:00 GMT

Last-Modified: DD. month YYYY HH:MM:SS GMT

Cache-Control: no-cache, must-revalidate

Pragma: no-cache

In case access to headers is not possible, the same functions can be achieved
with the usage of the following META tags:

<meta http-equiv="expires" content="Wed, 26 Feb 1997 08:21:57 GMT">

<meta forua="true" http-equiv="Cache-Control" content="must-revalidate"/>

<meta http-equiv="Pragma" content="no-cache, must-revalidate">

Soft cache disable

This is the illustration of how page cache can be disabled without interfering with
the back-button functionality, which should always bring the user back to the
previously visited page.
No HTTP header or META tag should be used to disable caching. All the links to
an application page should be different. This can be achieved by adding
dynamically a bogus HTTP GET parameter to each internal link. The time in
seconds is a good candidate for this. The following JSP/JSTL example shows how
a link to a newly modified bookmark page could be created to make the
 microbrowser perceive it as a different URL. This fools the browser into reloading
the page from the service and not from the cache:

<jsp:useBean id="now" class="java.util.Date" scope="request"/>

<a href="bookmarks?id=${bookmark_folder_id}&amp;

cache_buster=${now.time}">Go to Bookmarks</a>

It goes without saying that this trick cannot be performed with static XHTML-MP
pages.

Manage User Input (use input masks/minimize clicks)

Use input masks to minimize user input. Beware of HTML-style forms. Do not
require that users login each time. Do not mask user input when entering a
password.

Input Masks
Most mobile devices let users specify input-masks, i.e. the format with which
user-input is supposed to be entered. If a telephone number is required of the
user, setting the input form in numeric mode greatly simplifies the task of
entering the data for the user. Also, this prevents user errors.

Beware of Forms
XHTML-MP forms are very similar to the ones in HTML, which, in turn, mimic
widgets such as push button, radio buttons, check buttons, combo boxes (also
called 'drop-down' boxes) and others commonly found in desktop applications.
While those widgets are usable in web pages and desktop applications, they are
often implemented in ways that force users to do far too many clicks on a mobile
device. Selecting, activating and deselecting each single widget is time
consuming and not pleasant, particularly on devices without a stylus or other
pointing device (the great majority of devices).
Developers should get creative about ways to minimize recourse to such
widgets. While complex forms with text fields, radio buttons and drop-down
boxes are the norm on the web, they should be avoided on a mobile devices by
splitting a form in several atomic steps (such forms are sometimes referred to as
'wizards'). Wizards make users focus on a task at the time and are less error-
prone than monolithic (elective) forms.

Avoid Logins
Logins are a big killer for usability. Requiring users to type a username and a
password before they can use the application will reduce the number of users by
two-thirds or more.
If the application business model does not allow for the removal of a login task
altogether, developers should at least make whatever they can to recognize
users the second time they access the service and refrain from requiring login.

Do not use password masks

Reading what is on the screen of a mobile device is often hard enough for the
user of the device. Peeking over the shoulder of the user is less likely to disclose
a password than observing the user's keypress sequence.
For this reason, hiding user input to users themselves by replacing each
character with a '*' (star) symbol (or similar) will do very little to protect privacy,
while making it generally harder to use the service. For this reason, users should
be made enter passwords in clear text.
This practice does not detract from the aforementioned practice to avoid login
and find alternative ways to identify users.
Input Masks:
XHTML-MP lets developers add input masks with the following syntax:
<input type="text" name="pin" value="" style="-wap-input-format:NNNN" />
Some early versions of XHTML-MP microbrowsers did not understand the above
syntax and were better served with the following syntax:
<input type="text" name="pin" value="" format="NNNN" />
Choosing the syntax in the first example is preferable. Not only is it more
elegant, but the CSS syntax will not make the application break on browsers that
do not support it.
The XHTML references in the reference section contains the specification of
formats.
It should be noted that this is an area in which different microbrowsers behave
differently and adopting adaptation is strongly encouraged.
For example, input masks such as "NNN-NNN-NNNN" to identify a US phone
number may be supported usably on some devices and not in others. If
adaptation is not an option, relying on a simpler numeric input mask would be a
better choice for this case.

Forms:
Radio buttons, checkboxes and combo boxes tend to be confusing and require
too many clicks. It is usually possible to re-define complex forms in terms of set
of menus.
For example, the following code shows a combo box implemented though a
syntactically correct XHTML-MP code snippet. The combo box is rendered as
shown on the left. This is not very usable, since users are required to perform
the following activities:
• Scroll to the combo box and select it (which brings them to a virtual page
that implements the choices. This makes the user loose context)
• Select the right value
• Choose to abandon the combo box (which brings them back to the original
context)
• Focus on what the next thing to do is (de-select the combo and select the
next widget in the form).
Forcing the user to perform a large number of clicks and to concentrate
continuously on what he or she is doing is likely to make the application feel
unfriendly and hard to use.
 Top of Form
Age: Age:
<select>
<option value="17">Less than
18</option> Less
<option value="25">[19- than 18
25]</option>
<option value="45">[26-
[19-
44]</option> ->
25]
<option value="100">over
44...</option>
</select> [26-
44]

Over
44
Bottom of Form
To optimize the number of clicks, a better option is to break down the form in
more atomic parts which require users to focus on a single task at the time. The
case described above could be implemented in terms of single steps. In
particular, the age could be collected by providing a set of links. When to user
selects a link, the age is chosen and the user is automatically brought to the
next step of the form.

<title>Age</title>
: Age
<a href="next/form?age=17">Less than
18</a><br> Less
<a href="next/form?age=25">[19- than
25]</a><br> 18
->
<a href="next/form?age=44">[26- [19-
44]</a><br> 25]
<a href="next/form?age=100">Over
44</a><br> [26-
44]
Over
44
For example, text input fields often require clicks to activate and deactivate.
Combo boxes bring users to a new virtual page and back after the selection,
which may be confusing to some users.
Creating usable forms is generally difficult. Developers are encouraged to do
usability tests with real users ([TESTING]) as early as possible in the lifecycle of
the application, possibly with the help of prototypes.
It cannot be ruled out that different forms are required to optimize usability on
different classes of devices. This is consistent with the general idea that
adaptation drammatically improves the success of mobile applications.

Avoid Logins:
 Assuming that removing login tasks completely is not an option because of a
mobile site business model, there are a few techniques to prevent users from
having to login again the second time around.
Most operators gateway attach extra HTTP headers to each mobile-generated
request which uniquely identify the user. This bit of information can be used to
recognize the user and log him or her in automatically.
Yet another option is to use cookies. While cookies may not be supported on
some ntwork or on older devices, they should be used to avoid the login task
when available.
Some WAP gateways can manage cookies on behalf of a device which does not
support them.

Do not use password masks:

This practice can be easily applied in XHTML-MP (and other HTML-derived mark-
ups) by using:
<input type="text" ..../>
in place of:
<input type="password" ..../>
to implement a password entry field.

Cookies may not be reliable

Carefully evaluate how cookies are used in the application. Cookies may or may not work on
some networks and/or some devices.
If an application only relies on cookies for improved service, but is not essential to the well-
functioning of the service itself, then cookie support can be safely assumed.
If cookies availability is essential to the correct functioning of the application (typically for
supporting user sessions), then alternative mechanisms should be assumed. URL-Rewriting is
the common way to by-pass the lack of cookie support.

One word of caution should be spent about usage of URL re-writing for mobile applications.
Many commonly available URL-rewriting packages assume that the HTTP client is a web
browser. For this reason the rewritten URLs include session IDs that can be very long and
contain special characters. This can cause problem on some mobile devices.
Some URL rewriting libraries let themselves be configured to address this problem by
avoiding special chars and keeping session IDs under 50 chars. Creating one's own URL
rewriting function is also a possibility.

Finally, in many cases, operator gateways and independent portals attach unique headers and
values to each HTTP request, such as phone number headers (x-wap-msisdn, x-nokia-
msisdn, x-up-calling-line-id) and subscribeer id headers (x-up-subno). The headers
can be exploited as unique keys to track users and the foundation for session management.

Large content

Delivered mark-up and images should not exceed 10 Kilobyte totally.

 Each mobile page should not contain more than 10 Kilobytes of content totally
(i.e. XHTML+Pictures+CSS).
It is observed that device memory, screen size and download speed should not
be the only limiting factors when deciding how much content to deliver to a
device. The form factor of a mobile device will make it hard for the user to scroll
precisely through large amounts of text and images, even when a large screen
and a stylus are available.
For this reason, it is recommended that mobile pages do not exceed 40kb totally
even for high-end devices.

Keep images small

Do not deliver pictures that are wider than the screen.

Developers should find frameworks to serve pictures in different sizes to

different classes of devices in order to avoid scrollbars and low-quality resizing.
Pictures should be constrained by the screen size of the baseline device
(120x120 pixels).

Developers should make sure that their software can produce JPEG pictures
without extra information and small in size.

Specify image dimensions

Specify the real image width and image height in the mark-up.

Specify image size using the following syntax.

<img src="images/logo.gif" alt="ComPany" width="100" height="20" />

One possible exception to this practice might be a free wallpaper site, where
users can be sent a whole picture while specifying the dimensiones of a smaller
thumbnail. In that case, saving the page will work without having to fetch the
full-size version.

Minimize the amount of clicks to get to content

Minimize the number of clicks required to carry out activities.

Application menus should be organized to offer access to the most commonly

used functions with the least possible numbers of clicks.
Most commonly used functions should be made available as top links, while less
used functions should be pushed down. The idea that less commonly accessed
functions are removed completely from the mobile UI should be considered,
particularly when the primary reason for adding them in the first place was their
existence on a companion web site.

Turn telephone numbers into links that start a phone call

Enable one-click calls for phone numbers.

There are two ways to implement one-click phone calls:

<a href="wtai://wp/mc;+39393939777778">+39 393939777778</a>

 or

<a href="tel:+39393939777778">+39 393939777778</a>

Fewer than 10 links

Only exceed 10 links per page if the application demands it.

Minimize the number of items in menus. Keep the total number under 10.

No Thinking Web

Do not try to port all functions of a website to mobile.

When designing the port of a web site to mobile, one possible approach is
identifying two kind of information:

1. Information that users want to access when they are mobile.

2. Information that people want all the time

This may turn up to include only 5% or less of a web site current functions, but
that is still acceptable. In fact, that is the key to creating a mobile site which has
high value for mobile user and which, ultimately, makes it acceptable for users
to carry the cost (time, money and concentration) of accessing the service.

Not everything is good with W3C Best Practices

Beware of W3C MWI Best Practices.

W3C MWI Best Practices should be ignored by developers who are new to
mobile.

Test with real users

Find real, non-techie users and make them perform functions. Observe what
problems they have.

It is also advised that usability testing starts as early as possible, by using

prototypes (or, even, just mockups) of the pages. It is not uncommon that
achieving good usability has an impact on the back-end. For this reason, such
changes should be managed earlier rather than later.