Make your site mobile friendly

The number of mobile devices loose in the world greatly exceeds the number of desktop (or laptop) computers filling up desk and table space in offices and homes. The number of people who might view your site while clutching a screen measuring anywhere from 100 pixels to 640 pixels in width increases daily. Creating mobile-friendly […]

The number of mobile devices loose in the world greatly exceeds the number of desktop (or laptop) computers filling up desk and table space in offices and homes. The number of people who might view your site while clutching a screen measuring anywhere from 100 pixels to 640 pixels in width increases daily. Creating mobile-friendly content is quickly becoming less of an occasional add-on and more of a standard practice.

This article will take a look at how you can create mobile-friendly content, how you can test your work, and offer a few tips for writing CSS for the media type handheld. If you are a Dreamweaver or Flash user, we’ll also take a look at something new from Adobe that will help you test your pages for handheld devices.

Start with the basics

If you begin with standards-based HTML that is formatted with logical, semantic markup, you’re ahead of the game already. A well structured document with clear organization and semantic markup will display cleanly, be usable, and be accessible on any device – mobiles included. Using CSS to separate content from presentation means your content will be accessible, even on the least capable mobile device. Pay attention to other basics as well. For example, good alternative text is an essential for any non-text element in your pages. Make sure that form fields are properly labeled.

Clean, semantic markup is crucial when you consider the variety found in mobile devices. Some phones may only understand WAP. More capable phones may understand WAP2, which opens them up to rendering websites with XHTML and CSS. Some devices may display only monochromatic screen colors, while others may have full color. Some devices support CSS, some do not. Some only understand HTML 3.2, while others understand XHTML. Some devices undertand tables, floats, frames, JavaScript, and dynamic menus, but many do not. Most devices don’t support cookies. Devices at the high end of the mobile market such as BlackBerry, Palm, or the upcoming iPhone are highly capable and support nearly as much as a standard computer.

All those possibilities are enough to make you long for the days when the browser wars meant coding for Internet Explorer 4 or Netscape Navigator 4! But we have two things now that we didn’t have in the bad old days: a large body of knowledge about how to write standards-based HTML and XHTML using semantic markup and about how to separate content from presentation with CSS. If you stick to best practices in those two areas, the need to worry about every single rendering possibility from mobile devices diminishes and you can develop with confidence.

Testing your site

None of the free or fee-based testing options can equal the testing results you get with an actual device. I recommend testing with real mobile devices much as possible, but I know it isn’t feasible to run out and buy every single mobile device. There are some fairly reliable ways to test your site without going to that extreme. Some of the testing techniques are free, some are not. First, let’s look at the free options.

Opera provides two good testing tools. Using the standard Opera browser, select View > Small Screen to see your page rendered in an approximation of what a mobile screen might display. The Opera web developer bar has a button called Display that allows you to toggle CSS on or off when viewing a page using small screen view. Here you see two Opera small screen views of my blog, Web Teacher, first with CSS, then without.

As you can see, Opera renders the images in small screen view. (We’ll talk more about images later.) Note that the small screen view renders the content in source order, that is, the order in which the elements appear in the HTML. Elements are clearly distinguishable from a semantic viewpoint: headings, links, paragraphs, blockquotes. The organizational and semantic underpinnings hold up so that the content is readable and useable. This is especially easy to see in the second screen shot, with the CSS toggled off. Keep in mind that neither of the displays in the previous two screen captures are influenced by a handheld CSS media type stylesheet. When a heldheld CSS stylesheet is present, Opera’s small screen view will take it into account. More about this in a bit.

Opera provides a free browser that can be downloaded and installed on handheld devices. It’s called Opera Mini. (You can purchase Opera Mobile for even more capability.) Both are available at opera.com. Since Opera is in the business of providing browsers for mobiles, the company made a helpful online mobile simulator at operamini.com/demo. Here, you can load a page into the Mini Demo and operate it with mouse or keyboard as if it were a real mobile phone. The screen capture shows that the Mini Demo renders images and CSS. Again, there is no handheld CSS media type stylesheet affecting this rendering.

