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.

20101121 – Apple, iPhone Human Interface Guidelines

CHAPTER 2 Human Interface Principles: Creating a Great User Interface A great user interface follows human interface design principles that are based on the way people—users—think and work, not on the capabilities of the device. A user interface that is unattractive, convoluted, or illogical can make even a great application seem like a chore to use. But a beautiful, intuitive, compelling user interface enhances an application's functionality and inspires a positive emotional attachment in users. Metaphors When possible, model your application's objects and actions on objects and actions in the real world. This technique especially helps novice users quickly grasp how your application works. Folders are a classic software metaphor. People file things in folders in the real world, so they immediately understand the idea of putting data into folders on a computer. Metaphors in iOS include iPod playback controls, tapping controls to make things happen, sliding on-off switches, and flicking through the data shown on picker wheels. Comments: This is inline with Nielsen's Heuristics: Match between system and the real world. Direct Manipulation Direct manipulation means that people feel they are controlling something tangible, not abstract. The benefit of following the principle of direct manipulation is that users more readily understand the results of their actions when they can directly manipulate the objects involved. iOS users enjoy a heightened sense of direct manipulation because of the Multi-Touch interface. Using gestures, people feel a greater affinity for, and sense of control over, the objects they see on screen, because they do not use any intermediate device (such as a mouse) to manipulate them. To enhance the sense of direct manipulation in your iPhone application, make sure that: ■ Objects on the screen remain visible while the user performs actions on them ■ The result of the user's action is immediately apparent See and Point An iPhone application is better than a person at remembering lists of options, commands, data, and so on. Take advantage of this by presenting choices or options in list form, so users can easily scan them and make a choice. Keeping text input to a minimum frees users from having to spend a lot of time typing and frees your application from having to perform a lot of error checking. Comments: Selecting choices/options is better than keying in text. Presenting choices to the user, instead of asking for more open-ended input, also allows them to concentrate on accomplishing tasks with your application, instead of remembering how to operate it. Feedback In addition to seeing the results of their actions, users need immediate feedback when they operate controls and status reports during lengthy operations. Your application should respond to every user action with some visible change. For example, make sure list items highlight briefly when users tap them. Audible feedback also helps, but it can't be the primary or sole feedback mechanism because people may use iOS-based devices in places where they can't hear or where they must turn off the sound. In addition, you don't want to compete with the iOS system sounds users already associate with system alerts. iOS automatically provides feedback when it's temporarily busy by displaying the activity indicator. During operations that last more than a few seconds, your application should show elapsing progress and, if appropriate, display an explanatory message. Animation is a great way to provide feedback to users, as long as it's both subtle and meaningful. Animation pervades iOS, even in nonimmersive applications. As a means of providing feedback, however, it is used to enhance the user's experience, not as the focus of the user's experience. Comments: Animation (such as progress bar) and audible sound are useful feedbacks when the user does an action (such as downloading, installing). User Control Allow users, not your application, to initiate and control actions. Keep actions simple and straightforward so users can easily understand and remember them. Whenever possible, use standard controls and behaviours that users are already familiar with. Provide ample opportunity to cancel operations before they begin, and be sure to get confirmation when the user initiates a potentially destructive action. Whenever possible, allow users to gracefully stop an operation that's underway. Comments: Use familiar or standardised controls. Get user's confirmation for destructive action (e.g. delete file). Make "Stop" button to enable user to terminate a certain process after process has commenced. Aesthetic Integrity Although the ultimate purpose of an application is to enable a task, even if that task is playing a game, the importance of an application's appearance should not be underestimated. This is because appearance has a strong impact on functionality: An application that appears cluttered or illogical is hard to understand and use. Aesthetic integrity is not a measure of how beautiful your application is. It's a measure of how well the appearance of your application integrates with its function. For example, a productivity application should keep decorative elements subtle and in the background, while giving prominence to the task by providing standard controls and behaviors. Be sure you design the user interface elements of such an application carefully, so that they provide an internally consistent experience. Comments: Aesthetics is also important to enhance usability. Source: Apple Inc (2001). iPhone Human Interface Guidelines: User Experience. Apple Inc, Cupertino, California. Pp 31-33

20101013 - Hu, ...Quantitative Usability Requirements Spec & Usability Evaluation..

A full life-cycle methodology for structured use-centered quantitative usability requirements specification and usability evaluation of websites by Hu, Guoqiang, Ph.D., Auburn University, 2009 , 201 pages; AAT 3386203 My Interest: 1) QUEST – Hu's usability evaluation method. 2) Expert usability review. 3) User usability testing. 4) SUS – System Usability Scale. 5) Usability metrics (usability criteria) of QUEST. Action: To search for his dissertation or journal article. Want to read more. Background World Wide Web has gained its dominant status in the cyber information and services delivery world in recent years. But how to specify website usability requirements and how to evaluate and improve website usability according to its usability requirements specification are still big issues to all the stakeholders. Research Goal To help solve this problem, we propose a website usability requirements specification and usability evaluation methodology that features a structured use-centered quantitative full life-cycle method. Methodology A validation experiment has been designed and conducted to prove the validity of the proposed methodology, QUEST (Quantitative Usability Equations SeT). Its principle is to prove that QUEST has stronger website usability evaluation capability than the most typical existing usability evaluation methods. Apparently, if QUEST's website usability evaluation capability is established, then its usability metrics can be used to quantitatively specify upfront user usability requirements for websites. In the validation experiment, 7 usability experts and 20 student subjects were recruited to perform 4 tasks on 2 open source calendar websites, WebCalendar 1.0.5 and VCalendar 1.5.3.1; 4 sets of usability data had been collected, which were corresponding to the following 4 usability evaluation methods respectively: expert usability review, traditional user usability testing, SUS (System Usability Scale), and QUEST. Comments: He should also compare against other popular usability evaluation methods such as heuristic evaluation, and cognitive walkthrough. He should also compare against other more popular Usability Questionnaires, such as QUIS and SUMI. Noted that a good method has been compared, i.e. user usability testing. Generally, he has not done a FAIR comparison. Results Discussion According to the experiment results: both the expert usability review and the traditional user usability testing were inconclusive on which of the 2 target websites had better usability; although SUS rated the overall usability of WebCalendar 1.0.5 at 66.00 and VCalendar 1.5.3.1 at 61.75, it was subjective and vague on usability problems; in contrast, QUEST not only rated the overall usability of WebCalendar 1.0.5 at 56.59 and VCalendar 1.5.3.1 at 35.97, but also revealed where the usability problems were and how severe each usability problem was in a quantitative manner. Comments: After reading Hu's abstract, an idea came to me. Initially, I have thought of selecting the type/hybrid of UEM based on literature review and comparison. Benchmarking on Hu, I could also do a study to compare various UEM and select the UEM type/hybrid based on the results of study. Conclusion In conclusion, it clearly can be stated that QUEST has stronger website usability evaluation capability than all other 3 most typical existing usability evaluation methods. So, the proposed methodology has been validated by the experiment results. Note: No Preview nor Full-Text dissertation is available for download.