A Brief Tour of the Application User Interface
Before you delve into the details about specific views and controls, it’s helpful to gain a high-level understanding of the way these elements can work together and how users expect them to behave. This chapter introduces the views that comprise the building blocks of most applications, describing where they belong and touching on how they’re used.
To learn more about the appearance, behavior, and usage guidelines of individual user interface elements, be sure to read the chapters following this one. Understanding how each user interface element is designed to be used helps you use it correctly in your application and, if appropriate, customize it to meet your needs.
Application Screens and Their Contents
Every application, regardless of type, has an application window. Programmatically, the window provides the background on which you present all your application’s information. But users are not aware of this window; instead, they experience your application as a collection of screens through which they navigate.
Although it’s not a programmatic construct, you can think of a screen as corresponding to a distinct visual state or mode in your application. Users can see individual screens when they navigate through an information hierarchy, tap different tabs in a tab bar, or tap an Info button to view flip-side configuration options.
Depending on the style of your application, you might have a large number of screens or just a few. For example, Mail can display an accounts screen, screens that list the mailboxes in each account, screens that list the contents of each mailbox, and a screen for each message, in addition to a message composition screen. On the other hand, the Stocks application displays two screens: One screen displays a list of companies and a stock-performance graph and the second screen displays application configuration information.
For the most part, users think of an application screen and the device screen as identical. However, an application screen’s content can extend beyond the bounds of the device screen, requiring users to scroll. For example, the Contacts screen is a single screen in the Phone application, even though it’s likely to list enough names to fill the device screen several times over.
Each application screen can contain various combinations of views and controls. Some views include specific controls that do not belong anywhere else, and some controls can be used in a variety of views.
Alerts, action sheets, and modal views are distinct types of views that do not exist in an application screen like most other views; instead, they float above application screens and their views. See “Alerts, Action Sheets, and Modal Views” for more information about these views.
Four types of views have special status in the user interface of an application, although they do not need to be included or always be visible in every application. These are:
The status bar. This is a unique view that isn’t technically part of the application window, although an application can customize the appearance of the status bar to some extent. See “The Status Bar” for more information.
The navigation bar. This optional view appears just beneath the status bar and can include titles, buttons, and segmented controls. See “Navigation Bars” for more information.
The tab bar. This optional view appears at the bottom edge of a screen and contains segments that activate different modes in the application. See “Tab Bars” for more information.
The toolbar. This optional view appears at the bottom edge of a screen and includes controls that perform specific actions in the current context of the application. See “Toolbars” for more information.
Figure 5-1 shows three of these views in an application screen. Note that if this application used a toolbar, it would appear in place of the tab bar.
In an application that displays some combination of these four views, you can think of the area between the bottom of the navigation bar and the top of the toolbar or tab bar as the content area. In this area, an application screen can contain arbitrary views to display content, such as table views, web views, and image views. Figure 5-2 shows examples of two of the content-area views available in iOS: a style of table view and image views. To learn more about the behavior and appearance of some of these views, in addition to the controls associated with them, see “Table Views, Text Views, and Web Views.”
As mentioned above, there are some controls that are available only in specific views. An example of such a control is the disclosure indicator, which has a specific use in a table view. You can see an example of the disclosure indicator (it looks like >) in the left-hand list in Figure 8-1. These controls are described in the sections that cover their associated views. In addition to these, however, there are a handful of controls, such as the detail disclosure indicator, that have a wider usage. See “Application Controls” for more information on the controls available to you.
Using Views and Controls in Application Screens
In iOS, UIKit determines the behavior and default appearance of views and controls. As much as possible, you should use the standard user interface elements UIKit provides and follow their recommended usages. Doing this helps you in two important ways:
Users are accustomed to the look and behavior of standard views and controls. When you use familiar user interface elements, users can depend on their prior experience to help them as they learn to use your application.
If iOS changes the look or behavior of standard views or controls, your application continues to work and automatically looks up to date with little, if any, work on your part.
Many controls support some kind of customization, usually in color or content (such as the addition of a text label or an image). If you’re developing an immersive application, it’s reasonable to create controls that are completely different from the default controls. This is because you’re creating a unique environment, and discovering how to control that environment is an experience users expect in immersive applications.
In general, though, you should avoid radically changing the appearance of a control that performs a standard action. If you use unfamiliar controls to perform standard actions, users will have to spend time discovering how to use them and will wonder what, if anything, your controls do that the standard ones do not.
Last updated: 2010-08-03