This morning a Tweet piqued my interest; “FT.com launches subscription web app aimed at Smartphone & tablet users bypassing app store tariffs”. An interesting concept, so I followed the link which took me straight to the FT.com website. Now, if there’s anything that’s going to drive me away from a website it’s a pop-over — except, that is, a pop-over when I just happen to be trying to access your site using my mobile. This is what I got:
The irony that the article was about a service aimed at Smartphone users was’t lost on me.
There are numerous steps you should complete before launching a new website; cross-browser testing, checking for dead links, proof-reading. These are covered more than adequately elsewhere but in this article I’m going to look at a number of steps applicable specifically to launching a Drupal site. You may not agree with them all, but then none of the following are compulsory — these are just my personal recommendations.
There are numerous steps you should complete before launching a new website; cross-browser testing, checking for dead links, proof-reading. These are covered more than adequately elsewhere but in this article I’m going to look at a number of steps applicable specifically to launching a Drupal site. You may not agree with them all, but then none of the following are compulsory — these are just my personal recommendations. Rather than simply list them as bullet points, I’ve tried to give some of the rationale between these tasks, and pointers to online resources where I can.
There’s certainly a big buzz right now about responsive web design; flexible layouts that adapt dynamically to the user’s device and its capabilities; screen size, resolution and so on. One of the major uses for this technique — a combination of flexible grids, resizeable images and CSS media queries — is as a mechanism for creating a mobile version of a site. And it’s a very useful approach — dynamically changing the layout according to your device’s capabilities enables content to be re-structured for the small screen with little effort. Also, putting the onus on the device to interpret the style rules makes sense, removing the need for messy, server-side browser detection based on user agent strings. However as tempting as it might be to use this technique as your sole approach to mobile-enabling a site, it is to ignore a number of other factors and issues prevalent in designing — and building — for the mobile web. Displaying a website in such a way that it looks better on a mobile device is only a part of the process for creating a mobile version; there are other factors which should be considered, such as how and where the mobile version of the site is going to be used, a user’s motivation for using the site and assessing what is appropriate for the mobile-friendly version of the site. Whilst it is true that some people will only ever visit your site from a mobile device, it is likely to be used differently and should be tailored as such — it’s not just about making it look right on a small screen. For example if I’m accessing the RAC website via my mobile, it’s much more likely I’m doing so for breakdown assistance or real-time traffic information, than researching my options for car insurance. Interfaces need to be considered carefully on a mobile site; it’s not just about styling. If I visit a website for a cinema chain I’d expect something like a drop-down where I can select the cinema I’m interested in; on their mobile site they’d be missing a trick if they didn’t use geo-location to save me time. My second argument is more pragmatic and technical. Take the simple example of a blog, with a typical two column layout — using media queries, the right-hand column might be shifted below the main content area (i.e. the articles). Or perhaps the tertiary nature of a typical right-hand column means it can be stripped out altogether. However this creates two major inefficiencies — the HTML is fetched from the server and never used, and typically-dynamic content, whilst most probably cached, still has to be generated from somewhere and it seems illogical to generate something which doesn’t ever get seen. Responsive web design calls for images to be resized by the device; but by this time the full-size image has been downloaded (at least on iPhones) — a significant inefficiency, and bad news if you’re on an old mobile network. Even Apple themselves advise not to rely on this technique. Better to use servcer-side resizing or a web service such as tinySrc. The solution? Use media queries to fine-tune the display of a mobile version of a site, not just realign or tweak the content of a desktop website. Implement a separate strategy for the mobile version, and use server-side technology to cherry pick the required content and elements, and present this using an alternative theme layer. (Ensuring, of course, that the desktop version is available if required.) Take advantage of features that work well on mobile devices such as geo-location. I do support media queries in responsive web design to help enhance the mobile experience. If you’ve got a simple site and want it to work okay on mobile device, go for it. But blindly assuming that they can be used alone to create a rich user experience on mobile devices is a little short-sighted.
I recently developed a simple module for a project I was working on, which is so generic that it may well be useful to other people or on other projects. I was surprised to find that there was no existing module (that I could find) doing the same thing, so I wrote it myself (I’d actually inherited the project, and the person working on it had tried to achieve the same thing but by hacking part of the Drupal core — which is not a smart idea). The structure and implementation of the module was such that it seemed an ideal example to use as a tutorial in Drupal module development.
For those not familiar with the Taxonomy module, this core piece of Drupal functionality (though not enabled by default) allows you to categorise content in a number of ways — the most obvious being simple categories or tags.