Coding for the mobile web page
Good morning — 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
:hoverandonClickare 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:
- Do nothing except follow web standards.
- Create a completely seperate mobile site
- 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
labelelements 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 href="http://dev.opera.com/articles/view/how-to-serve-the-right-content-to-mobile/">explained in my article here. It is a workaround of sorts, but certainly not ideal. This should improve in the future.
via:thinkvitamin
Labels: CSS
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home