The incredible growth rates for the iPhone, iPod touch, and iPad have pushed consumers to a new "App" economy, with developers racing to the platform. Mobile touch-centric interfaces vary greatly from traditional computing platforms, and programmers as well as designers must learn to adapt to the new form-factor.
The iPhone User Interface Cookbook offers a complete breakdown of standard interface design on the iPhone, iPod touch, and iPad. You will learn the tools behind the trade, how to properly utilize standard interface elements, and custom UI tricks that will help your work stand out on the App Store.
The book is designed to be a complete overview of interface design on all iOS platforms, offering insight and an inside look into app design. A variety of topics are covered, starting with an overview of tools for the app interface designer, touching upon popular interface components such as the Tab Bar, and offering suggestions for complex game interfaces. Whether you're new to the platform or a seasoned developer with numerous applications in the App Store, this book strives to teach everyone simple and easy to implement tips for iOS interface design. Regardless of skill level, the iPhone User Interface Cookbook offers a detailed breakdown of all things interface design.
In the Preface, we'll touch upon the basic features of iOS and the common tools that we'll use as interface designers. If you're uncomfortable with the thought of being considered a designer, start your reading here.
For Chapter 1, Getting Started: Prototyping, Proper Tools, and Testing our Design, we'll touch upon the first steps of interface development. We'll start out with early design sketches, then progress on to the point where we put our app onto a device or offer a test build for beta users.
In Chapter 2, Customizing our Icon, the Navigation Bar, and the Tab Bar, we'll tackle the first thing the user sees when using our app: the icon. This 512 pixel square will be an essential piece of the puzzle if we want to see success, and we'll discuss some ways in which our work can stand out from the crowd.
Chapter 3, Different Ways To "View" our Application, is all about the different content presentation views that are available for our application. We'll discuss web views, Twitter views, modal views, and much more.
What's the difference between a Tab Bar and a Navigation View? In Chapter 4, Utilizing Common UI Elements, we'll tackle the various navigational interface elements that exist for our use in iOS.
Chapter 5, All About Games is action packed, as we tackle interface challenges that exist for games on iOS. Unsure about how to best go about game play mechanics or a heads up display when working with a touch platform? These recipes will help you gain a high score in interface design.
First impressions and final goodbyes are the topics that we'll take on in Chapter 6, Starting, Stopping, and Multitasking. From the Default.PNG to multitasking in iOS 4 and 5, we'll learn about the best ways to design our application for the stop and go nature of iOS.
Chapter 7, Notifications, Locations, and Sounds helps teach interface principles requirements that come into play when we design to include push notifications, badges, iCloud, location services, or iAds into our app. These are all common app features, and our app will be more successful if we use each correctly in our interface.
We'll discuss app configurations, copy and paste, and accessibility in Chapter 8, Accessibility, Options, and Limited Opportunity to Help our User. While often overlooked, the features discussed in these recipes are often responsible for the extra polish that pushes an app into the top sales charts.
Finally, for Chapter 9, Migrating to the iPad, we'll grow up a bit and talk about the iPad. Interface design for the larger screen and wider aspect ratio can be a bit different than the work we produce for the iPhone, and we'll discuss those differences here.
Looking for a bit more help? We'll tackle the problem of direct manipulation and the importance of application responsiveness in Appendix A,
As a final encore, we'll discuss the interface challenges that arise when designing a touch based operating system in Appendix B, If you need a stylus, you blew it. Software designed around use with a finger instead of a mouse can be a bit tricky, but we'll help you master the subject.
The iPhone Interface Cookbook is written from the ground up for people who are new to iOS or application interface design in general. Each chapter discusses the reasoning and design strategy behind critical interface components, as well as how to best integrate each into any iPhone or iPad application. Detailed and straight-forward recipes help give guidance and build understanding far beyond what is offered through Apple's Human Interface Guidelines.
If we want to develop an attractive yet functional user interface, we need to start by taking the time to fully understand the uniqueness of the iOS operating system and how it is designed to provide an exceptional touch-centric experience. Let's take a look at the key hardware features that the user will use to interact with and experience our application.
Take note of the hardware features present on the iPhone or iPad. All iOS devices have a circle home button located below the touch-sensitive screen, volume controls found on the side of the device, a headphone jack, and a sleep button on the top of the device. On the iPhone and iPad, a switch can be found that toggles silent mode on and off.
Several other features can be found on each device, depending on the model. A rear-facing camera has been prevalent on the iPhone since the first model in 2007. A front-facing camera has become a common addition since the introduction of the iPhone 4 and Facetime in 2010. Recent iPod touch and iPad devices have also received front and rear cameras. All devices besides the first generation iPod touch contain a microphone for recording audio. With the addition of the iPhone 4S, Apple included its system-wide Siri voice dictation software, which is available to all applications through inclusion of the standard keyboard.
An ambient light sensor and accelerometer can be found on every iOS device. Bluetooth has been a staple of every iPhone and iPad, with iPod touches receiving the feature in 2008 models and beyond. A gyroscope is a new addition to iOS devices, being introduced with the iPhone 4 in the summer of 2010.
Music, photos, and applications are all held on the device in flash ROM storage. The amount of storage on each device can fluctuate anywhere between 8 GB to 64 GB and is not expandable after a user has purchased the device.
Unlike other touch capable phones or tablets, iOS devices contain no programmable hardware buttons for developers or designers to work into an application. Instead, every interaction between the user and the application must be implemented through either a software interaction with the touch screen or by utilizing the accelerometer or gyroscope for user interaction.
We've just begun to scratch the surface on the functionality available to iOS designers. Here are a few more tips that we can use to best understand the basic principles of iOS user interface development.
Fully understanding the hardware specifications and limitations for the device we're looking to target is absolutely essential. The more we know about who will be using our application and what device features they have, the better we can fine tune our user interface in order to provide a great experience for the end user.
Before we ever begin to map out any interface design, we should take the time to sit and consider where and when people will be using our application.
Imagine we are looking to build an application to help bus riders in Chicago keep track of stop locations. In this app, it wouldn't make sense to use the accelerometer and have the app update the user's location when the device is shaken, because the constant stop and go nature of a bus ride could accidentally trigger an update and frustrate the user.
Even though Apple's cap of a 2 GB file size per application is usually more than enough space for any app, it's also important to remember that many wireless carriers across the world place a limit on the size of applications that can be downloaded over the wireless data network.
When determining a target audience and use case for an application, it's important to see what app size limitations are in place for the target market.
Using our example of an application to help bus riders find detailed stop information, it would be detrimental to have our app size be above the wireless download cap placed by the carrier, because users would be unable to download the application while walking around the city looking for a bus stop.
In designing the user interface for an iOS application, we're lucky that very few tools are required during the production process. That being said, this does mean that the tools we do need are that much more important when it comes to producing a quality application.
Let's look at what hardware and software we're going to need in order to develop the best interface possible for our application.
The first thing we need to do is pick up a capable computer for design work. Since we're developing for iOS, a Macintosh is definitely preferable if not required. If we're not going to be doing any programming, it could be possible to get away with a PC that runs Adobe Photoshop, but this is not recommended. Without a Macintosh, we will not have access to the iOS Simulator and other tools that Apple provides for design.
All other things being equal, a quality monitor of significant size may be the most important attribute when picking up a computer for design work. The iMac or a Mac Pro with Cinema Display may be the best option, but a Macbook or Macbook Pro is certainly sufficient. Given the Retina display of the iPhone or large display of the iPad, we'll want to have as much room for high-resolution art on our monitor as possible.
Currently, the Mac Pro is the only Apple computer that is easily upgradable after initial purchase. With a slight bit of tinkering, it's easy to add more RAM or install a new hard drive on the professional grade machine, so it should be our first choice if we're looking for a device to build upon in the future.
In comparison, it is relatively difficult to upgrade an iMac, Mac Mini, Macbook Pro, Macbook, or Macbook Air. Any Apple computer should be more than capable of producing exceptional UI design, but this lack of expandability should be something to keep in mind in case we plan on upgrading our machine down the road.
Pick up a copy of Adobe Photoshop and if possible, Adobe Illustrator. Adobe offers a variety of packages on software, which can all vary greatly in price depending on our needs and circumstances. When it comes to design and graphic production, Adobe is the gold standard and we can never go wrong by having their design suite on hand. Ultimately, Photoshop is really the only application we will need, but it never hurts to have Adobe's entire design suite just in case.
Many designers like working in Illustrator because it makes it easy to do vector drawings, which are resolution independent and work well if we ever need art for a magazine ad or promotional banner. We also never know when Apple will increase the resolution on iOS devices, as they did in 2010 with the Retina Display, and it is much easier to upscale artwork for higher resolution screens when resource files are easily available in vector format.
If Photoshop is out of our price range, fear not, as there are several other raster graphic programs that can help in the design process. Acorn by Flying Meat Software, found online at http://flyingmeat.com/acorn/, is an extremely capable image editor that can be purchased for only $50. Acorn is fundamentally similar to Photoshop, so moving between the two is quite easy.
 |
