Max Maxwell runs www.singforjoy.org.nz, and had heard the advisory warning from Google, at end of 2014, that mobile-unfriendly sites would gradually descend in its search listings. He asked me if I could protect him against such a woeful fate.
I admit to being something of a Luddite when it comes to mobile phones, but of course recognise my minority status in that regard. I had never worked on the mobile aspects of web design before, and I was quite keen to learn about this new specialisation of web development.
The isssues and techniques for mobile sites are evolving and still seem somewhat in the wild west frontier stage. Sing For Joy is a pretty straightforward site and I was determined to ensure that Max didn't have to write two sets of content, separately for desktop and mobile.
The three very basic technical aims for a mobile conversion are:
- make sure your mobile users don't have to scroll horizontally, only vertically. This mainly amount to avoiding fixed width above 320pixels (at the minimum) or conditionally allow them at a couple of higher levels dependent on the device. Often you have to hide the classic wide banner picture, replace with a smaller one. And if you have several panels normally side by side, use CSS to ensure that they move down to the left and arrange themselves top-bottom on a narrow screen. There are very many helpful pages of device sizes, of which I found this one to be the simplest.
- Make sure your menu navigation is easy to find; typically change it to a vertical list just below the header with one item per row (unless your links have very short text). Also, ensure that the menu items are spaced sufficiently for stubby, inefficient fingers to stab at them reliably.
- Keep your fonts large enough to read.
There are several techniques for handling mobiles and we used a blend of two:
- PHP choice: I decide to offer different markup for the page header for desktop and web, using the tests supplied by the mobiledetect.net PHP library. This allowed us to show a mobile display with a header image then a reduced menu below that. For desktops we preserved the complete layout with left hand menu and right body content.
In the desktop version, the left column, with menu and testimonials, is quite long and not easily adapted to mobile.
- CSS media queries: for mobiles, we ditched the great landscape header photo of Max's choir at work; and adopted a colourful. non-photo logo, which was easily scaled down to the 300+pixel size which is agood starting point for mobiles. Then it was an easy bit of finesse to offer small and large logos for different standards of devices, switched by a CSS media query:
@media only screen
and (min-width : 401px)
and (max-width : 480px)
There remained some small adjustments for font sizes and spacings, et voila. And the only page which was a partial duplicate was the home page, meaning that Max would not have to make similar edits twice to keep his site up to date.
I was very pleased that all this was achieved with no prior mobile knowledge, in under 10 hours of work.
You'll find your conversion is a lot easier if you've used CSS styles all the way through on the original. If you've used inline styles, you may find you have to move those into CSS sheets so that you can apply a conditional media query.
How do you know if you've done enough? Even looking at your site with your own mobile isn't enough of a test, because there are several different classes of mobile (mainly varying in screen resolution). As always, Google comes to our rescue with their "Mobile Friendly Test". And it is indeed a friendly test, in the familiar Google tradition. It will test a page (not a whole site) for how it satisfies the important mobile requirements. It's a great thrill to see "Awesome! This page is mobile-friendly". Don't just do the home page: make sure you test several key pages on your site, to get a fair judgement. And also, don't bend over backwards fixing every single page - there will probably be some pages that are either too hard to fix, or too unimportant. Keep a sense of perspective.
Since doing this work, I discovered the Bootstrap system, which had been partly implemented on another (big) project. I was very impressed by its simplicity. I'd guess it is best implemented from scratch, maybe not so suited if you are retrofitting to a large project. I look forward to applying it in earnest some time.
While developing your changes, you could check each time on your mobile device; however I found it far easier to use the "trestwebresolution" page at infobyip.com. This lets you pick a device or manually set a screen resolution, and see your site within those constraints. (It's only mimicking the size, and doesn't judge things like whether the links are too close together). I was surprised that it could see your "localhost" and virtual host sites (fellow nerds will know what I mean), not just sites on the internet. It simply makes an Iframe of the required size, and pastes your URL there. (Of course, in the end, you should still check on some real devices). The Firefox Developer toolbar also has a resize option - but at narrow sizes, this greatly obscures the output from Firebug, so it's not as good as infobyip.
Also regarding sizes: your principle intent is to get rid of a horizontal scrollbar, which will tell you that the mobile user need only scroll up-down in the preferred manner. But don't waste time (like I did) on one diversion: no matter how much CSS I tweaked on one site, I couldn't get rid of the horizontal scroll bar. I could see it was only representing a couple dozen horizontal pixels. Eventually I realised the reason: the page was a tall page, so the infobyip Iframe needed a vertical scrollbar; the thickness of that vertical bar ate into my limited horizontal resolution, hence I got only abut 460 of my 480 pixels. And hence the Iframe applied a horizontal scroll bar as well. In other words, to mimic a 480-wide mobile with a tall page, you should ask for about 500 pixels wide with infobyip or similar utility.