Chapter 6

Designing the iPhone UI

WHAT YOU WILL LEARN IN THIS CHAPTER:

• Understanding the iPhone viewport
• Exploring IOS design patterns
• Designing for touch

More than anything else, the iPhone and iPad are known for their usability, intuitiveness, and overall positive user experience. The native IOS user interface (UI) is known by novices and geeks alike as being easy to use; no instruction manual needed.

An IOS web app doesn’t need to copy or perfectly emulate native IOS UI design and controls. In fact, some developers even argue that developers shouldn’t try to create IOS-focused web apps. Regardless of your position on that issue, there’s one thing you will want to do when you create an IOS web app — create a usable and navigable UI.

That’s why, in this chapter, you explore many of the common design patterns that Apple uses in its UI as well as the key design patterns used to present data in a mobile device. In this chapter, I focus primarily on iPhone; in Chapter 7, I focus on iPad.

EVOLVING UI DESIGN

User interface design has been evolutionary rather than revolutionary over the past decade. Most would argue that Mac OS X Lion and Windows 7 both have much more refined UIs than their predecessors. As true as that may be, their changes improve upon existing ideas rather than offer groundbreaking new ways of interacting with the computer. Web design is no different. All of the innovations that have transpired — such as HTML5 and Ajax — have revolutionized the structure and composition of a website but not how users interact with it. Moreover, mobile and handheld devices offered a variety of new platforms to design for, but these were either lightweight versions of a desktop OS or a simplistic character-based menu.

Enter IOS.

An IOS interface is not a traditional desktop interface, though it has a codebase closely based on Mac OS X. It is also not a traditional mobile interface, though the iPhone and the iPad are obviously mobile devices. Despite the fact that you build web apps using web technologies, an IOS interface is not a normal web application interface.

Because the underlying guts of IOS web applications are based on tried and true web technologies, many are tempted to come to the IOS platform and naturally want to do the same things they’ve always done — except customizing it for the new device. That’s why the biggest mindset change for developers is to grasp that they are creating IOS web apps, not web applications that happen to run on IOS. The difference is significant. In many ways, IOS web applications are far more like Mac or Windows desktop applications — users have a certain look and feel and core functionality that they expect to see in it.

On the Web, users expect every interface design to be one-offs. Navigation, controls, and other functionality are usually unique to each site. However, when working on a platform — be it Windows, Mac OS X, or IOS — the expectation is much different. Users anticipate a consistent way to do tasks — from application to application. Operating systems provide application program interfaces (APIs) for applications to call to display a common graphical user interface (GUI). Because IOS web apps do not have such a concept, it is up to you as an application developer to implement consistency.

THE IPHONE VIEWPORT

A viewport is a rectangular area of screen space within which an application is displayed. Traditional Windows and Mac desktop applications are contained inside their own windows. Web apps are displayed inside a browser window. A user can manipulate what is seen inside of the viewport by resizing the window, scrolling its contents, and, in many cases, changing the zoom level. The actual size of the viewport depends entirely on the user, though an average size for a desktop browser is roughly 1000 × 700 pixels.

The entire iPhone display is 320 × 480 pixels in portrait mode and 480 × 320 in landscape. However, application developers don’t have access to all of that real estate. Instead, the viewport in which an iPhone developer is free to work with is a smaller rectangle: 320 × 416 in portrait mode without the URL bar displayed (320 × 356 with the URL bar shown), and 480 × 268 in landscape mode (480 × 208 with the URL bar). Figures 6-1 and 6-2 show the dimensions of the iPhone viewport in both orientations.

FIGURE 6-1

FIGURE 6-2

Users can scroll around the viewport with their fingers. However, they cannot resize it. To use desktop lingo, an IOS application is always “full screen” and takes up all available space.

If the on-screen keyboard is displayed, the visibility of the viewport is further restricted with the keyboard overlay, as shown in Figures 6-3 and 6-4.

FIGURE 6-3

FIGURE 6-4

