Here are some thoughts I've been cultivating for the past year about developing websites and web applications in a mobile world.
I am not going to talk about whether or why we should develop mobile-friendly websites; instead I will assume that that is what you are doing, and enumerate some things to consider as you do.
I chose the word “dimensionality” for the title because, as I visualise it, the domain of developing mobile-friendly websites has several different classes of consideration which are entirely orthogonal. It is quite easy to find articles on the web that talk about detecting mobile devices, or presenting alternative layouts, or simplifying navigation, or making click-targets larger, etc. however very few of those articles seem to be mindful of the fact that they only address one class of mobile-friendly design considerations; or worse, that some seem to unwittingly conflate the classes, applying a solution from one issue to an entirely different class of problem.
Well, I'm going to set the record straight!
I may have been a bit harsh when I said that the issues are entirely orthogonal. They aren't. As with all things, there are gradients and overlaps and fuzzy edges. I could devise a hierarchical ontology classifying the classes of issues, but I think that would be a waste of time. Instead I'll make some arbitrary headings, and clump things together under them.
And here they are:
Different devices have different sizes. They have different numbers of inches per screen, and different numbers of pixels per inch, and different numbers of pixels per view angle. This class of consideration covers all these issues, and is widely discussed on the web. I will mention some of the key concerns, and possible strategies for addressing them.
Small screens can't fit margins.
On a typical desktop computer (let's say anything larger than 1024×768px) there's room for a sidebar on the left with your site's main navigation, breakout boxes on the right, and a sticky banner across the top with easy-access buttons for common actions, all without overly crowding the all important content you are delivering. On a QVGA device (320×240px) you would be flat out fitting a heading and three lines of text.
Never fear, solutions abound! My advice would be:
It's up to you whether your baseline design targets the full-screen desktop environment (with graceful degradation for smaller screens), or the other way around (mobile-first), based on how you prioritise the devices and how hard you think it will be to implement one over the other.
Small screens flow differently.
This is almost exactly the same as the previous concern: you can't fit as many lines of text on a smaller screen, those lines wrap sooner, and boxes take up more (relative) space.
The solution is the same as above: work out which devices you need to support, work out some designs to suit those devices, then work out a responsive design that incorporates them all.
Small screens need small images.
There is a phrase floating around the web recently: art direction. I think the Cloud Four Blog expresses it best. Simply put: for a small screen, one can either downscale pictures or crop them. This is a choice you as the designer have to make, and you may have to lean on the standards a bit to achieve your design.
As a general rule, my implemented solutions for this class of concern are all client-side. I make all the resources available to all browsers and devices, provide hints about which resources are intended for what context, and let the browser choose. I may call it “responsive design” and “CSS rules,” but essentially that's what I'm doing.
Along with screen size, different devices are capable of doing different things. Some have more powerful processors, or more memory, or access to higher bandwidth, or the ability to display more colours. And further, on any given device there may be a choice of different software packages (read: browsers) which have different capabilies such as standards compliance, scripting support, even differences in how they route bits of data from the web to the screen.
The big issue that springs to mind is:
Not all browsers have javascript.
I could replace “javascript” with just about anything and it would still be true. And, in fact, my approach to dealing with it would be the same.
<noscript>
fallbacks, to ensure minimal functionality is maintained when the scripts don't run; orDitto Flash, CSS, webfonts, X image format, etc.
This class of concern can be solved by either (or both of) client-side and server-side logic. If I know that, for example, iOS devices don't support Flash objects, I can detect them from the server and deliver an alternative version of the document (server-side). Or I could assume the worst of everyone, and simultaneously send the Flash object, and instructions for what to do if/when it doesn't work (client-side).
This isn't about UX per se; in this section I'm specifically referring to the physical interface, and how the human user interacts with the device.
How do users scroll?
This is one aspect I've come acrss which rarely gets a mention. If the device in question uses windows and scrollbars, you can put fixed-sized elements with over-sized contents all over the shop and let people scroll to their merry hearts' content. (Whether or not this constitutes good design is a different question.) However if the device uses viewports things can be a little different.
While designing a site one must keep in mind that, for example, iPhone users might find it difficult to scroll a box in the middle of a page, and so might like an alternative presentation (although preferably not one quite so bland).
Can they hover?
With a mouse it's quite easy to move the cursor over an element, and have this trigger an action; or give focus to an element and send it a hardware action (e.g. scroll) without activating the “click” mechanism. On a touch-screen phone that can be a lot trickier.
While designing a site one should consider whether or not to include things like hover menus, and if one does, whether and how to support devices that don't do hover.
Can they type?
Directly related to the previous concern is keyboard shortcuts; simple on a desktop computer, impossible on my Android phone. Once again it's up to the designer to decide whether or not to use them, and how much to rely on them.
This class of concern I usually solve server-side. Since the issues usually involve a rethinking of the whole site interface, I'll usually design two completely different versions of the site, and use server-side client detection to choose which to deliver.
There's a VentureBeat article I read a few months ago which originally solidified in my mind this idea of dimensionality. It describes some of LinkedIn's approach to web design, specifically the relationship between mobile and desktop devices. Now it might be sensationalist (or otherwise poor) journalism for said article to use “Responsive design” just doesn’t work
as a heading, but it's definitely wrong; I interpreted Kiran Prasad's statement as: responsive design is a tool for presenting the same content in the same use case on different devices.
Removing the editorial insertions from the quote, Prasad said, “We're looking at the ‘entrenched’ use case, the coffee-and-couch use case, the two-minute use case.” Where VentureBeat went wrong was equating use cases with devices; as though it's impossible to want to get a two minute summary while sitting at a desktop, or that users will never want to get some serious work done on their iPad. The thought I had at the time, and am professing now, is: each use case represents a different product.
To use the LinkedIn example, the “entrenched product” would provide the full functionality of the site, including all the administration tasks and that sort of thing. The “coffee-and-couch product” might let you play with your profile, search for contacts, make recommendations, etc. The “two-minute product” might just present a summary of news articles and updates from your groups and contacts. In an ideal world, all three products would be usable on any device, using responsive design or whatever equivalent technique is appropriate to make that level of content work on the given device. The big advantage is that this gives the user the power to decide which product they want to use.
I really want to emphases that last sentence, but it would be a bit naff. It's a really important point, though. If you see that I'm accessing your site from my phone it might be reasonable for you to assume that I'm here for a two-minute update, and initially serve me the appropriate product, but I might have a specific task in mind that is only possible using the entrenched product, so would really like the ability to switch to it and still have it work on my phone.
My strategy here, and my suggestion to everyone else, is:
That final point is, I think, the main point I'm trying to make with this entire post. There is a difference between the device I'm using, and what I want to do on your site.
So in summary: be mindful of the devices people will use to access your site, be mindful of what various devices are capable of doing, and be mindful of what people will want to accomplish while visiting your site. Go forth and be productive!