We'll also want to make sure that we've downloaded the latest version of Apple's iOS SDK tools as well. The iOS SDK can be downloaded for free from Apple's Developer Center, regardless of whether we are registered in the iOS developer program or not. When we're ready to download the SDK, we can visit http://developer.apple.com/devcenter/ios/index.action.
If we're not performing any of the programming for our application, we could get away without using or learning how to use the iOS SDK, but this is not preferable. The iOS SDK, along with XCode, allows us to change art resource files quickly and then launch the iOS Simulator to see how resources look when running in our application.
While this seems like a fairly limited tool set, we should be able to compete with nearly any user interface in the App Store once we have these items. Anything we can't build in code can be produced in Photoshop, which gives us the flexibility of only needing one application for the majority of our work. The negative side to this is that we're going to be spending a lot of time in one application, so we need to be comfortable in the image manipulation program.
We won't dive too deep into Photoshop in this book, so you may find yourself struggling a bit at first if you've never used the application. Luckily, there are many resources available to help teach Photoshop, written by individuals who are extremely talented with the application. A simple web search of the Photoshop technique you're looking to learn or a stop by a bookstore should provide more than enough information on improving our Photoshop skills.
Many websites and blogs focus primarily on the design of iOS applications. Here are a few handy resources that can help inspire and educate.
iDev101 offers a great breakdown of the exact sizing requirements of different iOS UI elements, which can be found at http://www.idev101.com/code/User_Interface/sizes.html.
The iPhone GUI PSD http://www.teehanlax.com/blog/2010/08/12/iphone-4-gui-psd-retina-display/ is an extremely handy Photoshop file compiled by Teehan+Lax. The file typically sees an update whenever Apple makes changes to UI elements, making this an extremely valuable resource for any designer.
365PSD is an extremely useful site by Dutch designer Jonno Riekwel, which releases a new Photoshop file per day as a free resource. A good deal of the posts focus on iOS and the files can be a great way to learn first hand how a specific UI effect was performed in Photoshop. To download files from 365PSD, we should visit http://365psd.com/.
In developing an operating system without a keyboard or physical buttons, Apple had to decide on whether or not to facilitate interaction with a stylus. Ultimately, it was decided that a stylus would create an unsatisfactory experience and the device was built from the ground up to only support human finger interaction.
There are many benefits in developing a touch only operating system. Users have no stylus to lose, the barrier between person and device is essentially torn down through direct interaction, and the device can easily be managed with only a thumb when held in the palm of a hand.
While often considered to be an afterthought, it's important to understand how our users will hold the device with using our application. Difference in aspect ratio, hand placement, and grip are rather serious attributes that can greatly change the development of our interface.
Let's take a look at how hands are both a blessing and a curse.
While nearly everyone who first uses an iOS device has had an experience with a traditional button based cell phone, the large screen touch based devices offer a significant difference by allowing a truly orientation independent device.
In many respects, the decision to create a device which functions as properly right side up as it does upside down was intentional on Apple's part. All iOS devices contain a single, circular, and orientation neutral button that sends the user back to the home screen upon impression. All other menus and buttons to control an application are produced on screen and as such, defined by the developer.
This establishes an incredible sense of free reign for creative design in application perspective. Games such as Doodle Jump by Lima Sky can offer entertaining and fast paced play mechanics while various Twitter applications can offer landscape views for reading or typing away at tweets. Applications such as Ocarina by Smule can flip an iPhone or iPod touch completely on its head and require a user to rotate the device completely around so that the microphone can be used to mimic an actual ocarina.
In deciding which orientation best fits our iPhone or iPod touch application, the general purpose of our app will help guide our way. In nearly every situation, the user expects the application to function properly within the portrait orientation. Unless our app is a game that requires a simulated control pad and buttons or landscape orientation, we should always assume that users will expect portrait orientation in some respect or another. Landscape can offer an intriguing and greatly appreciated bonus for many users, especially in applications that depend heavily on typing or data entry, as many users prefer typing on the larger landscape keyboard.
 |
