Training Users for Cheap: Offering Simple Guided Tours in Your Mobile Interfaces
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Not every app’s functionality is as obvious to users as developers would like. As a consequence, your UI may both incur support costs and garner unwelcome reviews when confused users cannot figure it out.
Creating training materials for your app can prove as big a development challenge as the app itself. For many developers, perfect is the enemy of good. They’re so focused on creating the best possible training system that they overlook solutions that are merely good enough. A simple but reusable training harness enables you to minimize costs and get started with training.
Custom Tour System
I started building my suite of tutorial classes a few years ago. You see a skeletal example in Figure 1. On the iPad, my tours consist of a series of popovers, which optionally point to items they describe. On the iPhone, a stack of view controllers replaces the popovers. The same classes and set-up power tours on both systems.
)
Figure 1 This boilerplate guided tour contains text, image, and navigation elements. When presented on the iPhone, the view controller shown in this popover is pushed onto the navigation stack
Over time, my tour classes have grown to accommodate built-in elements like UIKit’s new support for HTML-based attributed strings as well as custom elements like animated gifs. But when I first started, I had a list of non-negotiable requirements.
- My tours needed to keep track of a user’s training through the defaults system. Each app could check defaults to determine if training had finished. I vary how each app uses this knowledge. Some apps present the tour at launch until complete. Others allow users to skip out, not presenting again unless specifically requested by the user. This default item enables each app to implement its own system.
- The tours had to run platform agnostically. Because popovers are essentially view controller containers, this was quite easy to accomplish. On phone devices, I push controllers. On tablets, I embed them. Otherwise the programmatically generated controllers are identical.
- My scripting had to be simple, centralized, and flexible. I wanted to ensure that at any time I could add new tour stages or re-order the ones I already had, whether during development or after deployment for app updates.
- Each stage had to support a localizable headline, body text, next button, and an image. Although I generally deploy only to English, I wanted the system to be international-ready, so these elements had to be settable from the scripting method. My latest system adds iOS 7 HTML support to provide further lightweight customizations such as bolding and italics. My image can now be an animated GIF, which is a great resource for show-don’t-tell tutorials.
- Users had to track where they were with respect to the tour so that they wouldn’t feel trapped. That’s why both the iPhone and iPad versions offer the page indicator control. At any time, users can tell how far they’ve progressed. Because I keep my tours short, I do not allow many “opt out” points. You should think about where in your training a user should be allowed to leave and adjust your tutorials accordingly.
- The tour had to take charge of the interface, and users would not be allowed to perform normal tasks until they’d left the tour. Establishing a delegate protocol for a controller that could disable and enable its own interface was essential. My delegates implement one method, setInterfaceEnabled:, which allows the calling view controller to prepare itself for the training and recover after.
Even satisfying these bullet points, the system I eventually settled on has limitations. It assumes it describes a single main interface. The iPhone presentation is a stack of view controller presentations that cover the interface it describes. (This was the original motivation for why images had to be a part of the tour.) The tour contains no deliberate interactivity beyond page-to-page navigation.
These limitations, however, enabled me to create an exceedingly simple harness. What follows is an example of how little scripting it takes to build a tour.
- (void) setupTour
{
// Create a tour
tour = [[GuidedTour alloc] init];
tour.delegate = self;
// Build stages
GuidedTourStage *stage;
// This stage (see Figure 1) has an image
stage = [[GuidedTourStage alloc] init];
stage.header = @"Welcome";
stage.body = @"Intro Text";
stage.image = [UIImage imageNamed:@"flowers"];
[tour addStage:stage];
// This one uses HTML
stage = [[GuidedTourStage alloc] init];
stage.header = @"Stage 1";
stage.body = @"Text that talks about <i>Stage 1</i> \
in an interesting fashion";
stage.desiredView = button; // Location hint for iPad
[tour addStage:stage];
// This one uses an animated GIF
stage = [[GuidedTourStage alloc] init];
stage.header = @"Thank you!";
stage.gifPath = [[NSBundle mainBundle]
pathForResource:@"sample" ofType:@"gif"];
stage.nextButtonText = @"Done";
[tour addStage:stage];
}
The classes that power this tour are at my Github repository. They consist of a stage class (a data structure describing the stage properties), a tour view controller (it uses these properties to populate a view), and the tour itself, which is little more than a smart array. Although minimal, they provide a jumping-off point for anyone who wants to build a customizable tour system.
Designing Tours
A successful tour should be highly focused. Always respect your user’s time and attention. Determine what features are the most pertinent to getting started and limit your initial tour to those items. You can always provide additional tours for more experienced users, and your training should not overwhelm your product. A user is less likely to quit from an app with 4 or 5 intro frames than one requiring 17 or 20 steps. Never forget that your interface always contains one more button than you design for. When your users feel trapped or bored, they'll press the Home button instead of tapping Next.
Keep your language light and tight. Use style hints to punch your meaning. In Figure 2, this tour stage uses HTML to pop its example text (monospaced) and related trivia (italics). Admittedly, this example is wordy due to the nature of the app.
)
Figure 2 Always assume your users have a limited attention span. Get to the point as quickly as possible
Don’t ignore your headers. They offer the best way to get a single idea across before you expand that idea in your text and supporting media. In fact, design your headers to match the key points you need your users to understand. Think of them as the elevator pitches of your training materials.
If you can, substitute pictures for words, especially pictures that move, when teaching an interaction. There are some terrific finger-shaped cursors available. I use PhoneFinger, which is available as an open source repo. You'll find others with a quick Internet search.
You may also want to highlight touches using a kit like TouchKit, which I wrote about on InformIT a few years ago. Use the simulator or an AirPlay destination like Reflector to move your app to a desktop computer and QuickTime to capture the screen recording.
There’s a great discussion on converting movies to GIFs at this gist by Alex Dergachev. If you decide to go the gifsicle route he recommends, you may need to install Homebrew and brew cast. Be sure to read the comments on that gist as there are lots of great tips and links there as well.
)
Figure 3 Custom finger cursors highlight interaction on screen shots and in videos. Where possible, use a wide range of finger styles for audience inclusiveness
If your app is complicated, end your tour with a callout to your help system. Tell your user how to search for and find answers – through built-in or online manuals, video resources, and so on. Incidentally, this is probably not where you want to include links to your ticketing system as your user has now spent a grand total of a minute or so invested in your app.
Wrap Up
Guided tours go a long way toward getting your users up to speed with your app. Even limited systems like the one discussed in this write-up help users better understand and invest in your product. Yes, you’ll have to schedule in time to design, script, and implement a tour, but you’ll be setting your priorities in the right place for the long term.