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.

20101121 - Common Tasks for iPhone

Comments: Below are the common tasks of iPhone as defined by Apple Inc. It is important to understand these before going to Design Guidelines. Chapter 4 Handling Common Tasks 45 Starting 45 Stopping 46 Accommodating Multitasking 46 Hosting Ads 48 Managing Settings or Configuration Options 50 Supporting Copy and Paste 51 Supporting Undo and Redo 52 Enabling Local and Push Notifications 53 Making Your Application Accessible 56 Providing Search and Displaying Search Results 56 Using the User's Location 57 Handling Orientation Changes 58 Using Sound 58 The Ring/Silent Switch—What Users Expect 59 Volume Buttons—What Users Expect 59 Headsets and Headphones—What Users Expect 60 Wireless Audio—What Users Expect 60 Define the Audio Behavior of Your Application 60 Manage Audio Interruptions 64 Handle Media Remote Control Events, if Appropriate 66 Providing Choices 66 Providing a License Agreement or a Disclaimer 67 Starting iPhone applications should start instantly so users can begin using them without delay. When starting, iPhone applications should: ■ Specify the appropriate status bar style. ■ Display a launch image that closely resembles the first screen of the application. This decreases the perceived launch time of your application. ■ Avoid displaying an About window, a splash screen, or providing any other type of startup experience that prevents people from using your application immediately. ■ By default, launch in portrait orientation. However, if your application runs only in landscape orientation, your application should launch in landscape regardless of the current device orientation. This signals users to rotate the device to landscape orientation if necessary. ■ Restore state from the last time your application ran. People should not have to remember the steps they took to reach their previous location in your application. Comments: That's why almost all mobile phones have a Starting animation to hide the fact that the phone does take some time for the process of starting up. Stopping People quit an iPhone application by opening a different application. In particular, note that people don't tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should: ■ Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable. ■ Save the current state when stopping, at the finest level of detail possible. For example, if your application displays scrolling data, save the current scroll position. Comments: Auto saving of data at appropriate frequency is important. iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways: ■ It provides feedback that reassures users that there's nothing wrong with your application ■ It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application If certain circumstances prevent only some of your application's features from working, you can display either a screen or an alert when users activate the feature. Although an alert doesn't allow much flexibility in design, it can be a good choice if you can: ■ Describe the situation very succinctly ■ Supply a button that performs a corrective action ■ Display the alert only when users try to access the feature that isn't functioning Comments: Three types of stopping: (1) User exits the application; (2) Application quits due to certain reasons; (3) Certain features of the application does not functions. Accommodating Multitasking Thriving in a multitasking environment hinges on achieving a harmonious coexistence with other applications on the device. At a high level, this means that all applications should: ■ Handle interruptions or audio from other applications gracefully ■ Stop and restart (that is, transition to and from the background) quickly and smoothly ■ Behave responsibly when not in the foreground The following specific guidelines help your application succeed in the multitasking environment introduced in iOS 4.0: ■ Be prepared for interruptions, and be ready to resume. Multitasking increases the probability that a background application will interrupt your application. Other features, such as the presence of ads and faster application-switching, can also cause more frequent interruptions. The more quickly and precisely you can save the current state of your application, the faster people can relaunch it and continue from where they left off. ■ Make sure your UI can handle the double-high status bar. The double-high status bar appears during events such as in-progress phone calls, audio recording, and tethering. In unprepared applications the extra height of this bar can cause layout problems. For example, the UI can become pushed down or covered. In a multitasking environment, it's especially important to be able to handle the double-high status bar properly because there are likely to be more applications that can cause it to appear. ■ Be ready to pause activities that require people's attention or active participation. For example, if your application is a game or a media-viewing application, make sure your users don't miss any content or events when they switch away from your application. When people switch back to a game or media viewer, they want to continue the experience as if they'd never left it. ■ Ensure that your audio behaves appropriately. Multitasking makes it more likely that other media activity is occurring while your application is running. It also makes it more likely that your audio will have to pause and resume to handle interruptions. ■ Use local notifications sparingly. An application can arrange for local notifications to be sent at specific times, whether the application is suspended, running in the background, or not running at all. For the best user experience, avoid pestering people with too many notifications. ■ When appropriate, finish user-initiated tasks in the background. When people initiate a task, they usually expect it to finish even if they switch away from your application. If your application is in the middle of performing a user-initiated task that does not require additional user interaction, you should complete it in the background before suspending. Source: Apple Inc (2001). iPhone Human Interface Guidelines: User Experience. Apple Inc, Cupertino, California.

