Site icon Treehouse Blog

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 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:

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:

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:

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 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

Exit mobile version