Writing for Mobile Devices

In this article "device" means a small, mobile unit such as a smart phone or PDA. The rules for designing for small devices are mostly the same as the rules for good design in general, but some factors are particularly important.

Low bandwidth

Downloading pages from a mobile device is slower and more expensive than it is from a stationary computer with broadband or in a company intranet. Efficient coding will make the pages more responsive for everyone, but the speed-up is particularly great for devices. Better code also reduces server load. As a rule of thumb, there shouldn't be more markup than there is text. A well designed HTML page should have so little markup that it is possible to read the page from the source code.

More space consuming than the code itself (HTML, CSS, and scripts) are the attached images, applets, and other media.

Making compact code

Replace all font tags with CSS classes. Not only is it faster and more compact, it is easier to maintain and develop.

Use meaningful markup. <h3>A Headline</h3> is not only shorter and more readable than <p><font size="+2" face="Helvetica"><b>A Headline</b></font></p>, it also tells the browser this is a headline. Opera can use this information to the user's advantage. For instance, on devices with a full keyboard, the S and W keys are used to go to next or previous headline. You can try it on this page.

The default headline look may not be as desired, for that reason many designers started using the font tag instead years ago and have stuck to it since. This is no longer necessary as CSS gives you full control of how the headlines should look, and this part of CSS is reliably supported by every browser, including Netscape 4.

The site navigation section of a page can often be needlessly large. Changing from a complex table layout to CSS can dramatically reduce code size.

The best solution is to replace table layouts with CSS. This may not always be feasible, and will not work well with Netscape 4 and some similar browsers. A compromise that gives almost the same savings is avoiding deeply nested tables (tables inside tables inside tables), while keeping the basic table layout.

Remove unneeded code. If the default text color is black, code like <font color="#000000"> is just filler, as is adding align="left", the default value for text alignment. Removing code by hand is time consuming, but often the code is automatically generated from a script, where it can be removed once and for all. Optimizing templates can also be a good investment.

When scripts or stylesheets are shared by several pages, link to external files instead of embedding the scripts/stylesheets in the pages themselves.

Efficient graphics

Large images are less useful on a device, and those larger than a screenful will make for a worse user experience. Background images are not recommended. Images can be very costly to download and they need a lot of memory and time to display. The images shouldn't be larger than about half screen size (about 100-150 pixels). Opera in small-screen mode will not display many images and resize others to fit the screen.

Always specify the image height and width in the source code (either using CSS or HTML). This has several important advantages. Since the browser will know how much space an image uses beforehand, the page can get its final layout before the images finish downloading. This will give the impression that the page loads faster. If the browser is set not to download graphics at all, it can still keep the original layout. Finally, and maybe most importantly, many images that are not fit for handheld devices can be avoided before downloading them. This can make for a great difference in download time and cost, ultimately determining whether the user will want to revisit your site, or visit it with graphics.

If your web site is graphics intensive, the user may chose to turn off graphics. Make sure the site works without them.

Browsing without graphics

Browsing with images turned off is usually faster, cheaper, and more efficient. Therefore important functional elements on web pages, such as buttons and headlines, must be usable even without graphics. The trick is to add alternate text to the images.

Alternate text ("alt-text") can also be added to more illustrative graphics, such as photos, to give the user enough information to determine whether or not it will be worthwhile to download images on this page. If the graphic element is unimportant or purely ornamental, adding alt="" (with nothing between the quotes) to the image tag is recommended.

To test how a page looks like without graphics, just turn them off. This can be done with any browser, but is particularly simple to do with Opera. Browse through your pages, and see where problems occur.

When using graphics for headlines

It is much better to use text than graphics for headlines for a number of reasons, but if you do use an image for a headline, you should always include the headline text in the alt-text, and you should mark it up as a headline.

How to do this

When using graphics for navigation

Navigation buttons should always have an alt-text, as the site would otherwise be difficult to use.

How to do this

The Device Screen

Size

One of the more obvious differences between a device and a desktop computer is the screen size. Only a part of the page will be visible, and two elements you can depend on to be in view at the same time on a desktop computer may have to be scrolled to on a device.

