Blog

This morn­ing a Tweet piqued my inter­est; “FT​.com launches sub­scrip­tion web app aimed at Smart­phone & tablet users bypass­ing app store tar­iffs”. An inter­est­ing con­cept, so I fol­lowed the link which took me straight to the FT​.com web­site. Now, if there’s any­thing that’s going to drive me away from a web­site it’s a pop-​over — except, that is, a pop-​over when I just hap­pen to be try­ing to access your site using my mobile. This is what I got:

Screen­shot of the FT Pop-​over on an iPhone

The irony that the arti­cle was about a ser­vice aimed at Smart­phone users was’t lost on me.

There are numer­ous steps you should com­plete before launch­ing a new web­site; cross-​browser test­ing, check­ing for dead links, proof-​reading. These are cov­ered more than ade­quately else­where but in this arti­cle I’m going to look at a num­ber of steps applic­a­ble specif­i­cally to launch­ing a Dru­pal site. You may not agree with them all, but then none of the fol­low­ing are com­pul­sory — these are just my per­sonal recommendations.

There are numer­ous steps you should com­plete before launch­ing a new web­site; cross-​browser test­ing, check­ing for dead links, proof-​reading. These are cov­ered more than ade­quately else­where but in this arti­cle I’m going to look at a num­ber of steps applic­a­ble specif­i­cally to launch­ing a Dru­pal site. You may not agree with them all, but then none of the fol­low­ing are com­pul­sory — these are just my per­sonal rec­om­men­da­tions. Rather than sim­ply list them as bul­let points, I’ve tried to give some of the ratio­nale between these tasks, and point­ers to online resources where I can.

There’s cer­tainly a big buzz right now about respon­sive web design; flex­i­ble lay­outs that adapt dynam­i­cally to the user’s device and its capa­bil­i­ties; screen size, res­o­lu­tion and so on. One of the major uses for this tech­nique — a com­bi­na­tion of flex­i­ble grids, resize­able images and CSS media queries — is as a mech­a­nism for cre­at­ing a mobile ver­sion of a site. And it’s a very use­ful approach — dynam­i­cally chang­ing the lay­out accord­ing to your device’s capa­bil­i­ties enables con­tent to be re-​structured for the small screen with lit­tle effort. Also, putting the onus on the device to inter­pret the style rules makes sense, remov­ing the need for messy, server-​side browser detec­tion based on user agent strings. How­ever as tempt­ing as it might be to use this tech­nique as your sole approach to mobile-​enabling a site, it is to ignore a num­ber of other fac­tors and issues preva­lent in design­ing — and build­ing — for the mobile web. Dis­play­ing a web­site in such a way that it looks bet­ter on a mobile device is only a part of the process for cre­at­ing a mobile ver­sion; there are other fac­tors which should be con­sid­ered, such as how and where the mobile ver­sion of the site is going to be used, a user’s moti­va­tion for using the site and assess­ing what is appro­pri­ate for the mobile-​friendly ver­sion of the site. Whilst it is true that some peo­ple will only ever visit your site from a mobile device, it is likely to be used dif­fer­ently and should be tai­lored as such — it’s not just about mak­ing it look right on a small screen. For exam­ple if I’m access­ing the RAC web­site via my mobile, it’s much more likely I’m doing so for break­down assis­tance or real-​time traf­fic infor­ma­tion, than research­ing my options for car insur­ance. Inter­faces need to be con­sid­ered care­fully on a mobile site; it’s not just about styling. If I visit a web­site for a cin­ema chain I’d expect some­thing like a drop-​down where I can select the cin­ema I’m inter­ested in; on their mobile site they’d be miss­ing a trick if they didn’t use geo-​location to save me time. My sec­ond argu­ment is more prag­matic and tech­ni­cal. Take the sim­ple exam­ple of a blog, with a typ­i­cal two col­umn lay­out — using media queries, the right-​hand col­umn might be shifted below the main con­tent area (i.e. the arti­cles). Or per­haps the ter­tiary nature of a typ­i­cal right-​hand col­umn means it can be stripped out alto­gether. How­ever this cre­ates two major inef­fi­cien­cies — the HTML is fetched from the server and never used, and typically-​dynamic con­tent, whilst most prob­a­bly cached, still has to be gen­er­ated from some­where and it seems illog­i­cal to gen­er­ate some­thing which doesn’t ever get seen. Respon­sive web design calls for images to be resized by the device; but by this time the full-​size image has been down­loaded (at least on iPhones) — a sig­nif­i­cant inef­fi­ciency, and bad news if you’re on an old mobile net­work. Even Apple them­selves advise not to rely on this tech­nique. Bet­ter to use servcer-​side resiz­ing or a web ser­vice such as tinySrc. The solu­tion? Use media queries to fine-​tune the dis­play of a mobile ver­sion of a site, not just realign or tweak the con­tent of a desk­top web­site. Imple­ment a sep­a­rate strat­egy for the mobile ver­sion, and use server-​side tech­nol­ogy to cherry pick the required con­tent and ele­ments, and present this using an alter­na­tive theme layer. (Ensur­ing, of course, that the desk­top ver­sion is avail­able if required.) Take advan­tage of fea­tures that work well on mobile devices such as geo-​location. I do sup­port media queries in respon­sive web design to help enhance the mobile expe­ri­ence. If you’ve got a sim­ple site and want it to work okay on mobile device, go for it. But blindly assum­ing that they can be used alone to cre­ate a rich user expe­ri­ence on mobile devices is a lit­tle short-​sighted.

I recently devel­oped a sim­ple mod­ule for a project I was work­ing on, which is so generic that it may well be use­ful to other peo­ple or on other projects. I was sur­prised to find that there was no exist­ing mod­ule (that I could find) doing the same thing, so I wrote it myself (I’d actu­ally inher­ited the project, and the per­son work­ing on it had tried to achieve the same thing but by hack­ing part of the Dru­pal core — which is not a smart idea). The struc­ture and imple­men­ta­tion of the mod­ule was such that it seemed an ideal exam­ple to use as a tuto­r­ial in Dru­pal mod­ule development.

For those not famil­iar with the Tax­on­omy mod­ule, this core piece of Dru­pal func­tion­al­ity (though not enabled by default) allows you to cat­e­gorise con­tent in a num­ber of ways — the most obvi­ous being sim­ple cat­e­gories or tags.