Another free way to test your site for clear structure, organization, and proper semantics is with Firefox’s Web Developer extension. Use this tool to disable images, JavaScript, and CSS and you’ll have a good idea about whether your content is going to make sense and be navigable in one of older and less capable mobile phones.

Here’s a Firefox screen capture. For this, the Web Developer Toolbar was used to disable all CSS, all JavaScript, and all images.

Viewing the page without images and with no functioning JavaScipt is very useful in terms of testing for older mobile devices. Keep in mind that some of the less capable mobile devices don’t render tables. None of them understand frames. Seeing your site this way really drives home the importance of standards-driven, semantic markup.

Using specific emulators

Some of the phone and PDA manufacturers have emulators on their sites that you can download and use for testing. Depending on your target audience, testing on a specific emulator might be helpful. If you are interested in specific device or manufacturer, check their site for developer resources. (For example, Sony Ericsson’s Developer World, Nokia has a developer forum with an XHTML section,

Testing CSS Handheld media stylesheets

An important tool in the Firefox Web Developer Toolbar is CSS > View CSS by Media Type > Handheld. If you look at Web Teacher in a standard monitor, you see that it is a simple two column layout using a left float for the content div and a large margin-left to create the sidebar as a second column. I’ll add a stylesheet for handheld media to the testing mix. It contains only two rules — to reset the sizes of the content div and sidebar div and to remove the float. Here’s the entire stylesheet:

#content {
	float: none;
	width: 95%;
}
#sidebar {
	width: 90%;
	margin-left: 5%;
}

The link to this stylesheet was added to the document head after the all media stylesheet, so as to be last in the cascade. I’ll use a link element for this. For those mobiles that do understand CSS, using link is more reliable than using @import for bringing in styles, although some of the more capable devices understand @import. Here’s the link element:

Media types are mutually exclusive. A user agent can only support one media type when rendering a document. If I want to retain any of my existing styles in a handheld display, I need to take one more step, and that is to list all the media types I want my existing styles to apply to in a comma separated list. I change the link element for my existing stylesheet, which is called 2col.css to include this media attribute: media="handheld,all". The two link elements are now:

The styles and the color scheme I have in 2col.css should also apply to handheld renderings, but the two column layout will be removed by the mobile.css rules.

Testing with the Firefox Web Developer Toolbar menu CSS > View CSS by Media Type > Handheld should now show handheld media results, and it does.

The first screen capture shows the two column layout, as it normally displays with the all media stylesheet. The second shows Firefox using the handheld media view.

From the second screen capture, you can see that Firefox has expanded the content div to 95%, according to the mobile.css rules. If you scrolled down the page past the content div, you would find the sidebar div now displays at 90% width after the content div. Note in the second screen capture, that styles from 2col.css such as the presentation of the list under the title image and the background gradient behind the headings are retained because of the handheld media designation in that stylesheet.

You may not want to retain any of your all media styles in the handheld CSS rules, as in this example. Keeping the background images, for example, results in longer page load times. Since many wireless mobile devices load very slowly, you want to really simplify things for handhelds. In that case, simply leave the handheld media attribute out of your main stylesheet. I’ll give you more tips for simplifying things for handheld media shortly.

Testing with subscription services or with software

The testing tools I just mentioned are all free. There are other options that are not free, but you might find them helpful and worth the expense. Browser Cam, where you can test your sites in all sorts of browsers, has added a testing area called Device Cam. Here you can test a page in a smattering of Windows Mobile-based PDAs and several BlackBerry versions. Here’s a screen capture of the test page in a Device Cam rendering of a BlackBerry. Note the strong resemblance to what you saw previously in Opera’s small screen view when the CSS was toggled off.

A brand new option for owners of Adobe’s latest CS3 software is Adobe’s Device Central. Device Central uses skins for dozens of mobile devices to display your content in various ways. Here’s a rendering of the test page in a Nokia 7390 skin.

