On the Dimensionality of Designing the Web for Mobile Devices

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!

How Many Dimensions?

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:

  1. device size the most obvious class of concern: how big is the screen, and how much info can we cram in there?
  2. device capability actually a generalisation of size; what browsers and standards does the device support?
  3. human interface is there a mouse? Keyboard? Touch screen? Multitouch? Drag&drop, swipe, pinch, etc.?
  4. use case how is the user going to use this service?

Device Size

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:

  1. consider the devices that will be used to view the site, ordered by frequency and/or how much you care about them
  2. simultaneously, consider the site's navigation; what pages exist, how they are navigated between, how much access the user needs to have at any given moment
  3. sketch out some designs specifically suited for the top few devices (and maybe an outlier, if you want to cover more bases) that address the site's navigation needs
  4. try and come up with a responsive design that incorporates all your designs, or at least their key features

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.

Device Capability

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.

  1. consider the lowest common denominator about which you care
  2. work out a strategy for supporting the relevant browsers; for example
    • using <noscript> fallbacks, to ensure minimal functionality is maintained when the scripts don't run; or
    • designing bottom-up, creating the site initially with no scripting at all, then adding script-based enhancements
    • anything else you can think of; for example on this site (look at it in a very narrow window) I created a whole separate page which exactly duplicates the slide-down navigation menu, linked from the menu button. If the browser supports my scripts, the menu will slide down when the button is clicked; if not, clicking the button will take the user to the menu page.

Ditto 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).

Human Interface

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.

Use Case

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:

  1. determine the use cases; work out who is going to be using your site to do what and how
  2. design a product for each use case; they might be lighter or heavier versions of the same content, or provide a subset of the functionality, or they might be completely different sites (who knows?)
  3. treat each product as a different site, and develop each one for all appropriate devices, as you would any stand-alone website

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!

thumbnail image

Matthew Kerwin

CC BY-SA 4.0
development, ux, web
Here are some thoughts I've been cultivating for the past year about developing websites and web applications in a mobile world.

Comments powered by Disqus