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 will be a smoother process. You’ll work with your team to break down how you are 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
My purpose for waiting until now to describe the development process in detail is that many people who build apps are extremely anxious to “get started,” without really understanding what it means to get started. In particular, those who have the design and development skills to build an app without help often forgo the processes of researching competition, understanding what’s going to make their app different, and sketching the key screens of their app, and instead start building it right away. The result is a misinformed app that is doomed to fail before it even hits the App Store.
Here’s a secret you’re going to be very happy to know: you’ve actually already begun the development process...the right way. Most people associate “development” only with designing 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. Although those in the software industry divide the various parts of the development process differently, here’s how I’ll refer to them in this book (noting what’s been accomplished and what will be accomplished in later chapters):
Apple’s Human Interface Guidelines (HIG)
App name, icon, and screens (including splash screen)
Integration with external data sources
Testing your app and interacting with beta testers (Chapter 6)
Building an app onto a device using Xcode (Appendix)
As a reminder, from Chapter 1 and Chapter 3, you know that marketing is an ongoing process you’re following in conjunction with developing your app. I’ll continue to point you to Chapter 8 to help you keep building your marketing crescendo.
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 as only a guide. Building an app that is driven by customer feedback means 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.
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,” and “update” can be used interchangeably.
Verbiage aside, there are three key aspects of a roadmap:
Outlining the initial universe of features for your app
Breaking down these features into specific tasks
Appropriately prioritizing these features, and subsequently the tasks related to the features, into their respective releases
Compared to the third item, you’ll find the first two are much more operational in nature.
Before you can strategically assess what features should be assigned to a specific release of your app, you need to outline all the features that have been rolling around in your head. You probably wrote some of them down somewhere, but they are still likely not fully defined. You can 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 create a list 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 recommend that you use some sort of digital means instead of pen and paper so that you can more easily manipulate and share them. 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 worrying about how to structure or categorize them.
Here is 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 what you consider your features, try to do the same.
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
Rewind/fast forward (5s; 15s; 30s; 1 min; 5 min; etc.)
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 screen requires.
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.
Although other factors can 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:
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., email) to further discuss what your customers consider to be important.
Remember that anytime 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 your solutions (features) and the benefits you plan to offer them through your app.
One way to further distinguish the most critical features of your app is to determine which ones would compel your customers to purchase your app. Beyond pushing these features to the top of your list, those who are pursuing In App Purchases will begin to identify what features should be paid upgrades.
Some number of basic features will be required for your app to function. If they are not present, your app will be inoperable. For instance, if you are connecting to an external web service, this may include logging in to 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. A feature’s level of complexity will impact how long it takes you to build it. Whoever is designing and developing your app will need to determine the time required to build features. 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 of 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 a combination of both. Obviously, the complexity of the features will have a direct impact on cost; pursue the most customer-important, simplest, and least costly features first.
Based on the aforementioned factors, the feature list for the first version of your app should be taking shape. To further understand what features will 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 feature you’ve identified. That will occur by you and your team breaking down the features into tasks.
By breaking down a feature into a short, descriptive task, you’ll have a more comprehensive understanding of whether it can be built in a couple of hours or a couple of days. The t-shirt sizing you did will help you get started. An S feature, for example, may have only one task associated with it, whereas an 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 earlier, 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 compromising the purpose of why you started building this app. That doesn’t mean you should rush your app to Apple, but if your estimates are showing that your first app will take three months to build, 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 than it is to start building them, only to realize that they will prevent you from getting into the App Store in a timely manner.
Although it’s a broad and sweeping recommendation, I’m going to urge you to ensure that your initial release requires no more than eight weeks of design and development time. If you can reduce the amount of time you spend on the first version, you minimize the risk of your app sinking into an abyss of never launching. So, consider those eight weeks as not a goal, but rather the absolute maximum amount of time you should allocate for that first release. This should hold true even if you are submitting your first app to the App Store. In fact, I’d argue that it’s OK to spend up to eight weeks on an initial release only if it’s your first app. More experienced developers should strive for two to four weeks.
Now that you’ve identified the features for your first release and the remaining unassigned features for your app, and you’ve allocated time to build the first version of your app, you can begin to construct your roadmap. My 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 manage the progress of the app, and that it is focused on vision and not execution.
If you choose to maintain your roadmap in a spreadsheet, note that 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 regarding what Apple calls the “Availability Date”). At this point, you only need two columns. The first column will be labeled “1.0” (or whatever you choose as the initial version number for your app), and will include all the features you’ve identified for this release. The second column will be labeled “Backlog” and will include a prioritized list of the remaining features you’ve outlined for your app (see Figure 5-1).
Going forward, you will 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 9). You can visit http://kenyarmosh.com/appsavvy to get a sample roadmap spreadsheet.
Having outlined the features of your app, you should take this opportunity to create a better description of your app. Not only will this enable you to more clearly discuss your app with customers, contacts, friends, and family, but also, and more importantly, this description will become part of your marketing assets and will be used in such places as your website and the App Store.
The first part of your description should be a short tagline that quickly communicates the essence of your app. It doesn’t have to be a complete sentence, and instead can be 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 also want to begin exploring some app names. As you can see from the preceding app samples, as well as from other top apps in the App Store, simple and straightforward names are better. Even Robocat’s creatively named weather app, Outside, still communicates what it is about. The other benefit for simpler names is that they will be more memorable and 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 the availability limitations is to append the word “app” to the end of the desired name. For example, here are the domains and Twitter handles for the apps mentioned earlier: 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 the tagline, you’ll want to expand it to a three- or four-sentence description. Prospective customers will read this information immediately after looking at your app’s name and tag line. This description should capture your app’s key differentiators. Here are descriptions for Tweeb and Digital Post:
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. Here’s what I included for Tweeb:
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 doesn’t exist yet, make your tag line, description, and features aspiring. Spending a small amount of time detailing these items now will help you to focus on what you want the core of your app to be as you move through the rest of the design and development process.
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 in this section 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, although you will possibly be relying on others to design and develop your app, knowing what is being worked on and being able to provide intelligent feedback regarding work in progress 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, the less upfront work there will be for your designer and developer. This not only speeds the progress of your app, but also reduces your bottom-line costs.
You’ll work closely with your designer to expand your concept app. Through that collaboration, you’ll determine your app’s color scheme, fonts, logo, app icon, and of course, the screens themselves. Be inspired as you undertake your app’s design. Review with your team apps 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 also how you interacted with the app. In the following paragraphs, Josh Clark, the author of Tapworthy: Designing Great iPhone Apps (http://oreilly.com/catalog/0636920001133/; O’Reilly), provides some key points regarding the importance of visual design. Note that his tips for iPhone apps are equally 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). 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 toy-like? 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’s 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). This technique requires a light touch, however; don’t distract from the content itself or drain the meaning from otherwise familiar controls.
You stay classy. Luxurious textures applied with taste (Figure 5-4) 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), 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)—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.
Two good resources on the process of designing an app’s icon include Michael Flarup’s “iPhone App Icon Design: Best Practises” (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.
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 is especially unique because the interaction with these devices is centered on touch (i.e., Apple’s Multi-Touch).
To give a little more context to the importance of the touch metaphor (besides what we covered in Chapter 2), an entire subspecialty of the larger design field is 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. This should underscore how significant the user experience will be with your apps, where the screens are considerably smaller yet controlled with touch gestures.
Apple heavily touts the Multi-Touch elements of its devices and the new standard it set with the iOS platform. The company has worked diligently to preserve the elegant experience it has enabled on its devices, both within its own apps and with those developing for the Apple platform. To do that, Apple has created a set of standardized design frameworks and extensive Human Interface Guidelines (HIG) for each of its devices.
If you’ve completely ignored all of Apple’s documentation to this point, do yourself a favor and read the HIG for both the iPhone and the iPad (part of the iOS Reference Library). In doing so, you’ll learn how Apple approached porting apps such as Mail and iPhoto to the iPhone, and subsequently, how it 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 its design frameworks and you’ll learn how to properly implement each of them. In Figure 5-7, 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 that these elements are properly implemented. This particular point is critical, for two reasons:
Apple is fairly stringent about its HIG, and failing to observe them, at least in the past, was one of the most common reasons for app rejection during the approval process.
Apple favors applications that embrace the same simplicity of its applications; this partially follows from adhering to the HIG.
Through the HIG, I’m hoping you are now completely aware that your application will need great visual and user experience design to be considered a well-designed app.
As mentioned before, the differences between the iPhone and the iPad start with how you use the devices. The iPad display is more than 2.5 times larger than the iPhone display, so unlike the iPhone, the iPad is not extremely functional when you use it with only one hand; you need to use both hands or rest it on a surface. And where the iPhone and iPod touch are predisposed to being 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 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 (shown in Figure 5-7) to a popover view (see Figure 5-8).
The proverbial elephant in the room, however, is the difference in display size between the two devices. Although a big design challenge with the iPhone is 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 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 to understand the different elements available:
The views and controls for each device facilitate 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 resultant 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 people treat it. The iPad’s dimensions make it comfortable to use for much longer periods of time, especially for reading, browsing the Web, and managing email. 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 such as Things, flick games such as Flight Control, and streamlined mobile views for websites such as Mint.com. Comparatively, the earliest successes for the iPad included the document reader GoodReader, numerous newspaper and magazine apps, full-sized board games such as 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 Amazon.com’s iPhone and iPad apps, in Figure 5-9 and Figure 5-10, respectively, 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.
The big task in 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) is completed, as you will need to use these branding assets in other places, such as your website, even before the app is released.
Of course, at this stage you likely haven’t developed wireframes for your entire application. As you gain experience in wireframe development, I recommend that you have done so once you reach this stage in future projects. Assuming you haven’t, though, have your designer start with what you did develop and work on that screen (or those screens) until 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 remaining screens. The features you outlined for the first release should inform how you identify the remaining screens and flow for your application.
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 Table 2-1 in Chapter 2).
Depending on the devices you target, multiple versions of the same screen and icon will 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 (see Figure 5-11). 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 require a simple resizing, but rather will entail a fresh approach that caters to the device. The same is true for the icons. 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 icons can contain more detail and richer textures. It is very likely that the next-generation iPad will also have Retina display, which will require another variation of design assets.
Focusing on the user experience of your app will go a long way toward removing some of the confusion or questions your customers may have, but it won’t eliminate all of them. That’s why, as you finish 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 the app. Figure 5-12 shows how Penultimate explains its eraser function.
Depending on your app, you may not have the opportunity to create 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 Figure 5-15—which, when tapped, displayed customized help text on the screen (see Figure 5-16).
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 such as http://ipadappsthatdontsuck.com, http://www.tappgala.com/, http://wellplacedpixels.com/, and http://tapfancy.com/. Regularly discuss with your team, and especially with your designer, apps that inspire you.
Getting into the details of programming may send chills through your body. Most people feel less comfortable with development than with design because development is typically a less familiar area and does not provide the same type of visual inspection that design does.
There are ways to check on the progress of development, though, and validate that it is on track and moving forward. 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 time thinking about how the various pieces of your application interact. In larger technical efforts, before a single line of code can be written, an architecture of the system is usually created. Some may consider this overkill for an iPhone or iPad app, but I recommend that you have your developer provide either a concise written description of your app’s architecture or a 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 expect. Taking the time to think through these aspects with your developer before any code is written greatly reduces the risk of the developer not accounting for a major piece of functionality or a scenario that can cause you to miss your initial release deadline.
The majority of your developer’s time will be spent programming the inner workings of your app. As 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 mean no functionality is available for a longer period of time at the start of the development process. But this approach will avoid a situation in which you think you are coming to the end of the development phase, only to discover there’s a serious problem with a complex and integral part of the app.
If your app integrates with external data sources through APIs or web services, the parts that handle this integration will likely be the most complex. This could include connecting to social networking sites such as 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 your control. Your developer will need plenty of error checking to make integrations work; your job will be to try to break them once they’re 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.
In Chapter 4, I mentioned ensuring that you have access to your app’s in-progress design and development assets. In that context, ensuring access was as a matter of safety and to protect you from relationships gone bad. Hopefully, however, you’ll primarily use this access to successfully collaborate with your team members.
Although 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 include 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, but 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 who probably needs access to all of the assets.
Today, the most commonly used repositories are based on Subversion or Git. Developers will usually dictate what 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 as both your hosted source control repository and your issue tracker, making them more appealing options. Here are a handful of repository 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. Although 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 client 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 earlier). The following list 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 (see Figure 5-17). 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 the repository.
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 the Appendix for those who are interested.
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, overutilizing the device’s CPU, or being submitted with poorly written code.
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 to the status of features and their tasks. As customers enter the picture more fully—while testing the app, and later, when it’s live in the App Store—you’ll also need a way to track 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 collaboratively manage your development progress or customer feedback. The tools available are plentiful and competitively priced. Before investing too heavily in any of them, ensure that they’ll meet your needs.
The tasks, from the breakdown of your features, are the smallest building blocks of your app. You’ll input these tasks (also referred to as “issues” or “tickets”) into an issue tracking tool, which will allow you to assign when they are due, their priority (e.g., highest, high, normal, or low), their owner, which release they are part of (in this case, probably the 1.0 release), their current status, and other information, depending on the tool you select. As you, your team members, and your customers uncover problems with your app, you will also log and track these problems (bugs) in this tool.
“Status” is an important field in any ticket, because it should inform you whether the ticket is not started, is in progress, or is completed. You and your team members should be very diligent about updating tickets with notes and editing fields such as “Status” or “Ownership” regularly. If tickets are kept up-to-date, you will know if you are staying on schedule in 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.
If your app becomes very popular or even shows any signs of life, you’ll begin to get overwhelmed with customer inquiries and feedback through a variety of channels (e.g., Twitter and email). As 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.
Customer support tools present a couple of challenges, but don’t let this devalue their importance. The first challenge is that you won’t be able to capture a significant customer support channel—Twitter—through any automated fashion. The second challenge, which relates back to the first, is that customer support inquiries will often require that you create a ticket in your issue tracker. For example, if you receive a customer question—through Twitter, email, 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. When the bug is fixed you’ll need to update that ticket’s status and let the customer know the issue has been resolved. The interconnectedness of these actions is why some customer support tools integrate with issue trackers.
Unfortunately, there’s no perfect solution to this, and you’ll have to evaluate, publicize, and then be firm about how customers should contact you regarding support or feature requests. You may, for example, indicate that you don’t offer support through Twitter, or opt to use a shared support email inbox (e.g., email@example.com) instead of a third-party support tool.
Here are some customer support tools worth considering:
Be demanding yet reasonable 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 such as Multi-Touch (although it can do so using a third-party tool called iSimulate; see http://www.vimov.com/isimulate/).
In general, the earlier your app gets on a device, the better. So, even early in 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 onto the device 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 the design of a screen from your app is near completion. This screen will be used on its own, so it does not need to be integrated into your app yet. When that is the case, go to the Phase 3 section in Chapter 8. Figure 5-19 represents the evolution of the wireframe I showed you back in Chapter 3.
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 one or two sentences. Then we write down all the features and tasks that are needed to fulfill that core purpose. The most important features usually [become] 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. 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 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?
Mark: For the most part, [we allocate] whatever time is needed to fix the issue. And that means solving the issue or finding a suitable workaround. 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: [We do] very little [rapid prototyping]. 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 also functional and easy to use?
Mark: We use them. And [we] have other people use them. We tend to take design risks with our apps, and they don’t always work out. What looks good onscreen 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 the development of your shiny apps?
Mark: Having clear goals for the app from the beginning and sticking to them. For us, our goal for all of our apps [is that they] are fun, focused, and easy to use. We really try to build around [that] goal.
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 more than 1 million 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?
Roustem: 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 righthand 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 to be the key differences between designing for the iPhone versus the iPad.
Roustem: There are a lot of similarities in designing [for the] iPhone and iPad. The main difference is that the amount of real estate on the 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 developers 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 the Mac, we currently have thousands of beta testers, whereas on the 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?
Roustem: 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?
Roustem: 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?
Roustem: It is a fairly straightforward process on the 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?
Roustem: This was an easy decision. It helped to differentiate between the regular and Pro editions and also created a certain symmetry where the Pro edition combines all features of 1Password for iPhone and 1Password for iPad.
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 actually building 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 bringing the first version of your app to the App Store and will 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.