Summary: Apple’s iOS Human Interface Guidelines

When designing an iPhone app, there should be a few things on your checklist before starting coding. One of them should be reading Apple’s incredibly useful and important iOS Human Interface Guidelines. They guide the design of your app, and ensure that you (A) don’t spend valuable time re-inventing the iOS design wheel and (B) ensure Apple’s doesn’t reject your app for not meeting its guidelines.

But, at 70 pages, it’s a long a read. As part of designing Ning’s iPhone app (not the highest ratings, I know), I read through the guidelines and summarized them. I figured other people might find the summary useful, so here it is!

Ch. 1: Device Characteristics

  • Use the small screen real estate as a reason to eliminate any needless functionality and focus on only the UI elements that are absolutely necessary
  • Newer iPhones support iOS 4.0, which allows apps to continue running in the background even while they are not the active application
  • Take advantage of standard iOS UI controls, so that users are better able to quickly learn how to use your app
  • There are three main types of application styles
    • Productivity apps
    • Utility apps
    • Immersive apps
  • Productivity apps are hierarchal and the model user interaction model consists of
    • Organizing the list
    • Adding to and subtracting from the list
    • Drilling down until the desired level of detail is reached, then performing tasks
  • Remember, users will typically want to open your app, use it briefly, then quit
  • 80-20 rule: 80 percent of your users will use very few features, while 20 percent will use most of them
  • In productivity applications, use hierarchal breadcrumbs to remind users where they are, where they came from and make it possible to navigate back

Ch. 2: Creating a great user interface

  • Use metaphors to communicate actions to your users, like folders or on/off switches
  • Use existing iOS metaphors where possible and don’t redefine them
  • To enhance the sense of direct manipulation:
    • Objects on screen should remain visible when you manipulate them
    • The result should be immediately apparent
  • Present options instead of allowing open-ended input
  • Allow users to cancel operations before they begin, or even after they start
  • Be sure to get confirmation when a user initiates a destructive action

Ch. 3: From Product Definition to Branding

  • Craft a product definition statement — a declaration of your applications main purpose and intended audience
  • How is your audience different from other iOS apps?
  • To ensure that your audience can learn your app quickly, follow these ease-of-use guidelines:
    • Make it obvious how to use your app
    • Concentrate frequently used, high-level information near the top of the screen
    • Minimize text input
    • Express essential information succinctly
    • Provide a fingertip-size target area for all tappable elements
  • With each UI element, ask yourself “Is this is something that users need right now?”
  • Subtle animation can communicate status and feedback, but be wary of overdoing it
  • Avoid technical jargon in the UI
  • Users can perform specific movements, or gestures, to get particular results
    • Fingers are much larger than mouse pointers, so you UI must be finger-friendly
    • Examples include pinching to zoom, flicking to scroll
    • Try to limit the gestures you require to the most familiar — the tap and drag
    • Avoid making less common gestures the only way to complete an action
  • Strive to include branding in a refined, unobstrusive way
  • See gesture chart

