Lập trình iphone chuyên nghiệp part 2

Designing a User Interface

User interface design has been evolutionary rather than revolutionary over the past decade. Most
would argue that Mac OS X and Windows Vista 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 AJAX and XHTML — have revolutionized the
structure and composition of a Web site, 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 iPhone and iPod touch.
An iPhone/iPod touch interface (I ’ ll refer to it as an “ iPhone interface ” for short) is not a
traditional desktop interface, though it is has a codebase closely based on Mac OS X. It is not a
traditional mobile interface, though iPhone and iPod touch are mobile devices. Despite the fact
that you build apps using Web technologies, an iPhone interface is not a normal Web application
interface either. iPhone is clearly the first groundbreaking UI platform that many developers will
have ever worked with.
Because the underlying guts of iPhone applications are based on Web 2.0 technologies, many Web
developers will come to the iPhone platform and naturally think they are just creating a Web
application that runs on a new device. That ’ s why the biggest mindset change for developers is to
grasp that they are creating iPhone applications, not Web applications that run on iPhone. The
difference is significant. In many ways, iPhone applications are far more like Mac or Windows
desktop applications — users have a certain look and feel and core functionality that they will
expect to see in your iPhone application.
On the Web, users expect every interface design to be one - offs. Navigation, controls, and other
functionality are unique to each site. However, when working on a platform — be it Windows,
Mac OS X, or iPhone — the expectation is much different. Users anticipate a common 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). Since the iPhone
does not have such a concept, it is up to the application developer to implement such consistency.
c02.indd 13c02.indd 13 12/7/07 2:40:06 PM12/7/07 2:40:06 PM

Chapter 2: Designing a User Interface
14
This chapter will provide the high - level details and specifications you need to consider when designing a UI
for iPhone. Chapter 4 continues on by diving into the actual code needed to implement these user interfaces.
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 URL bar
displayed (320 × 356 with the URL bar shown), and 480 × 268 in landscape mode (480 × 208 with URL
bar). Figures 2 - 1 and 2 - 2 show the dimensions of the iPhone viewport in both orientations.
Figure 2 - 1: Portrait viewport
Status bar: 20 pixels
URL bar: 60 pixels
Content: 356 pixels
Button bar: 44 pixels
Width: 356 pixels
c02.indd 14c02.indd 14 12/7/07 2:40:09 PM12/7/07 2:40:09 PM
Chapter 2: Designing a User Interface
15
Figure 2-2: Landscape viewport
Status bar: 20 pixels
Content: 208 pixels
Button bar: 32 pixels
Width: 480 pixels
Users can scroll around the viewport with their fingers. However, they cannot resize it. To use desktop

lingo, an iPhone application is always “ maximized ” and takes up the full 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 2 - 3 and 2 - 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 can be manipulated. When Mobile Safari 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. While 980 pixels may be acceptable
for browsing a scaled down version of ESPN.com or CNN.com , an iPhone application will almost
certainly want to avoid this type of scaling by customizing the
meta viewport
element. You learn how
this is done in Chapter 4 .
Exploring Native iPhone Applications
Before you begin designing your iPhone application, a valuable exercise is exploring the built - in
Apple applications that come with the iPhone right out of the box. As you do so, you can consider how Apple
designers handled a small viewport as well as how to design an intuitive interface for touch screen input.
However, to fully appreciate the design decisions that went into these applications, you need to
understand the differences in the way in which users use iPhone applications compared to their desktop
c02.indd 15c02.indd 15 12/7/07 2:40:10 PM12/7/07 2:40:10 PM
Chapter 2: Designing a User Interface
16
Figure 2-3: Forms in Portrait viewport
Status bar: 20 pixels
URL bar: 60 pixels
Keyboard: 216 pixels
Width: 356 pixels
Content: 140 pixels
Form assistant: 44 pixels
Figure 2-4: Landscape viewport
Status bar: 20 pixels

Keyboard: 180 pixels
Form assistant: 44 pixels
Width: 480 pixels
URL bar: 60 pixels
c02.indd 16c02.indd 16 12/7/07 2:40:12 PM12/7/07 2:40:12 PM
Chapter 2: Designing a User Interface
17
counterparts. After all, consider the types of applications that you will 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 and 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 sys-
tem 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. While 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 iPhone applications, you can see that they generally fall into these three
categories as well. However, because of iPhone ’ s viewport and file storage constraints, task - based
applications take a back seat role to the aggregators (see Table 2 - 1 ).
Table 2-1: Categorizing Apple’s iPhone Applications
Aggregators Task-based Widgets
Mail Safari Stocks
SMS Phone Weather
Photos Camera Clock
YouTube Calendar Calculator
Notes Maps
Contacts (Address Book)
iPod
While the document is the primary point of focus in a traditional desktop application, a document is
often consumable and non - permanent on the iPhone device. Most of the documents that users work
with are consumable: Web pages, SMS messages, YouTube videos, quick notes, Google maps. Even
Word, Excel, and Acrobat documents are read - only and only accessible as email attachments. What ’ s
more, for the more permanent storage pieces of information, you tend to sync with a master copy on
your desktop — iPod songs, videos, and photos. In fact, there are only three cases in which you actually
c02.indd 17c02.indd 17 12/7/07 2:40:13 PM12/7/07 2:40:13 PM
Chapter 2: Designing a User Interface
18
Figure 2-5: Contacts’ 1-line navigation list
Figure 2-6: Mail’s 4-line navigation list
create data on the iPhone that you then store permanently — calendar appointments, emailed photos,
and contacts.
The focus of iPhone usage is consuming information far more than creating information. If your
application conforms to this usage model, your UI design needs to account for that reality.
Navigation List – Based UI Design
Since the focus of the iPhone is to consume various amounts of information, navigation list – based design
becomes an essential way to present large amounts of information to users. 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 2 - 5 ), whereas Mail uses a 4 - line list style to display both message header information
and optional text preview (see Figure 2 - 6 ). Finally, YouTube sports a wealth of information in its 2 - line
item (see Figure 2 - 7 ). Table 2 - 2 lists each of the various navigation style lists.
c02.indd 18c02.indd 18 12/7/07 2:40:13 PM12/7/07 2:40:13 PM
Chapter 2: Designing a User Interface
19
Figure 2-7: YouTube’s 2-line navigation list
Table 2-2: Different Types of Navigation Lists
Application Style Displays
Contacts 1 line Name of contact (last name bolded)
Mail 2.7 lines (default 4) Message title and optional text preview
Google Maps List 2 lines Location name, address
SMS 3 lines Message title and text preview
Table continued on following page
c02.indd 19c02.indd 19 12/7/07 2:40:14 PM12/7/07 2:40:14 PM