The Phone Factor

By Opera Software

Phones can be summed up as being slow and small. Designing for phones isn't different from designing for desktop PCs, but a greater focus is needed on what is important on a page and how to achieve that efficiently. Redundancy is not desirable on small devices, as you can't as easily scan and ignore surplus content as you can on a big screen.

Page design

The desired layout for handheld devices is single-column, with the important information near the top of the page. Redundant information should be removed or hidden, but be careful not to remove content the user actually will need or want. Horizontal scrolling during reading is very distracting and should be avoided at all cost. There are several strategies that are in use:

• Use very fluid designs. Designs based on tables, frames, or absolute positioning are ill suited for devices. It is hard to make an attractive design based on one size fits all unless it can be pared down to the very essentials.
• Let Opera do the reformatting. Create a design optimized for normal desktop displays and let the browser adapt the content. This strategy works especially well if the source code content comes in logical order.
• Make several versions of the page, one for desktop and a few more versions for devices, and let the server decide which one to send.
• Let the content adjust to different types of display, using CSS handheld media, Media Queries, or JavaScript based queries.

Some common device screen sizes (pixel width x height)

• 128 x 128 pixels - Nokia Series 40 devices. A very common device size.
• 176 x 208 pixels - Most Nokia Series 60 version 2 devices
• 176 x 220 pixels - Most Microsoft 2003 smartphones
• 208 x 320 pixels - Most UIQ version 2 devices
• 240 x 320 pixels - [Quarter VGA] Most EZX, MS Pocket PC in portrait mode, UIQ version 3
• 320 x 240 pixels - Same as above in landscape mode
• 352 x 416 pixels - Nokia N90
• 640 x 200 pixels - Nokia Series 80
• 640 x 320 pixels - Nokia Series 90
• 640 x 480 pixels - [VGA] Large screen phones

Unless the browser is in fullscreen mode the actual page size will be somewhat smaller than the screen size. For the smallest sceens you can expect about the same width, but 20 to 40 pixels smaller height. The display resolution, also known as pixel density, will often be higher than what is common on desktop. This means that the pixels may be physically smaller. This is to some extent offset by the devices having higher quality screens which is viewed at a closer distance.

Tips

• Avoid spatial dependencies. Two elements that are next to each other on a big screen will typically be below each other when adapted to a small screen. Depending on how the page is coded the elements can be close or far apart. There is no guarantee they will be both displayed simultaneously.
• Let pages degrade gracefully, that is work even if one or more elements can't be handled by the phone.
• Don't include useless elements.
• Frames and positioning is not suited for small screens. Be careful with tables and floats too.

Network Speed (Bandwidth and Latency)

There are two components to network speed. Bandwidth is how much data can be transferred through the network at a given time, usually measured in bits per second. A file that is twice as big will take twice as long time to download. Latency is how long time you have to wait from sending a request until you get a response, a round trip to the server and back. This delay is a constant dependent on the network, a big file will have the same delay as a small one. Latency typically is less than a second on fixed lines and can usually be ignored. On wireless connections the latency can run into several seconds causing a noticable wait. In typical browsing low bandwidth is a bigger issue than long latency.

Phone networks have very low bandwidth relative to terrestial lines, even relative to wireless local networks like 802.11. Some common phone network bandwidth capabilities:

The real bandwidth can be much lower than the theoretical maximum, especially for congested networks. A typical phone user can have something like GPRS at 50 kbps (thousand bits per second). Furthermore a flat rate is not yet the rule. Most users pay for the amount of transferred data, giving them a strong financial motivation to avoid large data transfers. More data also means more data processing and memory use, further slowing down the perceived speed of browsing.

Media files, primarily images, comprise the majority of bandwidth and memory used in browsing. Since images larger than the phone screen usually will be scaled down to fit, oversized images are a waste of time and money. Other media, like audio, video, or binary files, tend to be even larger and not directly accessible for the lower end devices with neither a plug-in interface nor a viewer.