20101121 - Usability & Design Guidelines for iPhone

Part II Designing the User Interface of Your iPhone Application 69 Chapter 5 A Brief Tour of the Application User Interface 71 Application Screens and Their Contents 71 Using Views and Controls in Application Screens 73 Comments: I think Apple Inc has come out with comprehensive set of usability and design guidelines for iPhone user interface. This helps ensure that iPhone apps developer come out with highly usable apps. Chapter 6 Navigation Bars, Tab Bars, Toolbars, and the Status Bar 75 The Status Bar 75 Navigation Bars 76 Navigation Bar Contents 77 Navigation Bar Size and Color 79 Toolbars 79 Toolbar Contents 80 Toolbar Size and Color 81 Tab Bars 81 Providing Additional Tabs 82 Badging a Tab in a Tab Bar 84 Chapter 7 Alerts, Action Sheets, and Modal Views 87 Usage and Behavior 87 Using Alerts 88 Using Action Sheets 89 Using Modal Views 89 Designing an Alert 90 Designing an Action Sheet 93 Designing a Modal View 96 Chapter 8 Table Views, Text Views, and Web Views 99 Table Views 99 Usage and Behavior 99 Table-View Styles 100 Table-Cell Styles 102 Table-View Elements 108 Switch Controls 109 Using Table Views to Enable Common User Actions 110 Text Views 113 Web Views 114 Chapter 9 Application Controls 117 Activity Indicators 117 Date and Time Pickers 118 Detail Disclosure Buttons 120 Info Buttons 120 Labels 121 Page Indicators 122 Pickers 124 Progress Views 125 Rounded Rectangle Buttons 126 Search Bars 126 Segmented Controls 128 Sliders 129 Text Fields 130 Chapter 10 System-Provided Buttons and Icons 133 Using System-Provided Buttons and Icons 133 Standard Buttons for Use in Toolbars and Navigation Bars 134 Standard Icons for Use in Tab Bars 136 Standard Buttons for Use in Table Rows and Other User Interface Elements 137 Chapter 11 Creating Custom Icons and Images 139 Application Icons 140 Small Icons 142 Document Icons 142 Web Clip Icons 143 Icons for Navigation Bars, Toolbars, and Tab Bars 144 Launch Images 146 Tips for Creating Great High-Resolution Artwork 148 Source: Apple Inc (2001). iPhone Human Interface Guidelines: User Experience. Apple Inc, Cupertino, California.

20100926 - Karlson, Interface & Interaction Design for one-handed Mobile Computing [touchscreen mobile phone]

