16 May 2010

Saving State in iPhone Apps

1. I quit my twitter client for a minute to google something, grab a URL, or answer an IM. I go back to the twitter client to continue reading.

2. I quit my twitter client because I’m done reading it. It’s 11 PM and I’m going to bed.

In the first case I’d absolutely like to be back where I was. In the second case, however, this is only likely to confuse me and make me tap my way back to the timeline the next morning. It’s been ten hours; why would I still care to see the tweet I was looking at last night?

That’s a topic I’ve been pondering, particularly since the announcement of OS 4.0, with no good conclusion in sight, because it does get into mind-reading territory. What is it that my user is trying to do right now? (Why, hello, Clippy.)

For instance, Unicode always starts from a blank slate, because I assume that in most cases you want to start typing a new message, but there must be times when users are inconvenienced by that choice (not least of which, if they’ve been interrupted by a phone call in the middle of setting up text). And No Pic No Chat doesn’t remember where you were for the same reason: in most cases, you probably don’t really want it to (plus, there were slight technical complications, so I got lazy).

With multitasking in OS 4.0, though, that just doesn’t work so well anymore. When you switch away from an application, it’s going to remember its state as long as it’s in memory, whether the developer likes it or not (unless they actively work around that fact by resetting the app when it comes back to the front); but as soon as the OS removes it from memory, it’s going to start from scratch the next time it’s launched — making for a completely different user experience, for completely arbitrary reasons.

Switch away from Unicode to read a text message, then come back, and what you had originally typed is still in memory (whether you tap the app’s icon on the home screen or in the multitasking tray doesn’t make any difference, as far as I know). Switch away from Unicode to open a couple of really big websites in Safari, or play a video or whatever, and the OS will boot Unicode out of RAM, so the next launch will actually be a launch this time. Yet, as far as the user is concerned, their interaction with Unicode has been exactly the same in both cases — so their experience should also be exactly the same.

There’s no choice anymore, all apps pretty much have to save their state now (which is why Settings does, even if it can seem stupid, as Mrgan points out in his example). But what of those cases where you expect most users not to want their app’s state to be saved?

My recommendation is that apps should expire their saved states after n hours. What do I have in mind for n? That’s a hard call, but I’d pick a duration past which the human brain is unlikely to feel like it’s still “doing the same thing”. So, one hour, perhaps.

That’s a pretty interesting idea. (I wish I could have been bothered to have it myself.) When I get around to it, I might even go for something like fifteen minutes. If you’re away from Unicode for that long, you’re probably done with what you were working on.


P.S. While typing this I figured out a better way to handle the situation in Unicode — regardless of multitasking — so I’ll be posting an update someday soonish.