Programming the iPhone User : UX Anti-Patterns - Memory Lapse

Network-aware applications, such as RSS readers or clients for sites like Twitter and Digg, inherently depend on an Internet connection. Without web access, the data they display is off-limits.

The first time users launch such an application, they probably expect a load operation of some sort, preferably with a progress indicator to show that the application is doing something in the background. Notice should be given not only that a download is in progress, but also whether or not the download is successful. In most cases, a successful operation will simply display the downloaded data. Failures can be communicated with an icon, as in Twinkle, or with passive messaging, as in Shovel.

Figure 1 shows the first launch and network sync for the TED application. The translucent overlay and status indicator tell the user that the application is actively communicating with the TED web services, while the underlying screen gives a preview of the type of content. This approach is preferable to that taken by many applications that fail to store information when applications close, requiring users to have a network connection to continue reading content they have already downloaded at least once.

Figure 1. The first launch and network sync for the TED application

After the first successful download, user expectations change. Users expect that applications will store downloaded data between launches. This expectation comes from the overall feeling on the iPhone or iPod Touch that applications don’t start and stop, but rather are paused, waiting for users to switch them back to the forefront.

Generally, an application should not forget data—especially the most recent data successfully downloaded. Users should not be penalized for changing albums, making a phone call, answering a text message, or otherwise closing an application. The application should provide the same functionality when reopened as when it was last closed, despite access to networks.

Figure 2 shows the result of launching both Shovel and Tweetie in the absence of a network connection. Users would likely benefit from an option to read content from the most recent successful sync.

Figure 2. The network error handling in Shovel and Tweetie

The Facebook application uses a disk cache and does an excellent job of avoiding the memory lapse anti-pattern. Any data loaded into the Facebook application is saved to disk and redisplayed when the application is opened. This approach works very well to provide value to users without a network connection. It also has the side effect of improving speed for users who are online, because data is only pulled from the network if it is outdated or missing; otherwise, it’s served from the cache.

When the Facebook application is asked to display content that is not cached and there is no network connection, users are given a clear but non-disruptive notice. Figure 3 shows the Facebook application responding to a request for data that cannot be located.

Figure 3. The error screen for unavailable data in the Facebook application

Developers of networked applications should work to avoid the memory lapse anti-pattern. Mobile applications are far more likely than desktop applications to encounter unfavorable network conditions. A good rule of thumb for data persistence is to ensure that your application can be opened on an airplane or on the New York City subway and still provide value to your users.