Interface and interaction design for onehanded mobile computing by Karlson, Amy Kathleen, Ph.D., University of Maryland, College Park, 2007 , 282 pages; AAT 3297319 My Interest: 1) How she developed the Design Guidelines & Interaction Techniques. 2) How she tested/evaluated the Design Guideline – the 4 Applications. Action: To read specific parts of the Dissertation in future. Motivation Mobile phones are not only a ubiquitous social accessory, but rapid technology advances have transformed them into feature-rich, Internetenabled mobile PCs--a role once reserved for touchscreen-based personal digital assistants (PDAs). Although the most widespread phone styles in circulation feature the classic combination of numeric keypad and non-touchscreen display, larger touchscreen devices are gaining ground, as indicated by the fervor surrounding new devices such as Apple's iPhone and LG's Prada phone. Yet as devices evolve, users will remain constrained by the limits of their own visual, physical, and mental resources. Research Goal My research has focused on the specific limitation that mobile users often have only one hand available to operate a device, which can be especially problematic for touchscreen-based devices, since they are frequently designed for two-handed stylus operation. Considering the growing volumes of data that small devices can now store and connect to, as well as the expanding cultural role of mobile phones, improving usability in mobile computing has potentially enormous implications for user productivity, satisfaction and even safety. My own exploratory surveys have suggested that one-handed use of mobile devices is very common but that today's hardware and software designs do not support users in performing many tasks with only one hand. Motivated by these findings, the research goal of this dissertation is to contribute substantial knowledge in the form of empirically backed design guidelines and interaction techniques for improving one-handed usability and operation of mobile devices, with particular emphasis on those with touch-sensitive displays. The guidelines for one-handed mobile device design are the product of a series of studies conducted in pursuit of foundational knowledge in user behavior, preference, thumb capabilities and touchscreen-thumb interaction characteristics for singlehanded device use. Methodology I also demonstrate the application of these guidelines through the development and evaluation of four applications. Two involve designs for navigating among programs, one provides an interface for searching large data sets, and the last offers a generalized mechanism for controlling arbitrary touchscreen interfaces with a thumb. Each of these applications explores a different one-handed interaction technique and offers perspective on its viability for one-handed device use. Chapter 2 Foundations: Why Design for One-Handed Mobile Devices? 2.1 Related Work 2.1.1 Effects of Device Size on Design 2.1.2 Attention and Mobility 2.1.3 Impact of Form on Physical Resource Demands 2.1.4 Strategies for Reducing Hand Requirements 2.1.5 The Role of Audio in Mobile Interaction 2.2 Exploratory Study 1: Field Study 2.2.1 Method 2.2.2 Measures 2.2.3 Results 2.2.4 Discussion 2.3 Exploratory Study 2:Web Survey 2.3.1 Method 2.3.2 Measures 2.3.3 Results 2.3.4 Discussion 2.4 Conclusion Chapter 4 Applications: Touchscreen Design Strategies for One-Handed Mobile Computing 4.1 Overview 4.2 A Comparative Design Strategy 4.3 Related Work 4.7 AppLens and LaunchTile Formative Study 4.7.1 Participants 4.7.2 Measures 4.7.3 Materials 4.7.4 Tasks 4.7.5 Procedure 4.7.6 Results 4.8 Discussion 4.9 Conclusion Chapter 5 Applications: Search Strategies for One-Handed Mobile Computing 5.1 Motivation 5.2 Related Work 5.6 User Study 5.6.1 Participants 5.6.2 Method 5.6.3 Equipment 5.6.4 Tasks 5.6.5 Measures 5.6.6 Procedure 5.7 Study Results 5.7.1 Task Times 5.7.2 Percent Correct 5.7.3 Satisfaction 5.7.4 User comments 5.7.5 Usability Observations 5.8 Discussion 5.9 Conclusion Chapter 6 Applications: A Technique for Generalized One-Handed Interaction with Touchscreen Interfaces 6.1 Related Work 6.4 Study 1: Direct Interaction vs. Peripheral Hardware 6.4.1 Independent Variables 6.4.2 Tasks 6.4.3 Hypotheses 6.4.4 Implementation and Apparatus 6.4.5 Method 6.4.6 Participants 6.4.7 Procedure 6.5 Study 1: Results 6.5.1 Task Times 6.5.2 Error Rate 6.5.3 Satisfaction 6.5.4 Preference 6.5.5 Discussion 6.6 Study 2: ThumbSpace vs. Shift for Palm-Sized Touchscreen Devices 6.6.1 Independent Variables 6.6.2 Implementation and Apparatus 6.6.3 Tasks 6.6.4 Method 6.6.5 Participants 6.6.6 Procedure 6.7 Study 2: Results 6.7.1 Task Times 6.7.2 Error Rate 6.7.3 Input Choice 6.7.4 Satisfaction 6.7.5 Preference 6.8 Discussion