Because users have a much smaller viewport than they are used to working with on their desktop, the iPhone viewport has a scale property that you can manipulate. When Safari on IOS loads a web page, it automatically defines the page width as 980 pixels, a common size for most fixed width pages. It then scales the page to fit inside of the 320 or 480 pixel width viewport. Although 980 pixels may be acceptable for browsing a scaled-down version of a website, an iPhone application avoids scaling by customizing the viewport meta tag.

As I talked about in Chapter 5, you use the viewport meta tag to set the width and scale of the viewport. If you are creating a web app targeting iPhone, then you need to set the viewport to be the exact width of the device — 320px in portrait mode and 480px in landscape mode. (For iPad, you’d use 640px in portrait mode and 1024px in landscape.) To make things easier, Safari on IOS supports constants so you can avoid the specific numeric values. Therefore, to set the viewport for a normal iPhone web app, you should add the following meta tag to the head of your HTML document:

<meta name="viewport" content="width=device-width; initial-scale=1.0;
   maximum-scale=1.0; user-scalable=no;"/>

The width=device-width attribute sets the width to a fixed size and ensures that the viewport is not resized when the user rotates to landscape mode. The initial-scale=1.0 sets the scale at 1.0, whereas the maximum-scale and user-scalable settings disable user zooming of the web page.

EXPLORING IOS DESIGN PATTERNS

Before you begin designing your IOS web application, a valuable exercise is exploring the native IOS applications on the device or from the App Store. As you do so, you can consider how other designers handled a small viewport as well as how to design an intuitive interface for touch screen input.

Categorizing Apps

To fully appreciate the design decisions that went into these applications, you need to understand the differences in the way in which users use IOS applications compared to their desktop counterparts. After all, consider the types of applications that you find installed on your desktop computer. An overly simplistic categorization is as follows:

• Task-based applications: The typical desktop application, whether it is on Mac, Windows, or Linux, is designed to solve a particular problem or perform a specific task. These applications, (such as Word, Excel, PowerPoint, Photoshop, or iCal) tend to act upon one file or a few files at a time. The UI for these applications is often quite similar, including a top-level menu, toolbar, common dialogs for open/save, main destination window, and side panels.
• Aggregators: The second category of desktop application is aggregators — those applications that manage considerable amounts of data in which you tend to work with many pieces of data at a time rather than just one or two. iTunes manages your songs and videos, iPhoto and Picasa manage your photos, and Outlook and Apple Mail store your emails. The UI for aggregator applications is typically navigation-based, consisting of top-level navigable categories in a left-side panel (playlists in iTunes, folders in Mail, albums in iPhoto) and scrolling listings in the main window.
• Widgets: A third category is widget-style applications, which are mini applications that display system or other information (battery status meter, weather, world clock), or perform a very specific task (lyrics grabber, radio tuner). A widget UI typically consists of a single screen and a settings pane.

On the desktop, task-based applications have traditionally been the dominant category, though aggregators have become more and more important over the past decade with the increasing need to manage digital media. Although widgets are quite popular now that Apple and Microsoft have added this functionality directly into their OS, they remain far less important.

When you look at built-in IOS applications, you can see that they generally fall into these three categories as well. However, because of the device’s viewport and file-storage constraints, task-based applications take a back seat role to the aggregators (see Table 6-1).

TABLE 6-1: Categorizing Apple’s Built-in IOS Applications

The document is the primary point of focus in a traditional desktop application, but it is not surprising for a document on an IOS device to be consumable and temporary. You have the Pages, Numbers, and Keynote applications for IOS, but many of the documents that users work with are consumable: web pages, SMS messages, YouTube videos, quick notes, and Google maps.

Navigation List-based UI Design

Because the focus of many IOS apps is to consume various amounts of information, navigation list–based design becomes an essential way to present large amounts of information to users on the iPhone. As I mentioned earlier, desktop applications typically relegate navigation lists to a side panel on the left of the main window, but many iPhone applications use “edge-to-edge” navigation as the primary driver of the UI.

Not all navigation list designs are equal. In fact, the iPhone features at least eight distinct varieties of navigation lists. For example, the Contacts list uses a single line to display the name of a contact in bold letters (see Figure 6-5), whereas Mail uses a four-line list style to display both message header information and optional text preview (see Figure 6-6). Finally, YouTube sports a wealth of information in its four-line item (see Figure 6-7). Table 6-2 lists each of the various navigation style lists.