Ch. 4: Handling Common Tasks

  • When your app is starting, it should:
    • Specify the right status bar style
    • Display a launch image that closely resembles your first screen
    • Avoid displaying a splash screen that delays interaction
    • Launch in portrait orientation
    • Restore state
  • Stopping
    • All iPhone apps should be prepared to quit at any time, so save user data as soon as possible and as often as reasonable
    • Save current state, with as much detail as possible
    • Never quit programatically, ask users to correct information
    • If some needed action prevents some of your apps’ features from working, display a screen alert and allow user to correct
  • Allowing for Multitasking
    • App should behave responsibly when running in background
    • Be prepared for interruptions, and be ready to resume
    • Be sure your UI can handle the double-high status bar
    • Be ready to pause activities that require attention or participation
    • Ensure audio behaves appropriately
    • Use local notifications sparingly
    • When appropriate, finish user-initiated tasks in the background
  • In iOS 4.0 you can allow advertisements to display within your application
  • Managing settings and configuration options
    • Settings represent information that users change once, or very rarely
    • Configuration options are values that users might change often
    • Settings and configurations should be mutually exclusive; your app should have one or the other
    • Focus your solution on the needs of 80 percent of your users
    • Get as much info as possible from other sources, such as info from built-in apps or device settings
    • Prompt users to enter settings within the application
    • You can make configuration settings available via the main user interface or on the back of a screen
  • iOS provides a pasteboard menu that supports cut, copy, paste, select and select all in text views, web views and image views
    • You can customize these behaviors to suit your application
    • Accomodate menu display in your layout
    • Consider enabling the selection of static text if it’s useful to the user
    • Don’t make button titles selectable
    • Combine support for undo and redo
  • Enabling local and push notifications
    • Local notifications are scheduled by an application and delivered by iOS, even if the application is not in the foreground
    • Push notifications are sent by an application’s remote server
    • When notifications arrive, you can update a badge on app’s hoe screen or display an alert — and you can display a sound when either happens
    • Be sure to provide a custom message for the alert
      • Short enough to display on 1-2 lines
      • Use sentence style capitalization and ending punctuation
    • Provide custom title for action button. Typically “Close” on the left and “View” is on the right, but it can be changed
  • To make your application accessible, give VoiceOver the information it needs
  • Providing and displaying search
    • You can responsible for implementing search in your application
    • Display a search bar above lists
    • When possible, filter remote data as users type, but display progress for lengthy searches
    • Avoid using a tab for search, unless it’s a primary action
    • You can add “scope” bars to search, like “From” and “Subject” in Mail
  • Location sharing is a system-wide setting
    • If your app needs location to run, show the alert to request it immediately
    • If user’s location is not essential, you can just restrict the feature of your app that requires it
    • If a feature needs location information to function, avoid any programmatic calls that trigger the alert before the user selects the feature
  • If a user rotates the device to “see more” don’t scale the view, you must rewrap text
  • If part of your app displays in only orientation, your app should not respond to changes in orientation
  • Managing sounds in iOS
    • When a user switches to silent mode, it does not silent sounds from actions that are explicitly meant to produce sound, like playing music
    • You must decide how your audio should behave when the user or other apps generate sound or change settings
  • iOS provides the following elements you can use to offer choices to users:
    • Lists. Users tap a row in a list to select an item.
    • Pickers, such as date and time pickers
    • Switch controls, such as sliders.

Ch. 5: Tour of the Application User Interface

  • Every application has an application window
  • Screens correspond to a particular view, state or mode within your app
    • Application screens can extend beyond the device, requiring scrolling
  • Four types of views have special status in the user interface
    • The status bar, at the top of screen, can be customized by apps in limited ways
    • The navigation bar, includes titles and controls
    • The tab bar, allowed access to segmented sections of an app
    • The toolbar, allows users to access actions
  • Content area is the are between the navigation bar and the tab/toolbar
  • As much as possible, user standard user interface elements, so that…
    • Users are accustomed to look, feel and behavior of your application
    • If iOS changes look/behavior of controls, your app is updated instantly

