Chapter 4. Design Tools: Building a Better Flashlight
Now that you’re up to speed with the language and frameworks used to create applications on the iPhone, you’re ready to start coding, right? Wrong!
You may have years of experience developing applications for the desktop or Web, but the iPhone is a radical new platform running on a mobile device. Understanding how one or more fingers work with your user interface takes time. Assumptions based on how applications work in a controlled work environment change when you move into a chaotic mobile environment. These big differences also mean that the tools you’ll use to design your app will change.
This chapter will introduce you to some of the unique elements of iPhone design. You’ll also learn about a decision process that helps you come to terms with this new platform. And once you’ve gone through that process, you’ll see how to start thinking about the code that will implement your ideas.
Plan Before You Code
You’ll find a lot more to developing iPhone applications than just writing code. In this section, you’ll learn what’s different about designing iPhone software, how to create effective user experiences, how to start visualizing your ideas, and what tools will help during the design process.
Why Call in a Designer?
If you made it through the last two chapters unscathed, you’re probably not someone who does design for a living. And that’s just fine, because this section isn’t about drawing things that are pretty. It’s about making things that work pretty.
Many developers think a designer is someone who comes in at the end of a project and cleans up graphics—someone who can take all of those ugly images you created as placeholders and update them before you ship the product.
Designers can certainly do these things, but you’re selling them short if that’s all you ask them to do. Great designers will help you determine what the product should do by providing the perspective of someone who’s not intimately involved with the technology.
As a developer, you tend to look at problems from the implementation outward. A designer thinks about the final product and works inward toward how it’s constructed. When the logical left side of your brain encounters the designer’s artistic right side, great things can happen.
Designers provide a point of view that you don’t have. Don’t be afraid to get this valuable input early in your product’s lifecycle.
Focus on the user and her task. Your primary goal is to always think about use cases before forging ahead with a design solution. Some developers like to write user stories to formalize the kinds of tasks their customers will perform.
Follow established conventions. Apple has done an excellent job developing actions, behaviors, gestures, and metaphors with the built-in applications. You’d be wise to follow their lead whenever possible.
Maintain consistency. People intuitively learn the patterns in your application. Make sure that the look and feel for these patterns remains the same throughout your design. This is especially important when you need to deviate from the established conventions mentioned above.
Reduce complexity. Designing a complex interface is easy. The most difficult job of a designer is distilling the elements down to their most basic level. Always question the need to add “just another control.” Removing parts of your interface should give you more satisfaction than adding them.
Make the application’s state clear. If a background task like refresh is occurring, you need to convey that information to the user. When a user performs an action, visual feedback in the form of a highlight or an animation lets her know what’s going on internally. Assume that people will make mistakes, so provide well-written feedback, and give them a way to undo the action.
What’s Unique about iPhone Design?
Even if you’ve had years of application design experience and the list in the previous section is second nature to you, you’re still going to face many new challenges in your design. If you’re wondering what’s so different about designing for the iPhone, there’s a simple answer: lots!
Let’s get physical
Finger size and reach. A fingertip, like the one shown in Figure 4-1 is much larger than a mouse pointer. The length of the finger can also be a limiting factor when trying to reach different areas of the screen at the same time. Hands also come in a wide variety of sizes.
Motion of the device. Movement can act as an output such as vibration or as input with the accelerometer.
One or two hands in use. Interaction patterns change dramatically depending on whether the user is using your application with one hand or two.
Display rotation. The layout of your design can change when a user switches between portrait and landscape orientations.
You also need to take into account environmental factors. A low-contrast design may look great in controlled lighting conditions, but when a user takes his phone out of his pocket on a bright and sunny day, he’ll have trouble viewing the information you’re presenting. Similarly, your design may be easy to read while stationary, but many people will use your app while jostled around in a bus or train.
It’s important to take your creation outside the office and to see the effects of the real world on its usability. Do this early and often throughout the development process.
The Internet in your pants
Some people use the iPhone as a satellite device. These folks have a desktop computer in their home or office. The iPhone acts as a way for them to take their information on the go. Some aspects of app design for this group are:
The Mail application is useful for notification and triage. Composition of long messages isn’t comfortable.
Capture and display of photos is easy, but extensive processing of the image is beyond the capabilities of the CPU.
Applications that don’t sync important data back to the desktop are frustrating to use. Apple’s built-in Notes application is an example.
The other group of iPhone users is the one that doesn’t have another computer. For many people, their new smart phone is the first time they’ve had a personal computing device. These users don’t expect the kind of features available on a real computer, but they’ll still need flexibility while using your application.
There’s one other major area where the iPhone differs from the desktop: The resources available are much more limited. Table 4-1 compares the device sitting on your desk with the one in your pocket.
Several GHz with multiple cores
Several hundred MB
Wired connection with several Mbits of bandwidth
Wireless connection that can run as slow as dialup speeds
Thousands of pixels in each dimension
Hundreds of pixels in each dimension
As you can see, in most cases the resources are an order of magnitude smaller than you’re used to. Many of these limitations will come into play when you’re implementing your design; others will have an immediate impact.
For example, the small display obviously limits the amount of information you can present on a single screen. Likewise, the limited amount of memory and processing power prevents you from putting thousands of items in your app’s lists. Displaying hundreds of items is less taxing on the system and on the user who has to interpret the information. Less is more, both for the device hardware and the person using it.
Keep it simple
You have a lot of new things to come to terms with in your first iPhone application. Don’t be afraid to avoid some of them initially.
Many successful designs on the iPhone started out simple. The developers focused on solving the problem at hand and kept the implementation as basic as possible. As their knowledge and experience about the platform grew, so did their product.
Your application will certainly evolve over time. Remember that it’s much easier to add a feature in a future release than it is to remove one once it’s in a customer’s hand. Don’t try to guess what people want from your application. Let them tell you and guide your education in this new and exciting platform!
The Design Process
Whether you’re a designer or developer, you can use some simple steps and tools to get your application idea off the ground.
A paper prototype
Even if you don’t have the skills to make nice-looking icons and images, you can still draw rough prototypes of your design. Your paper drawings may not be pretty, but they’re just fine for getting the initial feel of the app.
You’ll find yourself imagining what it’s like to touch the controls drawn on the paper. It’s also easy to move pieces of paper around as you envision the transitions between one screen and another. The fact that it’s hard to write down lot of information in a constrained space naturally forces you to simplify ideas.
And unlike with code, if you find something that doesn’t make sense, it’s just a matter of pulling out the eraser and modifying the interface. Tools like Xcode and Interface Builder make your life much easier when you’re implementing designs, but they can be a huge waste of time when you’re in the discovery phase of development.
Paper also has another nice quality: It lets the designer and developer work together at the same time. It’s difficult for a group to work on a Photoshop composition or on an Interface Builder document simultaneously. With paper, everyone can have a pencil and contribute. See Figure 4-2 for an example of a paper prototype.
A pencil and paper and…
So what tools do you need to create these paper prototypes? Obviously, you need paper and a pencil, along with a couple of less obvious things. Take a look in Figure 4-3 at the tools that Cultured Code used to create the diagram in Figure 4-2.
Why the eraser? You shouldn’t be afraid to make mistakes at this point in your design. Also, if you’re working with a group, the eraser is an important tool to help refine someone else’s idea. Highlighting pens are also helpful for visually breaking up the interface’s components.
You’ll also want to have an iPhone handy, with the latest version of the iPhone OS. You’ll frequently want to refer to Apple’s apps as examples of how to do things “the iPhone way.” iPhone users are most familiar with the device’s built-in software: If you mimic those designs and interactions, you’ll be creating something that’s easy for folks to learn.
The most important thing in this photo is the screen template with the iPhone’s standard UI dimensions. You’ll be drawing a lot of these boxes as you work through your design.
Christian’s template was created by hand out of necessity. Luckily, entrepreneurs have realized that there’s a strong demand for these types of products, and now several paper prototyping solutions are on the market:
http://uistencils.com. This user interface stencil by Design Commission makes it a snap to draw the standard symbols and controls used on the iPhone. They also sell a sketchpad that works beautifully with the stencil. You spend your time thinking about the design rather than how to draw it. Both Figures Figure 4-4 and Figure 4-5 were created using this stencil and sketchpad.
http://appsketchbook.com. Stephen Martin came up with this sketchbook after being asked to design several iPhone user interfaces. The result is a high-quality spiral-bound notebook with a wireframe template printed on each page. Perfect for the designer who wants to capture an idea.
Make it pretty
Once you have a feel for the overall design of the application, you’ll want to start formalizing how it’s going to look onscreen. This is the point where you start thinking about branding and adding unique elements to your app.
For many companies, this is a really important part of the process. A firm like UPS doesn’t want their app to be the standard shades of blue with black and white text. They’re going to rely on their corporate color scheme of brown and gold. You can also bet their logo will be featured prominently.
This work is best left to a designer who’s an expert with Photoshop and other illustration tools. If you’re a developer, people will notice that you can’t draw, and that distracts them from the awesome code that’s behind the images. If you haven’t gotten a designer involved during the paper prototyping stage, you’ll need to spend time explaining your design. Which is another reason to get one involved early in the process.
Not all designs will go through this step. If you’re going to use the standard UI controls and layouts, there won’t be much for a designer to do.
As your designer is working on mockups, you’ll want to make sure that they know that the standard UI widgets are available in several document formats. If your designer is working with Illustrator, they’ll want to know about Mercury Interactive’s vector UI elements (http://www.mercuryintermedia.com/blog/index.php/2009/03/iphone-ui-vector-elements). For designers who prefer to work in Photoshop, Teehan+Lax (http://www.teehanlax.com/blog/2009/06/18/iphone-gui-psd-30/) and Smashing Magazine (http://www.smashingmagazine.com/2008/11/26/iphone-psd-vector-kit/) both provide PSD files with elements arranged in layers. Another option is to use Patrick Crowley’s stencil kit for OmniGraffle (http://graffletopia.com/stencils/413).
Working in Illustrator provides the most flexibility. Editing vector objects is generally easier than moving bitmap layers around. You’ll also future-proof your work by producing it in a format that’s readily scalable, and that’s handy when a print publication asks for some screenshots that are larger than 320 x 480 pixels!
A first impression
You’re also at a point where you can start thinking about the most important graphic in your application: the icon that appears on the home screen. This graphic is the first thing potential customers will see in iTunes, whether it’s in search results or being listed as one of the top-selling apps. Think of it like a business card: You want to make a good impression, so let a professional handle this illustration!
The human brain processes shapes and colors much more quickly than words. As you work through the design of your application icon, focus on a distinctive color palette with clearly defined shapes. Avoid complicated and cluttered designs.
How does it feel?
Remember how your first app seemed huge when you ran it in the iPhone Simulator? The same effect occurs when you’re working in Photoshop: The iPhone’s 320 x 480 display looks bigger than it really is. If you’re customizing user interface components, remember that your designer is working in an environment where the light is carefully controlled.
Both these factors tend to skew the design toward something that’s appropriate for the desktop and not for a mobile device. That’s why it’s so important to expose your design to the real world.
The easiest way to get a feel for the Photoshop mockups is to save the 320 x 480 images and sync them to the built-in Photos app. Once you have the designs on the device and are carrying them around, it’s easy to open the app and look at them in different conditions like bright sunlight and fluorescent lighting.
It’s also possible to verify control sizes and placement by placing your finger over the simulated interface elements. Watch out for content that gets obscured by your hand as you move your finger around. It’s also a good time to see how things feel for left-handed users and whether the design works well for one- or two-handed use.
Living in Harmony with Your Designer
Designers and developers have decidedly different mindsets and ways of working. The last step of the design process for you, the developer, is thinking about how you’re going to work with the designer to get the assets from their design tools into your development environment.
Finding a common ground
It’s likely that your designer lives and breathes in Photoshop. Take a look at Figure 4-4. Designers know every nook and cranny of this madly complicated program and can do amazing stuff with it. Fortunately, you don’t need to go out and buy a copy of Photoshop to use their work. All you need to do is ask the designer to supply your graphics in the PNG file format. This standard format is easy to export from a layered Photoshop document, and you can use it directly in your Xcode project.
If you need to edit the designer’s work after delivery, it’s usually just a matter of cropping or making other minor adjustments to the image. Many developers use a tool called Acorn (http://flyingmeat.com/acorn/) to do this simple cleanup.
When you’re working with a designer’s mockup, it’s often necessary to measure various parts of the image to get the specified alignment right in Interface Builder or code. Is that button spacing 10 pixels or 11 pixels? What’s the background color for this view? For these types of measurements, the Iconfactory’s xScope tool is invaluable (http://iconfactory.com/software/xscope). This application provides a loupe, rulers, guides, and other tools that let you inspect and align screen graphics.
Give the designer control
For maximum efficiency, give designers direct access to your version control repository. A lot of tweaking tends to be involved with graphics built into a typical iPhone app. These constant changes can result in a lot of file transfers, test builds, emails, and other communication between the developer and designer.
You can save yourself a lot of time if you teach the designer how to build your app and how to replace images using the version control system. As you both feel more comfortable with the arrangement, you might find the designer making changes to your NIBs. And after you’ve adjusted a UIColor definition for the hundredth time, you might even suggest that the designer modify your source code!
Keep in mind that designers are typically visual thinkers. Their talents usually don’t include working directly at the command line for extended periods. If you’re going to provide the designer with access to your repository, you’ll want to use a tool like Versions (http://versionsapp.com/) that provides a graphical interface.
Feedback: Don’t Take Your Own Word for It
Now that you’re done learning some of the basics of the design process, it’s time to start thinking about what drives your decisions. The answer is both simple and complex. You’re building this product for people to use. Their feedback should be the most important factor in the design.
The Providers of Feedback
You’re probably thinking: “Dude, it’s simple. Feedback comes from customers!” Which is absolutely true. But customers come in many different forms.
You’re the most important customer. If you don’t use and love your own product, how will your customers? The product came about because you had an itch that needed scratching: You tripped in the dark one time too many. So now you have a flashlight on the phone in your pocket.
At the same time, you’re the worst customer. You’re atypical because you know every single nuance of the product. People who are downloading your app from iTunes are not in that enviable position. But they’ll be quick to notice things that you’ve overlooked!
Your marketing department
Developers tend to look at marketing people with an evil eye. They get a bad rap for asking for things that are hard to implement or that don’t seem logical. They’re looking at your product like a normal person would. Their motivation is to position, promote, and sell that product to other normal people.
The best marketing people are the ones who act as a conduit of information and ideas between you and the person who buys your creation. If you’ve done any marketing, you know that developers are more receptive to ideas if they’re descriptive rather than prescriptive: Explain your problem, not your perceived solution. If you’re a small developer, you won’t have a marketing department. That’s fine because you can easily find a surrogate.
Find someone you can bounce ideas off of. It should be someone who understands what the product does but not how it’s implemented. This person can be your spouse, or best friend, or even the barista at your favorite coffee shop. All that matters is that this person is willing to have a long-term discussion about what you’re doing and to provide unbiased feedback.
Be careful about using your designer for this task. Like you, they’ll have an intimate knowledge of the product and may not be able to look at things with an untainted eye.
The people who plunked down their credit cards
Simply put, users are what make your product great. Whether they love your work, hate it, or are completely ambivalent about it, their feedback can help you improve your product.
User feedback comes in many forms:
Support email. Users will contact you by email when they encounter a bug, don’t understand how something works, or have a great feature idea. Trends in these communications are excellent indicators for how your product needs to evolve.
Beta testers. These folks are the first ones to be exposed to new features and other changes in an application. If they complain about something not being right, chances are good that thousands of others will join them when the product goes into wide distribution.
If you still need testers, try a site like iBetaTest (http://ibetatest.com/) that connects developers with enthusiastic users.
Notice that all of these things should be taken in aggregate. Resist the urge to change your product direction on the basis of one email. It’s an admirable desire to make every customer happy, but the reality is that you can’t. Find the things that will please the most people.
Imagine that you released the Flashlight application you developed in the first chapter. You’ve been getting great feedback about the product. It’s now time to develop version 2.0. What are you going to implement?
You’ve been getting a lot of support email about the need to control brightness. Many users have been complaining that the light is just too bright while they’re navigating a dark bedroom: Spouses are being woken! It’s clear from these reports that you need a quick way to lower the light level.
As you read your reviews in iTunes, you see a lot of people complaining about that wonderful shade of yellow you chose. Not everyone has the same great sense of color you do. Adding a color selector will make many customers happy.
Your marketing department (also called your spouse) spent some time evaluating the competition for your app: Many of those apps include a flasher. You think that’s a great feature because you often exercise at night with your iPhone in an armband.
While at lunch with marketing, you start talking about the new flasher feature. You’re merely matching the competition with the new flasher feature. Is there a way that you can give it a unique touch, maybe make it even more useful? It would be cool to have a "disco light” that randomly changes color while flashing. That’s something that none of your competitors have, so marketing agrees that this feature should be investigated. But apart from making you a hit at parties, the feature isn’t very useful.
And then it hits you both: What if the flasher could send an SOS signal? This international sign of distress would let rescue workers spot your customer’s phone. Besides it being a great marketing angle, you’re providing a feature that could potentially save someone’s life.
So now you have your feature list for the new version:
Bigger, Stronger, Faster
You’ve collected all the feedback, and feel good about the list of features that you want for version 2. Time to whip out the pencils and start designing the user interface!
The Light Side
The main view for the app is straightforward. The light source is predominant, and you’ll need control mechanisms at the bottom of the screen for the various modes and settings access, as shown in Figure 4-5.
You’re leaning toward using a toolbar to hold these controls at the bottom of the screen. A tab bar control is better suited to switching between views in an application—the app has only one view. The toolbar also has the advantage in that you can make it translucent, letting part of the underlying light source shine through.
UITabBar is best used in applications that need to switch between views with different operational modes. Apple’s use of the tab bar in the iPod and YouTube apps lets users pick different views of music and video collections. Users can also reconfigure tab bars to display preferred sets of information.
On the other hand, UIToolbar is appropriate for actions that work within a single context. A toolbar button lets the user act on the information in the view.
When designing your UI, think carefully about which of these control mechanisms is right for your application.
When switching modes, it’s a good idea to give the user some feedback, so you decide to put an information view at the top of the screen. It would be nice to hide the information when possible, since it reduces the illumination produced by the light source.
So now you’re feeling pretty good about the main view, but things are about to get more difficult with the settings interface. You have more controls to deal with, and they introduce some subtle interaction problems.
The Flip Side
Luckily, you’ve learned to use paper prototypes as a way to work through these issues. Sketching your screens, as shown in Figure 4-6 helps you identify trouble spots.
Your first decision is to include a small preview of the current settings. The reason for this preview is that without it, your users would constantly be flipping back and forth between the settings and the main view.
You’ve also decided that slider controls are necessary to control the brightness of the light and the speed for the flasher. It makes sense to put them under the preview since they’re so closely related.
The first idea you have for picking the right color is a grouped table view. This makes sense, since it’s similar to picking a ringtone in the sounds section of the Settings app. As you start drawing the interface, you quickly discover a problem: The UI gets cramped when you get more than four or five colors.
You’d like to give the user a selection of about eight colors to choose from. When you play around with the one you have on paper, it becomes obvious that the preview will scroll out of view when you move toward the bottom of the list.
So your next thought is to just have a single button that shows another list when you press it. But as you imagine the interaction on paper, this solution actually makes the problem worse; the preview gets hidden and there’s a lot of wasted space.
As you think about other possible controls for selecting the color, you remember UIPickerView. It would be perfect: It has a fixed size and can display an arbitrary number of items. The height of the picker view also gives you more room for the preview and sliders.
A few minutes with paper saved you from writing a lot of code that would have been thrown away. And you now have two documents that you can use when discussing the interface with both your designer and marketing. Well done!
The Drawing Board
This flashlight is an admittedly simple application; the interface has only two screens. In more complex projects, you’ll have many more. Go back and look at the number of screens in Christian’s drawing at the beginning of the chapter, and you’ll have a new appreciation for the complexity in an application like Things. In spite of these intricacies, a methodical approach to the problem lets you come up with a solution that fits the users’ needs with consistency and without undue complexity.
It’s important to keep in mind at this point that the design process is never complete. As you continue to talk to designers, marketing people, beta testers, and customers, the diagrams you just produced will change. Don’t be afraid to pull out the eraser and improve your design. Iteration isn’t just for coding!
Technical Design: Between Pictures and Code
The final step in the iPhone app design process is to translate the visual design into a technical design. You’re going to be creating classes with methods as you work toward what you’ve put on paper. It’s a good idea to think about how these pieces are going to fit together in the Model-View-Controller (MVC) pattern that was mentioned in the previous chapter.
If you neglect this important step, you’ll find that you end up rewriting a lot of code. You don’t need to write a 100-page specification that describes the technical needs in minute detail, but you do need to spend a little time planning where you’re headed.
A good first step in this process is to start giving things names. You’ve probably already come up with some terminology as you’ve discussed the design with the other members of your team. It’s time to start codifying the pieces of your application.
A UIViewController typically manages a screenful of data in an iPhone app. Since you’re going to have two screens in your product, that’s a natural place to start naming things. The view with the light source is the first one that you see after launch, so you decide to call it the “main screen.” It would be fun to call the other view the “dimmer switch screen,” but you think better of it and call it the “settings screen.”
Now it’s time to start thinking about the things you find on each screen and to give them names, too. This is when you start thinking of what you’re going to call your models, views, and controllers. As with your visual design, strive for simplicity and consistency.
So what kinds of classes are going to be required for the main screen? You’ll need a view controller class to manage the contents of the screen. That controller will, in turn, manage view classes for the information at the top of the window, the light source, and the toolbar. Call these views the “info view,” “light view,” and “toolbar.”
You’ll also need a couple of models. One will manage and persist the current settings for the flashlight, so it makes sense to call it the “flashlight model.” It also seems like a good idea to put the emergency signal generator into its own "SOS model.”
Overall, the classes will fit together as shown in Figure 4-7.
This is also a good time to start thinking about the kinds of instance variables that each class is going to need. The view controller will have instance variables for each of the views and models (so that it can send messages to them). You’ll also need actions to respond to the button presses on the toolbar: –toggleFlasher, –toggleDisco, –startSOS, and –showSettings.
You decide to have two types of messages in the info view: one for informational messages, the other for alerts. That type along with the message will be stored as instance data for the view.
The light view will have a state: The illumination state can be on, off, or flashing. You also want to be able to control its brightness and color, so you’ll add properties for those to the view. A delegate instance variable will also let you report touch events back to the controller via the –lightView:singleTapAtPoint: and –lightView:doubleTapAtPoint: methods.
Since you’re trying to simulate the physical behavior of a light bulb, it also makes sense to define how quickly the light reacts to changes. An envelope will let you change how quickly the light turns on (attack) and turns off (release).
The last view, the toolbar, will have items consisting of buttons that send actions and visual separators. For the flashlight model, you’ll want to store and retrieve the brightness, speed, and default color. The disco mode will need a random color, so you’ll add an attribute for that as well. The SOS model will need a method to start sending the signal and a way to get the current Morse code element (a dot, dash, or the gap between each).
The dimmer switch
The settings screen will also have a view controller that sits center stage. It’s going to use the same flashlight model used by the main screen since you want the current flashlight data to be consistent across both views.
You’ll also get to reuse the light view class from the main screen. It has properties like brightness and color that you can use for the preview. Objective-C and Cocoa Touch make it easy to write something once and use it over and over again.
The standard slider controls will be used for the light’s brightness and flasher speed. Likewise, you’ll be using the standard picker view to select the color. The sliders will invoke the –brightnessChanged and –speedChanged methods on the controller. The controller will act as a delegate for the picker view and implement the –pickerView:didSelectRow:inComponent: method to track changes in the control.
Like with the main view controller, there will be instance variables for each of the views and the model. Figure 4-8 shows the overall architecture of the screen.
Where to Go from Here
As you’re developing your first iPhone user interface, you’re sure to have additional questions about the “right way” to do things. When that happens, the best advice is to take a look at the iPhone Human Interface Guidelines. Every iPhone developer should become familiar with this document from Apple that describes fundamental interaction principles along with the views and controls that can implement them. (You can find a link to it at www.missingmanuals.com/cds.)
You’ll also find several books in this book’s appendix that can help you maximize the user experience of your iPhone application.
Ready to Code!
The main purpose of going through this lengthy design process before touching a line of code is to filter out the bad ideas and refine the good ones. Any changes that pop up during the implementation will be minor. The major functions and features won’t be affected, and you’ll avoid the costs and headaches of mid-course corrections.
Attention to the details of design will also pay off when you start selling your app on iTunes. You’ll find that it’s easier to market your product because you have a clear vision of its purpose and the types of customers who will be interested in purchasing it. Customers will also appreciate the care you’ve put into the app’s construction, and you’ll get good reviews and word-of-mouth recommendations.