Device Central can load a live URL or a file from many of the Adobe CS3 applications. It responds to the presence of a stylesheet of the handheld media type when the page is rendered using Opera’s small screen view. Using the Opera small screen view is an option with each of the skins in Device Central. Deselecting the option to view the rendering with Opera’s small screen view in Device Central rendered this page as two columns, in spite of the presence of the handheld stylesheet rules meant to eliminate that.

Tips for handheld CSS

Handheld media stylesheets can be more extensive than the two rule example I showed you previously. A few more rules would certainly benefit Web Teacher, but keep in mind that handheld stylesheets should be as small and compact as possible because of download time.

What can you do to simplify your site and make it more usable in mobiles? First, eliminate some of these problematic items from mobile display.

• Eliminate floats and frames
• Eliminate columns – one column with the content first is the best option
• Eliminate scripted effects such as popups or pop out menus in favor of plain old HTML and simple text menus
• Eliminate decorative images that slow down the loading process. Use display:none to remove anything that isn’t absolutely necessary, such as links to external resources. Remember, however, that devices that don’t understand CSS won’t do anything with display: none. Any essential images need to be reworked for the small screen and the width and height attributes need to be included in the HTML.
• Eliminate nested tables and layout tables. If you have tabular data, consider finding a way to present it in a linearized alternate display.

Once you’ve simplified through elimination, start building the rules you need to add. Consider these ideas.

• If you’re not already using relative measures, switch to ems or percentages rather than pixels
• Reduce margins, paddings and borders to suit the small screen
• Use smaller font sizes for headings and paragraph text
• If you have a long navigation list at the start of the page, add a skip to main content link, or move the links to the end of document flow. Keep the number of clicks required to get to content as minimal as humanly possible. Without a mouse or keyboard, most mobile users have to click laboriously through any top navigation.
• Make sure your color combinations provide good contrast between foreground and background colors, particularly for devices with fewer color options.

Tips for bloggers

Some blogging software provides the opportunity to format a single blog posting with several different templates, one of which can be meant for mobile users. This specially formatted and simplified material is posted to a unique URL on your site, perhaps something like mobile.mysite.com. If you’re a blogger, check your software to see if you have this capability with your blog. One important consideration for the mobile users of your blog is to keep the number of blog postings per page to a minimum for faster downloads.

In summary, making your site mobile friendly can be boiled down to a few concepts. Use validated, standards-based HTML or XHTML, ensure meaningful semantic markup with presentation removed to a stylesheet, and add handheld media rules as needed.

Coding for the mobile web —- Chris Mills

Introduction
Good evening — in this article I will aim to demystify the world of mobile web development, or in other words, developing web sites so that they will provide an acceptable user experience on mobile devices. I’ll run through how “the mobile web” differs from the normal web, the basics of techniques you can employ […]

Introduction

Good evening — in this article I will aim to demystify the world of mobile web development, or in other words, developing web sites so that they will provide an acceptable user experience on mobile devices. I’ll run through how “the mobile web” differs from the normal web, the basics of techniques you can employ to make your sites work sucessfully on both mobile and desktop browsers, some general DOs and DON’Ts for mobile web design, and numerous resources where you can go to find out more information.

How does the mobile web differ from the normal web?

This is a good question — first maybe we should start by answering the question what is the mobile web? after all, there isn’t a separate mobile web that users of mobile devices plug into, leaving the desktop web for when they get home in front of their home computer. When I say mobile web, I mean the Web as viewed through mobile devices.

At Opera, we passionately dedicate ourselves to creating browsers that allow you to view the whole web, regardless of (dis)ability or browsing device. There is one and only one web, and you can make this one web work for everyone on every device as long as you treat it with a bit of care and respect and follow web standards when creating your sites. There are exceptions to this rule however — in some cases separate mobile sites DO make sense, as you’ll see below.

The playing field is not level on mobile

