Thoughts on branding, design, writing and life by Kevin Potts. Established 2003.

Mobile Site Development Made Easy

Building mobile versions of client websites has become part of my regular service as a freelancer. Here are some of the things I’ve learned along the way. (Plus some snappy links for technical deep dives.)

I know these “9 Billion Tips For Mobile InterWeb Development” are popping up all over the place, and not just for cheap SEO reasons. There really is a disparate list of random tips and tweaks that make for easy list-writing, and I wanted to highlight a few of the core tricks that make the production of mobile versions easy. Like print style sheets, it’s something I’ve rolled right into my regular set of services because these days, there is no reason a site should not be optimized for different screen sizes.

Over the past dozen or so client projects, I’ve settled into a quick groove that makes mobile development snappy.

Build for iPhone, Others Will Fall Into Place

I do this for several reasons. The iPhone is the smartphone that matters. While there may be more total Android devices out there and Nokia is bigger than Hasselhoff in Europe, the web-browsing experience on iOS has been spectacular since the first generation. People buy an iPhone to browse the web, and they expect a good experience.

More importantly, getting the mobile version right in the iPhone means getting it right in others. Webkit is used in many devices, the screen resolution is about average, and it uses touchscreens, which are a bit more finicky than the traditional point-and-click of a device like the BlackBerry Curve. In my decidedly unscientific tests, a site that works in iOS works perfectly in different BlackBerry devices, the Palm Pre, and others.

Apple defines trends. Optimize for them, and almost by definition you’ll stay ahead of the curve.

Forget Most JavaScript

There are many different functions of JavaScript: analytics tracking scripts, controlling Ajax content and modifying the DOM, producing enhanced UX functionality on the front-end, and much more. The issues on mobile arise for the last bit.

A lot of visual whiz-bang effects written for large screens loses a lot of potency on mobile browsers. jQuery UI effects like sliders and accordions fall apart because of no touch support, photo galleries collapse in small widths, and lightboxes break very quickly. In these instances, a website must operate without JS support. I don’t even load jQuery UI for my mobile sites.

There are two ways of hiding the loading of extraneous scripts: client-side and server-side. PPK shows a quick JavaScript method using screen.width conditionals. I prefer doing this via PHP, and find Andy Moore’s lightweight detection script invaluable for this task. Every kilobyte of JS not loaded by a mobile device is one modicum of better user experience.

Placement of Media Queries

CSS3 media queries are by far the most efficient means of altering the display of a page based on screen dimensions and density. A lot of articles discussing this recommend a separate CSS file optimized for mobile in addition to the desktop version. They might be loaded like this:

<link rel="stylesheet" href="desktop.css" media="only screen and (min-device-width: 481px)" />
<link rel="stylesheet" href="mobile.css" media="only screen and (max-device-width: 480px)" />

This works, but it’s not always efficient. For instance:

  • Older IE does not recognize media queries, so desktop.css has to be called a second time inside a conditional comment. Unnecessary page weight.
  • Because some of the core color and type styles will be repeated between both desktop.css and mobile.css, it’s one extra step to maintain consistency. It also means a lot of repeated code.
  • If you ever wanted to create a third style sheet (maybe for the iPad), you would have to add yet another CSS file to the set.

If you add the media queries inside a single CSS file, you avoid the need to treat IE separately, have built-in consistency with core visual styles and no code repetition, and can easily scale the file to alternative sizes and pixel densities. However, this also has downsides:

  • The CSS file itself is a larger initial download. Based on my work to date, it’s about 15-20% more code.
  • If the CSS file calls a lot of assets such as background images and fonts, they’re going to be downloaded for both desktop and mobile. A separate mobile-only CSS file could exclude these.

The second point is the real killer, so weigh the options carefully. I tend to work in one single file, but your mileage may vary.

Go For Speed

In the wonderland of mobile, it’s all about bandwidth. Speed matters, and it matters big time. Here are the simple tricks that help me make things go a little bit faster:

  • Compress everything, even the HTML.
  • Minification is cheap and easy. I love this simple PHP minifier.
  • CSS3 “effects” over images. Rounded corners, gradients, bevels, shadows and all sorts of other goodies can be rendered at lightspeed with a few lines of CSS, and obviates the need for bulky images. Less to download and fewer HTTP requests makes everyone happy. For those on older IE … well they just get square corners and no nice shadows.
  • Avoid unnecessary font-face rules. I just finished a client site that used League Gothic, and it costs me 84.7 kb to load the four file formats. Ugh.
  • Put the necessary JS at the bottom of the page so it’s called last. But you already knew that.

Optimize for the Viewport

Beyond media queries, there’s only two things you need to add to make your mobile version sing. This bit goes into the CSS file:

-webkit-text-size-adjust: none;

This avoids the iOS’s bizarre need to fuck with font sizes every time you turn a device on its side.

Also, the viewport meta tag should be loaded at the top of the HTML page. There are a bunch of attributes, but the base installation is best:

<meta name="viewport" content="width=device-width" />

This sets the width correctly and still allows the user to zoom into selected areas. To prohibit zooming, the following can be used:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

However, removing the ability to zoom is an accessibility barrier, and should only be used for application-level sites where the dimensions are critical to a better user experience. For content-driven sites, this is rarely the case.

More Technical Advice

Here is where those “9 Billion Tips For Mobile InterWeb Development” articles come in. These are a few I have found valuable.

, ,

commentary + criticism

nuova simonelli

wrote the following on Wednesday August 11, 2010

Nowadays, the number of people accessing the Internet with their phones is exploding. It is therefore imperative that most of the companies web presence has a properly formatted version to allow quick and easy browsing for us. Can’t say how friendly it was but they made it so easy! Thanks for the useful information.

Richard, Joomla Developer

wrote the following on Tuesday November 30, 2010

All good advice.

As much as I hate the retrogressive step to multi-versions of a site, I do wonder whether to some extent whether a completely new phone version would be the better approach, than just re-styling using CSS.

CSS is good for changing the look of a site, but often phones may require different functionality on a site to work their best, and you are going to be limited if trying to do that with CSS alone.


wrote the following on Wednesday December 1, 2010

Go For Speed:
I think, speed isn't only importent for mobile sites – it's very import general. Because page speed is a ranking factor in Google.

Gunnar Andreassen

wrote the following on Tuesday December 14, 2010

Totally agree on “Build for iPhone first statement. Once the basics are done it's easy to add Android etc.


wrote the following on Friday February 18, 2011

I think, people are using more and more iphones and mobiles these days and its very important to code keeping this in mind.

Thanks for the useful post.