TABLE 6-2: Different Types of Navigation Lists

FIGURE 6-5

FIGURE 6-6

FIGURE 6-7

However, no matter the style of the navigation lists, they are each designed to quickly take you to a destination page in as few interactions as possible.

What’s more, the top title bar of the app usually provides contextual information to help users understand where they are in the hierarchy of the application. The left side often has a back button that enables users to return to the previous screen. Read more on this in the “Title Bar” section later in the chapter.

Application Modes

Native iPhone applications also often have modes or views to the information or functionality with which you can work. These modes are displayed as icons or buttons on the bottom toolbar (see Figure 6-8). Interestingly, in the initial release of iCal, the buttons were on the top. However, in subsequent releases, Apple moved the bottoms to the bottom to adhere to the convention of navigation on top, modes on bottom (see Figure 6-9).

FIGURE 6-8

FIGURE 6-9

Table 6-3 details these modes.

TABLE 6-3: Application Modes and UI Access

Therefore, as you begin to examine how you should design the UI of your application, look to see what parallels there are with the built-in iPhone application design. Even if you don’t emulate its look and feel, you might want to have a consistent approach.

EXPLORING SCREEN LAYOUT

By the time you have studied and evaluated the UI design of the built-in applications, you can then begin to determine what parallels may exist with the type of application in which you are building.

For applications that need to use a navigation list design, you need to download one of the frameworks that I discuss in Chapter 15. Each of these enables you to easily implement edge-to-edge navigation list–based applications.

The four common components of a typical mobile app are a title bar, a navigation list, a destination page, and a button bar.

Title Bar

Most IOSWeb applications should include a title bar to emulate the look of the standard title bar available in nearly all native IOS applications. When the URL bar is hidden (as I explain later in this chapter) the custom title bar displays just below the status bar at the top of the viewport (see Figure 6-10). The title bar includes the following elements:

FIGURE 6-10

• Back button: A back button should be placed on the left-hand side of the toolbar to allow the user to return to the previous page. The name of the button should be the same name as the title of the previous screen. This “bread crumb” technique lets the user know how he got to the page and how to get back. If the page is at the top level of the application then there is no back button.
• Screen title: Each screen should have a title displayed in the center of the toolbar. The title of the page should be one word and appropriately describe the content of the current screen. You do not want to include the application name in each screen title of the application, as you would for a standard web application.
• Command button: For some screens, you want to employ a common command, such as Cancel, Edit, Search, or Done. If you need this functionality, place a command button at the top right of the title bar.

Edge-to-Edge Navigation Lists

If you are designing an app specifically for the iPhone that aggregates or organizes lists of information, you typically want to follow iPhone’s edge-to-edge navigation list design pattern, as shown in Figure 6-11. Each of the cells, or subsections, is extra large to allow for easy touch input. In addition, to ensure that a user never loses context and gets lost, the title shows the current page, and a back button indicates the screen to which the user can return. When a list item expands to a destination page or another list, an arrow is placed on the right side indicating a next page is available.

FIGURE 6-11

When a list item is selected, the navigation list should emulate Apple’s slide-in animation, appearing as if the new page is coming in from the right side of the screen to replace the old.

Table 6-4 lists each of the specific metrics to emulate the same look and feel of the Apple design in edge-to-edge navigation lists.

TABLE 6-4: Metrics for Apple’s Edge-to-Edge Design

Rounded Rectangle Design Destination Pages

In a navigation-list UI design, a user ultimately winds up at a destination page that provides a full listing of the specific piece of information for which she was looking. Apple implements a rounded rectangle design, as shown in Figure 6-12. Labels are displayed on a blue background, and items are grouped together logically and surrounded by a rounded rectangle box. Table 6-5 describes the specifications you should follow to implement this Apple design.

TABLE 6-5: Metrics for Apple’s Rounded Rectangle Design

FIGURE 6-12

DESIGNING FOR TOUCH

