How to make your website mobile compatible
5th Sep 2010 | 11:00
What you need to know about mobile compatible websites
Building mobile websites
The days of building websites targeted solely at desktop or laptop environments are over. Users can and will access your website from a variety of internet-enabled devices.
Accessing the web from mobile devices is far from new. However, the popularity of smartphones and cheaper data packages from network providers have driven a sharp rise in mobile web usage, which is not just reserved for the latest and greatest smartphones.
As website owners, mobile devices also offer some fantastic features typically not available on the desktop – functionality such as clicking a hyperlink in your website to call your phone number, or adding your contact details to an address book. And with more advanced devices, a mobile website can provide more targeted, location-aware content for your visitors.
MOBILE FONTS:Computerlove's Advanced Profile on the iPhone demonstrates how the @font-face technique can be used to bring brand fonts onto a mobile site
With the growing importance of mobile devices and the diversity of access it brings, it's vital as website owners, designers and developers that we think smarter and broader about how we enable visitors to engage with our sites.
You need to have a clear policy and strategy in place for making your website accessible to as many internet-enabled devices as possible. Over the following pages, I'll look at some key lessons the team at Code Computerlove has learned while developing mobile websites. I'll cover general hopefully use and apply to your own websites.
Which technology for mobile sites?
The first question you may be asking is: What technology is involved? Well, a technology stack, served by your existing web server, and utilise your existing web development skills. You use XHTML and CSS. There's no need to invest in learning a new formatting language or resurrect an old one such as WML (Wireless Mark-up Language).
At Code Computerlove, our base-level entry devices have to support WAP 2.0, which in turn supports XHTML-MP (Mobile Profile) and WCSS (Wireless Cascading Style Sheets). We also target high-end devices that fully support XHTML and CSS through to HTML5 and CSS3.
XHTML-MP is simply a subset of XHTML for mobile use and WCSS is a subset of CSS. Whilst XHTML-MP has been adopted and superseded by the W3C with XHTML-Basic 1.1, it's still the most widely supported XHTML variant. If you know XHTML, you already know XHTML-MP and XHTML-Basic. The same applies for WCSS.
However, at the lowest level, like the desktop version of your website, the mobile website should still work without them.
To reiterate, mobile websites are built using existing web technologies. The main challenge is that given the sheer diversity of mobile devices, support for these technologies is inevitably inconsistent.
Certain devices may not support particular features, or features common to devices may be implemented in different ways. So how can you be sure your mobile website will look and act the same on all mobile devices if they all implement the technology in slightly different ways? How can you test your mobile website effectively? How can you assure your clients that their mobile website will work flawlessly on all devices?
BASIC PROFILE:The Basic profile of the site on OpenWave shows the lowest common denominator
The simple answer to these questions is … you can't! It's a tough call to make, but an important one. It's logistically impossible to set up and test all of the XHTML-supporting mobile devices that are available, as well as dealing with quirks that each device offers.
Ironically, appreciating this early on will actually help your build, testing and quality assurance processes. At Code Computerlove, we came up with a two-pronged approach to help us deal with this diversity.
Firstly we agreed to support at the lowest level, only those devices that support XHTML and CSS. Secondly, we used the concept of 'device profiles'. A device profile is simply a way of logically grouping devices.
The criteria for each group can be based on device capability, manufacturer and operating system, or by any other criteria. We created three core profiles. The 'Basic' profile covers low resolution, text-only devices. The 'Intermediate' profile includes devices that support images and have a screen resolution greater than or equal to 240 pixels (such as the BlackBerry, Nokia N95 and Nokia Xpress).
Finally, the 'Advanced' profile includes the latest smartphones based on WebKit browsers, such as the iPhone and Android phones. These profiles help us both to generalise and specialise device capabilities. They help us form a design, build and testing strategy, as well as enabling us to demonstrate to our customers how a mobile website experience will differ between diverse mobile devices.
These profiles are not set in stone. Neither are they static. Profiles may vary between projects and customers. They reflect which agreed device features are to be targeted, as well as the specific handsets we need to support.
During the life cycle of a website, new profiles may be added and old profiles removed. Additionally, they require regular reviews to guarantee their relevance and to ensure that new devices entering the market are properly assigned to the right profile.
Device profiles play an important part in our build process. We assume that all devices adhere to the basic 'text-only' profile. This is our default, fallback profile that will work on all devices. We then progressively enhance a site for subsequent profiles.
INTERMEDIATE PROFILE:The intermediate device profile for the First Group TransPennine Express site shows how it looks on more advanced mobile devices
For example, the Intermediate profile introduces a wider colour palette and the use of images. The Advanced profile extends this further by using advanced CSS3 techniques or more interactive scripting elements.
Device detection, testing and structure
So how do you determine whether a web page request is coming from a mobile device? And secondly, how do you determine what profile a device belongs to?
We do this by simply inspecting a web browser's user agent details and matching them up in a device capability file, which contains extended details about the device. Each web browser has user agent information about itself, such as vendor, version or operating system.
Irrespective of whether a browser is running on the desktop or mobile device, whenever it requests a page from a server, it also sends this information as part of that request. A server can then use this information to determine whether a request has come from a mobile device or not and what capabilities that device has.
To help with this, there are a number of publicly available 'device capability' files that you can use with your server-side technology. These files contain extended information about the web browser and device accessing your site, such as screen resolution, colour depth, image support, touch screen support, manufacturer and operating system.
These database files come with a number of pre-built helper methods, enabling you to integrate them easily into various server-side web technologies such as PHP, ASP.NET and Java.
At Code Computerlove, we use the paid-for subscription service DeviceAtlas. For a minimal yearly cost, this service provides us with regular database updates as well as an online database for browsing phone capabilities.
There are of course alternatives, and a popular open source project called WURFL (Wireless Universal Resource File) is available from wurfl.sourceforge.net. Alternatively, you could write your own user agent detection routine!
How do you test your mobile website and device profiles? There's no substitute for using real physical devices. Not only will you see precisely how the site will look, but you'll also experience any hardware challenges that the device will throw up, such as screen size or quirky input mechanisms.
Physical testing on every single device is, of course, logistically impossible. But you should try to obtain a few devices that fit each of your device profile characteristics. And if you're building a site on behalf of a client, it's worthwhile trying to get hold of the common handsets they use. There are also a number of software-based testing tools you can use in your daily build and testing process.
TEST AS MUCH AS POSSIBLE:The more devices you can test on the better, but testing on all devices is next to impossible
For testing your mobile site within your desktop browser, use the Firefox User Agent extension. This extension changes the browser details that are sent to your server, spoofing the server into thinking you're accessing the site from a mobile device.
It's important to note that you'll still be viewing the website via the Firefox rendering engine, not how it will be actually rendered on mobile devices. What it will show you, though, is an approximation of how your site will look across various device profiles.
For greater accuracy, there are a number of device simulators available for you to install on your development box for BlackBerry, Android, and iPhone to name a few. Furthermore, there are hosted options offered by Opera, Nokia and Device Anywhere. The latter is a paid-for service hosting thousands of genuine mobile device simulators.
IMPROVING ALL THE TIME:The Intermediate profile on a BlackBerry shows improved formatting and imagery
Perhaps one of the most useful tools is the now-defunct OpenWave simulator. It's fantastic for experiencing your mobile website against a small resolution, text-only device profile. Due to its limited nature, what you'll get is an immediate indication of whether your navigation and content work for mobile.
Throughout this article, I've been discussing mobile websites as distinct entities from desktop websites. But do you need to build separate websites? Do you need separate URLs for your mobile website?
There's no right or wrong answer to these questions. In an ideal world, your website should be accessible to all devices – desktop or other – and be capable of rendering itself where possible, using the same content and navigation structure.
This singular approach works brilliantly if you know from the outset that your website is to target multiple devices as this can be factored in accordingly when planning structure, layout and content. However, if you have to retro-fit mobile onto an existing desktop site, it may be easier to run the two as separate sites.
Navigation and content that traditionally works well on the desktop may not when displayed on a mobile device. Desktop navigation may seem unnecessarily complex on a mobile device, and content may need rewriting, either to be shorter and more immediate or to be split across multiple pages.
As the amount of server-side branching logic increases to alter navigation and content for desktop and mobile, it's then a case of either re-evaluating your design, structure and content or, if the two sites serve slightly different objectives, running the two as separate instances.
At Code Computerlove, we've separated out our desktop and mobile website. We've found this easier when internally managing site assets such as style sheets, scripts and images and server-side logic.
We are, however, in a convenient position in that our content management system enables us to share content between multiple websites. So, while both are distinct sites, there's crossover and shared content between both.
Do you need a separate URL to distinguish your mobile website from your desktop website? Again, there's no right or wrong answer to this: it's purely down to your own requirements. You don't need a '.mobi' domain, an 'm.' subdomain or a 'mobile' folder as part of your main website's URL.
At Code Computerlove we've used the 'm.' sub-domain approach for mobile – for example, m.codecomputerlove.com – and www for desktop, as this suits our requirements.
If a mobile device browses to the desktop URL, it's redirected to the mobile site. The mobile site contains a hyperlink that enables the visitor to navigate back to the desktop site if they wish to. Conversely, if a desktop browser visits the mobile site, we don't force a redirect back to the desktop version.
Structure and content
Due to restrictions on screen real estate and the various input mechanisms used by mobile devices, relying on a traditional multi-column desktop-based layout doesn't work. This is true even for smartphones that accurately render desktop websites. The novelty soon wears off when scrolling through and zooming around desktop-targeted websites.
At Code Computerlove, we've developed a standard template structure for our mobile websites, initially based on a template that can be found at MobiForge.
This template follows a single-column, fluid-width design. What this means is that the user need only ever scroll vertically and that the page always fits the available width of the mobile device's web browser. The template is purposely 'light'. It encourages simple navigation with tightly written, relevant and focused page content.
Additionally, the template promotes the use of clean and simple XHTML markup that mobile devices with limited processing capabilities, memory and variable network speeds are able to render quickly.
MOBILE TEMPLATE:This diagram will give you an idea on how to structure a mobile website
The template is composed of a header containing the company name or logo; top and bottom breadcrumb trails displayed on all pages except the homepage, enabling the visitor to navigate back through the site with ease; a page content area; sub-navigation links; and a footer containing copyright information plus, more importantly, a hyperlink to the desktop version of the site.
Final tips and tricks
To wrap things up, here are a few final tips and tricks to help with your mobile website development:
Mobile-specific META tags
A number of XHTML META tags that are specific to mobile websites can be used in addition to the common tags such as author and description. A review of these can be found here.
One important one is the viewport META tag, which can be used to set the initial scale of the width of the site to fit the screen. This is especially important for iPhone browsers. It forces your mobile website to fully fit the screen at the correct resolution and prevents the user 'zooming' into a page, for example:
<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;" name="viewport" />
CSS and presentation tips
Given the variable nature of screen resolutions, it's best as a rule to stick with relative units such as percentages and ems. Relative units will help when it comes to making a quality and scalable mobile design. With perhaps the exception of more advanced smartphones, fonts and sizes are in general poorly supported.
It's best to assume that most devices will only use their default font faces and sizes for XHTML elements. CSS background images tend to be well supported. However, your design must work well in the event that they aren't.
We did find a glitch with BlackBerry browsers. To ensure maximum support, make the URLs to your background images absolute, not relative, to the style sheet.
Image resizing and scaling
It's preferable not to push full-size desktop-targeted images to mobile users. Where possible, ensure your images are optimised accordingly. There may be instances where you need to scale images dynamically on the server to match the screen resolution you're serving to.
If you're using DeviceAtlas for browser detection, you can obtain the actual screen width of the web browser and rescale the image accordingly, using such tools as ImageMagick or any other server-side image manipulation library.
First published in .net Issue 205
Liked this? Then check out Mobile web design: platform by platform
Sign up for TechRadar's free Weird Week in Tech newsletter
Get the oddest tech stories of the week, plus the most popular news and reviews delivered straight to your inbox. Sign up at http://www.techradar.com/register