Ch. 6: Navigation Bars, Tab Bars, Toolbars and the Status Bar

  • The Status Bar
    • Immersive applications can hide the status bar, but be wary of doing so, as most users want it to be visible
    • If you sometimes hide the status bar in your app, consider allowing users to bring it back with a single tap (like Photos in detail view)
    • If your app is performing an operation that will take more than a few seconds, you can display the “network activity indicator”
  • Navigation Bars
    • The bar typically does three things:
      • Usually displays title of the current view
      • Enable navigation among different views in an application
      • Contains controls that users can take on that view’s content
    • Initial view in a productivity app should be a navigation bar with nothing but the title of the first view
    • When user navigates, title should change and back button should appear
    • A multi-segment, breadcrumbs-style back button is not recommended
    • If you do not need to display a back button, you can display an “Edit” button to manage the view
    • In landscape mode, the navigation bar is thinner, so take that into account when designing icons
  • Toolbar
    • Appears at the bottom of the screen
    • Contains buttons that perform actions related to objects in the current view
    • Designers should aim to have no more than 5 action icons in the toolbar
    • You can design your own icons, or use the predefined iOS buttons
    • Just as with nav bar, landscape view can change the toolbar height
  • Tab Bars
    • Tab bar allows users to switch between different views or modes within an application
    • Tab bar should never include buttons for actions users can take
    • The tab bar displays icons and text in tabs, all of which are equal in width and display a black background.
    • A tab bar does not change its height or opacity, regardless of orientation
    • If your tab bar contains more than 4 tabs, iOS will show the first four then use a “More” tab to display the rest
      • Users can click the “Edit” button in “More” view to customize which tabs are displayed first
    • Add a badge to a tab to display non-critical information, like the number of unheard voicemails

Ch. 7: Alerts, Action Sheets and Modal Views

  • Alerts, action sheets and modal views are views that appear when something requires user’s attention
  • See: Visual breakdown of alerts, action sheets and modal views
  • All are modal, meaning a user must dismiss them to proceed, so don’t use them too often
  • Alerts give people important information that affects their use of an application
    • Alerts appear unattached, signifying arrival is due to a change in the app or device, not a user action
    • Display text explaining the situation, and allow give user ability to take action to rectify
    • Also use alerts to notify user that action is potentially dangerous, and allow them to continue or cancel
    • Hitting the “Home” button when viewing an alert should be the same as hitting “Cancel”
    • To confirm a user-initiated action, use an action sheet
    • Don’t use an alert to notify user about something they can do nothing about
  • Action sheets give people additional choices for the action they are taking
    • Provide a selection of ways the task can be completed
    • Get confirmation before completing a potentially dangerous task
  • Modal views provide more extensive functionality for the current task
    • Support multi-step user interaction
    • Use to select more than one option, or collect information
  • Designing an alert
    • You can specify the text, the number of buttons, and the button contents in an alert
    • Alert titles should be short, informative, fragments — and can be negative
    • Alert message should be sentences with punctuation, ideally two or fewer lines
    • Avoid explaining which button to tap in the alert text (“Tap ‘OK’ to…”)
    • Text alert in both orientations
    • Aim for two-button alerts, as one-button alerts are purely informative
    • Give alert buttons short, logical titles, especially verbs/verb phrases
  • Designing an action sheet
    • Action sheets display as a result of a user action
    • Action sheet background colors should coordinate with your navigation and toolbars, being either black or blue
    • Display “Cancel” at the bottom of an action sheet
    • For potentially destructive actions, use a red color button and place it at the top of the sheet
  • Designing a modal view
    • Include a title that describes the task
    • Include whichever controls are needed to accomplish the task
    • You can specify the “Vertical” or “Flip” method to reveal the modal view
      • If you use different methods, make sure there is logical reasoning, as the user will assume there is