One strategy is to use different sized images for desktop and devices. This can be done server side (using browser sniffing) or client side. It is possible to use the CSS3 'content' property to replace content, like @media handheld {#big-image {content: url(small-image.png)}}. Alternatively JavaScript can be used, though on low-end devices JavaScript can have been shut down manually or automatically. A more common strategy is to skip oversized images (with display:none or similar technique), as they aren't usually relevant for small devices, and show the other images, letting them scale as necessary.

Code files (like HTML, CSS, and JS) are usually smaller than media files, but the processing cost of code files can be considerable.

The server round trip delay is considerably longer for wireless connections, and this is fairly independent of the actual bandwidth. Avoid making more round trips than necessary. For instance an external style sheet linking to another via an @import rule will require three sequential round trips (first the HTML file, then the intial CSS file, followed by the imported CSS file) before the page can be properly displayed.

Tips

• Don't use huge images
• Use alt text for 'img' and fallback for 'object'
• Make code files terse and efficient
• Don't create long sequences of round trips required to render a document

Processor speed

For long battery life as well as for size and cost limitations the processors you will find in phones are slow or very slow. PDA style devices have more massive batteries and lower standby requirements so they usually have tolerable processor speed. While the difference between an efficient design and a slow inefficient design can be acceptable on a fast desktop machine it will make a huge impact on a phone.

All browsing processes will take noticeable time to process: document parsing, styling, image processing, page rendering, running scripts, user interaction. A good design will be snappier than an average one, and a bad design can make a page unusable. Some processes are inherently costly, in particularly page reflow and DOM mutations. This cost is higher the more complex the page is.

Tips

• Don't use redundant code
• Don't use huge images
• Optimize JavaScript where it counts
• Don't run massive processes in the background (it won't be in the background on a phone, and the battery life will be lowered)
• Avoid reflows (don't change page layout needlessly)

Memory

Devices always have too little memory available so the strategy is to use the little there is optimally. Images need a lot of memory. Little memory also limits the cache size, making the cache much smaller than ideal. Pages with many large files will flush much of that cache making the overall experience more sluggish. Markup uses much more memory than text to build up the DOM tree. The fewer elements a document has the faster it will respond, so remove the useless markup. Don't be afraid to use markup, but make it count. CSS and JS files can be needlessly complex too. Remove what you don't use.

• Don't use redundant code
• Don't use huge images
• Optimize JavaScript where it counts
• Don't run massive processes in the background

User interface and document windows

Phones don't come with an attached mouse, and they usually don't have a full keyboard either. Navigation and especially text input is more cumbersome than on desktop machines. Together with the small screen and slow processing the limited UI leads to designs that focus on what is important for the user. Selecting among options is easier than typing preferences, but keep select boxes reasonably small. Picking multiple choices in a select box is much harder to do than a single select.

Some browsers, including Opera Mini, only shows single window, design with that in mind. Even browsers that support multiple windows, like Opera Mobile, are constrained by available memory as to how many windows can usefully be displayed at once. Opera supports frames, but most phone browsers do not.

• Don't do pop-ups
• Don't depend on mouse-based interactions, in particular :hover and mouseover
• Avoid dynamic menus
• Don't force the user to type more than necessary

Design tips

Markup and CSS tips

• Use handheld as media type to deactivate reformatting technologies such as Small-Screen Rendering, but don't use it if you don't mean it.
• If disabling SSR be very careful with floats and absolute positioning, consider turning this off completely in the handheld style sheet
• Use scalable design to handle multiple screen resolutions/orientations with the same code. Failing that create the source code in natural order, important content first, and let SSR do its work.
• Be considerate with :hover, as there often is no mouseover on a phone (this includes CSS dynamic menus)

Graphics tips

• Don't use huge images
• Use alt text for 'img' and fallback for 'object'
• Don't use image slicing (cutting down images into smaller pieces), phone reformatting may scramble the image. If the image is big enough to consider slicing it then it is ulikely to be useful on a phone.
• Use clean and wellmade images, they are smaller in size and scale better
• Use PNG to achieve alpha transparency
• Use JavaScript/DOM for animations instead of plug-ins.

JavaScript tips

Above all else code efficient JavaScript, phones don't have the luxury of vast memory or fast processors to cater for poor code.

This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.