In the desktop domain, things are getting pretty easy for us web developers these days — most modern browsers support web standards pretty well, be they Opera, Firefox (and other Gecko-based browsers) or Safari (and other WebKit-based browsers). Even IE is causing us less pain than it used to, although IE 6 is still used by an alarming number of web users, due to factors such as corporate lock in. The story is quite different on mobile devices however:

• You’ve got web browsers that offer support for the full web, like Opera Mobile and Safari on the iPhone. Opera Mobile uses the same rendering engine as the equivalent desktop version, so the standards support is about the same.
• You’ve got constrained browsers, ie, browsers with a limited support for web standards. A few of these still only support WAP (such as WinWAP,) some support other standards like cHTML or HTML MP (for example the Japanese NTT DoCoMo iMode browsers,) and some support a limited subset of the web standards (such as Netfront, Pocket IE, and Blazer.)
• Lastly, you’ve got Opera Mini, and other browsers that work via a proxy system. It mainly just acts as a client interface between the user and a big server farm. When the user submits a URL, the client asks the servers to look up the page. They then convert it into a lightweight binary markup language, format it for viewing on a mobile device, and send it back to the client for viewing. The major advantage of doing it this way is that the pages are reduced in size by up to 90%, saving the user lots of money on bandwidth. language Say what web standards do and don’t work well on mobile devices. Because of the way the service is set up, Opera Mini doesn’t handle some aspects of Ajax/JavaScript very well — this is explained in detail here.

Note: don’t expect your ultra-interactive Ajax and DOM scripting animated sites to work well on mobile devices. JavaScript support on mobile devices varies a lot. Provide fallbacks at all times. An example of this approach is called Hijax.

So as you can see, you’ve got quite a bit more to think about in terms of cross browser support on mobile devices. But never fear — my advice below will send you in the right direction, and as time goes on standards support will improve across mobile browsers, to the point where mobile web development isn’t really that much of a worry anymore. When will that happen? Who knows!

What are the other constraints of mobile browsers?

Of course, there are more considerations when developing web sites that work on mobile devices, besides just mobile browser standards support. You also have to consider the constraints of the device itself, such as:

• Limited controls — don’t just assume your user can control everything with a mouse, provide a keyboard alternative. Some mobile phone users may not have a mouse pointer equivalent, so constructs like :hover and onClick are useless to them (this is important for accessibility as well — some users may have disabilities that affect their ability to use their hands.) Also important is providing aids for inputting data — most of you will already know how annoying it is having to fill in a long web form using a mobile phone. To get around this, try to make as many things as possible selectable from a drop-down list, rather than expecting the user to type it in. Prefilling form fields with the most likely option is also a good idea.
• Limited screen size — think about how usable your beautiful intricate 1024 x 768 design will look like on a 240 x 320 screen, or smaller than that…there are some ways to plan for this — you can deliberately make your design very simple and fluid, or you can serve appropriate pages to a mobile device using capability detection or media queries and media types (more on this later.) Some phones will help you out in this regard, with mechanisms such as “zoom modes”, but you can’t guarantee it.
• Limited memory and bandwidth — mobile devices will obviously have less memory available than desktop computers, therefore you need to think carefully about those image heavy galleries, and interactive streaming video applications you we planning on putting on your home page! Again, some mobile browsers have the option of turning images off, but again you can’t be sure.
• Limited typography — wow, you thought you had it bad with typography on desktop computers? You ’aint seen nothing yet! There are exceptions to this rule, but a lot of mobile devices have very limited font choices, like 1 or 2. This is partly down to the system, and partly down to the browser.
• Limited colour palette — some mobile devices also have a very limited palette. Think about how much your page’s experience reiles on colour, and make sure that colour contrasts still work ok on mobile devices.

It is constraints like these that really make the mobile web experience different from the desktop web experience. Never try to kid yourself that the user experience on your site will be EXACTLY THE SAME on mobile devices as it is on desktop devices — this isn’t going to happen. You do however need to make sure that the experience is still a good one, regardless of browsing device.