While the above flexibility applies to smaller iOS devices, Apple demands orientation independence when working with the iPad. Unless there is a specific reason as to why an iPad app could not support both landscape and portrait view, we're expected to design our application to fit both perspectives.
Designing visually appealing work for both portrait and landscape perspectives on the iPad can be a challenging experience. The device features a 4:3 aspect ratio which creates a screen size that's not quite a square, but not wide enough to be a true widescreen perspective either. This provides an interesting problem where it is difficult to create two unique orientation interfaces that work well in their own way.
To help account for both orientations, Apple has developed a fair amount of new interface elements for our use in an application. Popovers and Dual pane views are just two new tools that are at our disposal to help produce quality interfaces. Tab Bar and Navigation Bar views have also been redeveloped to help better fit the larger screen as well. In designing our application, we should provide some sort of dual interface perspective that best works to provide clear navigation regardless of orientation.
 |
Instapaper - © 2008-2011 Marco Arment
Instapaper by Marco Arment implements a prime example of an iPad application that provides a dual pane interface when in landscape view and a single pane presentation aided by a Popover sheet when in portrait view.
When holding an iPhone in portrait view, the thumb of the hand holding device is easily available for use on screen. This portrait view also allows for the opposite hand to also be used as a way to interact with the device with ease. When holding an iPhone in landscape view, the device is typically held in a fashion that allows for only the thumb of each hand to be used to interact with the screen. As such, the landscape perspective is best used for typing or game applications.
Due to the large size of the iPad, the device offers a different experience with regards to holding and interacting with the screen. Typically, the iPad is held with two hands much like a book, with one hand lifting up to touch on screen with the pointer finger when input is needed. A large bezel surrounding the device prevents a finger from accidentally coming in contact with screen and makes it difficult for a thumb to move from a relaxed position to the screen. This distance makes applications or games with persistent interaction, such as a game with a software simulated control stick, difficult to play for extended periods of time because the hand will naturally fatigue while being held up to touch the screen.
With this information in mind, we should be able to develop applications that behave predictably for the user. When the user knows what to expect with our app, time spent learning the application will diminish and users will have more time to enjoy our work.
Screen sizes and the touch surface can vary based on the device, which means we shouldn't assume a great iPhone app will automatically make a successful iPad app.
While the iPad and iPhone both run iOS, the size difference between the two devices can cause us to hold each considerably different. The iPhone and iPod touch are primarily one-hand devices while the iPad is more commonly held with two hands like a book.
Just because an interface works well on an iPhone doesn't mean it will necessarily translate to the bigger device and vice versa. Likewise, actions that work well with in one way on iPhone may need a different gesture or a button on iPad.
These size differences help demonstrate why we should have multiple test devices on hand during development. Just because one mechanic works well on a specific device doesn't mean we should assume that it would work well on another.
Being devoid of physical buttons, there are a few assumptions that we can make about our user base and how they'll interact with our app. Because nearly any interface imaginable is possible on the touch screen, it's important that we abide by documents like Apple's Human Interface Guidelines, which are written with perspective from designers who had a hand in the creation of the platform's interface elements.
Note
Apple's Human Interface Guidelines are exhaustive documents published on the iOS and Mac Dev Centers, located at http://developer.apple.com, for developers to learn how Apple intends interface items to be used inside applications.
In designing placement of components of our app interface, we should first understand what is required of us and should be placed in a specific location without compromise in all situations. Apple has established their Human Interface Guidelines, which detail procedures and specifications that must be followed by all applications and our work could get rejected by their review team if we decide to disobey these recommendations.
The most important thing to keep in mind with touch is that we should follow Apple's recommendations on placement of common UI elements. Essential elements such as the Navigation Bar and Tab Bar are placed on the top and bottom of the screen respectively for a reason. The high placement of the Navigation Bar serves the purpose of giving title and context to the information that is directly below, allowing us to move throughout an expansive table of information easily, much like thumbing through a stack of papers on a desk would be much simpler if the top of each page had an accurate title.
The Navigation Bar's placement anchored to the bottom of the screen allows for easy movement throughout multiple modal views without ever obstructing important information on screen with our finger. With just a quick touch, we can quickly swap between two or three important pages of data.
Not to be confused with a misplacement of the Navigation Bar in the Tab Bar location, many apps such as Maps or Calendar place a Toolbar anchored to the bottom of the screen that looks nearly identical to the Navigation Bar. As shown in the next screenshot, the two look similar but serve different purposes:
 |
