Blog
I wanted to explore a concept for switching apps on the iPad using a video demo. Existing methods of switching apps on the iPad require at least two steps in most cases, like so:
For work that requires moving amongst several apps, this quickly becomes cumbersome. Here’s an idea I’ve been exploring that involves a single continuous gesture:
This concept isn’t without its issues, some of which I discussed in my previous post. Nevertheless, I’d love to hear what others think.
Federico Viticci recently noted that people often criticize the iOS keyboard for the wrong thing:
Personally, I believe the iOS keyboard is great for writing, because it’s just a normal keyboard, but iOS text selection is in serious need of an update, because it feels outdated.
This struck a chord with me, and it got me thinking about how people confuse the problem with multitasking on the iPad.
Criticism about the iPad’s multitasking often focuses on having only one app on screen at a time or the inability to run apps in the background.[1] I think the real problem is that switching apps is cumbersome. Solve this, and most practical complaints about multitasking would disappear.
It’s easy to find examples of tasks which are more arduous on an iPad than on a traditional desktop computer. Consider booking a flight. It often involves coordination and research across email, calendar, a web browser, and a travel app like Kayak or Hipmunk.
Is this easier on a traditional computer because you can have multiple windows open? On an average sized screen there’s not enough space to show even 2 complete windows at once, so it’s not that you can use multiple apps at the same time particularly well.[2] And yet using a laptop can enable a fluidity that you can’t replicate on an iPad.
The problem becomes clearer when you think about switching between apps. Currently the iPad has four methods of doing so:
#1–3 involve at least two actions every time you switch apps. #4 is great for moving back to your last used app,[3] but doesn’t scale if you are using 3 or more apps, like in the flight booking example. You have to move through your app history one at a time, and the order of your apps changes with each switch.
In contrast, look at how easy it is to switch apps using a traditional GUI:
#1–2 have a huge speed advantage over the iPad equivalents as they involve one click and the targets are always visible on screen. Also, Fitt’s Law is in play with the dock/taskbar. #3 is somewhat like swiping sideways on the iPad, except you can see the order of all apps in an overlay instead of blindly moving from one to the next. As a result of these methods, working among multiple apps can be very efficient.
Based on the above, I think improving multi-app tasks on the iPad hinges on finding a solution to app switching that solves for two criteria:
I have a couple potential solutions. The first is to allow you to lock the app switcher on screen (the one that appears when you double-tap the home button). When locked, it would move to the top of the screen so as not to get in the way of the keyboard, and apps would shrink to accommodate it. This way hit targets for recent apps would be available on screen at all times in order to switch quickly. The problem with this approach is that it requires you to predict when you’re going to frequently move between apps so that you can preemptively lock the app switcher on screen.
The second possibility is to use a continuous gesture to bring up an app switcher and select an app. For example, a two finger swipe from the side of the screen would display a temporary overlay, and you would select a different app by continuing to swipe across. Lifting your fingers off the screen would switch to the app you had selected in the overlay.[4] Using two fingers would be less awkward than the four finger gestures that are currently used, and using one continuous motion would provide a speed advantage. The disadvantage to this approach is that, as with most gestures, it isn’t discoverable.
The above proposals aren’t ideal, but as with finding the solution to any problem, half the challenge is making sure you’ve identified the correct issue. I think it would be interesting to shift the discussion on multitasking to how to make multi-app tasks better.
Of course, in most cases this isn’t a valid complaint as iOS allows a variety of processes to run in the background. Hopefully periodic data syncing will be added to this list of processes in the near future. ↩
Snap Multitasking in Windows 8 is an interesting approach. It allows you to pull up a second app in minimized mode next to your main app. The problem is that only some apps can scale to a tall and narrow sidebar dimension and remain useful. In addition, this feature is disabled for screens smaller than 1366x768 because there isn’t enough space for it, so the iPad’s small dimensions makes this concept a nonstarter. But it does solve for some things which the iPad is particularly bad at, like instant messaging. ↩
With the caveat that the swipe direction is confusing. ↩
Ideally this behavior would replace either the swipe up or side swipe app switcher. There is no need to add yet another app-switching interface to iOS. ↩
John Gruber recently commented on the prevailing trend against skeuomorphism in software design, repeatedly describing minimalist designs as “true”. What bothers me about his analysis is the same thing that I have seen in discussions elsewhere on software design: taste is presented as if it is an objective measurement. Gruber’s use of “true” reminds me of Microsoft claiming that their Metro design language is “authentically digital”. “True” to what? “Authentically digital” how?
Let’s be clear here: 1s and 0s are authentically digital. The absence of gradients and a focus on typography are not. The backlash against gloss and shadows is a trending preference. Dressing it up in language that suggests that minimalism is objectively better than skeuomorphism is as nonsensical as stating that functionalist architecture is better than neoclassical, or that jazz music is better than rock.
There are, of course, objective criteria by which to compare software designs. Is one interface more efficient to use than another? Is one easier to learn than another?[1] You can argue these points and perform testing to discover which aspects are better or worse. But let’s stop framing personal taste as if it is an objective criteria by which to measure design.
Gruber concludes his discussion by stating, “If you want to see the future of software UI design, look to the history of print design.” I think this is an interesting point to consider. I also wonder if software design is more akin to architecture – will we look back in 20 years time and mourn the loss of artisan craft that used to go into digital design, in much the same way that we lament that there will never be another skyscraper with the extravagant detail of the Woolworth Building?
Above all, however, I wonder if there is a fundamental problem in criticizing skeuomorphic software design, then suggesting that the way forward is in mimicking another type of media. As with all inventions before it, software design will eventually find its own voice, and it will no doubt be wholly unique from other art forms. It’s perfectly fine to prefer minimalism over another style of design, as long as we recognize that what we are discussing is opinion, and opinion can never be true.
Update: Marc Edwards weighed in on this topic, as did Max Rudberg. Both are great perspectives.
Given that Metro is such a well known minimal UI style, it should be noted that one of the criticisms leveled against it is that it is hard to use. As Gruber himself noted back in 2010, inactive elements (like labels and titles) often look the same as interactive elements (like buttons and tabs). Minimalist interfaces can be both beautiful and usable, but many minimalist UIs fall into the trap of being beautiful and unusable. ↩
I recently had an unexpected experience with Airbnb. I was served with violations and potential fines of over $40,000 by New York City after hosting a guest in my room for 3 days while I was traveling. I learned a few lessons from that saga, one of which was to do with designing customer support tools.
Here’s what happened after I contacted Airbnb to tell them about my situation. First, someone from customer service responded to my message telling me that they were sorry to hear about what happened, but that it was my responsibility to know the law and they couldn’t do anything to help. I wasn’t surprised by this response, but it obviously did not put a smile on my face. So what happened next piqued my curiosity as a user experience designer.
A day or so later I received an automated email cheerily asking me to rate their customer service:
Hello Nigel Warren,
We’d love to hear what you think of our customer service. Please take a moment to answer one simple question by clicking either link below:
How would you rate the support you received?
Good, I’m satisfied
Bad, I’m unsatisfied
To recap: facing potential fines of over $40,000. Thousands in lawyer’s fees. Dealing with an unhappy landlord and building board. Months of stress. Any human could guess what kind of reaction this email would invoke. The customer service rep who dealt with me should have had some way of manually overriding this automated followup.
This seems obvious, but it’s hard to plan for all the potential edge cases when making the internal tools that companies use. Doubly so because they rarely go through as much design and testing as consumer-facing products.
The kicker to this story is what happened after a few more days had passed. I was contacted again by Airbnb, this time from someone on a different team who left me a voicemail and sent the following email:
Hi Nigel,
I hope this message finds you well. My name is [redacted] and I’m a part of the Host Consultation Team here at Airbnb. We’ve noticed you’ve been a great host on the site, and we still have a huge demand for accommodations in the New York area. Are you still interested in hosting?
Please feel free to reach out if you are interested in renting your property again with Airbnb. My direct line is [redacted] - I look forward to hearing from you soon!
Cheers,
[redacted]
I should point out that by this time, the New York Times had published my story[1] and Airbnb customer service had then reached out to me directly to apologize. The timing of this last email couldn’t have been more comic had Mike Daisey invented it for a one-man show. My girlfriend received the same message, so clearly Airbnb reps were working from an automatically compiled list of hosts in New York.
The lesson here isn’t that customer service is hard – that’s a well known fact. The lesson is that automated CRM systems need a manual override switch. It’s impossible to design for every possible edge case in an unpredictable world, so there needs to be a flag that says “the normal rules don’t apply here – shut this machine off” for when things get extreme.
Although at the time of publication the violations had been dismissed, they have since been reissued and the case is ongoing. A mighty stress. ↩