Making Small Devices Look Great

By Opera Software

• Writing for Devices
• Testing with Opera
• Designing for several media

Quick Tips

Coding tips

1. Use terse, efficient markup
2. Avoid frames
3. Avoid pop-ups
4. Avoid proprietary features, or use fallbacks
5. Specify image height and width
6. Use alternative text on images
7. Have fallbacks for JavaScript and dynamic effects

Testing tips

1. Test in Opera for Desktop, in Small-Screen view
2. Test with graphics turned off
3. Test with JavaScript turned off
4. Test with no mouse

Small-Screen design tips

1. Design with document order in mind
2. Design the small-screen version for maximum readability
3. Use only images suited for a small screen, hide the rest
4. Be careful with the use of colors, font sizes, and alignment

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. See the example on using alt-text with headlines.

When using graphics for navigation

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

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.

Testing for devices

The best way to test web pages is to use the devices themselves. This may not always be practicable, but the desktop versions of Opera all have built-in testing functionality.

While the desktop and device versions of Opera are based on the same code, there can still be minor divergences in how pages look and act. This especially applies to JavaScript, but also Opera's Small-Screen Rendering is optimized for each device.

Using the Opera desktop browser as test environment

Testing without Small-Screen Rendering

Make a window of the same size as the device. Opera allows you to include window size in the title bar. Now you will see two numbers in front of the page title, something like 1000:800. The number before ':' is the window width in pixels, the number after ':' is the window height in pixels. A common smartphone size is 320 pixels high and 240 pixels wide, a common regular phone size is 128x128 pixels.

1. Check Show windows size at opera:config#UserPrefs|ShowWindowSize.
2. Click the Save button at the bottom of that section of the opera:config
3. Restart Opera
4. Resize the window to the device size

You can add or remove the addressbar and scrollbars as Ctrl+F8 toggles the addressbar, Ctrl+F7 toggles the scrollbars.

Testing with Small-Screen Rendering

1. Create a page
2. Open the page in Opera
3. Select View > Small screen (Shift+F11, or Shift+Alt+F11on Mac)

Testing with a 'Handheld' stylesheet

1. Create a page, have at least one style sheet with media="handheld"
2. Open the page in Opera
3. Select View > Small screen (Shift+F11)

Turning off graphics

Opera has a three modes for graphics, On > Off > Cached only.

Turning off JavaScript

Opera users, also on devices, are likely to have JavaScript enabled. It can still make sense to test the pages with JavaScript turned off if they are making heavy use of dynamic HTML, for example with JavaScript menus. The differences with Opera for desktop means that it is not entirely reliable as a testing platform for JavaScript on devices. If the page still works with JavaScript turned off, it should work on a device too.

JavaScript can be turned off by pressing F12 and then J.

Testing without a mouse

Devices do not have a mouse, and many do not have any other pointing device. To simulate this, turn the mouse upside down and just use the keyboard for navigation and page interaction. The help files (F1) list all keyboard commands.

Validating the Pages

It is possible to automatically check whether or not a web page is written according to the standards. W3C has a validation service for HTML and XML, as well as for CSS. Other organizations have sites that allows you to test for accessibility. Even if you do not intend to have error-free pages, the test results they generates are very useful for spotting important errors before the user complaints arrive.

Validating HTML

1. Right-click on document, Frame > Validate Source (Ctrl+Alt+V)

You can also go to the W3C Markup Validation Service/.

Validating CSS

There is no built-in CSS validator function in Opera, but you can go to the W3C CSS Validation Service.

Validating accessibility

Making web pages accessible has much in common with making them work on a variety of devices. See this overview of Web Accessibility Evaluation Tools.

Validating JavaScript

Unfortunately there is no JavaScript testing service, so this must be tested the old fashioned way, by trying the script in different browsers to see how well it works. Test the script both with and without Small-Screen Rendering activated.

Web Pages with Multiple Views

What looks good on a big screen will not necessarily look good on a small one, but it isn't hard to make pages look and work great on a device without compromising the quality of the full screen design. Start with the normal page. Have document order in mind, using a few device-specific tips and doing a little extra testing is what it takes. If the HTML code is simple to understand and maintain, making a well-designed pages that can be used everywhere is a snap.

The best tool is media-dependent CSS. You can have CSS that only applies to PC screens, print-outs, presentations, or with devices. When you have finished a design for one medium, optimizing for the next will merely be to add a few extra lines of CSS.

Styling for handheld

