Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Streamlining Mobile Interactions

The mobile web is a harsh environment: mobile processors are slower than their desktop counterparts; network connectivity is flaky; bandwidth is low; latency is high; and touchscreen keyboards are slow. The best mobile web applications are the ones that excel at handling these challenges.

Streamlining Mobile Interactions

For desktop users, we’ll focus on interactions that take a longer amount of time and effort.

In this article, we’ll look at four core ways to streamline mobile interactions:

  1. Identify the tasks your users want to accomplish on a mobile device.
  2. Memorize as much as you can about your users’ situation.
  3. Presume that your users’ actions will succeed, and get them to their next task.
  4. Predict your users’ next actions, and prepare accordingly.

Task-Oriented Design Link

First things first: Why are your users here?

Desktop users keep a lot of web applications open for long periods of time so that all of the information they need is right at their fingertips. But a mobile device is used sporadically, when a task needs to be accomplished. The user may be checking Twitter because they’re bored and want to read an article that a friend has posted. Maybe they’re checking into a flight, sending dinner plans to a friend or looking up a bus schedule. They have a task that they’re trying to accomplish, and when they’re done, their phone will go back in their pocket.

Further Reading on SmashingMag:

Let’s say you’re in charge of Mobile Air’s mobile experience. On the desktop, Mobile Air’s home page is all about sales. Fare discount advertisements, enticing destinations and a trip planner are at the forefront. Off in the corner are options for checking into your flight, seeing your flight’s status and checking your rewards program.

For desktop users, we’ll focus on interactions that take a longer amount of time and effort (booking a flight) because desktop users are willing to spend more time on pages and are less likely to leave compared to mobile users5, whereas a mobile user is looking to accomplish a shorter task and they won’t have a lot of patience. Also, since checking flight status on a phone while at an airport is such a common use case we’ll bring that to the forefront.
Visitors to Mobile Air’s mobile website are away from home. The most prominent and accessible tasks should be flight status and check-in.6
Visitors to Mobile Air’s mobile website are away from home. The most prominent and accessible tasks should be flight status and check-in.

If you’re at home and want to visit Mobile Air, you’re not going to take the phone out of your pocket to do it if a perfectly good laptop is sitting on the coffee table. Visitors to Mobile Air’s mobile website are away from home. Odds are, they’re traveling right now. The most prominent and accessible tasks should be flight status and check-in. Reservations should be possible, but they aren’t as high a priority. Already, we’ve flipped the entire experience on its head because we know more about why our users come.

Memory Link

Once a user has visited our website and checked into a flight, we’ll know a lot more about them. We know that they have a flight coming up, for starters. Also, we know who they are, and we may have more information in our database, such as past and future flights. Using this information, let’s customize the home page for them by anticipating their actions.

Let’s say we know that Ann has checked into her flight that leaves tomorrow from New York City (NYC) to San Francisco (SFO). We also know she’s returning from SFO to NYC a few days later; and two weeks after that, she’s taking a trip to the Bahamas. Here’s how we could display her home page:

We know that the client is returning from SFO to NYC and taking a trip to the Bahamas. Here’s how we could display her home page.7
We know that the client is returning from SFO to NYC and taking a trip to the Bahamas. Here’s how we could display her home page.

So, how should we store this data? We could store it on the server in a database, and then use a cookie on the client. That’s the usual way to store this kind of thing. However, this is really a mobile-only interface, and it’s going to be short-lived; once the user has completed their flights, they won’t need this interface anymore. Additionally, storing the data on the server means that it won’t be available if Wi-Fi is lost (say, when Ann is on board and her phone is in airplane mode). Here’s an implementation of a flight-information cache using HTML5 localStorage:

