Mobile Web Best Practises 1.0 was a W3C recommendation originally put together in June 2006 by (among others) Phil, dotMobi, Vodafone and Opera. Despite it’s age and a constantly advancing industry, the content is still mostly relevant to today’s mobile web since it focused on the activity rather than the technology.
Challenges of the Mobile Web
When designing for the mobile web it’s important to think about people on the move. Different to designing for the desktop, you’re encouraged to design for the person first and the technology second. Ask questions like: why/where/when are they using my site? Understand the situation they may be in. There are some serious challenges to designing for handheld devices that must be faced:
- The screen is not very big. Yes it’s a limitation, but it’s important to meet this challenge and not make the user have to scroll from left the right.
- Input methods are different. Most phones have a numerical keyboard. You also might be walking whilst using it, or have other things on your mind. Think about the input paradigm.
- Pay As You Go customers. Data usage is important to keep low since not everyone is on a flat rate data plan.
- Advertising. It’s a small screen, respect your visitor, don’t allow your marketing department to take up all the space.
If you’re in the web industry, you may well have a decent smart phone. Remember, not every user has the latest and greatest gadget.
Things you must never do
- Pop-ups and target=”_blank”. Don’t spawn new windows on the mobile platform ever. If you do you risk leaving the user out of control.
- Graphics for spacing. Using graphics for part of your design is OK, but CSS was designed to describe spacing.
- Frames. Even if your mobile device supports frames, you can’t predict what they’re going to do.
- Image maps. Older devices don’t support these on the client side, some don’t even support it on the server side. Also, input elements of type “image” cause problems on handhelds because they’re too close to image maps. There are also associated accessibility issues.
- Tables for layout. A bad idea for accessible web design as well.
- Nested tables (for layout). These make a website a thousand times worse.
Things you are encouraged to do
- Design using a single column
- Create sites that don’t require zoom
- Provide basic navigation in one simple line at the top of the page
- Put other navigation at the bottom of the screen
- Dont obscure the content with an image
- Use progressive enhancement instead of graceful degradation
- Think accessibly, since there is a very close relationship between this and mobile
The concept of writing a website to suit every device, then extending it for those that can access extra features. Just as relevant on the mobile web as it is in accessibility. Phil’s advice:
- Fonts and colour – don’t use these to convey meaning.
- Tables – use sparingly, it’s better if you can get away with using an Unordered (ul) or Definition List (dl).
- Flash – which even the latest iPhone doesn’t support. Always have an alternative way to access this content. Also, use video but don’t rely on it. Again, bandwidth is a premium.
Can we have one web?
Is it possible to make a website that works on both desktop and mobile? Well, yes. And there are several ways to do it. Using the ‘media’ attribute you can use different CSS files to style for mobile and desktop. But you can also design your site to work for mobiles my default. See Phil’s examples of web pages that are friendly and unfriendly to mobile browsers.
If, as is his preference, you decide to stick to one stylesheet for all, his advice is to have the two most important links at the top left of the page and to focus the document’s content into one column. Phil has organised his site to prove that what he’s recommending is not purely theoretical.
CSS device detection
Even though CSS was designed to be able to deliver specific stylesheets to mobile browsers, they’ve had to handle lots of bad code and many mobile browsers are instructed to ignore it. Surprisingly… “The marketing departments of the device manufacturers don’t want to talk about the Mobile Web, they are keen to offer the ‘full Web’ and so top end devices ignore @media=”handheld” completely.”. See Dominique Hazaël-Massieux’s article on the importance of preserving the mobile experience.
Currently most mobile coding is lazy. For example, instructions like “display: none;” in your stylesheet only hide content and don’t prevent it being downloaded to the browser. This creates latency. But if you want CSS stylesheet switching without most of the worry of devices ignoring the ‘handheld’ declaration then you might try the Bushido Method. Developed by Dean Hamack at BushidoDesigns.net, it gives mobile device detection without using user agent detection or server side scripting (it doesn’t cover every device, but it’s good).
Device detection, going further than CSS
Although not 100% accurate, device sniffing is needed if you’ve decided to generate specific HTML. For this you can use a number of services including:
- DeviceAtlas Database from dotMobi (http://deviceatlas.com/)
- The W3C’s Device Description Repository Simple API
We’ve discussed changing style and content to suit the mobile context, but the guiding principle behind all of these tools is thematic consistency. For example your website may offer screen savers for desktop and ring tones for mobile. So thematic consistency and content are seperate, since content doesn’t need to be the same on the desktop and the mobile.
A good example of thematic consistency is the BBC News website. Like other good mobile sites, the BBC doesn’t split its mobile and desktop URIs. As has already been mentioned (link back to Linked Data), this is bad for search engine rankings. If you do need two URIs, only ever use one as a link and the other as a redirect (you could even use the REL attribute).
While checking content for consistency is down to the human, you can go some way to at least make sure that machines are happy with your code by using services like the mobileOK validator. As it says, to “check a web page for mobile-friendliness”. For example, Facebook currently gets a 70% score on this. The tool does 23 tests which are pretty smart – for example it warns if you have more than 20 resources requested by your web page. You can even display the mobileOK scheme logo if your pages validate (link and image). Additionally, there is now a BETA version of the new validator called Unicorn, pitched as one validator for web, this is meant to be a very good developer tool.
POWDER is a form of XML which shows that the whole of one website is mobileOK. There is a POWDER processor which converts the data into RDF. This then signifies that the given website is mobileOK and puts your site into the Linked Data ‘sphere’. This is the way to make that data available and mash it up with other data available for mobile web.
How can you justify any type of device detection (because it cannot be linked to, etc.)?
This is because you are designing for a user
You can’t make a mobile version of every page
Device detection can get you so far, as long as you don’t remove the control from the user
Is MobileOK testing similar to WCAG1.0 testing?
WCAG1.0 testing is similar to MobileOK testing (23 / 60 are machine testable cases)
There is a need for human testing just like with accessibility
Definition of widget from Opera evangelist – ‘mobile magic packed with web standards goodness’
Is there a page of arguments for and against various standards?
People have issues with mobile detection approach
There is a public mailing list
Everything is done in public with Mobile Web Best Practices
Will the mobile best practices be superseded?
Noone’s going to make a standard without being paid to do so
Our members support the standards by donating through their membership
‘W3C does not claim to be be-all and end-all’
If you want to influence any of the organisations you need to become a member of it
Various comments from the audience
‘I really wish that W3C was an open source group like Linux project’
You can use Opera Mini emulator that works pretty well to test designs in it
Ultimately you need to test on an actual phone
Yahoo have made a system called ‘Blueprint’ – you can write one mobile version which can be deployed to various devices – you write one language and it gets translated to relevant implementations
W3C has tried very hard to come up with ‘Content Transformation Guidelines’, but that has been very controversial indeed