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.
Consequences
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?).
Consequences
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.
Consequences
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.
Conclusion
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!
4 comments:
Hi Jeremy,
Couple of points to add. When people talk about 'responsive design' I've started to use the phrase 'responsive functionality' to make them think about the boundaries. Responsive design _should_ essentially be 'make this site work on small/different screen sizes' and perhaps 'take account of touch'. Nothing else IMO. It should be mostly doable with CSS.
Beyond that is functionality. If you want wildly different functionality, right now you have to consider going Native.
Secondly, one of the main themes to emerge regarding 'why go native' is bandwidth and internet access - the return to the world wide wait we all suffer using our phones. Some apps are being built essentially so web content can be cached on client devices (and presented via neat slideys).
Some interesting stuff is being devloped in this area e.g. PouchDB. Client-side databases accessed via js could provide the right half-way house.
I recently came across an issue I had not considered before, namely that scaling content for all viewports is not just a consideration for devs and designers but authors too.
Recently completed a completely adaptive site and technically it adapts and responds extremely well. The only real flaw is the authors' desire to fit whole paragraphs into titles and captions. Yes we can reduce font size but it still needs to be readable/accessible. If we restrict the character count of titles, captions and teasers authors complain. We can't just truncate sentences and expect that they will make sense. We can only point out that these elements ideally suit one or two short sentences and not an essay. Not many authors are in the habit of checking their content on different devices. Seeing our neatly fluid layout being stretched out of shape as it tries to contain far, far too much text at small sizes is a bit sad!
@ Mike L: Thanks for your thoughts Mike, that sounds like a useful distinction. I might personally add some other things into the design part of "responsive", particularly some content. Conditionally loading media can be as much about design as functionality but is not generally achieved with CSS alone. You're also right of course about needing to go native for some functionality, but I can also imagine scenarios where your mobile experience works quite differently to your desktop one but without requiring anything a mobile browser can't do. For instance one might allow for some customisation of the home page (perhaps hiding most content but letting users add it back in). On the whole, though, I suppose it's either a case of removing fancy stuff from the mobile version or wanting to offer something that only an app can do.
@ Monique: This is a really important problem, isn't it? I'm sure there are ways that one can build/manage a single site/set of content that can be put together so that an appropriate portion of text is shown for the platform, but it would require well-behaved authors and might still have its limitations. Perhaps it would end up pushing you to have separate sites or sets of content for different users or contexts in the end. It's such a tough thing to balance, how much extra work we want to make for ourselves and for authors, and how much we want to dictate what users experience. Always for me we come back to that problem: how will we know what's the right rendition to show a user, how much choice can they have, and how much of a management nightmare will that give us?
*****
PS Here are a couple of references I should have put in the post. Here are a couple of posts by Jeremy Keith (@adactio) on the conditional loading of content and "responsible responsive images". And here's enquire.js, a library that looks interesting for letting you do more with media queries
Post a Comment