Chapter 5. Getting a Working App
|Buy the Book||Contact the Author|
App Savvy focuses on the business, product, and marketing elements critical to pursuing, completing, and selling an app. Learn about every step in the process, find the right developer, and make your app unique.
Enjoying this content? Purchase the print book or the DRM-free ebook for computers, readers, and mobile devices. Buy the book now at oreilly.com >>
Ken Yarmosh is the author of App Savvy and the founder of a boutique mobile agency based in Washington, D.C. Their work has has resulted in successful apps for national brands such as PBS and Network Solutions and strong, strategic foundations for traditional businesses and serious startups.
Want more personal help with mobile? Ken and his team can help. Learn more >>
You may be frustrated that you still don't know what your app is going to look like or how it's going to function. Not to fear: with an initial validated concept defined and the right people now in place, getting a working app is going to be a smoother process. You'll work with your team to break down how you are actually going to build the app, further refine your concept, and determine what the first version of the app you submit to Apple will include.
In this chapter, you'll explore:
Understanding your app's roadmap
Breaking down the features for the first version of your app
An overview of the design and development process
Managing the progress of your app
The Development Process
My purpose for waiting to describe the development process in detail until now is that many people who build apps are extremely anxious to "get started," without really understanding what it means to get started. In particular, for those who have the design and development skills to build an app without help, instead of researching competition, understanding what's going to make their app different, or sketching the key screens of their app, they proceed straight into building it. The result is a misinformed app, which is doomed for failure before it even hits the App Store.
Here's a secret you're going to be very happy about: you've actually already begun the development process... the right way. Most people associate "development" only with design or programming. But the entire development process—at least when building apps intelligently—includes your efforts to outline your app assumptions, your initial wireframes, and the validation of those ideas and assets with your customers. Of course, there's more to your app than what you've done up to this point, and even more than the actual programming that is soon to start. While those in the software industry divide the various parts of software development differently, here's how I'll refer to them in this book (noting what's been accomplished and will be accomplished in later chapters):
- Design and Development
Design (this chapter):
Apple's Human Interface Guidelines (HIG)
App name, icon, screens (including splash screen)
Development (this chapter):
Integration with external data sources
As a reminder, from Chapter 1 and Chapter 3, you know that marketing is an ongoing process you're following in conjunction with the development of your app. I'll continue to point you to Chapter 8, Building Your Marketing Crescendo in order to help you keep building your marketing crescendo.
Your App's Roadmap
To bring the initial version of your app into the App Store, and to keep making progress on it beyond that point, you need a plan. In the technology world, this plan is often referred to as a roadmap. There are many different philosophies and approaches to creating a roadmap; I'm going to distill what I consider the core of that for you by sharing how I develop an app roadmap.
Before I do that though, I want you to understand that you should always consider your roadmap only a guide. Building an app that is driven by customer feedback means that your roadmap needs to be fluid and flexible, constantly influenced and adjusted by what you hear from customers. Readjusting your roadmap based on feedback matches the same paradigm you are using to initially build your app; you'll continue to start with your own assumptions (i.e., the features for a release from your roadmap) and then validate them against customer input and the data you have at your disposal.
Releases, Features, and Updates
The roadmap of your app consists of your app's releases. A release consists of a distinct set of features for your app, where a feature is a specific function your app performs. A release is also commonly referred to as a version of your app. Most often, the first release or version of your app that you submit to Apple will be "1.0." After the initial release of your app, Apple refers to the subsequent versions you submit as updates. Thus, in most cases, "release," "version," or "update," can be used interchangeably.
Verbiage aside, there are three key aspects of a roadmap:
Outlining the initial universe of features for your app.
Further breaking these features down into specific tasks.
Appropriately prioritizing these features and subsequently the tasks related to those features into their respective releases.
Compared to the third item, you'll find these first two are much more operational in nature.
Get Features Out of Your Head
Before you can strategically assess what features should be assigned to a specific release of your app, you need to outline all of the features that have been rolling around in your head. Some of them likely have been written somewhere yet are still not fully defined. You can likely infer features from the competing factors from your strategy canvas, assumptions you've validated with customers, and any wireframes you created. So, your first job is to use those materials and whatever else you've been thinking about but never verbalized to list out all of what you consider to be the features of your app.
At this stage, you don't need to get fancy about where you capture your features but I do recommend you use some sort of digital means instead of pen and paper. You can start listing out "features" in any tool you prefer but I recommend keeping them digital. I write "features" because it doesn't matter if it really is a feature, a task or item that is related to a feature, or just some idea you have about your app. What's most important at this point is to get these items listed quickly and without worry about how to structure or categorize them.
Below was the initial list of features I created with my team for AudioBookShelf. Note that I'm a little more experienced in this process, so I grouped these features into categories as part of this process. Once you've listed all of what you consider your features, try to do the same.
Initial Feature List for AudioBookShelf
Discovery through scrolling across bookshelf and seeing spines
Books show age (e.g., antique versus glossy) and width based on book length
Typography on books varies
Explore different styles (e.g., leather bound); color important
Cover / Title
Play / pause / stop
Rewind / fast forward (5s;15;30;1min;5min;etc)
Chapter forward / back
Another way to think about features is to consider the screens you might have in your app and develop your list based on what each of them require.
For many reasons, associating features with a release—and in particular, your first release—is not a trivial exercise. Beyond the more obvious question of how to determine which features will go in which release, it will be extremely tempting to always try to squeeze in one more feature. For now, you need some guidance on how to begin thinking about what features should be included in the first version of the app you submit to the App Store.
While there can be other factors that influence the set of features you include in the first version of your app, here are a number of common elements, starting with the most important.
- Customer Feedback
You have a great starting point for knowing what customers consider the key features of your app. From your customer interviews you discovered what problems or situations your customers are most frustrated with, as well as what they are hoping you can solve for them in your app. With your initial wireframes and feature list, you can use any of the channels you have available (e.g., e-mail) to further discuss what your customers consider to be important.
Remember that any time you discuss features with customers, don't focus on the feature itself. Instead, talk about their problems, wants, and needs and relate that back to you solutions (features) and the benefits you plan to offer them through your app.
- Why They'll Buy
One way to further distinguish the most critical features of your app is to find out which would compel your customer to purchase your app. Beyond pushing these features to the top of your list, for those who are pursuing In App Purchases, you'll begin to identify what features should be paid upgrades.
- Core Functions
There will be some number of basic features that will be required for your app to function. These are features that make your app inoperable unless present. For instance, if you are connecting to an external web service, this may include logging into it from your app with a username and password. For AudioBookShelf, at a minimum, the playback controls of play, pause, and stop were required for the audiobook to work.
Features vary in how easy or difficult they are to implement. The level of complexity of the feature will impact how long it takes you to build it. Evaluating the time required to build features will need to be determined by whoever is designing and developing your app. Don't assume that design-intensive features are necessarily development-intensive or vice versa.
At this point, you and your team may not have a sense for the exact effort required to build a particular feature and that's fine. It's more important to get a general sense by categorizing the difficulty of features relative to each other. A useful metaphor commonly used in the wider software development community is the "T-shirt sizing" method, whereby you might label a feature as S, M, L, or XL depending on how difficult it will be to build. It will be unlikely, for example, for you to deliver four "XL" features in one release unless you have a large number of development resources available.
These initial complexity estimates will be refined as your features are broken down into actual design and development tasks.
You're not building your app independent of costs. You can have a monetary cost of a budget you or your company has specified for your app, a scheduling cost of needing to get your app into the App Store by a certain date, or some combination of both. Obviously, the complexity of features will have a direct impact on cost; pursue the most customer-important, simplest and least costly features first.
Design and Development Tasks
Based on the factors above, the feature list for the first version of your app should be taking shape. To further understand what features will actually make it into the 1.0 release of your app, you need to get a better handle on the level of effort required to build each of the ones you've identified. That will occur by you and your team breaking down these features into tasks.
By taking a feature and breaking it down into a short, descriptive task, you'll have a more comprehensive understanding of if it's something that can be built in a couple of hours or couple of days. The T-shirt sizing you did in Complexity will help you get started. A "S" feature, for example, may only have one task where a "L" feature could have five or more. Defining these tasks and subsequently understanding how long a particular feature might take to build will require close collaboration with your team members.
The motivation for the more detailed level of effort estimates you'll receive from defining these tasks is that time will be an overarching factor for every release you submit. As described above, time itself is a constraint but it also will equate to dollars spent and dollars lost. The longer you don't submit the first version of your app to Apple, the more time competitors have to launch a similar app or improve an existing one. You'll risk losing downloads or sales and potentially compromise the purpose of why you first started building this app. That doesn't mean you should rush your app to Apple but if your estimates are showing your first app will take three months to build, then it's time to remove some features from the first version.
It's not uncommon for proven, experienced developers, especially of games or larger apps, to take three months to build and launch an app. Even in their case, it's a risky proposition to take that long to get an app to the App Store.
Be aggressive with pushing features out of your initial release during your roadmap planning. It's better to cut them now then to start building them only to realize that they will prevent you from getting into the App Store in a timely manner.
Creating Your Initial Roadmap
While it's a broad sweeping recommendation, I'm going to urge you to to keep your initial release to require no more than eight weeks of design and development time. The reason is that you'll minimize the risk of your app sinking into an abyss of never launching if you can reduce the amount of time you spend on the first version. So, consider that eight weeks not a goal but rather the absolute maximum amount of time you should allocate for that first release. That should hold true even if you are submitting your first app to the App Store. In fact, I'd argue that it's only okay to spend up to eight weeks on an initial release if it's your first app. More experienced developers should strive for two to four weeks.
With the features you've identified for your first release, the remaining unassigned features for your app, and the time you've allocated to build the first version of your app, you will begin to construct your roadmap. My personal preference for maintaining an app's roadmap is to use a table format in a spreadsheet or wiki. Wherever you maintain your roadmap, realize that it is distinct from the tools you will use to mange the actual progress of the app and is focused on vision and not execution.
Typically, the columns of the spreadsheet are dedicated to the versions of the app planned, with the first row being the version number, the second being the Apple submission date, and the third being the tentative release date (see Chapter 7 for details about what Apple calls the "Release Date"). At this point, you only need two columns. The first column will be "1.0" (or whatever you choose as the initial version number for your app), consisting of all the features you've identified for this release, and the second will be labeled "backlog," which will include all the prioritized list of the remaining features you've outlined for your app (see Roadmap Example).
Figure 5.1. This example shows an early Tweeb roadmap. It was maintained in a wiki powered by the online collaboration tool PBworks (http://pbworks.com/).
Going forward, your spreadsheet will allow you to easily add new columns for new releases (updates), transferring backlog features into them or creating new ones based on customer feedback and other factors ("scoping" updates is covered in Chapter 09). You can visit http://kenyarmosh.com/appsavvy to get a sample roadmap spreadsheet.
Your App's Description
Having outlined the features of your app, you should take this opportunity to create a better description of your app. The most immediate use of doing so is that you will have a clearer way to talk about your app to customers, contacts, friends, and family. More importantly, however, is that this description will become part of your marketing assets and will be used on places like your website and the App Store.
The first part of your description should be a short, one-sentence tag line that quickly communicates the essence of your app. It's not even necessarily a sentence but more of a blurb. Here are a handful of examples for you:
"Tweeb - Twitter stats in the palm of your hand"
"AudioBookShelf – Listen to History’s Treasured Masterpieces on your iPhone"
"Outside - Reinventing the Weather Forecast"
"Digital Post ~ Newspaper for iPad"
"Grades ~ roadmap to an A"
As part of this step, you may want to also begin exploring some app names. As you can see from the small sampling of these apps, as well as other top apps in the store, simple and straightforward names are better. Even Robocat's creatively-named weather app "Outside" still communicates what it is really about. The other benefit for simpler names is that they will be more memorable as well as searchable—through search engines, beyond the App Store.
Additional factors to consider when thinking about your app's name, include checking the availability of website domains (use http://instantdomainsearch.com/ and http://www.bustaname.com/ to speed that process) and Twitter handles. A popular way to overcome these limitations is to append "app" to the end of the desired name. For example, here are the domains and Twitter handles for the apps mentioned above: http://www.tweebapp.com and @tweebapp, http://outsideapp.com/ and @outsideapp, and http://gradesapp.com/ and @gradesapp. You don't necessarily need an app-specific Twitter handle if you've decided to use your personal Twitter account to engage customers.
After you have this tag line, you'll want to expand it to a three to four sentence description. Prospective customers will read this information immediately after looking at your app's name and tag line. This description should capture the key differentiators for your app.
"Tweeb is a Twitter analytics and Twitter follower management app for the iPhone and iPod touch. It's the only app that provides a simple, digestible, and comprehensive view of how you're doing on Twitter."
"A variety of top news sources have been pre-selected & filtered including AP, Reuters, AFP, Christian Science Monitor, McClatchy, Politico and more. No need to add or manage RSS feeds, Digital Post always stays up-to-date with the top news stories!"
The final part of your description should detail five to seven specific features about your app. You don't need to list every feature. Just highlight the ones your customers have told you are the most significant and compelling:
On-demand stats that always includes fresh, up-to-date data.
Clean, crisp, and intuitive "Summary" dashboard with trends for tweets, followers, buzz, and clicks.
Quickly view your recent tweets, manage those you follow (“friends”), and post from your favorite Twitter client in the “Me” tab.
See if what you are tweeting is creating any "Buzz" by checking out those who are mentioning or retweeting you. Tweeb supports Twitter retweets and will also show you who is retweeting you.
Better understand follower engagement by viewing click data for tweets that include bit.ly or j.mp links in the “Clicks” tab.
Since your app still doesn't exist, make your tag line, description, and features aspirational. By spending a small amount of time detailing these items now, they will help you to focus on what you want the core of your app to be as you move forward through the rest of the design and development process.
Design and Development
Although detailed discussions of an app's design and development are beyond the scope of this book, I want to outline some of the primary elements of each. What I cover below will be a good starting point for you but you should strive to deeply understand all aspects of bringing an app to the App Store. So, while you will possibly be relying on others to do the actual design and development of your app, knowing what is being worked on and having the ability to provide intelligent feedback on it will make you a more useful member of your team. Ultimately, that will help deliver a better app to the App Store.
As alluded to previously, the more detailed the product assets you create—research, wireframes, feature and task list, and roadmap—the fewer questions and consequently, less upfront work there will be for your designer and developer. That not only speeds the progress of your app but reduces your bottom line costs.
You'll work closely with your designer to expand your concept app. Through that collaboration, you'll create your app's color scheme, font selections, logo, app icon, and of course, the screens themselves. Be inspired as you undertake your app's design. Reviewing apps with your team that reflect what you consider great design; it's a major distinction for Apple and for customers. Through these sessions, take time to not only study the actual designs but how you interacted with the app. Below, Josh Clark, the author of Tapworthy: Designing Great iPhone Apps (O'Reilly) provides some key points about the importance of visual design. Note that Josh's tips for iPhone apps are equally as applicable to the iPad:
"As an app designer, your interface choices affect not only what your customers can do with their devices but how they feel about them, too. A well-designed interface has the power to charm and beguile. Don't dismiss this as touchy-feely hokum: an emotional connection is the basis for all marketing and storytelling, and make no mistake, your app is in fact a story. In this very personal context, people think about an app as content more than “software,” an experience more than a tool, and entertainment more than a task. Here are some pointers for balancing style, efficiency, and usability in an iPhone interface—the ingredients of personal connection.
Choose a personality. Just like people, apps are irresistible when their personalities are in tune with both audience and context (Figure 5.2, “Voices has a Vaudeville personality appropriate to a funny-voices novelty app.”). An efficient, just-the-facts design lends an air of confidence to a productivity app. Warm wood textures, meanwhile, give other apps an organic feeling that is both homey and luxurious. Don't let your app's personality emerge by accident. Before you start tinkering with color schemes, graphics, and navigation models, consider how you'd like people to perceive your app. Businesslike and authoritative? Comforting and familiar? Sleek and poised? Homespun and crafty? Fun and toylike? Opulent and plush? By choosing a personality for your app before you start crafting its visual identity, you give yourself a framework for making consistent decisions based on the emotional vibe you're after.
Favor standard controls. Because they're commonplace, the iOS' standard controls are sometimes dismissed as visually dull. Not so fast: commonplace means familiarity and ease for your audience. Conventions are critical to instant and effortless communication. That's why road signs around the world are standardized. Drivers hurtling down the freeway shouldn't have to do double takes to figure out what a sign means. When instant and effortless communication is critical, conventions are a designer's best friend. Buttons, icons, and toolbars are the road signs for your app, and iPhone screens that use standard controls have a no-nonsense seriousness that lends them a similar authority and don't-make-me-think understanding. Before creating a brand new interface metaphor or inventing your own custom controls, ask whether it might be done better with the built-in gadgetry.
Add a fresh coat of paint. Standard controls don't have to be dreary. Use custom colors and graphics to give them a fresh identity (Figure 5.3, “Wine Steward adds a parchment graphic to the background of each table cell, making the entries appear to be written on an aged wine label”). This technique requires a light touch, however; don't distract from the content itself or drain the meaning from otherwise familiar controls.
Figure 5.3. Wine Steward adds a parchment graphic to the background of each table cell, making the entries appear to be written on an aged wine label
You stay classy. Luxurious textures applied with taste (Figure 5.4, “Organic textures add a sense of luxury to the of Cross Fingers.”) increase your app's perceived value. The same sumptuous materials of beloved personal totems—a leather-bound notebook, a glossy gadget, a retro timepiece—can likewise be put to good use in your interface to conjure the same attachment.
Borrow interface metaphors from the physical world. Lean on users' real-world experience to create intuitive experiences. People will try anything on a touchscreen, for example, that they'd logically try on a physical object or with a mouse-driven cursor. The card decks, spinning dials, push buttons, sliders, and light switches of the iPhone's standard toolkit require no learning; we already know how to use them thanks to our experience with their real-world counterparts. These physical look-alikes are most effortless when the interface is the same size as the gadget that inspired it. When iPhone apps mimic a real-world handheld device (Figure 5.5, “Guitar Toolkit creates an intuitive interface by mimicking a guitar tuner.”), for example, the iPhone actually seems to become that device, and you inherit the time-tested ergonomics of the original, too.
Don't be afraid to take risks. Make sure your interfaces are intuitive, sure, but don't be afraid to try something completely new and different. Designers and developers are hatching fresh iPhone magic every day, and there's still much to explore and invent. While you should look hard at whether you might accomplish what you need to do with standard controls, it's also worth asking, Am I going far enough? Allow yourself to explore the possibilities, and don't be afraid to experiment with offbeat concepts.
The app icon is your business card. The icon carries disproportionate weight in the marketing of your app, and it's important to give it disproportionate design attention, too. Think of the icon as a packaging label (Figure 5.6, “App icons for Canabalt borrow the colors, styles, and textures directly from the app interface to create recognition and fidelity.”)—it's great if it's pretty, but it's even more important that it be descriptive and identifiable at a glance, for both branding and usability. Avoid cryptic or inscrutable imagery, and don't be overly clever with the visual metaphors. More commerce, less art. Make your app icon a literal description of your app's function, interface, name, or brand."
Figure 5.6. App icons for Canabalt borrow the colors, styles, and textures directly from the app interface to create recognition and fidelity.
Two good resources on the process of designing app icon's include Michael Flarup's "iPhone App Icon Design: Best Practices" (http://pixelresort.com/blog/iphone-app-icon-design-best-practises/) and Sebastiaan de With's "Here, Icon Icon" (http://blog.cocoia.com/2010/here-file-file/). Point your designer to these links.
User Experience Design
Of course, there's more to designing an app than aesthetics alone. Beyond colors and typography, which are extremely important, the design process for the iPhone and iPad are especially unique because the interaction with these devices are centered around touch (i.e., Apple's Multi-Touch).
To give a little more context on the importance of the touch metaphor (besides what was covered in Chapter 2), there's an entire sub-speciality of the larger design field that's dedicated to user experience and interaction design. Those involved in this arena focus on designing products to be usable and easy to understand instead of creating the visual aspects of them. Many designers take on both roles, with some doing so more successfully than others.
The importance of user experience, in particular, has grown tremendously in the digital age. And that attention increased back when the primary mode of interaction was through the mouse and keyboard on much larger screens. That should underscore how significant the user experience will be with your apps, where the screens are considerably smaller yet controlled with touch gestures.
Human Interface Guidelines
Apple heavily touts the Multi-Touch elements of their devices and the new standard they set with the iOS platform. They've worked diligently to preserve the elegant experience they've enabled on their devices, both within their own apps and with those developing for their platform. To do that, they created a set of standardized design frameworks and extensive human interface guidelines (HIG) for each of their devices.
If you've completely ignored all of Apple's documentation to this point, do yourself a favor and go read the human interface guidelines for both the iPhone and iPad (part of the iPhone OS Reference Library). By reading them, you'll learn how Apple approached porting apps like Mail and iPhoto to the iPhone and subsequently, how they did the same from the iPhone to the iPad. You'll also become familiar with all the iPhone and iPad views and controls that Apple provides in their design frameworks, and you'll learn how to properly implement each of them. In Instpaper Landscape, Macro Arment's popular Instapaper shows the split view in use for the iPad version of his app.
With the knowledge you will gain from the HIG, even if you are not a design expert, you'll help shape your app's user experience by ensuring these elements are properly implemented. This particular point is critical for two reasons:
Apple's is fairly stringent about their HIG and failing to observe them—at least in the past—was one of the most common reasons for having an app be rejected in the approval process.
Apple favors applications that embrace the same simplicity of their applications; that partially follows from adhering to the human interface guidelines.
Through the HIG, I'm hoping that you are now completely aware that your application will need great visual and user experience design to be considered a well-designed app.
iPhone versus iPad
As written before, the differences between the iPhone and the iPad start when using the devices themselves. The display of the iPad is more than 2.5 times larger than the iPhone, so unlike an iPhone, the iPad is not extremely functional with only a single hand; it either needs both hands or to rest on a surface. And where the iPhone and iPod touch have pre-existing dispositions to be portrait-oriented, the iPad appears more natural and useful when in landscape mode.
For the iPad, however, there is a much higher expectation, almost a demand, that applications will work in both modes. The change in orientation typically only alters the view and controls that are displayed. For example, when in portrait mode, the list of folders for Instapaper is moved from the master pane of the split view (see Instpaper Landscape) to a popover (see Instapaper Portrait).
Figure 5.8. Notice how in portrait mode, the list of folders for Instapaper is moved to a popover view.
The proverbial elephant in the room, however, is the size difference in the display between the two devices. While a big design challenge with the iPhone was its limited screen real estate, the iPad has the exact opposite challenge, with considerably more screen to fill. To accommodate these differences, even though the iPhone and iPad share some common views and controls, Apple did release a number of iPad-specific ones with the launch of the iOS 3.2. You probably already saw many of the iPhone or iPad views and controls in either your wireframing tool or Apple's HIG. You can also leverage Teehan+Lax's iPhone and iPad GUI Photoshop design templates:
What the views and controls for each device facilitate are the different use cases for the iPhone and iPad. As you might recall from the multitasking discussion in Chapter 2, the iPhone's focus is on discrete and short-lived, often time filling tasks, flowing from its portability. Clearly the iPad is also portable but unlike the iPhone, it is not pocket-sized. The resulting experience is that it is used more like a laptop than the iPhone is. Arguably, the iPad is a more portable laptop and that's how many treat it. The iPad's dimensions make it comfortable to use for much longer periods of time, especially for reading, web browsing, and managing e-mail. Even though the iPhone 3GS and iPhone 4 can also be paired with a Bluetooth keyboard in iOS 4, the iPad is the obvious winner for this feature, with its considerably larger display.
You can see these differences most evidently in the popular apps on each device. The killer iPhone apps included to-do managers like Things, flick games like Flight Control, or streamlined mobile views for websites like Mint.com. Comparatively, the earliest successes for the iPad included the document reader GoodReader, numerous newspaper and magazine apps, full-sized board games like SCRABBLE for iPad, and Apple's own iPad optimized iWork suite (Pages, Keynote, and Numbers).
Beyond the HIG distinctions, however, these iPad apps reveal considerably more custom visual design. With the iPhone's smaller real estate, many developers got away with using the native design elements provided by Apple for their iPhone apps. Not customizing the design becomes much more obvious on the iPad, however, and the best iPad apps take advantage of every pixel available, reinterpreting and reinvesting in their interfaces on this device. For example, compare theFigure 5.9, “Amazon.com's iPhone App” and Figure 5.10, “Amazon.com's iPad App” and notice the more custom design of the latter.
It's going to take some more time to truly understand how people experience and interact with the iPad. For some initial usability results, read Jakob Nielsen's first findings at http://www.useit.com/alertbox/ipad.html.
Translating Wireframes to Screens
The big task of the design phase will be to translate any wireframe assets you initially created into a refined, usable, and visually pleasing design. I recommend that your designer begin this part of the process once a first pass at the branding elements (colors, fonts, and logo) are completed. The reason is that you will need to use these branding assets in other places, such as your website, even before the app is released.
Of course, you most likely haven't developed wireframes for your entire application. As you get more experienced with wireframes, I recommend that you do. Assuming you didn't, have your designer start with what you did develop and work on that screen (or those screens) until you you jointly agree that they properly reflect the look-and-feel (visual design) and layout (user experience design) that you want for your app. In other words, finish one or two screens and use them to help set the tone for the remainder of them. The features you outlined for the first release should inform how you identify the remaining screens and flow for your application.
Devices and Resolutions
With the introduction of the iPad and subsequently the iPhone 4, designing for iOS apps has become increasingly more intensive. The reason relates to the differences in the sizes of these devices and their resolutions (see Summary of Devices in Chapter 2).
Depending on the devices you'll target, there will be multiple versions of the same screen and icon that need to be created. In fact, if your app is to be released across all devices, it will require up to nine versions of its icon because of the screen sizes and resolutions of the iPhone (original, 3G, and 3GS), iPhone 4, and iPad. You can point your designer to the following links, which provide more detail about this subject:
As described in the iPhone versus iPad section, some of these screens will not be a simple resizing but entail a fresh approach that caters to the device (Figure 5.11, “Neven Mrgan shows the most common icons required across all iOS devices.”). The same goes for the icons themselves. In particular, the iPhone 4's Retina display provides for the highest quality design with 326 pixels per inch (versus 163 for its predecessor or 132 for the iPad). This means that icons can contain more detail with richer textures. It is very likely that the next generation iPad will also have a Retina display, which will require another variation of design assets.
Focusing on the user experience of your app will go a long way to removing confusion or questions that your customers may have but it won't eliminate all of them. That's why as you near the completion of your app's design, you should consider adding fun and interactive ways to guide and educate your customers about your app.
The best approach is to incorporate this guidance into the natural use of the app. There's usually a correlation between apps that include this type of detail and their level of success. One stellar example is the iPad app Penultimate, which is a notebook that allows a person to sketch and write notes. The first notebook included in Penultimate is a dedicated user guide, detailing the various functions of an app. Figure 5.12, “Penultimate details the eraser function in the first notebook.” shows how Penultimate explains its eraser function.
Other great examples include the initial introduction to Tapbots' Pastebot (Figure 5.13, “Tapbots' Pastebot Initial Introduction”) and the opening hint from Sophia Teutschler's Articles (Figure 5.13, “Tapbots' Pastebot Initial Introduction”).
Depending on your app, you may not have the opportunity to do such an engaging experience. In Tweeb, for example, I opted for a more content-focused implementation. Tweeb performed some fairly complex calculations and so even though it received rave reviews about its design, some customers had questions about how their stats were calculated. Nearly all customer questions were addressed by directing them to the information button available for each screen—identified by the "i" shown in Tweeb Information Button—which, when tapped, displays customized help text on the screen (see Tweeb Twitter Support).
Figure 5.15. When tapped, the Tweeb information button—the "i" shown here—reveals the help text, which is specific for each screen.
As you explore more and more apps, take screenshots; press the Home + Power buttons at the same time and a screenshot will be saved to the device's Camera Roll. Over time, you'll have a nice collection of best practices, tips, and unique design elements that you'll be able to adopt and make your own. For additional inspiration visit galleries like http://ipadappsthatdontsuck.com, http://www.tappgala.com/, http://wellplacedpixels.com/, and http://tapfancy.com/. Regularly discuss apps that inspire you and that you admire with your team and especially your designer.
Getting into the details of programming may send chills through your body. Most people feel more uncomfortable with development because it's typically a less familiar area, not providing the same type of visual inspection that design does.
There are ways to check on the progress of development though, validating that it is on track and making progress. Before I help you understand how to do that, I want to give you a brief overview of what will be happening in the development process.
Your developer should spend some amount of time thinking about how the various pieces of your application interact with one another. In larger technical efforts, before a single line of code can be written, there's usually an architecture of the system created. Some may consider this overkill for an iPhone or iPad app but I recommend that you have your developer either provide a concise written description of your app's architecture or some visualization of it.
From personal experience, I can tell you that even developers who have taken the time to create a sketch of an app's technical architecture often run into situations they didn't initially think about. Taking the time to think through these aspects with your developer before any code is written, however, greatly reduces the risk of them not accounting for a major piece of functionality or scenario that can throw off you hitting your initial release.
Programming and Integration
The majority of your developer's time will be spent programming the inner workings of your app. Like with the design process, I recommend having your developer try to focus on one screen or feature at a time. This will allow you to fully test and experience a completely finished part of your application versus having random, unconnected pieces available.
Push your developer to identify and start on the hardest elements of the application first. This might cause no functionality to be available for a longer period of time at the start of the development process. But, this approach will avoid a situation where you think you are coming to the end of your application only to discover there's a serious problem with a complex and integral part of your app.
If your app integrates with external data sources through APIs or web services, the parts that handle this integration are likely to be the most complex. This could include connecting to social networking sites like Facebook or downloading data from a server. These situations will require your application to check network connectivity and potentially cache or store data onto the device. The challenge with integrations is that your app will be dependent on something external to it and outside of your control. Your developer will need plenty of error checking to make integrations work; your job will be to try to break them once it's available for testing.
Installing your app onto your device is covered in Chapter 6. You should, however, start installing and testing the app on your device(s) as soon as a feature or screen is ready.
Repositories and Source Code
In Chapter 4, I mentioned ensuring you have access to your app's in-progress design and development assets. In that context, it was as a matter of safety and protecting you from relationships gone bad. Hopefully, however, you'll primarily use this access to successfully collaborate with your team members.
While it is mostly a tool that your developer and designer will use, to facilitate this collaboration, you'll want to use a hosted repository to house your app's assets. The repository should be the location that includes the designer's creative designs or artwork, the developer's code, and possibly any strategic materials. The repository not only allows all team members to access these assets, it will also provide version control, ensuring that everyone is using the most current version of the assets, and that they are able to recover and compare older versions of the assets. In reality, your developer is the only person that probably needs access to all of the assets.
Today, the most commonly used repositories are Subversion or Git-based. Developers will usually dictate which they prefer, so don't be concerned about which to choose. Some project management tools covered in the next section, such as Unfuddle, can act both as your hosted source control repository and issue tracker, making them more appealing options. Here are a handful of options for you and your team to consider:
These repositories are also useful if you plan to open source all or part of your app (e.g., http://github.com/brow/leaves) and make it publicly available. While uncommon, it is worth noting that you will probably not want to open source anything until you've submitted and released the app.
To make it easier to get the source code from your repository (e.g., Unfuddle or GitHub), I recommend using version control software rather than just using a web or command line interface. The software you use is dependent on the type of repository for your app (noted above). The list below includes options for each:
It's always good to try a couple of options until you feel comfortable. Once you've settled on one, ask your developer to help you connect to your repository. There will be a one-time setup and after that you should only be refreshing ("update" in SVN or "pull" in Git) your source. The software you downloaded will make these updates easy going forward because there are buttons that initiate this process (Figure 5.17, “The Mac application "Versions" provides an "Update" button to retrieve the latest source code.”). Unless you are also the designer and/or the developer, it's highly unlikely that you'll ever need to send anything back to your repository, so you'll mostly be bringing the updated assets down from your repository.
Figure 5.17. The Mac application "Versions" provides an "Update" button to retrieve the latest source code.
At this point, the main benefits of having access to the repository will be to have physical possession of your app's assets, as well as to see how often your app is being updated (technically, how often commits with new or updated code are sent to the repository). There are other benefits, such as being able to build your app onto your device. This is a more technical process that is mentioned in Chapter 6 and detailed in Appendix A, Tips and Tools for those who are interested.
Tuning and Optimization
Much further into the process, the development focus should shift from building new functionality to tuning and optimizing what exists. From a customer perspective, this means making the app snappier, smoother, and issue free. More technically, your developer will be working on ensuring that your application is not leaking memory, over-utilizing the device's CPU, or being submitted with poorly written code.
Managing Your App's Progress
Conceptually, you now understand the types of steps involved in building your app. It's time to get more tactical again though, so that you can help guide your app into the hands of your testers and eventually into the App Store.
Managing your app's progress requires good organization and collaborative, real-time access into the status of features and their tasks. As customers come more fully into the picture, both through them testing the app and later when its live in the App Store, you'll also need a way to track all of their input.
You can try to develop your own solutions but it's best to turn to any number of third-party tools built specifically to help you with collaboratively managing your development progress or customer feedback. The tools available are plentiful and competitively priced. Before investing too heavily into any of them, ensure they'll meet your needs.
Tasks and Tickets
The tasks, from the breakdown of your features, are the smallest building blocks of your app. You'll input these tasks into an issue tracking tool, which will allow you to assign when they are due, their priority (e.g., highest, high, normal, or low), who the task (also referred to as "issue" or "ticket") is owned by, what release the task is part of (in this case it's likely "1.0"), what the current status of the task is, and other information, depending on the tool you select. As you and your customers have problems with your app, you will also log and track these problems (bugs) in this tool.
"Status" is an important field of any ticket, because it should inform you if it is not started, in progress, or completed. You and your team members should be very diligent about updating tickets with notes and editing fields likes "status" or "ownership" regularly. If tickets are kept up to date, you will have very good visibility on whether you are staying on schedule with meeting your app's submission date or if you have fallen behind. Because the highest priority tickets will be worked on and completed first, you will start moving the lower priority ones to the next release or the backlog.
Here are some issue tracking apps to consider:
Customer Feedback and Support
Should your app become very popular or even show any signs of life, you'll begin to be overwhelmed with customer inquiries and feedback through a variety of channels (e.g., Twitter and e-mail). Like with your tickets, you'll need to stay organized and the first step in doing that is to try to funnel as much of this information to one place as possible. Thus, your customer support tool will be comparable to your issue tracker but externally (i.e., customer) focused.
There are a couple of challenges with customer support tools but don't let that devalue their importance. The first challenge is that you won't be able to capture a significant customer support channel in it through any automated fashion—Twitter. The second challenge, which relates back to the first, is that customer support inquiries will often necessitate you creating a ticket in your issue tracker. For example, if you receive a customer question—through Twitter, e-mail, or your customer support tool—about a function of your app that you previously had not verified as broken, you'll need to create a ticket in your issue tracker for this bug. Upon the bug being fixed, you'll need to update that ticket's status and the customer about the resolution. The interconnectedness of these actions is why some customer support tools offer integrations to issue trackers.
Unfortunately, there's no perfect solution and you'll have to evaluate, publicize, and then be firm about how customers should contact you about support or feature requests. You may, for example, indicate that you don't offer support through Twitter or opt for using a shared support e-mail inbox (e.g., email@example.com) instead of a third-party support tool.
Screens and Prototypes
Be greedy and demanding throughout the design and development process. Your team should be iterating quickly, delivering new or updated assets every day. On the design side, these assets should be screens or artwork for the app. On the development side, this should be a working prototype of the latest app that incorporates the existing design assets. Speed and consistency are more important than polish and the risk of missing deadlines during the earliest stages of this process.
The value of a fully functioning prototype of your app—installed on an actual device—should not be underestimated. Your developer will demo your app in a tool called the "iPhone Simulator." This tool only mimics an actual device and will not uncover certain bugs or include full support for capabilities like Multi-Touch (although it can do so using a third-party tool called iSimulate -- http://www.vimov.com/isimulate/).
In general, the earlier your app gets on a device, the better. So, even early on this process, you should push your developer to always test the app by building it onto the device. Developers often won't want to test the app this way because it takes slightly longer to load it there compared to the iPhone Simulator. At the very least, however, it must be tested on the device itself before it is sent to you.
Your next marketing checkup should occur when you have the design of a screen from your app close to being done. This screen will be used by itself, so it does not need to be integrated into your app yet. When that is the case, go to the section called “Phase 3” of Chapter 8, Building Your Marketing Crescendo. Figure 5.19, “The evolution of Tweeb, from wireframe to design.” represents the evolution of the wireframe I showed you back in Chapter 3.
Tapbots - Paul Haddad and Mark Jardine
Positions: Founders; Programmer (Paul) and Designer (Mark)
Background: Tapbots are "utility robot" apps designed and engineered for the iPod touch, iPhone, and iPad. These applications are easy to use, focused, and fun.
Ken: Assume you have an app you feel good about pursuing, how do you map out building it? Do you break the app down into screens, features, or stories? Do you create a development schedule?
Mark: The first thing we do is figure out what the core purpose of the app is. It's usually described in 1-2 sentences. Then we write down all the features and tasks are needed to fulfill that core purpose. The most important features are usually version 1.0.
We try to keep an app from doing too much. Pastebot is almost an exception, but we did our best to stay on focus. Many suggested features that would make Pastebot benefit as a notes app. We felt strongly that it was intended to be a clipboard manager and its features should be focused around that task. It can be tough to say no to potentially good ideas, but in the end, we need our apps to stay focused.
Once the core features have been established, I start sketching wireframes and Paul usually begins the low level groundwork for the app. We usually have about 90% of the artwork done before Paul starts coding anything on the interface level. The missing 10% usually consists of minor things like settings, dialog boxes, and other things not essential to the core functionality of the app. Once the app is in somewhat of a working condition, we iterate on what's not working which includes design, functionality, and the user interaction experience.
We don't make a development schedule until we see the end of the road. Being a small team has its advantages. We don't have the pressure to meet deadlines. We work until we feel the app is good and not to a time limit. Once we are at the end of the road, we do need to plan for testing, localization, and marketing so that's when we start making schedules.
Ken: Whether its the iPhone or some other platform, something typically goes wrong or not according to plan when developing software. What sort of time do you allocate (if any) to potential problems and bug fixing?
Mark: For the most part, whatever time is needed to fix the issue. And that means solving the issue or finding a suitable work-around. It really depends on the size of the issue. Some bugs can wait while others demand immediate and full attention.
Ken: Related to these issues, do you do any rapid prototyping to identify potential roadblocks in the development of an app or do you move immediately into full development once you have your plan in place?
Paul: Very little, I might check if something is possible given the current hardware limitations (speed/memory) but for the most part it's full speed ahead with development. Our apps tend to be simple enough from a concept standpoint that it doesn't make sense to spend a ton of time prototyping things. For the most part the majority of the time I spend is in getting the UI to look and work just right.
Ken: How do you—and how can developers—reduce development time without cheating in the process? What aspects of creating an app can be done in parallel? What can't? Are there ways to get apps done faster besides having more resources available?
Paul: I'm a big fan of creating reusable classes/components. It won't save you much/any time on your first iPhone application but if done correctly it'll save time in future applications. Every app we create adds more classes to our library, which means we don't have to duplicate efforts and we can also get a consistent look and feel to our apps. Another great benefit with using reusable classes is that often features for new apps can be quickly added to existing apps which makes for happy users.
Ken: Tapbots is known for its incredibly polished interfaces. What do you do to ensure that they are not only polished but functional and easy to use?
Mark: We use them. And have other people use them. We tend to take design risks with our apps and they don't always work out. What looks good on screen doesn't always translate well when the user is interacting with it on the iPhone. We aren't afraid to design/code something and then start over if it doesn't feel right. The biggest part about our apps is the overall feel of them when using them. We put a lot of effort into making sure that WOW factor is there. If we, the developers, are excited with how it works, then we can be pretty sure that customers who haven't spent hours upon hours with the app will enjoy it.
Ken: Discuss what you consider the key differences of designing for the iPhone versus the iPad.
Mark: I can't speak too much about the differences as I have yet to design for the iPad. My instinct though is that it's not a matter of just making everything bigger. The limitations and constraints of the iPhone made things simple. Now, there's a lot more pixels to worry about. Then there's the device orientation. Despite these concerns, I think it's safe to say we are going to love designing and developing for it.
Ken: Overall, what is the key part of in the development of your shiny apps to the App Store?
Mark: Having clear goals for the app from the beginning and sticking to them. For us, our goal for all of our apps are to be fun, focused, and easy to use. We really try to build around those goals.
Agile Web Solutions - Roustem Karimov
Company: Agile Web Solutions, creators of 1Password
Position: CEO and co-founder
Background: Started in 2006 by Dave Teare and Roustem Karimov, Agile Web Solutions is the company behind 1Password — the most popular password manager for Mac OS X, iPhone, and iPad with over 1,000,000 users worldwide.
Ken: Since you had an existing product, how did you initially map out 1Password for the iPhone? Did you break the app down into screens, features, or stories? Did you create a development schedule?
Agile: The development of the iPhone and iPad applications was driven by screens. Dan Peterson, our lead designer, mocked up most of the application screens in Photoshop before any coding started.
For the iPad version, once Dan completed the initial mockups, the whole team reviewed them and tried to imagine using the application on a real iPad. Things like being able to switch sections without moving your hand, left versus right-hand usage, and what portion of the screen is covered when interacting with it were considered. Basically, the screens were used as "target practice" and to help brainstorm additional ideas.
After the mockups were redesigned to incorporate the team's feedback, the development team started implementing the design. It was an iterative process and the layout and contents of each screen were revised as we worked through the implementation.
As for the schedule, we didn't really have a formal schedule but the goal was to be in the App Store by the launch of the iPad App Store. This forced us to limit the scope of the first version and we removed features such as syncing with MobileMe and attachments.
Ken: What makes developing for the iPhone and iPad unique? Please also discuss what you consider the key differences of designing for the iPhone versus the iPad.
Agile: There are a lot of similarities in designing iPhone and iPad. The main difference is that the amount of real estate on iPad requires a lot more effort during design. This is magnified by the fact that Apple encourages a custom user interface specific to the iPad.
Developing for the iPhone and iPad is a dream in many ways. There are amazing development tools, polished frameworks, and APIs. Also, the App Store helps the developer to not worry about running their own online store.
It comes with its own challenges as well. For example, developing on one platform and testing on another can be tricky because the iPhone Simulator is not 100% identical to the real device.
The biggest difference is that iterative development is much harder on the iPhone platform. This is because it could take several days for the application to be reviewed by Apple and accepted into the store. Apple also makes a large beta program impossible. On Mac, we currently have thousands of beta testers whereas on iPhone we cannot have more than about 50. As a result, we submit new versions much less frequently.
Ken: Whether it's the iPhone or some other platform, something typically goes wrong or not according to plan when developing software. What sort of time do you allocate (if any) to potential problems and bug fixing?
Agile: At first glance building "slack time" into the schedule to plan for the unknown seems like a good idea. The problem is Parkinson's Law: Work expands so as to fill the time available for its completion. If the schedule was expanded by 20% in an attempt to plan for the unknown, the feature set would increase by 20% as well.
Not only that but Apple is constantly creating new "magical and revolutionary" devices and adding new features. It is hard to plan far into the future when new "game changers" appear so frequently.
Instead of spending time on detailed schedules we prefer taking a more agile approach and do not plan far into the future. There is always something important waiting for the next version of 1Password and the priorities of these features are constantly changing. If something important pops up like a new platform or a critical problem, then we simply drop everything else until it is finished.
Ken: How did you decide what features went into 1Password and 1Password Pro? Specifically, how did you determine what paid features would compel customers to choose 1Password Pro?
Agile: I am not sure we did it right in the beginning. Some of the premium features, like folders or additional syncing options weren't ready when the Pro edition was launched and we decided to start with a lower introductory price. Today, this could be done much easier with the in app purchase option.
Ken: Do you have any guidance for developers on thinking about how to break up major (e.g., v3.0) and minor (e.g., v2.1.1) updates? Do you work on major and minor updates in parallel? When is an update complete and ready to be shipped?
Agile: It is a fairly straightforward process on Mac where we make all major upgrades paid, include new features into the point (3.1, 3.2) updates and mostly provide bug fixes in the point-point (3.1.1, 3.1.2) updates. There is no paid upgrade option for iPhone or iPad apps and we simply try to keep the major version in sync with the desktop application and use point and point-point updates in a similar fashion.
Ken: You launched the iPad version of 1Password Pro as a Universal app. What went into that thought process?
Agile: This was an easy decision. It helped to differentiate between the regular and Pro editions and also created a certain symmetry where Pro edition combines all features of "1Password for iPhone" and "1Password for iPad."
Link - http://agile.ws/
Here's what you learned in this chapter:
Although you didn't realize it, you already started the development process through the work you've done up to this chapter; that work gave you the foundation to start the actual building of your app the right way.
Outlining the features of your app will help you develop your app's roadmap; your roadmap will be your guide to bring the first version of your app to the App Store and serve as a starting point for what features may go in future releases.
Developing your app's description now will help you better communicate what your app is about in your customer interactions; this description will also inform your website content and eventually, your App Store description.
Understanding some of the aspects of the design and development process, at least at a high-level, will make you a more useful team member; you will need to continue to expand your knowledge of iPhone app design and development to truly be able to guide an app successfully into the App Store.
Leveraging third-party web-based tools to manage the features, tasks, and feedback of your app will keep you organized; you and your team will use these tools to better collaborate with one another and have a real-time view into the progress of your app.