The only way to be really sure that your site provides a good mobile experience is to test, test, and test again, on multiple devices. Some web designers have been known to have half a dozen mobile devices at hand to test on, in addition to their normal phone, desktop computers, and game console browsers.

Different approaches to the problem

It is generally recognized that there are three ways to approach the mobile development problem (this is corroborated by Cameron Moll — check his book out for more.) I’d recommend trying to follow way number three if possible — as stated earlier, at Opera we believe that there should only be one web — but as I’ve also said earlier, there are some case where this is difficult to achieve, and/or unnecessary. the three methods are as follows:

1. Do nothing except follow web standards.
2. Create a completely seperate mobile site
3. Create one site, but add code to optimize it depending on the device and browser looking at it.

Let’s now go through each of these in turn.

Do nothing except follow web standards and best practices

The foundation of every good web site is a good HTML structure, with CSS for style and JavaScript for behaviour. If you follow the standards carefully, there is a pretty good chance that most mobile browsers will be able to at least interpret your sites and render them in a manner that is basically usable. For example:

• A site with good logical source order structure and without decorative images in the markup will display logically in a mobile browser’s single column/mobile mode.
• If your form elements have label elements then the browser will make more sense of form fields
• If you also use good graceful degredation/progressive enhancement techniques for your CSS and JavaScript so that functionality not supported in browsers is either simplified, or ignored and an alternative provided, the chance of the site providing an acceptable user experience is increased greatly.