The same HTML page can be presented in many different ways for different media using CSS. The most efficient way to add code for the different media is to split up the style sheet into one for each media rule, that way it isn't necessary for a handheld device to download the projection style sheet, or the desktop PC to download the handheld stylesheet.

<!-- This stylesheet will be displayed by all -->
<link rel="stylesheet" href="all.css">

<!-- This stylesheet will only be displayed on PC screens -->
<link rel="stylesheet" href="desktop.css" media="screen">

<!-- This stylesheet will only be used for printing -->
<link rel="stylesheet" href="printout.css" media="print">

<!-- This stylesheet is for slide shows -->
<link rel="stylesheet" href="presentation.css" media="projection">

<!-- This stylesheet will be used by devices -->
<link rel="stylesheet" href="phone.css" media="handheld">

There are other variants that can be used, for instance a simple override for devices like this:

<!-- The styles used on all media -->
<link rel="stylesheet" href="all.css">

<!-- But there are some device-specific rules  -->
<link rel="stylesheet" href="small.css" media="handheld">

It is possible to have a list of media a style sheet applies to. This set of style sheets has one style sheet for all interactive media, and one style sheet for printouts.

<!-- A style sheet for the screen media -->
<link rel="stylesheet" href="screen.css" media="screen, projection, handheld, tv">

<!-- Some print specific rules  -->
<link rel="stylesheet" href="printout.css" media="print">

Screen

What the web page looks like on a computer screen. This is the most common way to browse the web. Web pages for computer screens are often "optimized" for a certain size (for example 800x600), and use tables for page formatting. Obviously this will not work well on a phone or other small devices, but this problem can be overcome by adding a few handheld rules.

Print

What the web page should look like when printed out. Many sites use a "Print button". This is hardly ever necessary with modern browsers that all support the print media type.

A print style sheet will typically:

• Hide screen-specific content like navigation and repeated elements,
• Take into account that print is a paged medium with fixed page size,
• Compensate for lack of color and for lack of interactivity, for instance by printing out the URLs that in other media would be clickable links.

While absolute units (points, cm, inches) should be avoided for other media, they may be appropriate for print.

Projection

The projection medium is used for slide show type presentations. The major difference with screen is that projection (like print) is a paged medium, while screen is a continuous medium (you scroll from the top to the bottom of the document with no interruptions in between). The projection type is only supported by Opera, and only on desktop.

Like print, projection is a paged medium. A web page can consist of many slides. Since projection is primarily used for presentations, extraneous information (like web navigation) is usually hidden to show only the main points in the presentation.

Handheld

This media type is used for devices. It is mainly used to compensate for the small screen size, and partially other factors, like color capabilities.

The handheld style sheet is primarily used to reposition and resize content to fit the small screen. Like projection, it can hide some content for a more efficient presentation.

The "handheld" medium is a relatively coarse mechanism, as "handheld" includes a very diverse group of devices from the smallest smart phone to the largest PDA. One future technology that will allow more precise customization is Media Queries. Opera is actively involved in the development of Media Queries.

TV

Used for TVs and similar media. In most cases the same styles as with screen would be used.

Aural

Used for spoken version of a web page. The CSS properties that are used (such as voice-family, volume, cue-before) are entirely different from the five visual media types above.

Other media

The list is not complete. There are four more media types defined in CSS2, and there might be more in the future. One of these, all, is the default value and applies to all media. The three remaining CSS2 media, braille, embossed, and tty, aren't currently used by any browser.

Document order

Designing a web page for multiple media is much simpler when you take in account document order. Document order is the order the HTML source code is in. In most cases a page is displayed by this order. Content early in the source code is displayed above content that comes later, and elements close to each other in the source code remain close to each other when displayed.

One exception is tables. Tables are displayed cell by cell left to right for each row going down. If the cells have a large size, the distance between the elements can be great, even if they are close in the page source. In the example below cell 3 is far from cell 4, and cells 1 and 4 are visually close even if they have the entire content of cells 2 and 3 between them.

While a PC screen may be large enough to have several columns of text, this is rarely feasible on a handheld device. For that reason tables will usually be reformatted to document order (that is, the text will be read 1-2-3-4-5-6).

The other exceptions to HTML being displayed in document order are the CSS features floats and positioning. Float moves content to the far left or right of its containing box. Positioning can move content to any position on the page or even stack content on top of each other, or hide some content behind other content. Float and positioning are rarely useful on a small screen, and, if you are not careful, they may result in the positioned element being moved outside the screen, forcing the user to scroll.

It is better to place the important content early, and to have the additional/extra code (like navigation sections) grouped so that it is easier to skip.

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