Mobile app UI state restoration in relation to the length of inactivity time

Question

A common guideline for mobile apps is that they should be built to accommodate interruption, and that the app should be restored after interruption to the last state that the user was in. For example, from the iOS App Programming Guide:

However, the user should never have to care if an app is already running or was terminated. From the user’s perspective, quitting an app should just seem like a temporary interruption. When the user returns to an app, that app should always return the user to the last point of use, so that the user can continue with whatever task was in progress. This behavior provides a better experience for the user ...

However there is the issue of the amount of time elapsed since the interruption or last activity. Within a reasonable amount of time, the state of the app would be relevant to the user, but if the elapsed time is too long (depending on the nature of the app/task), then the stored state might not be meaningful at all to the user after resumption.

For the sake of an example, I have an educational app where users are quizzed about their knowledge in a given subject, and the app can of course be interrupted in the middle of this task. Then the question is where to bring the UI state after shorter or longer times of interruption. Longer times can be in days or more.

We can think of numerous other examples of tasks where the above applies, such as browsing through a list of items, images or docs; or a data entry task, and so on.

Lets consider some possibilities for handling resumption of an app after interruption or inactivity in relation to the length of elapsed time:

1. always going back to the last state at resumption, and making a task cancellation element always visible or easily accessible.

2. having a time threshold setting, and if the elapsed interruption time is bigger than the threshold, using a modal view on resumption to ask the user whether to continue with the task or cancel it. Else if the elapsed time is smaller than threshold going to the last state directly. (setting is not necessarily exposed to users)

3. having a time threshold setting, and if the elapsed interruption time is bigger than the threshold then going to the main view directly, but when the user selects the same task that was earlier interrupted, they are taken to the saved state (with or without a modal question are two possibilities). Else if elapsed time is smaller than threshold going to the last state directly.

4. using two time thresholds, one to show a modal or direct to main view as above, the other (very large) to just forget the state completely and start with the main view.

5. Other ideas ?!

Which of these options are more reasonable, more common, or better match the expectations of users? And what guidelines would you offer for handling this issue.

Answer 1

I think that switching contexts while user isn't aware of that is a bad idea, so option 1 will be more convenient in your case. Restoring the context is not only supposed to put user into the most recent state he's left the app but also helps him to remember what exactly happened at that moment of time (works as a memory trigger). And even if it seems like the state is not relevant anymore it still will work as a memory trigger and help user to decide what to do next.

Answer 2

I agree with Alexey. The expectations of users is exactly what is specified by Apple's guidelines (quoted in the OP). That's a simple model easily grasped. The only other model that's as simple is the old always-start-at-initial-state, which is usually a bad fit with iOS use patterns.

A model that accounts for time of inactivity is more complicated. There's bound to be a moment of surprise ("Why this it reset? It usually doesn't do this. Is it broke?").

It is possible that time-sensitive more complicated model be a net positive, but it would require some serious testing to be assured of that.