One of the most critical design considerations you need to take into account for iPhone interfaces in particular is that that you are designing an interface that interacts with a finger, not a mouse or other mechanical pointing device. A mouse pointer has a small point that’s just a couple pixels in height, but a finger can touch 40 pixels or more of the screen during a typical click action. Therefore, when laying out controls in an application, make sure the height of controls and spacing between controls are easy to use even for someone with large fingers.

NOTE Because iPhone is a mobile device, keep in mind that users may be on the go when they are interacting with your application. Maybe they are walking down the street, waiting in line at a coffee shop, or perhaps even jogging. Therefore, you should allow enough space in your UI to account for shaky fingers.

Standard navigation list cells should be 44px in height. Buttons should be sized about the size of a finger, typically 40px in height or more and have sufficient space around them to prevent accidental clicks. You can get by with a button of 29 to 30 pixels in height if no other buttons are around it, but be careful. Table 6-6 lists the recommended sizes of the common elements.

TABLE 6-6: Metrics for Touch Input Screen

In addition to sizing and spacing issues, another important design decision is to minimize the need for text entry. Use select lists rather than input fields where possible. What’s more, use cookies to remember last values entered to prevent constant data reentry.

WORKING WITH FONTS

With its Retina Display and anti-aliasing support, iPhone is an ideal platform to work with typefaces. Quality fonts render beautifully on the iPhone display, enhancing the overall attractiveness of your application’s UI.

Helvetica, Apple’s font of choice for IOS, should generally be the default font of your application. However, IOS does offer several font choices for the developer. Unlike a typical web environment in which you must work with font families, IOS enables you to make some assumptions on the exact fonts that users have when they run your application. Table 6-7 lists the fonts that are supported on IOS.

TABLE 6-7: IOS Fonts

Safari on IOS automatically substitutes three unsupported fonts with their built-in counterparts. Courier New is substituted when Courier is specified. Helvetica is substituted for Helvetica Neue, and Times New Roman is used in place of Times.

BEST PRACTICES IN IOS UI DESIGN

When you are designing for IOS, there are several best practices to keep in mind:

• Remember the touch! Perhaps no tip is more critical in iPhone UI design than always double-checking every design decision you make with the reality of touch input.
• Make sure you design your application UI to work equally well in portrait and landscape modes. Some native applications, such as Mail, optimize their UI for portrait mode and ignore any changes the user makes to orientation. Third-party IOS web app developers do not have that same level of control. Therefore, any UI design you create needs to work in both orientation modes.
• Avoid UI designs that require horizontal scrolling. If your interface design requires the user to scroll from side to side within a single display screen, change it. Horizontal scrolling is confusing to users and leaves them feeling disoriented within your application.
• Keep your design simple. As attractive as the IOS interface is, perhaps its most endearing quality is its ease of use and simplicity. Your UI design should follow suit. Avoid adding complexity where you do not need to — either in functionality or design (see Figure 6-13).
• Use familiar lingo. You know the saying, “When in Rome.” Well, when designing for IOS, be sure you do not bring along the UI baggage you are used to elsewhere (Windows, Mac, or even the Web).
• Use UI frameworks, but use them wisely. Mobile web app frameworks (see Chapter 16) are major assets to the IOS web app developer community and provide a major head start in developing applications. However, don’t automatically assume that their prebuilt designs are the best way to go for your application. You may find another approach is better for your specific needs.
• Restrict use of a black button bar. A translucent black button bar (such as the one used by the iPod app in Figure 6-8) should only be used in your application for displaying modes or views, not for commands. Use the other button types for commands.
• Minimize the rabbit trail. Because IOS users are primarily concerned with consuming data, you should get them to the destination page as soon as possible. Therefore, make sure you are optimally organizing the information in a way that enables a user to get to the data he needs in just a couple of flicks and clicks.
• Place text entry fields at the top of the page. When your application requires data-entry fields, work to place these input fields as near to the top of the page as possible. Top positioning of text entry fields helps minimize the chances of the user losing context when the on-screen keyboard suddenly appears at the bottom of the screen.
• Communicate status. Because your application may be running from a 3G connection, its response may be relatively slow. As a result, be sure to provide status to the user when performing a function that requires server processing. This visual cue helps users feel confident that your application is working as expected and is not in a hung state.
• Label the title bar appropriately. Make sure each screen or page has its own title. The Back button should always be named with the title of the previous screen.
• Unselect previously selected items. When a user clicks the Back button in a navigation-list UI, be sure that the previously selected item is unchecked.
• Break the rules — competently. Although it is often wisest to design your app to be consistent with the design patterns that I’ve been discussing in this chapter, not every IOS application UI needs to rigidly conform to a design implemented already by Apple. You may have an application in which a different look-and-feel works best for its target users. However, if you decide to employ a unique design, be sure it complements overall IOS design, not clashes with it.

