20101122 - Handling Common Tasks for iPhone - part 2

Hosting Ads In iOS 4.0 and later, you can allow advertisements to display within your application and you can receive revenue when users see or interact with them. It's essential that you plan when and how to integrate ads with your UI so that people are motivated to view them without being distracted from your application. You can host an iAd, which contains the ad content, in a specific view in your UI. When people tap an ad in this view (called a banner view), the iAd performs a preprogrammed action, such as playing a movie, displaying interactive ad content, or launching Safari to open a webpage. The action can display content that covers your UI or it might cause your application to transition to the background. The dimensions of the banner view are: ■ In portrait, 320 x 50 points ■ In landscape, 480 x 32 points To ensure seamless integration with banner ads and to provide the best user experience, follow these guidelines: Place the banner view at or near the bottom of the screen. This placement differs slightly, depending on the bars that can be in the screen: ■ If there are no bars at the bottom of the screen, put the banner view at the bottom edge of the screen. ■ If there are no bars at all, put the banner view at the bottom edge of the screen. ■ If there is a toolbar or tab bar, put the banner view directly above the toolbar or tab bar. Ensure that banner views appear when it makes sense in your application. Although it's recommended that a banner view be at the bottom of a screen, you choose which screens should contain banner views. For example, you might want to choose a context that functions as a sort of interlude in the main task of your application. People are more likely to enter an iAd experience when they don't feel like they're interrupting their workflow to do so. This is especially important for immersive applications such as games: You don't want to place banner views where they will conflict with gameplay. Comments: For games, put the banner view at the game entrance screen or game score screen, not during the gamplay screen. As much as possible, display banner ads in both orientations. It's best when users don't have to change the orientation of the device to switch between using your application and viewing an ad. Also, supporting both orientations allows you to accept a wider range of advertisements. Comments: Should design for portrait ad banner and landscape ad banner. While people view or interact with ads, pause application activities that require their attention or interaction. When people choose to view an ad, they don't want to feel that they're missing events in your application, and they don't want your application to interrupt them. A good rule of thumb is to pause the same activities you would pause when your application transitions to the background. Don't stop an ad, except in rare circumstances. In general, your application continues running and receiving events while users view and interact with ads, so it's possible that an event will occur that urgently requires their immediate attention. However, there are very few scenarios that warrant the dismissal of an in-progress ad. One possibility is with an application that provides Voice over Internet Protocol (VoIP) service. In such an application, it probably makes sense to cancel a running ad when an incoming call arrives. Note: Canceling an ad might adversely impact the kinds of advertisements your application can receive and the revenue you can collect. Managing Settings or Configuration Options iPhone applications can offer settings that define preferred application behaviors or configuration options users can specify to change some functionality of the application. Settings should represent information, such as an account name, that users set once and rarely (if ever) change. Users view application-specific settings in the built-in Settings application. Configuration options are values that users might want to change frequently, such as category types displayed in a list; configuration options should be available within the application itself. You should consider settings and options to be mutually exclusive. That is, you should not offer both settings and configuration options in your application. Comments: Put in "Settings" and "Configuration Options" in the apps to be designed. Even without setting, users should be able to use the apps. It's best when iPhone applications do not ask users to specify any settings at all. Users can begin to use these applications right away without being asked to supply set-up information. To achieve this in your application, there are a few design decisions you can make: ■ Focus your solution on the needs of 80 percent of your users. When you do this, the majority of users do not need to supply settings because your application is already set up to behave the way most users expect. If there is functionality that only a handful of users might want, or that most users might want only once, leave it out. ■ Get as much information as possible from other sources. If you can use any of the information users supply in built-in application or device settings, query the system for these values; don't ask users to enter them again. ■ If you must ask for set-up information, prompt users to enter it within your application. Then, as soon as possible, store this information in your application's settings. This way, users aren't forced to quit your application and open Settings before they begin to benefit from your application. If users need to make changes to this information later, they can go to your application's settings at any time. Unlike settings, configuration options are likely to be changed frequently as users choose to see information from new sources or in different arrangements. You can react dynamically to changes users make to these options, because users do not leave your application to access them. You can offer configuration options in the main user interface or on the back of a screen. To decide which technique makes sense, determine if the options represent primary functionality and how often users might want to set them. For example, Calendar allows users to view their schedules by day, week, or month. These options could have been offered on the back of the screen, but viewing different parts of a calendar is primary functionality and users are likely to change their focus frequently. Supporting Copy and Paste iOS provides an edit (or pasteboard) menu that supports Cut, Copy, Paste, Select, and Select All operations in text views, web views, and image views. The commands in the menu allow people to make changes to their content and copy content from one application into another. For example, you can specify the subset of commands the menu displays and you can influence where the menu appears. You have no control over the color or shape of the menu itself. Use commands that make sense in the current context. For example, if nothing is selected, the menu does not contain Copy or Cut because these commands act on a selection. If you support an edit menu in a custom view, you're responsible for making sure that the commands the menu displays are appropriate for the current context. Note that you cannot specify custom commands to display in the menu. Accommodate the menu display in your layout. UIKit displays the edit menu above or below the insertion point or selection, depending on available space, and places the menu pointer so that users can see how the menu commands relate to the content. You can programmatically determine the position of the menu before it appears, so you can prevent important parts of your UI from being obscured, if necessary. Support both gestures people can use to invoke the menu. Although the touch and hold gesture is the primary way users reveal the edit menu, they can also double-tap a word in a text view to select it and reveal the menu at the same time. If you support the menu in a custom view, be sure to respond to both gestures. In addition, you can define the object that is selected by default when the user double taps. Avoid creating a button in your UI that performs a command that's available in the edit menu. For example, it's better to allow users to perform a copy operation using the edit menu than to provide a Copy button, because users will wonder why there are two ways to do the same thing in your application. Consider enabling the selection of static text if it's useful to the user. For example, a user might want to copy the caption of an image, but they're not likely to want to copy the label of a tab item or a screen title, such as Accounts. In a text view, selection by word should be the default. Don't make button titles selectable. A selectable button title makes it difficult for users to reveal the edit menu without activating the button. In general, elements that behave as buttons don't need to be selectable. Combine support for undo and redo with your copy and paste support. People often expect to able to undo recent operations if they change their minds. Because the edit menu does not require confirmation before its actions are performed, you should give users the opportunity to undo or redo these actions. Supporting Undo and Redo iOS gives people the ability to undo and redo their typing in text views. People initiate an undo by shaking the device, which displays an alert that allows them to undo what they just typed, redo previously undone typing, or cancel the undo. Comments: Undo and Redo are important features especially for text entry, or picture editing. UIKit allows you to support undo in a more general way in your application. You can specify: ■ The actions users can undo or redo ■ When your application should interpret a shake event as the shake to undo gesture ■ How many levels of undo to support To provide a great user experience for the undo and redo capability in your application, you should: ■ Supply brief descriptive phrases that tell people precisely what they're undoing or redoing. UIKit automatically supplies the strings "Undo " and "Redo " for the undo alert button titles, but you need to provide a word or two that describes the action users can undo or redo. (Note that the Cancel button cannot be changed.) For example, you might supply the text "Delete Name" or "Address Change," to create buttons titles such as "Undo Delete Name" or "Redo Address Change." Be sure to avoid supplying text that is too long: A button title that is too long is truncated and is difficult for users to decipher. Also, because this text is in a button title, use title-style capitalization and do not add punctuation. ■ Avoid overloading the shake gesture. Even though you can programmatically set when your application interprets a shake event as shake to undo, you run the risk of confusing people if they also use shake to perform a different action. The shake gesture is the primary way people expect to initiate undo and redo, but you can also include the system-provided Undo and Redo buttons in a navigation bar, if appropriate. You might do this if it's essential that you display an explicit, dedicated button to perform these functions within the context of your application, but this is unusual. ■ Consider the context of the actions you allow to be undone or redone. In general, people expect their changes and actions to take effect immediately. As much as possible, the undo and redo capability should be clearly related to the user's immediate context, and not to an earlier context. Source: Apple Inc (2001). iPhone Human Interface Guidelines: User Experience. Apple Inc, Cupertino, California.