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.
With 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.