Calendar - © 2007-2011 Apple Inc.
The Navigation Bar allows the user to navigate through vast tables of information either forward or backwards quickly. Anchoring a similar Toolbar to the bottom of the screen for various settings, as we find in Safari, allows for users to quickly manipulate data on screen with clear buttons. We should be sure to follow these established conventions with regards to navigation.
Action sheets can often be implemented in an app upon pressing an item in the Toolbar. Action sheets offer quick and temporary choice between several different options. For an example of an action sheet, open Safari and tap the plus icon located in the center of the bottom Toolbar. As shown in the next screenshot, this option brings up three temporary choices that can be quickly chosen by the user:
 |
Keyboard placement anchored to the bottom of the screen is also a necessity for interface development. Whereas the software keys are not physically responsive to the press like the keyboard on our Mac or PC, the placement of each button becomes a trained response much like a tactile device. Custom keyboards in general can be a detrimental decision for our application in nearly every situation. Their sizing will confuse our users and be unnatural in comparison to every other keyboard on the device, leading to an unnecessary learning curve that causes frustration.
Picker views for date or different selection options are sized to fit into the same size of the Keyboard and should mimic placement conventions of the Keyboard as well. Whenever we implement this option, it should be anchored to the bottom of the screen and only be displayed when necessary.
 |