Dynamic menus are not well suited for small screens. If you are using dynamic menus, or other space-demanding effects, try to have non-dynamic fallbacks.

Color

Modern devices usually have a color screen, but they offer less contrast than a normal PC screen. Devices are also often used in sunlight and other difficult conditions while PC screens are used in more controlled environments. Reducing screen contrast can be used to conserve battery length. For these reasons you should use good contrast between foreground and background. Expect subtle color differences to disappear.

Window management, frames

Avoid using frames. Opera does support frames on devices, but the small screen size still means that frames are an obstacle. Frames can be displayed in one of three ways:

• No frames
• As a list
• All frames

No frames means that Opera uses the <noframes> content instead of the frameset. For this to work well, the noframes content has to be useful, and not only a message that the user must turn on frames. Usually it is possible to generate a noframes version from a frames version. There is rarely a need for more than one content frame, all that is needed is automatically adding the essential content of the other frames.

As a list means that each frame is a separate window, along with a window listing all frames. Whether all windows are available at the same time depends on the device, but there is at least one frame plus the list frame. To make this easier to use, make sure that each frame has a distinct and meaningful name. It is much easier to navigate between Logo, Navigation and Content, than it is between Untitled, Untitled, and Untitled.

All frames keeps the frame structure as on desktop.

Window management, pop-ups

In particular avoid pop-ups. Pop-ups, creating new windows with JavaScript, are very distracting on a device where only a single window will be displayed at a time.

Context menus

Devices rarely have context menus, and in any case Opera doesn't give scripting access to them. Do not depend on scripts that interfere with the context menu.

Limited Input Capability

A mobile device usually has a limited keyboard or none at all. Entering data is much slower on a device. Be careful about setting time-outs (for example, do not break the connection after a minute), and do not force users to type more than necessary.

No mouse

Devices also do not use mouse navigation, so do not expect the user interaction to follow the exact same pattern as it does on a regular computer. Alternate and less space-consuming pointing devices, such as touchscreens, or keypad-based browsing are common.

Event handling

Pens and touchscreens tap, they do not click. They do not have a virtual cursor, so mouseover and mouseout event do not apply. There generally is a click event, pen taps are mapped into the mouseclick events, and devices without a pointing device often has a key that emits click events. Mouseup and mousedown events are much less predictable, as are keydown and keyup. Do not depend on double-click and right-click events. Some devices only have a virtual keyboard, you might not be assured of key events. The abstract UI events, blur and focus, apply.

The usual UI events should still work on a device, just do not have too fixed preconceptions on how they work. "Press the Y key to continue" isn't helpful if the device doesn't have a Y key.

The Processor, Memory and Storage

Speedy processors consume more energy than slower, so to conserve battery life device processors tend to be relatively slow. This means that some actions that are hardly noticeable on fast computers can take time on a device. The user may have to wait longer if you use excessively complex scripts or deeply nested tables. Normal pages should cause no problem.

Memory is a greater constraint. Devices have no hard drive, memory and file storage is one and the same, and there is too little of both. Large, complex pages use more memory, and graphics rich pages even more so. Pages with large file size will use more of the memory cache.

Java and plug-ins

The devices may have support for Java and common plug-ins like Flash or PDF, but they can rarely display web pages and Java or Flash simultaneously. Pages based purely on plug-ins should therefore be avoided.

Mobility

While all pages should be usable on a device, some kinds of pages are more likely to be useful than others. With a device you can get information you ask for right when and where you need it. Communication-oriented information, like a contact page with phone numbers, e-mail or physical addresses, or SMS can be more useful on a mobile device than it would be on a PC with fixed location.

Some capabilities are unique for a mobile device, HTML code like <a href="sms:12345678">Send me a message</a> will trigger the phone SMS editor, with the phone number "12345678" as the recipient. Since this is rarely useful for a desktop PC, without SMS capabilities you can set this link to only be displayed with the handheld media.

Pages: 1 2 3 4 print