Ch. 8: Table Views, Text Views and Web Views

  • Table views can be used to display lists of choices, grouped lists or indexed lists
  • Text and web views are unconstrained ways to accept and display content
  • Table view presents data in a single column list of rows
    • See: Table view examples
    • You can display header and footer information, around the whole list, or around groupings
    • You can allow users to add, remove or reorder list items
    • When an item in a list is selected, it should appear highlighted then either move to a new view or get a checkmark
    • When row selection results in a new view, selected row should highlight briefly as new screen slides into place
    • A table should display content immediately, e.g. display text then images as they download
    • If data changes infrequently, consider displaying the stale data while the app downloads the latest data
    • If nothing can be displayed right away, consider showing a “Loading” message
    • iOS defines two types of table views
      • Plain (UITableViewStylePlain), includes rows that extend from edge-to-edge
      • Grouped (UITableViewStyleGrouped), includes groups of rows inset from the edges
    • Text truncation is standard in all table styles
    • iOS offers four different predefined table cell styles
      • Default style, includes optional image on the left, followed by left-aligned black text
      • Subtitle style, includes default style plus a label on the next line
      • Value 1 style, includes left-aligned text label in black, with smaller, right-aligned text label in blue
      • Value 2 style, includes right aligned text label in small font, followed by left-aligned black text label on the same line
    • You can avoid text truncation by increasing row heights, but it can be problematic
    • If you want to create your own table cell style, it’s better to start from scratch than modify a standard one
    • iOS includes some standard table-view elements:
      • Disclosure indicator, which tells users they can tap on the row
      • Detail disclosure button
      • Delete button
      • Row insert button
      • Row reorder control
      • Checkmark
      • Switch control
    • Table views can allow users to do common actions, e.g.:
      • Selecting options where a user can choose a single item
      • Navigating hierarchical information
      • View conceptually grouped information
      • Look up indexed information
  • Text view is a region that displays multiple lines of text and supports scrolling
    • Keyboard typically is shown, allowing user to edit text
    • You have control over font styles of the entire text view, but not particular parts of text
  • Web view is a region that display rich, HTML content in your app
    • Web view can support mini-navigation controls for navigating web pages
    • You could implement web view to simply wrap a web site and create an iPhone application

Ch. 9: Application Controls

  • iOS provides controls you can use in your application that are familiar to users
  • Activity indicator shows progress of a task that is of unknown duration (e.g. the “spinning gear”)
    • You can control the size and color of the indicator
    • Indicator disappears when task is complete
  • You can use four different modes of a date and time picker to allow user to select:
    • Date
    • Time
    • Date and time
    • Countdown timer
  • Detail disclosure buttons can be used in your app outside table view
    • Reveal additional features or functionality
  • Info button reveals configuration details
    • Well-suited to utility applications
  • Labels are variably sized amounts of static text
    • You can control font, color and alignment
    • Ensure they are legible
  • Page indicators displays a dot for each page within a view
    • The dot representing the current page should have a glow
    • There is no programmatic limit to the number of dots
  • Use a picker to show a list of values
    • Users spin the picker wheel into the desired value appears
    • Remember that most values in the picker are hidden from user view
    • If you need to display a great many values to choose from, consider a table view instead
  • Progress views display progress on a task of known duration
    • Default style is designed for the main content area
    • The bar style is thinner, and designed for the toolbar area
  • Rounded rectangle buttons use title case and allow users to perform an action
  • Search bar accepts text from users, allowing them to input terms for search
    • Bar can have placeholder text, bookmarks button, clear button and descriptive text above
  • Segmented controls allow user to change views
    • It’s recommended to have five or fewer segments in each control
    • Control can have text or image, but not both
  • Sliders allow users to make adjustments to a value within a range
    • Slider consists of a track, a thumb, optional right/left images
    • You can use either vertical or horizontal sliders
  • Text field is a rounded rectangular field that accepts user input
    • When user taps a text field, keyboard should appear
    • You can display images on the right or left of the text field
    • Use left end of a text field to indicate its purpose and right to indicate additional features
    • You can use placeholder text to help guide users
    • You can specify the corresponding keyboard types

Ch. 10: System-Provided Icons and Buttons

  • iOS provides numerous icons and buttons, so avoid designing custom ones that look similar to defaults
  • Buttons have two styles: Plain (toolbars only) or bordered (navigation and toolbars)
  • Take advantage of iOS’s predefined icons/buttons

Ch. 11: Creating custom icons and images

  • Every application needs and application icon and launch image, along with some optional images
    • When iOS displays your icon on the home screen, it adds rounded corners, a drop shadow and a reflective shine
  • You must provide at least one launch image
    • A launch image looks very similar to the first screen your app displays
    • Design a launch image that’s identical to the first screen, except for:
      • The text
      • UI elements that might change

Add a Comment