Clock - © 2007-2011 Apple Inc.
As demonstrated about with the Clock application's alarm feature, Picker Views are expected to be anchored to the bottom of the screen and we should follow this guideline when implementing the control in our applications.
With regards to placing significant text and data on screen for our user, we should create conventional typography that preferably aligns flush left, at a size that is easily legible to the user. In creating labels or bodies of text, we'll often be using code similar to this:
cell.textLabel.font = [UIFontfontWithName:@"HelveticaNeue-Bold" size:17];
Correct text size is a subjective metric depending upon our audience and typeface, so it may often be helpful to provide multiple sizing options to our users when possible. If using a common font like Helvetica, we should try to make our text size 16 or larger if we want our work to be easily legible.
Note
For an example of well-placed text, we should follow the example of Notes and Mail with placement of either user entered or pre-defined text.
If we feel unsure about proper placement of a specific user interface element on screen, it is best to follow Apple's lead on whatever we're doing. Using Apple developed applications that come pre-installed on our iOS device is the best way to experience quality examples of how interface elements should be properly placed.
If we're looking to create a mobile webpage for our business or personal website, there are several basic web principles that we should be cautious of during our development. Here are a few tips for producing exceptional mobile HTML.
Multicolumn blocks of text are a web staple, with significant prevalence on many blogs and news sites. However, columns work poorly on the iPhone or iPod touch, as constant scrolling both vertically and horizontally can become confusing. We should refrain from using such a scheme and instead create a single column, even if it must be rather lengthy.
When designing for a desktop computer application or website, it's natural to place important navigation or action items near the top, bottom, or corners of the screen.
Placement of interface elements near sides of the screen is an extremely effective design principle on the desktop because of an interaction model called Fitts's Law.
In the simplest explanation, we place interface elements near the corner of the screen when working with a mouse because when the user moves the cursor from the center of the screen to a button near an edge, it's more difficult to miss the target because the cursor stops when it hits the screen boundary and as such, buttons placed there effectively have infinite widths.
While Fitts's Law works wonderfully with a mouse, it's less important and can create cramped interfaces when practiced on iOS. Since our user will be using their fingers, which are typically slower pointing devices which give the brain more time to adjust for distance in movement and in turn provides for greater accuracy, it's alright to utilize space in the center of the screen and space buttons further apart.
To tackle the recipes inside of this book, you'll be best served to have the following equipment on hand: a Macintosh computer running Snow Leopard or Lion operating systems, an iPhone, iPod touch, or iPad device, a copy of Adobe's Photoshop software, and sketching tools such as a notepad and pencil. Throughout the book, we will refer to additional software and tools that can help make interface creation easier; however these side notes will never be required during the design process.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "We can include other contexts through the use of the include directive."
A block of code is set as follows:
<rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:format>application/vnd.adobe.photoshop</dc:format> </rdf:Description>
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
<rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:format>application/vnd.adobe.photoshop</dc:format> </rdf:Description>
Any command-line input or output is written as follows:
# cp /usr/src/asterisk-addons/configs/cdr_mysql.conf.sample
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "clicking the Next button moves you to the next screen".
Feedback from our readers is always welcome. Let us know what you think about this book what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to< [email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail< [email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books maybe a mistake in the text or the code we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at< [email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at< [email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.