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.

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.

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.

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.

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.

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.

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.

Figure 5.7. From the iPad's HIG, Apple calls this content view a "split view."

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:

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.

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.

Figure 5.9. Amazon.com's iPhone App

Figure 5.10. Amazon.com's iPad App

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.

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.

Figure 5.11. Neven Mrgan shows the most common icons required across all iOS devices.

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.

Figure 5.12. Penultimate details the eraser function in the first notebook.

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”).

Figure 5.13. Tapbots' Pastebot Initial Introduction

Figure 5.14. Articles' Opening Hint

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.

Figure 5.16. Directing users to the information button via the Tweeb Twitter account.

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.

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.

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.

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:

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.

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.

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.

Issue Tracking

Here are some issue tracking apps to consider:

Figure 5.18. Unfuddle tickets for Tweeb v0.9.

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., support@tweebapp.com) instead of a third-party support tool.

Customer Support