About Me

My photo
Web person at the Imperial War Museum, just completed PhD about digital sustainability in museums (the original motivation for this blog was as my research diary). Posting occasionally, and usually museum tech stuff but prone to stray. I welcome comments if you want to take anything further. These are my opinions and should not be attributed to my employer or anyone else (unless they thought of them too). Twitter: @jottevanger

Wednesday, September 19, 2012

Mobile thinking

(well, pontificating.)

So, how to go mobile? Don’t ask me, every time we go around this one all the same questions come out. One site or multiple? One URL or more? (these are not the same question.) Is responsive design the way forward? What about performance? Do different users need different content and IA? Is the device or the use-case most important, and should we infer one from the other? When must we resort to an app? Everything seems to depend on something else, so how do we cut that Gordian knot? At IWM thus far we’ve only dabbled in mobile websites so we really haven’t settled on our approach yet, but recently we spent some time with colleagues from the National Gallery and Tate talking it over, and some things seemed to get a little clearer to me. Not answers, but perhaps a way through to some decisions. Bear in mind, of course, that given my limited experience of actually doing this stuff it’s possibly just BS, but anyways...

For starters, I think it’s three knots. Each is a bundle of objectives, factors, constraints and decisions. Some of these decisions will be easy to settle or there may be no choice about, whilst others are our degrees of freedom. The knots themselves seem to me to have limited impact on each other, though there are connections. What I hope is that they help us to address questions of principle and implementation in the right order.

Problem 1: Knowing which mode of display is required

How do we decide what version of a site or rendition of a piece of content is shown to a user to allow for their device, and what is the importance of user choice in this? What aspects of the device are significant? Really this is a question about whether we think we can guess what people need in order to achieve their objectives, and what happens if we guess wrong.

Informing considerations

User choice: is it important for users to have explicit control over how they see your site? Are the tasks they may want to achieve guessable from the platform they use and does this matter? Source: is the source a user comes from relevant (e.g. a social share), and should the URL they request determine what they see regardless of their device? Technical characteristics of devices: what are the significant technical dimensions along which devices differ (screen size? (if any) Touch vs keyboard/mouse vs voice interface? Functional capabilities?). User choice and source have a somewhat inverse relationship with the importance of technical characteristics in governing the experience, but aren’t mutually exclusive.


Various technical choices depend upon how we answer this problem (the role of URLs; mechanisms for allowing user choice or automatic detection), but maybe even content or the user journey are impacted. And the decisions over user choice, sources and technology will affect each other.
In terms of technology, for instance, unprompted client-side detection of window size (as would be used to perform media queries for a responsive design) is one option, whilst server-side detection of user agent properties is another (perhaps directly determining what rendition is shown; or else offering the user a choice that is saved as a cookie or redirects them to another URL).

Problem 2: What to show differently

Problem1 concerned identifying the important dimensions of difference (devices, tasks) and how much we should try to work this out on behalf of users or leave it to them. Once that choice is made comes the question of what should actually be different about the different renditions of a site to (hopefully) adapt the experience to users’ needs.

Informing considerations

Users and the tasks they wish to accomplish (again) - if we decided in Problem 1 that tasks were important in determining the selecting rendition that probably means renditions will differ along the dimension of tasks too. Form factors & device capabilities. Accessibility. Location (might we change the content according to where the user is?).


User experience and design. Delivery of media. If we choose to focus on facilitating different tasks for different platforms, then information architecture, content and functionality may also be affected.

Problem 3: How do we display it?

Finally, the bit we usually seem to skip right to: how do we get the right stuff onto the page and get it to look right once it’s there? There are links here back to 1 and 2, because the technical solution to rendering stuff to the display will be some combination of server- and client-side technology that is also going to relate to how (and where) the results of those two decisions are governed.

Informing considerations

Devices; technology; cost; performance.
Assuming we’ve gone down the HTML rather than the app route, there are (I think) three basic options, which can be combined: get the server to spit out different HTML depending upon what is required (on the basis of platform, user choice or whatever – see above); spit out the same basic HTML and change the lay it out with CSS via fluid design and/or using media queries and the like (which may also load some different assets); or spit out the same basic HTML (preferably HTML5) and remodel it with JavaScript-y goodness, possibly loading in different content at the same time.
Doing it all server-side may of course be difficult depending upon the technology you use to assemble your web-pages, or it might make a stronger case for a separate mobile site. Using CSS to do the layout is probably the simplest approach but it has limitations and means that with some minor exceptions all content will be loaded, whether it’s shown to the user or not (though I am no CSS maven so may have missed something here). Using the power of HTML5, combined with JavaScript, we can do a lot more, including pull in content only as it is needed. It’s possible to request images to be made on the fly with dimensions that suit the user’s screen, which could be a boon for page load weights. As it depends upon client-side code the results are perhaps a bit less in the hands of the website owner and users of older desktop browsers may suffer, but there are plenty of libraries out there now that profess to make the whole cross-browser thing less of an issue, and recent browsers do tend to play a bit nicer together than once upon a time. I suspect this is a pretty demanding route technically, or it could be (especially if on the server side you need to set up services for dynamically loading content), and thinking about how to make it play nicely with Drupal themes gives me shivers, but it’s got a lot going for it.
To be honest I get confused as to which of these approaches people mean when they say “responsive design”, and no doubt they can be hybridised anyway.


The choice here is basically leads us to our technical approach: whether the hard bits of the coding we have to do are client-side or server-side, feeding back to how we tell what type of rendering is required, whether we need to develop content feeds or other services, and so on. All will require continuing maintenance especially if there is some sort of automated detection going on, rather than user choice. And there will be cost implications whichever way, but they will depend upon the complexity of the requirements, the capabilities and flexibility of existing systems, in-house expertise and so on.


Huh? Well basically I wrote this just to rescue myself from all those circular discussions that seem to happen but if I'm talking through my hat speak up!