Guidelines for Chaining iOS Apps
A long-standing design goal for iPhone apps is that they support a very specific style of interaction: users take out their device, open an app, perform a task quickly and then they’re done—either because they take an incoming call or because they pocket their device to get on with other things. To enable this get-in-get-out interaction style, every app must have a well-defined purpose. App developers are encouraged to implement only the functionality required to perform the purpose of their apps. This development style pares down apps to keep them focused and avoids featuritis.
When users have well-defined goals, it’s often possible to meet those goals using a single, pared-down app. For example, setting an alarm using the Clock app, reading email using the Mail app, and watching movie trailers using the IMDb app, are all tasks users can perform with a single app.
When users have more complicated goals, however, it’s often necessary to use more than one app: a primary app and a secondary app. For example, a common iOS interaction idiom launches the Safari app to present web pages that provide extra information. If the user is satisfied by the information presented by Safari, then their information-seeking goal is complete. In this scenario, two well-focused apps chain together to provide users with more information than the primary app provides alone.
The problem with this app-chaining idiom occurs when users want to return to the primary app, either because they are not satisfied by the information provided by the secondary app, or when they need to return to the primary app to continue their main task. After finishing with the secondary Safari app, for example, users are responsible for navigating back to the primary app. Because Safari—or any other secondary app—has no knowledge of the primary app, Safari has no way to take the user back to the primary app.
Although navigating between apps is straightforward in iOS—either by swiping on the iPad or double tapping the home button to reveal the app switcher on the iPhone, iPod touch and iPad—this extra step interrupts task flow and adds to cognitive load: users need to think about how to reverse the switch from primary to secondary app, a switch they did not initiate in the first place.
One solution is to implement the functionality of the secondary app in the primary app. Although this is straightforward when the secondary app is Safari—which is often the case—this solution quickly breaks down for other secondary apps, both ideologically by violating the design requirement for highly focussed, single-solution apps, and practically by adding to the size of the codebase for any app that might chain with another app.
A better solution is to use an app-within-an-app idiom similar to the iAd model. iAd presents adverts in a modal dialog enabling a near full-screen presentation. Users interact with the content of the advert as if it were a separate app and then press the Done button to dismiss the modal iAd dialog. Presenting the secondary app in a similar modal dialog would provide the functionality of the secondary app without burdening users with the cognitive load of navigating back to the primary app.
Two guidelines spring from these solutions:
- If the secondary app is Safari, add web-browser functionality to the primary app to keep users within the primary app.
- If the secondary app is not Safari but is likely to meet the user’s goal, then launch the secondary app; otherwise open the secondary app modally within the primary app.
iOS doesn’t currently support the app-within-an-app idiom required by the second guideline, but it would make a useful addition to the app developers’ toolbox.