FIGURE 6-13

ADDING FINISHING TOUCHES

In order to transform your web app into something that looks and feels like a native IOS app, you need to put some finishing touches on it. In this final section, I show you how to launch the app in full screen, customize the status bar, and create a WebClip icon.

TRY IT OUT: Adding Finishing Touches to Your App

To make your web app appear much more like a native IOS app, follow these steps.

1. Create or obtain PNG images that you want to use as the icon for your app on the home screen of the IOS device. For iPhone 4 and above, you need 114 x 114. For iPad, you need 72 x 72. For iPod touch and older iPhone models, you need the default size of 57 x 57. Name the images as follows: touch-icon-iphone.png (57 x 57), touch-icon-ipad.png (72 x 72), and touch-icon-iphone4.png (114 x 114).

2. Save the image in the root directory of your web app.

3. Open the main page of your web app in a text editor.

4. Add an apple-mobile-web-app-capable meta tag to the document head and assign it a yes value:

<meta name="apple-mobile-web-app-capable" content="yes" />

5. Add a status-bar-style meta tag to the document head and set it to a value of black:

<meta name="apple-mobile-web-app-status-bar-style" content="black" />

6. Add the following link tags to the document head:

<link rel="apple-touch-icon" href="icon.png"/>
<link rel="apple-touch-icon" sizes="72x72" href="icon-ipad.png" />
<link rel="apple-touch-icon" sizes="114x114" href=" icon-iphone4.png" />

7. Save your file.

How It Works

By default, when you run your web app in Safari on IOS, Safari still takes up a sizable majority of the viewport with its URL bar and bottom bar. However, to take back that wasted space and to make your app look more like a native app, you should launch your application in full-screen mode, which your app does when the an apple-mobile-web-app-capable meta tag is provided in the document. However, full-screen mode only takes effect when you launch your app from the Home screen via a WebClip icon. When you access the page from the URL bar, Safari retains its URL bar and button bar.

When you use the apple-mobile-web-app-capable meta tag to go into full-screen mode, Safari still displays the top status bar. This behavior is not that unexpected because most native apps show it in the same way. However, if you prefer to mark the status bar, you can customize its appearance to be transparent black by using the status-bar-style meta tag and setting it to a value of black. However, this meta tag only takes effect if you also use the apple-mobile-web-app-capable meta tag to turn on full-screen mode.

Finally, the <link rel="apple-touch-icon/> tag enables you to add your app to the Home screen just like a native application. The graphic file you point to needs to adhere to the following conventions:

• Must be in .png format.
• Located in the root directory.
• As stated earlier, use 114 x 114 for iPhone 4 and above. For iPad, use 72 x 72. And for iPod touch and older iPhone models, use the default size of 57 x 57.
• Must be a rectangle — IOS automatically adds the rounded corners.
• It must be named apple-touch-icon.png or apple-touch-icon-precomposed.png. If you use apple-touch-icon.png, the iPhone OS adds round corners, drop shadow, and a “shiny coating” to the graphic. If you use apple-touch-icon-precomposed.png then the OS won’t add these effects.

Users can add the WebClip icon of your app by clicking the + button on the button bar when they navigate to the URL. In the pop-up dialog, users click the Add to Home Screen button (see Figure 6-14).

FIGURE 6-14

Unfortunately, because there is no formal install process of a web app, there is no programmatic way to automatically add a WebClip icon to the Home screen. The process must be carried out by the user.

• WHAT YOU LEARNED IN THIS CHAPTER