This is not a bad way to go, but there is more that can be done to improve the mobile user experience if you have the time and the knowhow to spend on it. If your target audience includes a great deal of users using either non-HTML browsers (eg Japanese browsers that support WAP or cHTML, then you may be forced to detect for the device and serve up appropriate content.

Provide a completely separate mobile site

As mentioned before, I think this way should be avoided if at all possible. You can do device detection and redirect automatically so that it doesn’t inconvenience the user base, but it does mean having to maintain two web sites. The main way to do this is to detect the browser via user agent sniffing or capability detection on the server-side, and then serve up the appropriate site. There are a number of good articles at dev.opera.com about how to do this — see the resources section at the end.

But there are exceptions, where a separate mobile site may mke sense — you’ve got to consider the user experience at all times. Some types of browsing device won’t be likely to make use of certain web sites, or certain features of certain web sites. For example, take a site such as a university campus that has search functionality for looking up department phone numbers, but also contains pages and pages of university history. You are likely to want to use the former on a mobile device, say if you are meeting someone but can’t find their department, but you are unlikely to want to sit and read reams of text on a mobile device while out and about.

In this situation, you could use some of the techniques described below to create a site that only serves a certain subset of it’s functionality to mobile devices, or it might just be easier to create a seperate site entirely for mobile devices. You could just detect what kind of device your users have and serve them the appropriate site automatically, making the process completely transparent to the user, but this is seen as bad by many — many people don’t like to be restricted like this, so if you are going to do it, provide a link to the full site so the user can try using it on their mobile browser if they wish.

One word of warning — device detection is very open to abuse. You often see a full desktop version of a site in all it’s glory, and then a really rubbish basic mobile site experience alongside it, because the developer is just dumbing the mobile site down to the lowest common denominator. It’s easier on him or her, but not fair on the target audience, as many mobile browsers can handle the full capabilities of the Web these days! You should instead be serving devices with as much capability as they can handle, and taking advantage of mobile specific benefits, such as location based services (LBS), and the tel: protocol, which can cause a mobile phone to dial a phone number when a link is clicked on.

Provide one site…

This is where it starts to get interesting. You can again rely on server-side capability detection, but optimize a single site for the mobile device, rather than redirect to a seperate site. There are databases of mobile phone capabilities availble, such as WURFL. This comes in the form of an XML file that you can query to find out the capabilities of a device, before sending it optimized content. You can also query the UA strings of a mobile device to find out details such as whether the device has a camera, what the screen dimensions are, and what languages it would prefer content to be delivered in.

On the client side, you’ve got a couple of options for optimizing content for mobile devices — media types and media queries.

media types

As you’ll no doubt already know, you can specify different CSS to be used for different purposes, for example:

the handheld media type allows you to target a mobile device with a stylesheet optimized for viewing on mobile devices (eg simplified layout, simplified typography etc.) It is a well-supported mechanism, and fairly simple to implement, but it does have it’s drawbacks. Again, it is often abused by developers to serve a site a crappy lowest common denominator layout. So much so in fact, that Opera Mini recently changed it’s default behavior from using the handheld stylesheet to using the screen stylesheet. Opera Mini can handle most full web sites, so it doesn’t really need to use the handheld stylesheet. You can set Opera Mini to use it instead if you wish by switching to mobile view in the browser preferences.

Media queries

Media queries are a CSS 3 construct that act in a similar way to conditional comments — you can enclose a block of CSS rules inside a media query, and then have them applied to your markup (or not) depending on a condition, such as “is the screen size less than 480 pixels”? Put into code, this would look something like the following:

img {
  margin: 0 0 10px 10px;
  float: right;
}

@media all and (max-width: 480px) {
  img {
    margin: 10px auto;
    float: none;
    display: block;
  }
}

You could even use a couple of media queries together, as follows:

body {
  max-width:800px;
  font-family:georgia, serif;
}

img {
  margin:0 0 10px 10px;
  float:right;
}

.info {
  position:absolute;
  left:8000px;
}

@media all and (max-width: 480px) {
  img {
    margin:10px auto;
    float:none;
    display:block;
  }
}

@media all and (max-width: 240px) {
  img {
    display:none;
  }
  .info {
    position:static;
  }
}

So in this example (source code available here,) images in browsers with a screen width larger than 480 pixels are displayed floated to the right, with the text flowing round them at a conmfortable distance provided by the margins. (There is an alternative message hidden in p elements with a class of info — check the HTML source out.) The text flow might start to look a bit crappy on smaller screens, where there isn’t enough room to have the images and an appreciable amount of text on the same line, so as soon as the viewport gets smaller than 480 pixels, the images are changed so that they no longer flow the text around them, but are instead displayed on separate lines using display:block. But wait — there’s more! If the screen gets far too small for the images to be displayed usefully, then they disappear, and the alternative messages are displayed in their places, to give textual descriptions of those pictures — this provides an alternative mechanism of getting that information across to the reader, and also provides a textual alternative for blind users using screenreaders to view the site. Figure 1 shows the three different display settings when the example is viewed in a browser that supports media queries, such as Opera 9.5.

Figure 1: The three different viewing modes of my example.

This sounds great, but what’s the downside? Well, browser support is currently very patchy for media queries. Opera browsers support them, so does Safari 3 (and other modern Webkit-based browsers), but Firefox <3 doesn’t, and neither does IE or other web browsers. One way to tackle this is to use a combination of media types and media queries. This kind of approach is explained in my article here. It is a workaround of sorts, but certainly not ideal. This should improve in the future.

Summary

That’s it for now. I hope my journey into the world of mobile development has been helpful. I’ve only scratched the surface here, so be sure to dig into some of the resources below to learn more.

Resources

• Mobile web design book, by Cameron Moll
• Designing and developing mobile web sites in the real world — a case study by Brian Suda
• Server-side capability detection for mobile devices by Brian Suda (includes more on WURFL, UA strings…)
• Ajax/JavaScript support in Opera Mini 4, by me
• Kristian von Streng Hæhre’s Opera Mini request header reference
• How to serve the right content to mobile browsers, again by my good self — includes media queries and media types
• Creating safe media queries that work cross browser
• Web design with Opera Mobile in mind, again by me
• The WURFL homepage
• The Opera Mobile homepage
• The Opera Mini homepage

Courtesy http://www.thinkvitamin.com