// After we fetch from the server, store it:
localStorage.setItem("flights", JSON.stringify([
  { from: "NYC", to: "SFO", at: "Sun Jan 1 2012 07:45:00" },
  { from: "SFO", to: "NYC", at: "Tue Jan 3 2012 16:00:00" }

// When we first open the page but before fetching from server, retrieve the data:
flights = localStorage.getItem("flights")
if (flights) {
  flights = JSON.parse(flights);

This will store flight information on the phone, but Ann still would not be able to open the application without Wi-Fi. That’s what HTML5 application cache manifests are for. A cache manifest tells the phone what files to download and use offline. When the phone regains Internet access, it will update these files. Below is a simple cache for our application.

First, add the manifest to the html tag:

<html manifest="/application.manifest">

Next, add the manifest:

  # 2013-02-14
  # v1

  # Primary assets


This manifest tells the browser to cache our core application assets but to require the network for all of our API methods. That way, our API data won’t be cached. Note that at the top we have a timestamp and version number. Any change to the manifest will trigger a cache update; so, whenever you ship a new version, just update the timestamp and/or version accordingly, and the next time the user is online, they’ll get a fresh version.

At this point, you may be wondering about browser support for these new features. With all of the constraints on mobile devices, HTML5 support is a welcome relief. HTML5 localStorage8 and offline9 support is available on Android 2.1+ and iOS 3.2+. iOS 3.2+ accounts for about 97%10 of Apple mobile devices, and Android 2.1+ accounts for about 99%11 of Android devices. Adding a check for localStorage would be responsible so that our application doesn’t crash when it’s not available; but we don’t have to add a manifest check because we’re not using any JavaScript to access that feature — the browser automatically picks it up.

Routing Link

At this point, we have a fast application that can work offline, but we haven’t tackled how it behaves when refreshed or when the user quits and reopens the browser. Suppose Ann is checking her flight’s status and is refreshing constantly. We could provide a button to do this, but what if she sleeps her phone and later pulls it out of her pocket? Browsers will destroy a page’s state after a while (or after switching apps), so your application needs to be able to resume. That’s where routes come in.

Any page that stands alone should have its own route, and it should be able to be loaded purely by opening that route — meaning that we must be able to reconstruct our application’s state without forcing Ann to start at the main page and then navigate back to where she was. To do this, we will need a router. You could build one yourself, but many great JavaScript routers are available for different frameworks. Here’s a router in Backbone.js:

// Define the router
var MobileAirRouter = Backbone.Router.extend({
  routes: {
    "": "dashboard",
    "flights/:id": "flight"
  dashboard: function() {
    // Display the main dashboard
  flight: function(id) {
    // Fetch flight with ID: id
    // Display flight info

// Instantiate it
var router = new MobileAirRouter();

// Start Backbone's history tracking
// That will trigger whichever route matches the current url

Combine a router with a localStorage-backed cache system, and you’ll have an application that can resume very quickly, even without Wi-Fi access.

Perceived Speed Link

The hard truth of the mobile world is that delivering content at desktop speeds is incredibly difficult. Most mobile data providers see ping times on the order of hundreds of milliseconds. This means that, assuming your application takes 0 milliseconds to process a request and the phone takes 0 milliseconds to handle and render it (yeah right!), you’ll still have a 300 to 500 millisecond delay waiting for the signal to travel across the network. The only option left is to cheat.

Instagram is praised for its user experience, and one of its core tactics is to perform actions optimistically12. This means that when a user says, “Post this status update,” the system immediately says, “Done!” and moves the user back to their timeline, adding the new photo. Never mind that the data hasn’t even left the phone yet. In reality, your photo was on Instagram’s servers before you hit OK, and it was on your timeline before the server confirmed it. A double shot of perceived speed!

Let’s apply this concept to our mobile reservation system. We’re going to have five pages:

  1. submit airports and dates,
  2. pick the first leg,
  3. pick the second leg,
  4. pay,
  5. get confirmation.

Our mobile reservation system on five pages.13
Our mobile reservation system on five pages.

Once Ann has picked her airports and dates — but before she has hit the “Find Flights” button — we will fetch the info for the first leg. This way, if she were to change those values a few times, we might incur an extra data cost, but the next page will appear almost immediately. Here’s how we can prefetch a page:

// Function to fetch flight legs
var fetchFlightLegs = function() {
  // Inside a closure, we keep some internal variables
  var key, deferred;

  // Return the actual fetchFlightLegs function
  return function(from, to, on, until) {
    // Make a key from the arguments, so that different
    // invocations restart the process
    var newKey = [arguments].join("-");

    // If request is not redundant, make a new request
    if (newKey !== key) {
      // Set the key
      key = newKey
      // And set the deferred to the new request
      deferred = $.get("/legs", {
        from: from,
        to: to,
        on: on,
        until: until
    // Return the deferred
    return deferred;

// Now, every time they change a field, we run:
fetchFlightLegs(from, to, on, until);

// Then, when they hit "next", we run it again
// But this time we use the results to render the page
fetchFlightLegs(from, to, on, until).done(function() {
  // render the legs page

// If the fields haven't changed, we piggyback on the current request,
// which has been in progress since they updated the fields

In order not to rack up huge data costs, we might want to wrap our calls in something like _.debounce from Underscore.js14, which will delay a function call up to a specified number of milliseconds, and renew the delay if the function is called again. Basically, it lets the application “settle down” before performing the fetch.

In our design, the first and second leg are selected on different screens, but that doesn’t mean they have to be separate requests. We can modify our fetchFlightLegs function to lump the first and second legs into one request. Thus, the transition from the first to the second will be instantaneous. The submission of payment information requires no fetching.

When the payment is POST’ed to the server, we will do it synchronously with a loading screen. We don’t want to assume success at this step. Plus, an unusually quick response could actually make Ann feel uneasy! Here’s what our request chain looks like with and without data prefetched:

Our request chain with and without data prefetched.15
Our request chain with and without data prefetched.

As you can see, we’ve parallelized the application and the user’s actions. The user can do what they need to do (pick dates, pick flights, etc.), while the application predictively loads the next page’s information. This takes a lot of waiting out of the equation.

Focus On What Matters Link

Mobile interaction is a different world, with different constrains and different expectations. Simply adding a responsive style sheet does not address your user’s changing demands based on the context of their use. Keep the following steps in mind when building a mobile web application:

  1. Identify the tasks your users want to accomplish on a mobile device.
  2. Memorize as much as you can about their situation.
  3. Presume that your users’ actions will succeed, and get them to their next task.
  4. Predict your users’ next actions, and prepare accordingly.

The mobile web is a harsh environment, but by simply focusing on what matters, you will find that these new constraints provide a clear path to a superior experience.

(al, il, ml)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15

↑ Back to top Tweet itShare on Facebook

Nick Gauthier is a web freelancer focusing on Ruby on Rails and JavaScript. His experience spans from SQL to Sass and he always tests, all the time. He wrote “Recipes with Backbone” with Chris Strom and recently released his most recent eBook “Mobile Web Patterns with Backbone.js”. Aside from freelancing Nick runs B’More Awesome, a Baltimore-based web training organization, and he also co-founded Exobrain, an online mind-mapping tool.

  1. 1

    theresa neil

    May 28, 2014 3:45 pm

    These are great guiding principles for native app design as well. Thanks for sharing.

  2. 2

    Great article!
    I’ve found creating user personas and documenting their flow is really helpful for stuff like this.

  3. 5

    Excellent article Nick. For a second though I thought that in “Memory” you suggested abandoning server-side storage in favor of local storage. But on a second read I (pwhew) realized that you suggest using both.

    One note though about the localstorage… It seems that it might be very replaceable by webworkers very soon. If you ask me: not soon enough. LS has been a real pain in the ass, since it is very hard to control sometimes.


    • 6

      Nick Gauthier

      May 30, 2014 2:03 pm

      Yup, I think of it like a cache. If you miss, hit the server. Or even if you hit, hit the server if you can to keep it fresh.

  4. 7

    Jabran Rafique

    May 28, 2014 7:22 pm

    Great article. Thank you!

  5. 8

    I’m not going to lie, I didn’t make it all the way through this article. I am sure what you’ve shown is a great example of an application using local storage as a means to keep data quickly accessible. But one para popped off the page:

    “If you’re at home and want to visit Mobile Air, you’re not going to take the phone out of your pocket to do it if a perfectly good laptop is sitting on the coffee table. Visitors to Mobile Air’s mobile website are away from home. ”

    Is this a typo? There is incredibly strong evidence to the contrary. I see it every day. My girlfriend has a laptop on the table, she has her phone in her pocket. She will use the phone 99.9999999999999% of the time. The one exception is when she knows that the site doesn’t have a suitable design to work with a smaller screened device and then incredibly reluctantly picks up the weighty laptop, waits for it to whirr into action uses the page for all of 20 seconds and promptly closes the lid. At which point, most of the time she’ll go back to using her phone for whatever it was she was doing. Shoes I would imaging. Or looking at puppies.

    The great thing about local storage is that it is widely available through web-browsers, but – and I haven’t checked, I don’t know whether smart watches uses the same kind of browser, or TV’s, or well you get where I am going.

    We worked on a prototype tool during our Hackfarm last year which was reliant on local storage, the only use-case we found where it failed is in the unlikely event that somebody would use the particular service on a device other than the phone in their pocket. We came up with the idea of getting the app to phone home on-start if a wifi connection was detected and update the user profile with the latest version of the cached data so it would be accessible on an additional device.

    • 9

      Michael Dozark

      May 29, 2014 1:05 am

      Hit the nail on the head, @Avangelist. Trying to divine a context for a mobile user and funnel them into a specific set of tasks different than those of desktop users is a dangerous proposition at best. If you do this, you are not giving your users what they want, you’re telling them.

      I like to point people to “Content Strategy for Mobile” by the crew over at A List Apart to explain this concept better:

      • 10


      • 12

        I have always agreed with the that “A List Apart” article. Presuming or assuming a user’s intent is never really a great idea on a mobile site at least.
        I can see Nick’s point as well in the writing of this article, but like in the “A List Apart” article that Michael Dorzark mentions, the assumption that the user is still looking for that particular flight again may not be the right assumption.

        Just like in the “A List Apart” article states, typically a separate mobile site does not need to be a ‘Lite’ version of your site. All content should be available on your mobile site, otherwise if you think you have too much content, the par is down for BOTH the Desktop and mobile sites, just as long as the content is on BOTH sites or your site might as well just be Responsive instead, and not have a separate mobile version of your site.

        What could have been great instead of assuming the user wanted to choose the same particular flight would have been to give the user an option to ‘Save my Search’ or ‘Save the Inquiry for Later’ or something like that, THEN store their lookup locally. This way it puts the action in the users court to decide what they want to do. Assuming the user wants to look up the same flight again on a site launch is not always the best assumption by the developer or user.

        I could see something like this being used on a mobile app, but not necessarily on a mobile website.

    • 13

      Lauri Kieksi

      May 29, 2014 2:39 pm

      Wholeheartedly agree with this sentiment. The best screen to carry out a task is the one closest to you. Often that is your smartphone, regardless of how many screens or devices you have lying around the house. Device context does not imply user context any more than it implies the color of the curtains in the user’s home. For anyone who thinks differently, I recommend Karen McGrane’s excellent book (or ebook) Content Strategy for Mobile. One of the key takeaways of the data and user studies cited by McGrane is that there is no such thing as a “mobile device use case” or a “desktop device use case”. There are different user contexts and use cases, but the user’s choice of device is neither a cause or a consequence of the user’s use case.

    • 14

      That’s exactly what I was thinking.
      The conclusion that users browsing on mobile means that they have “on the go” use cases is tempting but very often wrong. Just drawing that conclusion without evidence or research should absolutely be avoided.

      In fact there has been a study done by Google (, see Page 13) in 2012 that found that 60% (!) of mobile usage was done from home.

    • 15

      Nick Gauthier

      May 30, 2014 2:09 pm

      Thanks for the comments.

      I wasn’t stating an absolute, simply that in the specific case of air travel buying tickets is usually a bigger task where you need a calendar and maybe a few tabs to compare rates, making it something I would seek out a bigger screen and keyboard for.

      Of course, in any case you need to be tracking usage and using data to infer your usage patterns.

      The main thing I had in mind with this use case is to reduce pain. If you’re at the airport and you’re stressed and worried about missing your flight, I want to reduce that stress as much as possible. If you’re at home on the couch and you have to click over to “buy tickets” because it defaults to flight status, that’s not so bad because you’re relaxed. The last thing I want to do is frustrate someone who is already in a hurry and stressed out.

      So, in this case, my example was specifically towards a mobile air travel web site and *my imaginary users* on whom I did no research because I don’t actually build mobile air travel sites as my job.

      Any example that can fit in a blog post is by necessity over-simplified.

      • 16

        I first thought the same as Avangelist, but then your example UI made clear that all content is available, it’s just layoutted differently. I don’t see any problem in that case. Even if you’re wrong 90% of the times a mobile user is visiting. The main use case is to get someone to his flight and therefore that should have priority. Thumbs up.

      • 17

        Courtney Brillhart

        June 5, 2014 5:11 am

        This is still implying that the user is stressed out at the airport and in a semi on-the-go state. A better approach might be to start with the a Mobile First approach, then the design will be great regardless of screen size. I totally understand you were just trying to provide an example, but unfortunately it was really distracting and it summed up a sort of antiquated way of thinking we are trying so hard for our “old skool” types at work to stop doing. Not everyone has the luxury of having both a mobile device and laptop at their disposal. By 2015, more folks will be accessing the web through mobile devices than traditional computers, and it may be the only device they have. Thanks for listening…jumping off my soap box now. :-)

    • 18

      Nice work !

  6. 19

    manish gupta

    May 29, 2014 11:31 am

    Thanks for the interesting and nice article Dude!
    Great and humble thank you very much again for such a nice one again..

  7. 20

    Thanks for the article

  8. 21

    Well done Nick!
    I found the technical explanations in this article mesh in really seamlessly with the use case described, giving real meaning to stuff I had read about but that failed to register because of a lack of connection to the real world.
    Reading the reactions was interesting also. I’m making a note to never presume anything about mobile vs desktop use cases, in case some UX evangelist is listening and revs up into gear (I’m an agnostic). Just saying that we are prioritizing the cases where the mobile user is in the greatest need and under the greatest stress (trundling luggage on the way to the airport) is enough really, and it comes to exactly the same. in the end.
    My 2 cents is that blanket statements such as “mobile is the future” are misleading, if they are used to imply “the mobile version of the website must contain at least as much as the desktop version” – however much time my daughter spends on Facebook with her smartphone. Here’s a link with a few interesting statistics:
    89% of time spent on mobile is on mobile apps , only 11% on mobile web sites
    Website traffic per device (4th Q 2014): 73% traditional, 14% tablet, 12% mobile


    • 22

      Just a couple of suggestions about this blog’s usability:
      I was allowed to upgrade my own comment! Probably not desirable…
      On the other hand I wanted to edit my comment but was not allowed to do so


↑ Back to top