How to start building a mobile website
When I started on the latest redesign of this site some time ago (yes, well over a year ago Ben Kenny), I hadn’t really embraced the mobile web. I was focusing on the look and feel and the more technical considerations of getting my site properly themed in WordPress. It was near the end of the design and build that I realised that I couldn’t afford NOT to consider how this would be experienced on different devices.
The main problem was where to start. I started to look at ‘best practices’ and the very fact that I’ve rewritten this post a large number of times based on new (to me) knowledge is testament to how rapidly the mobile landscape is changing and how these ‘best practices’ are still being challenged and (re)defined.
I made some notes as I went along so I thought I’d cobble these together just in case I get amnesia and forget what the hell I’ve done it helps anyone starting to build a mobile website.
How to get started
There were a few decisions to make before I got started and this article on crafting media queries helped to get me thinking about this in more depth. The main conundrums I faced were:
- Mobile or desktop as the default?
- Media queries in one stylesheet or separate stylesheets?
- Use scripts or conditional comments for IE8 and below?
I went with a mobile-first approach as this seemed to make sense based on the kind of content I have on my site. With this in mind, I decided that the styles for mobile should be the default styles. This meant putting the styles for the mobile site into my main stylesheet before any media queries were used. I then decided to build in override styles for larger viewport sizes using media queries. There is a small issue in doing it this way though.
IE, my old ‘friend’
I’m being a little unfair here. I’m really talking about any browser that doesn’t support media queries, but IE 7 and 8 are the two big ones that fail in this regard. What happens to browsers that don’t understand media queries is that they will just render the default (mobile) styles.
This isn’t necessarily such a bad thing because although the users’ experience won’t be optimal, they’ll still be getting access to all the content. Luckily, there is a fix in the shape of respond.js. I decided that it would be good to give older browsers a bit of love, and I don’t mind the extra HTTP request.
The plan
Before I decided on any of the technical problems, I needed to have a plan. I decided to start small so I:
- Converted all of the fixed widths into percentages to make the site fluid.
- Added a media query to apply a different set of styles for mobile devices.
My whole thinking was to build a flexible site that applies new styles at certain breakpoints. I wanted to the flexible nature of the design do most of the work and add breakpoints when the layout started to break.
Making it flexible
My initial focus was converting those pesky pixels to percentages. I did this by hand, using a simple formula to work it all out. Although there are tools to help you with the maths, I thought the small amount of initial pain doing it manually would be worth it. It allowed me to gain a better understanding of how the flexible elements relate to each other.
The formula I used is one I first saw in Ethan Marcotte’s book: Responsive Web Design. I would recommend this book to anyone interested in responsive web design.
I won’t go into detail (as it’s been done better elsewhere) but this is the basic formula:
_target / context = result_
It’s easy to get lost when you’re sizing an element within another element that’s already had a percentage applied to it. For this reason, I’d advise putting the actual calculations in the comments like this:
#contact-main {
width: 52.083333%; /* 500px / 960px */
}
In the above example, you’ll know that the percentage is equivalent to 500px, so that will be your new context for any element that will sit within the #contact-main element when you come to do your sums. This means your new sums could be something like /* 200px / 500px */.
Media queries
Going with a mobile-first approach, I created the mobile (or ‘small screen’, whichever term you prefer) styles outside of any media query, effectively making these the default styles. The mobile-first philosophy also meant that I chose to specify a minimum width (rather than a maximum width or a min/max range).
@media only screen and (min-width:768px) {
[styles]
}
@media only screen and (min-width:980px) {
[styles]
}
These breakpoints are loosely based around those in Andy Clarke’s 320 and Up framework.
Where to put the media queries
There are largely two options:
- All in one stylesheet
- Each media query in a separate stylesheet.
I decided to put all the styles in one stylesheet. My main reasoning is fewer HTTP requests, and the ease of editing with all of the queries in one place.
Building and testing
As I have limited access to different devices my methods were pretty simple: a browser that was resized to different resolutions, a smartphone and the following tools:
This will give you an idea of roughly how the design will look but it’s certainly no substitute for testing on the kind of devices that your users may be using (as impractical as that may be for many people).
I found this list of mobile emulators after building this site so I’ll be checking some of those out. If you’re in a position to invest some of your hard earned cash then you there’s this guide to testing on mobile devices that highlights a base set of devices and OS’s for those on a budget. There’s also a recent article here that gives a timely reminder of the dangers of not testing properly.
What I’ve learned
To put it simply: a lot. There’s also a hell of a lot left for me to do to get this site working better. Here are some of the things I’ve found out:
- There’s no better way to learn the techniques you read about than to actually build something.
- The ideas behind responsive web design have pushed things in the right direction but they’re not the final answer.
- Finding a solution that doesn’t rely on JavaScript in some way is futile. I’m now at peace with the idea.
- New ideas and techniques are being invented daily and no-one really has all the answers.
- There is no one-size-fits-all solution to creating mobile sites.
- Anyone who says they’re a mobile expert is lying!
There’s a great article here that makes many good points including the fact that many mobile strategies focus purely on the technical aspects of a mobile website, often neglecting to look at how that the needs of a user change in a mobile environment.
This has certainly given me some food for thought…
7 Responses to How to start building a mobile website
-
Mungo says:
I was recently in this position and decided against the media queries approach by instead writing my own server-side code that detects whether the request came through on a mobile browser or not and if so render a mobile version of the stylesheet.
It made more sense to me to have two completely separate, dedicated, stylesheets as it seems cleaner in my mind (and doesn’t require any JavaScript), but I think both methods have their advantages and drawbacks.
Nice article though, Rob.
-
robjwood says:
Media queries are far from perfect, especially as you’re still downloading assets that the user won’t need. In an ideal world there’d be both server and client magic happening in harmony.
Is there a live example of your server-side method in action anywhere?
-
Ah, the 6 million dollar question.
I’m hoping to launch it in the next two weeks (it’s finished bar some content and integration with my app) so will post a link when I have.
-
-
Hi Rob,
Here’s the website I was on about earlier which uses that server side trick:
All the best,
Mark.
-
Mark, how does this work from a server side point of view? Do you have a huge list of mobile browsers and if one of them is detected it serves the specific stylesheet or is it cleverer than that?
Thank you please
-
Sorry for the delay – I didn’t get an email to say this thread had been updated.
There are only two stylesheets – standard and mobile but a class is also put in the body tag with the actual browser type (e.g. “ff3″) so you can tweak per browser without having to rely on hacks. (mobile or otherwise)
Essentially the server has a regular expression which checks against various names and versions in the HTTP header, determines if it’s a mobile browser – and if so prefixes the word “mobile” to any stylesheet – and then spits out the browser name for the body too.
Simples.
-
-
you being serious?