Important: Please note that most of this information is now out of date.
The release of Apple's iPhone has injected new enthusiasm into website design for mobile phones. Previously, the user experience for everybody was appalling. On my old(ish) Nokia, despite using the Opera Mini browser, even trying to access my email account is so frustratingly fiddly as to make it not worth the effort.
Now, at last, the iPhone interface has heralded a new mobile web dawn which all phone companies are keen to emulate.
In February 2009 usability guru Jakob Nielsen published an article entitled Mobile Web 2009 = Desktop Web 1998, in which he wrote:
“we're turning a corner in mobile Web usability. Just as Apple's Macintosh heralded a breakthrough in personal computer usability 25 years ago, its iPhone is pioneering a similar breakthrough in mobile usability today.”
The truth of the matter is that although the iPhone offers an experience comparable to the desktop environment, nearly all other handsets do not, making designing for mobile phones as challenging as creating HTML email newsletters.
In both cases, the use of CSS and HTML is as essential as that for desktop browsers, but their use for both mobiles and email newsletters requires following special procedures.
The content on both these platforms too has to be radically different from that on a desktop, or “normal”, website – less is the key to success here.
I've been meaning to recode one of my websites, Press Release 001, for sometime. It is a free press release distribution service and needs a more formal structure than it has at present. However, I couldn't resist creating a sister site first especially aimed at mobile phone users.
When designing for mobile phones the first aspect to think about is to decide whether just to modify the website or create a new one with its own domain – there is even a domain prefix called .mobi especially created for this purpose.
Design for mobile phones is so radically different that I would recommend starting from scratch on a separate domain. In my case I created a sub-domain called just m, or www.m.pressrelease001.com.
The main body uses the Drupal CMS and although it would have been fairly straightforward to install Drupal on the sub-domain and access the same database, I thought it would be best to handcode the new site.
I also decided to go for a low common denominator by following these guides.
- CSS to be in the head of the document rather than in a separate sheet.
- The cascading in Cascading Style Sheets to be ignored, meaning that only single classes and ids to be used one at a time.
- Images smaller than 200px wide – I actually found the 85px x 15px size perfect for a logo.
- Use XHTML Mobile 1.0 – although I'm sure XHTML 1.0 Strict would do just as well (The Guardian mobile site uses HTML 4.01 Transitional).
- Use accesskeys for links to enable easy user browsing.
- A light background under any link because many mobiles often paste a horrid blue over them.
But before any of that you need to decide what content to use. In fact, you'll be discarding more content than you use from the parent site because you'll need to keep it simple.
[If you are looking for a web designer in east London then please visit web design Stratford]
The problems with mobile browsing are of slow download times, tiny screens and a different style of keyboard.
All these problems make using a mobile for web surfing a difficult process at the best of times and your job as a web designer is to ease the burden that the technology places on the user.
In terms of content I decided just to use the press releases that are published on the frontpage of the main site. Forms for joining and submitting items are too complex for a handheld device.
Even then, it was clear that press releases of 1000 or 1500 words long would not be suitable for a screen 320px wide (some screens are even smaller at 128px or 176px); so I decided just to publish the summary.
The features of the site would be: the ten latest press releases split across two pages; with the title, summary and link to the relevant website so the user can seek further information if they so so desire. These links to other websites are clearly labelled as such so users are aware that they are leaving the site.
Basic, yes, but it's a good starting point – I'd rather aim to create a bare bones of a site first and then add more features and content later on if necessary.
I never used tables for this site but it is, like designing for email newsletters, a very common technique on a mobile site.
Another aspect that is unique to mobile sites is the use of the viewpoint meta tag, which looks like as I have used below:
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0;"/>
To break this down: the first attribute is the width as written in the CSS file so it could read 740px if that is the width of your site although I just used the generic term “device-width”. The other attributes, initial-scale and maximum-scale, are for iPhone and Blackberry – you can also use user-scalable and minimum-scale.
Rather than spend time here going into details about these it's best to play around with the settings and see how it affects the look of your site in either the iPhone or Blackberry browser, or read more about them here: http://developer.apple.com
Of course, if you do have a mobile sister site can the user find it? There are a number of scripts available that automatically tell if the user is accessing the site from a handheld device and then flip to the right site without user consent, but I would caution against them. For one, the sheer multitude of different phones means that it could be a buggy experience and I really believe that is up to the user if they want to access the mobile site or the “normal” version.
What I did was add a link just under the body tag of the parent site so that if anybody does access the parent body from a mobile the very first item will be a link with “mobile version” as anchor text.
The difficulty comes in testing your site.
The daddy of them all is DeviceAnywhere, who don't offer simulators but remote access to over 2,000 different handsets. You can sign-up and use their service for free for up to six days, but you should read the 300 page PDF user guide first and be warned that you must be familiar with the handset that you wish to use as you need to know how to access its browsing capabilities.
One good idea is to look at the mobile sites of big news corporations or other types of large companies. If they have specific mobile sites then you can guarantee that they would have spent considerable time and money perfecting them – take a look at the code and piggyback off their experience.
I really look forward to the day, coming soon, when mobile sites mature enough to receive recognition as a creative endeavour distinct in their own right.