Supporting context switching on the iPhone

Supporting people’s usage contexts has always been an important component to good interaction design. With mobile devices, the diversity of these contexts has gone up, and thankfully many applications have become more responsive to changes in context. It turns out though, that all of this responsiveness has created a big gaping need for better capabilities for easily returning to previous contexts. I think I’ve got an idea that would help.

Imagine Carl, an iPhone owner. As someone who is directionally challenged he relies on his phone for directions to almost anywhere. In the morning he accepts an invite to dinner across the bay and uses his phone to map the route and figure out how much travel time to plan. During lunch he opens the Map application to find a local electronics store. If he wants to use the route to dinner this evening has two options. Abandon the route, do his search and later reenter the addresses for directions, or save the origin and destination addresses as bookmarks to use later.

He has also figured out that for short trips he can just take a screen shot, so long as the directions fit on one page. This allows him to save many routes that he uses on a regular basis, though he hates that he can’t zoom in or scroll around, and they don’t show live traffic. He wishes that screenshots would actually be more like saved states of an application, that when he opened them would allow him to interact in the usual way.

He’d like to save states for more than just maps. He gets travel itineraries emails that he needs to reference repeatedly over a week long trip. He does the screenshot trick when he can, but sometimes they are long and he can’t screencap-scroll. If he could save the email screen state he could just return to that important email without scrolling or searching though his inbox.

He gets mobile boarding passes as links that open in Safari. The page tries to refresh when he opens the link from his email. If he could just save the screen state in Safari it wouldn’t need to refresh the page, and he could scroll down to locate his seat number.

savedStates.pngWith the recent introduction of multitasking on the iPhone, there is the possibility of saving an app in an open state. Why not extend this functionality to allow for saving multiple states of an open app? Apple could provide an application which works similar to how the photo app works with screenshots. But instead of static images of the screen the application would allow Carl to open the saved state of the application. Instead of a static screen, the information could be manipulated as usual (scrolling, zooming, turing on and off options).

Simple things like scrolling (which is not available on screen shots) would make it easy to save and retrieve mobile boarding passes. Saved states of the map application would maintain the route and allow for live traffic updates. It would be easy to retrive a specific email, or return to a web page without refreshing the data. For Carl the best part would be that he can save many different states, so he can save every route, and return to many different emails.

The application could replace the screenshot function. When Carl wanted to grab a screen state he would press the “Home” button at the same time as the “Sleep” button. Visual and auditory feedback would confirm the action was successful. To return to the saved state Carl would simply open the Saved States application. He is greeted with a simple interface; icons of the saved state of the screen are displayed in a time sorted matrix across the screen, he can scroll down, and view older state captures. Since he captured the states he has some visual memory of the screen and icon helps him distinguish between different captures. The sorting by time serves as a secondary way for him identify captured states. Once the desired state is located Carl touches the icon to relaunch the application into the saved state. Once open he can manipulate the application like normal.

With Saved States Carl can quickly capture a screen he will want to return to. When he revisits the saved screen state he has all the functionality he expects, but starts off with the application loaded with the data he wants, rather than starting out from the beginning every time.

4 Comments

Dan Zollman
This is an awesome idea! With "traditional" applications (e.g. Office, Photoshop), we already have saved states--that is, a saved document is usually as close to a 'saved state' as one would need. Web browsers can save tabs between sessions. But now, in many applications (mobile, web, and even desktop), the user's focus is on the many pieces of the application flow, not on document states, so "Saving" in the traditional sense is no longer helpful.
Melanie
I think you hit on something here - it is so frustrating as a user to not be able to get back to map directions I've already entered in, or to have to redo a search in my email or browser. I think it should work more like browsers do on the computer where you can have multiple tabs (like Dan was saying) or save it to your Favorites. If all the apps could save to this master favorites list that would be extremely helpful!
Stefan Klocek
@Dan: I agree with you - since the evaporation of the "Finder" in the iOS saving in the traditional sense is less helpful. But this introduced a problem when quitting applications, quitting without saving means the designer needs to choose to make the application reopen either in a default start state or to the last state open. Both of these make sense, but something more is needed. Google faces a similar problem with Google Docs, since the document is saved for you the last state is the only state. It is possible to review older versions of the document, but these are arbitrary, snapshots made by the system. It seems to me that the important thing is to have a way for the user to indicate intent, to "save" a version that is meaningful and useful to them. @Melanie: I agree, the thing to be careful of is making the saved state a local copy rather than reloading the page automatically. The user can refresh as a choice, but if the "tab" tries to reload the content, this is more like bookmarks rather than a saved state. Making a local saved state would give two things; reliable access to the state without a network, and a reliable way to save dynamic information that may change (a facebook wall, twitter, traffic on maps).
Dan Zollman
Exactly--the need is not to have a persistent state, but to be able to save a "state" as if it is a unique document.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment