Now that you have more than an instinct that your idea has some merit to it, it’s time to start defining some details about your app and how it might stand out in the App Store. To do so, you’ll need to be more familiar with the unique aspects of the iPod touch, iPhone, and iPad devices.
In this chapter, you’ll explore:
The uniqueness of Apple’s touch devices
Specifics about the iPod touch, iPhone, and iPad
What’s new in iOS 4
How to approach developing an innovative app
After browsing the App Store and thinking about the potential of your app, you may be excited to get started. Many people assume “getting started” means jumping straight into what the app is going to look like and how it’s going to function. Doing that is one of the biggest mistakes you can make.
First, a person who is not a designer or developer will need to collaborate on the creative and functional aspects of the app with people who do possess design and development skills. Trying to work on either of those now will only lead to frustration. Second, just as there was a structure to vetting your initial idea, there’s a structure to developing it.
I promise that you’ll get to how your app will look soon enough. In the meantime, you need to continue to refine your idea and create a set of assumptions about it. That starts with understanding more specifics about the iPod touch, iPhone, and iPad devices.
Part of what makes creating an app and developing on the iOS platform more unique than working with other software is a higher dependence on the device. Your app’s functionality will rely on the device it runs on and will need to be built to accommodate it.
Although in the following sections I will review the common features across all devices, and subsequently the features specific to each device, it is ultimately the designer’s and developer’s responsibility to properly implement them. I provide this information for context so that you have a more comprehensive understanding of what you can incorporate into your app. The intricate technical details regarding how these features are integrated into your app shouldn’t cause you angst.
Next to apps themselves, what has made Apple’s iOS devices so successful is touch. Sure, the ability to interact with a device through some sort of physical touch metaphor existed previously. It just hadn’t been created “the Apple way.”
The two biggest differentiators for Apple’s approach included a large keyboard-less display—now fairly common for mobile devices—and Multi-Touch. Multi-Touch allows the device to recognize more than one touch or gesture on the screen at once. It is what powered the revolutionary pinch to zoom feature on a map or photo.
Apple didn’t stop there, though, as even the more basic touch capabilities were improved, allowing “endless scrolling” by swiping up or down and left or right on the screen. The point is that Apple raised the bar dramatically, redefining how someone could interact with standard functions (e.g., email and voice mail), and eventually apps. All new smartphones and touch devices launched today have to at least try to compete on this front with the iPod touch, iPhone, and iPad.
You definitely don’t want to underestimate the significance of how the Multi-Touch paradigm will impact the experience of your application. Although the mouse and point-and-click have been the predominant experience for consumers for the past two decades or so, controlling an app via touch is exceptionally more personal and intimate.
The same is true with the device itself. People hold and experience their devices and apps while on the bus, in bed, and yes, even in the bathroom. They slip them into their pockets and slide them into their bags. They customize every aspect of them, from the background to the order of the icons on their Home screen. The Home screens of an iPod touch, iPhone, and iPad are little customizable worlds crafted and shaped in every way and everywhere, tap by tap, touch by touch, and swipe by swipe. These devices present a means to be perfectly unique reflections of their owners (e.g., see http://firstand20.com/), and it all starts with the experience of touch.
The iPod touch and iPhone allow for five simultaneous touch events. Developer Matt Gemmell discovered that the iPad more than doubles the number of touch events (see Figure 2-1), with 11 simultaneous touches (http://mattgemmell.com/2010/05/09/ipad-Multi-Touch), indicating that Apple clearly developed it for Count Tyrone Rugen (see the section Fundamentals of all devices in Fundamentals of all devices).
Apple no longer officially supports first-generation devices such as the original iPhone. Older devices and operating systems (pre-iOS 3.x) are increasingly becoming statistically insignificant, especially with Apple making iOS 4 a free upgrade. Thus, the following sections assume a baseline of second-generation devices running iOS 3.x. Because of the relative newness of iOS 4, it is addressed separately.
The three hardware features that are available on all Apple devices are WiFi, Bluetooth, and the accelerometer. The first two are probably familiar terms to you and relate to network connectivity. The significance of WiFi as a baseline is that certain devices will have access to the Internet only when a WiFi network is present. Thus, network connectivity cannot always be assumed.
It might seem odd that Bluetooth is a common element to all devices, especially when most people use it for hands-free headsets and the iPod touch and iPad do not have phone capabilities. Bluetooth is included on all devices because Apple relies on Bluetooth for peer-to-peer connectivity, most often taken advantage of in games. Bluetooth also allows the later-generation devices using iOS 3.2 and later operating systems to connect to a Bluetooth keyboard.
You are likely more familiar with what an accelerometer does than with the word itself. The accelerometer is what detects the movement and orientation of a device. In the former case, the device can detect side-to-side, up-and-down, and more sporadic shaking movements. The more basic function, however, is that the accelerometer powers apps to flip from portrait to landscape mode depending on how the devices are being held. If you are a physics geek, the accelerometer can offer a playground. Take a look at Illusion Labs’ games Labyrinth 2 and Labyrinth 2 HD, which showcase the accelerometer in all its glory.
Most of the functionality of the Apple-provided apps (see Figure 2-2) is accessible to third-party apps (like yours) through various technical frameworks, kits, and application programming interfaces (APIs). Since detailing those is both beyond the scope of this book and irrelevant to you, I’ll review the functions of Apple’s apps and how they are made available to you. I’ll continue to use the term “third-party” throughout this section to help distinguish the apps in the App Store from Apple’s apps.
The Contacts apps house all the contacts of a device. When in a third-party app that accesses the device’s Contacts, depending on what is selected (e.g., phone number), an app may close and activate some other action such as a phone call. In that case, the app will not necessarily reopen once that action is completed. In other cases, such as emailing, if in-app email is used, the device’s Mail app will open a new message and return to the app once it is sent or canceled.
Closely related to Safari is web video content. With YouTube being the Web’s most popular video destination site, Apple worked with Google to create a YouTube app optimized for Apple devices. Clicking on a YouTube video from within a third-party app will open the YouTube app; the app will return you to the third-party app when you are done with the video.
Continuing with media, the Photos and iPod app libraries are available to third-party apps. Developers often use these libraries when their app would benefit from including a photo from a device’s camera roll or from customizing sounds (e.g., an alarm clock app). Other media functions available include playing audio and video clips, as well as recording audio.
Another popular application function that’s available across Apple’s devices comes from the Maps app. Apple again partnered with Google to bring a customized version of Google Maps to Apple devices. Leveraging Maps’ features, developers can embed maps into their apps. Obviously, that’s typical for apps in the Navigation category, but this functionality is not used exclusively by navigation-based apps.
Recall that I mentioned the “keyboard-less” display before. Obviously, most apps would be completely useless without some way to input text or numeric content. Apple provides apps with several different onscreen keyboards that can be shown based on usage needs, including ones customized for entering a web address and phone number.
Beginning in iOS 3.0, Cut, Copy, & Paste was introduced and became an instant success. Although Apple has it enabled in most of its apps (wherever it makes sense), developers don’t always incorporate it. When they fail to, they hear about it from customers. To a lesser extent, the same holds true for keyboard auto-correction and auto-capitalization.
Mentioned in Chapter 1, In App Purchase is one of the more significant technical frameworks provided by Apple. It facilitates payment authorization through Apple without having to leave the application. Developers have found many uses for it, including selling new levels in games and turning on premium features such as push notifications.
On that last point, push notification is another technical framework that has a substantial customer-facing impact. Its official name is the Apple Push Notification Service (APN), and it sends or “pushes” an alert or notification to a customer’s device. The push notification can include a message, a sound, a badge number, or a combination of all three depending on the developer’s preference (see Figure 2-3). Push notifications are useful for encouraging a customer to reengage with an application depending on whether a particular event has occurred. With the launch of iOS 4, Apple has released local notifications.
All devices also have general location-based services available through WiFi. Through WiFi signals and access points, devices use technology from Skyhook and Google to calculate location in Apple’s apps (e.g., Maps), as well as third-party apps.
The second-generation iPod touch models have a 533 MHz processor. That’s actually faster than the iPhone 3G. The third-generation 32 GB and 64 GB iPod touch devices have the same specifications as the iPhone 3GS, namely a 600 MHz processor and 256 MB of RAM.
These specs, as well as the ones that follow, aren’t pointless. The performance and speed of an app can vary significantly across devices because of these hardware differences. Keep that in mind when you begin testing your app, which I’ll address in Chapter 6.
The iPhone includes all of the features of the iPod touch plus some additional capabilities. I’m not going to highlight obvious differences, such as support for phone calls and text messages. Instead, in the following list I’ll focus on the essential device-related features for the iPhone 3G, iPhone 3GS, and iPhone 4:
The “3G” in the name “iPhone 3G” stands for “3G network.” Essentially, it allows faster data delivery speeds through the cellular network compared to previous generations (that’s the “G”) of networks. This means the iPhone, unlike the iPod touch, can access the Internet outside of WiFi. Connectivity and speeds will vary based on network demands and availability.
Although all devices have basic location-based services through WiFi, what others do not have is the more precise positioning of GPS. GPS became a killer feature for Maps, allowing turn-by-turn navigation based on current location.
Beyond obvious uses, apps will often associate geolocation data from the available location-based services (WiFi or GPS) when creating content such as notes or photos so that a person can see the date and place where he jotted down a thought or snapped a picture. Of course, to snap a picture, you need a camera. The camera is the final major differentiator between the iPhone and iPod touch/iPad.
The “S” in the name “iPhone 3GS” unofficially stands for “speed.” Compared to the iPhone 3G’s 412 MHz processor with 128 MB of RAM, the iPhone 3GS has a 600 MHz processor and 256 MB of RAM, giving it a fairly sizeable upgrade on both fronts. With these specifications and support for up to 7.2 Mbps cellular data link speeds (compared to 3.6 Mbps for the 3G), the download speeds for the 3GS have been clocked to be as much as three times faster than for the 3G.
Apple also added a Compass app to the iPhone 3GS via a new electronic compass chip. But what made people considerably more excited was the 3-megapixel camera upgrade (from 2 megapixels) with support for video recording. These latter two additions are more commonly incorporated into third-party apps than the compass functionality.
As with the launch of the iPhone 3G compared to the original iPhone, the iPhone 4 was a major product update to the iPhone line and its iPhone 3GS predecessor. The design changes alone are significant, with the iPhone 4 being 24% thinner than the iPhone 3GS and constructed of stainless steel and glass rather than plastic. The engineering changes did not stop with the design. While making the iPhone 4 smaller, sleeker, and sturdier, Apple also considerably upgraded the specifications and features of the 3GS.
The upgrades start with Apple’s A4 processor—also used in the iPad—suggesting a 1 GHz processor speed and 512 MB of RAM. They continue with the introduction of a new high-resolution display called Retina display, a 5-megapixel camera, HD video recording, a front-facing camera that helps power FaceTime (Apple’s WiFi-based video chat), and a gyroscope, which in combination with the accelerometer allows for six-axis motion sensing.
Although the number of those additions is stunning, the one with the most immediate impact to you as an app developer is Retina display. It essentially places four times the number of picture elements—pixels—into the same screen size of the previous iPhone models. The result of this higher pixel density is a super-sharp display that makes text and graphics look extremely crisp. To take advantage of Retina display, though, you’ll need to prepare an additional set of design assets, as is required if submitting a Universal application (see Chapter 5).
The differences in the iPad start with how you engage the device. Its display is more than 2.5 times larger than the iPhone, so unlike an iPhone, the iPad is not extremely functional when you use it with only one hand; you need to either 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.
In terms of hardware specifications, the iPad was the first device to adopt Apple’s A4 processor, confirmed at 1 GHz. Ironically, the bigger iPad actually has only 256 MB of RAM, meaning that it has the same amount of RAM as the iPhone 3GS and half the amount of RAM as the iPhone 4. Similarly, although the display is more than 2.5 times larger than the iPhone, its pixel resolution is 1024 × 768, which is not as striking a difference against the iPhone 4’s 960 × 640.
Whereas iOS 4 has a software toggle for portrait mode lock, a device control unique to the iPad is screen rotation lock. As mentioned earlier, the iPhone, as a phone, has a somewhat natural association with being portrait-based. That’s not the case with the iPad, and so Apple created a button that allows the screen to be locked in portrait or landscape orientation. When you shift the button to the lock position, the screen no longer will shift orientations when the device is rotated. Although this is helpful to consumers, it adds another variable for developers. This control is the primary reason Apple recommends iPad apps be able to operate equally well in portrait and landscape modes.
Aside from differences in its size, processing power, and memory, the iPad has similar device components to the iPod touch, including the accelerometer, Bluetooth, push notifications, and so on, all properly adjusted for the iPad. Most of the Apple-provided apps are also on the iPad, but each app has been customized for the device. Apple’s iPad versions of its iPhone apps are the best examples that designing apps for the iPad requires its own approach.
By now, you likely deduced that the iPad WiFi model does not include a cellular connection and relies exclusively on WiFi for access to the Internet. As a result of not having that, it also is missing GPS and precise location positioning, using the more basic WiFi location services.
As I alluded to earlier, the WiFi + 3G model also includes GPS for use in Maps and third-party apps. This model is identifiable by the black strip across the top of the device and the micro-SIM card tray on its side. The micro-SIM card, which identifies you to the cellular network, enables the 3G cellular data connection.
This section on the iPad is short, for two reasons:
As mentioned previously, beyond physical dimensions, the iPad does not have many unique device-related features. The biggest changes from the iPhone are not the more obvious hardware differences, but rather how the iPad substantially affects the design and development of apps.
Since both iPad models share the same processor and memory specifications, there’s nothing to highlight as there is with the different models of the iPhone.
To help with all the differences between the iOS devices, Table 2-1 summarizes the key technical specifications of the iPhone, iPod touch, and iPad.
Pixels per inch
480 × 320
480 × 320
960 × 640
480 × 320
480 × 320
960 × 640
1024 × 768
WiFi + 3G
1024 × 768
The latest operating system for Apple’s touch devices, iOS 4 is significant and deserves to be addressed separately. As in the previous section, I will highlight how iOS 4 impacts end-user functionality. You’ll be especially happy to not have to focus on the inner technical workings of the 1,500 API changes.
Since there are upward of 100 new features in iPhone OS 4, I’m only going to outline the most important ones. These were also identified by Apple in its initial introduction of the new operation system, as part of the so-called seven “tentpole” features. Having worked with iOS 4, I can safely inform you that these really are the ones to focus on when familiarizing yourself with the new operating system.
iOS 4 is not compatible with first-generation iPhone and iPod touch devices. Certain features, such as multitasking, will only work with the latest devices, including the third-generation iPod touch and iPhone 3GS, which, as you may recall, share the same processor and memory specifications.
The inability to multitask on Apple’s touch devices has probably been the biggest criticism of the operating system from both developers and consumers. Apple introduced its version of multitasking as part of iOS 4.
I’m going to editorialize for a moment on the topic of multitasking and relate that back to Apple’s approach. Although it’s less true for the iPad because of its larger display, for the iPhone, iPod touch, and more generally mobile devices, multitasking carries a different importance compared to traditional computers. Unlike with their predecessors, mobile devices have considerably smaller screens and are exceptionally more portable. People use them to perform discrete tasks, whether they are functional or fun, and quickly move on to some other activity.
There are few cases in which this does not hold true. This includes when several related tasks must occur together or when a task is ongoing. Prior to iOS 4, Apple actually addressed these issues for its own apps. You probably don’t realize this, but apps such as Mail and the iPod always ran in the background pre-iOS 4. This was most evident with the iPod app because you could listen to music, for example, while also using other apps. So, what Apple did for multitasking in iOS 4 is essentially allow third-party apps to also take advantage of these functions.
Multitasking allows third-party apps to run in the background, meaning the apps continue to work even though they are not shown on the screen. Running in the background is especially useful for audio (e.g., playing an audiobook), VoIP (e.g., talking with someone on Skype), and navigation apps (e.g., getting directions to a location). Consumers can access these apps, and more generally, work across several apps simultaneously through Apple’s fast app switching, which reveals a taskbar of all running apps when you double-click the Home button (see Figure 2-4). Although it’s debatable whether this implementation captures common expectations of true multitasking, I would argue that Apple has addressed the core of multitasking and appropriately redefined it for mobile devices.
Included under the multitasking umbrella are task completion (e.g., download a file and inform the user when the download is complete) and local notifications. Local notifications are similar to push notifications but are triggered at specific times and remove the requirement to communicate with a server. Consider, for example, scheduling a reminder for taking medication or for watching a TV show.
Of course, there are some technical requirements to implementing the new multitasking features. During Apple’s iOS 4 announcement, Pandora founder Tim Westergren came on stage and stated that his team fully integrated the multitasking capabilities within a day and his app heavily leverages the background function.
Games are much more fun when played with other people. Apple helped facilitate that through peer-to-peer Bluetooth connectivity, but the capability was limited in many ways, including the fact that all players needed to physically be in the same room. Thus, game networks sprouted, which allow consumers to not only find and play against other players, but also have their profiles, stats, and other related information saved. This information is then accessible across any game that is part of the network. OpenFeint (http://openfeint.com), ngmoco’s Plus+ (http://plusplus.com), and Scoreloop (http://www.scoreloop.com/) are some of the most popular game networks.
A big announcement, as part of iOS 4, was Apple’s unveiling of Game Center, the company’s new game network. Game Center effectively offers the same functionality of the aforementioned game networks. This comes at some cost to the existing game networks since they invested so heavily into this infrastructure. At the same time, some of them have embraced Apple’s entrance into this arena, stating that they will begin shifting focus to new areas.
For you, the major benefit of Game Center over other options is that it will streamline your access to these social gaming features. In other words, you won’t necessarily have to explore the third-party options. At least in the short term, however, the existing game networks have a much larger adoption than Game Center, so you shouldn’t automatically dismiss them.
In the long run, for developers, the iAd Network has the potential to be the biggest part of the iOS 4 release. This relates back to the bias I described in the preceding chapter, which is that for the majority of developers, advertising as a way to monetize a free app is largely not viable. Apple has suggested the purpose of iAd is to change that, by creating mobile advertising that is both more emotionally engaging and more interactive than other options.
Part of Apple’s advantages over other mobile advertising platforms is that it is able to more fully leverage device capabilities and knows more consumers than third-party advertisers. At a more basic level, iAds ensure that consumers always remain in an app, which Apple believes encourages more people to explore the app. That, in combination with Apple’s revenue model, which includes charging one price to the advertiser for the ad being served and another for the iAd being tapped, already increases the number of opportunities for a developer to make money. And the likelihood of consumers actually choosing to tap on an iAd increases since Apple leverages its iTunes download history to serve the most relevant ad. This tactic is commonly referred to as behavioral targeting and other advertising platforms use it too, but they don’t necessarily have the same depth of information that Apple does.
As mentioned earlier, a lot is going on behind the scenes in iOS 4. Therefore, ensure that your developer takes advantage of the new tools that help automate testing (UIAutomation Instrument) and that provide better performance and power analysis of your application (Time Profiler and Energy Diagnostics Instruments).
You’ve been focused on gathering information about your app landscape and app idea, as well as learning about Apple’s devices and new operating system. Consider these to be some of the raw inputs required to build a fully functional app. Now you need to synthesize these inputs so that you can form an initial set of assumptions about your app.
Creating these assumptions will help communicate how you are trying to make your app a different and compelling offering in the App Store. That is, you’ll have a set of benefits your app proposes to customers compared to other options they have available. Being able to articulate these differences will allow you to incorporate outside perspectives, which will help you validate the assumptions you have about your app.
Being passionate about your app is an important part of launching it into the App Store. I can guarantee you that there are going to be moments where you question what you are doing, you wonder why you are spending nights and weekends in front of a computer while others are relaxing, or you are frustrated that the development of your app is not going according to plan. Above all else, your passion and commitment to your idea will keep you going through these moments. And because you actually quantified your app, you will have some sense of the actual rewards possible, which will motivate you to stick with what you are doing.
More relevant to the current discussion is that being passionate about your idea likely equates to you also being knowledgeable about the market or industry where your app is relevant. You have been further expanding that knowledge and should continue to do so for the life of any app you build, but you probably have some sort of starting point. That’s a huge advantage, because solving a problem or filling a void in a market that you are intimately familiar with is one of the best ways to lead you down a path where you create something useful and compelling. In short, build an app to solve the problems you experience firsthand.
Of course, passion can trip you up by making you think that your way to meet needs and solve problems in the form of your app is the way to do it. Few companies and businesses have the right to think that way—Apple is one of them. For you, proceeding with that perspective alone can cause you to squander a potentially great opportunity in the App Store market.
If you abide by the strategic framework that follows and the customer-driven mindset that I’ll begin outlining more heavily in Chapter 3, you’ll have the proper balance of validated innovation. On the one hand, you’ll be Apple-like in that you will seek to be market-disrupting. On the other hand, you’ll also include customer perspectives to validate the strong set of assumptions you’ve developed about your app before actually building it. This means your customers will have seen your app before it appears on the App Store. This approach marries these two somewhat contrasting schools of thought: promoting bold innovation while reducing the possibility of your assumptions being dramatically wrong.
It would be easy yet wrong for me to simply write that you should make your app “unique.” I don’t think anyone launches an app into the App Store because she thinks it will be boring or uninteresting. So, requesting that you make your app “unique” is simply not helpful.
At the core of uniqueness lies the concept of innovation. To become unique, one must alter or change the essence of what exists—innovate—to bring something new and exciting to the market. As you can imagine, this subject is comprehensive, and entire books have been written about it, some of which, ironically, aren’t particularly innovative. Blue Ocean Strategy: How to Create Uncontested Market Space and Make the Competition Irrelevant by W. Chan Kim and Renée Mauborgne (Harvard Business Press), however, has fundamentally shifted my approach to building products (and not just “apps”) for the past five years. I’m going to highlight some of what has been most relevant to me and offer it as a more strategic approach to discovering the opportunity for your app.
Competitive markets, being innovative, and related subjects have been researched, analyzed, discussed, and written about for decades. Admittedly, people much smarter than I am have thought more extensively about these topics. With that in mind, consider what I’m about to lay out for you to be a sampling of the core aspects of what you need to keep moving forward with your app idea. So, although Blue Ocean Strategy is a great addition to your bookshelf, you don’t need to read all of it before you can proceed with the process of creating your app.
The core lesson of Blue Ocean Strategy is to move out of the “red ocean” of competition and into the “blue ocean” of uncontested market space. That might seem intuitive, but the reality is that most businesses—and in the context of our subject, app developers—wind up taking on competition directly by only marginally improving the existing features of an app. The result is twofold:
Developers wind up fighting over the same customers.
Price becomes a primary means for customers to distinguish among apps.
The second point is part of what caused the so-called “race to the bottom” in App Store prices. That is, in a competitive App Store, when there is little to differentiate an app, developers turn to lowering price as a means to win customers. A price war can ensue until prices can go no lower than the $0.99 minimum. The outcome is good for customers but bad for developers.
Of course, the solution to not getting caught in that cycle is to not enter it. The Blue Ocean Strategy authors emphasize that “the only way to beat the competition is to stop trying to beat the competition.” To do that, your mindset needs to change from focusing on existing demand to demand generation, from customers to noncustomers, and from competitors to alternatives. Ultimately, you are not looking to win existing markets, but to make competitors irrelevant by moving into uncontested market space in the App Store.
Moving your app into a blue ocean starts with the concept of value innovation. Unlike a value proposition, which focuses on benefits for customers only, value innovation considers actions that positively affect both you and your customers.
You can generate value innovation by raising features customers like, creating ones they’ve never seen, and reducing or eliminating ones that don’t really matter to them. Reducing or eliminating features is what will benefit you, because this will lower the cost of bringing your app to the App Store. That may mean, for example, that pricing your app lower than competitors’ actually won’t impact your bottom line. Unlike them, you will operate at a lower cost structure, saving time by not developing expensive but inconsequential features.
Part of the reason I asked you to begin familiarizing yourself with the apps in your market in Chapter 1 is so that you can construct your strategy canvas. A strategy canvas is a visualization that does two things:
It maps out the features currently offered by competitors’ apps.
It will soon help you identify the areas to innovate.
Think about a strategy canvas as being a simple graph, with features (competing factors) for existing apps listed horizontally and the amount of investment in each feature by a competitor rated on the vertical axis from low to high (offering level). By rating the investment into each feature for each comparable app in your app landscape, you’ll be mapping out the value curve. The value curve is a representation of how an app performs across the key features of the app landscape. See Figure 2-5.
Remember that your goal is to move from a competitive to an uncontested market. In its current form, the value curve you constructed on your strategy canvas focuses only on the features relevant to the current app landscape. It may not be instinctual, but to create a blue ocean, you’ll need to shift focus, “from competitors to alternatives, and from customers to noncustomers...in order to gain insight into how to redefine the problem [your app] focuses on and thereby reconstruct [customer] value elements.”
The Blue Ocean Strategy authors spend considerable time building the case for this idea and defining “alternatives” and “noncustomers.” To more quickly communicate this idea, it’s easiest to understand this unconventional concept through an illustration. I’ll point to the extremely successful application developer Smule. Smule has produced such apps as Magic Piano and I Am T-Pain (see an interview with Smule co-founder and CEO, Jeff Smith, at the end of this chapter).
One example of why Smule exhibited blue ocean strategies is that its first app was the 19th virtual lighter on the App Store, yet it quickly rose to the #1 position on most App Stores around the world. Unlike developers of existing lighters, Smule recognized that lighters in and of themselves catered to only a small population of customers. Smule’s innovations included creating a social and musical component, which it calls “expressive audio.” Its Sonic Lighter iPhone app had the ability to “ignite” other flames on iPhones around the world, which could be seen within the app on its now-famous globe view. The flames could also be controlled via the built-in microphone of the device (know those device features!).
Smule’s leveraging of the social aspects found in other alternative apps, typically games, and creating this “expressive audio” helped the company move away from focusing solely on the existing competing features of similar apps. Instead of just developing a more visually appealing lighter, it redefined the value elements of why people wanted an app like a lighter. By doing so, it significantly broadened the appeal of the app to noncustomers, which is a large part of what pushed the app quickly up the App Store charts.
One last note on “alternatives”: while you are developing an app, it can be helpful to think about your app landscape, including alternatives available, outside the App Store. This could include websites, desktop software, or even nondigital solutions.
Analyzing alternatives and noncustomers will allow you to add new competing factors on the bottom of your strategy canvas. For example, Smule’s strategy canvas (see Figure 2-6) could have started with items such as price, ignition, brightness, flame type, and sound. As part of its expanded understanding of the market, it could have included social sharing and expressive audio.
The goal in adding these factors of competition is that you will be defining a new value curve—but this one will be for your app. For that to occur, you will leverage the Four Actions Framework, which includes four key questions (edited to be app-focused):
Which features taken for granted in the app landscape should be eliminated?
Which features should be reduced well below other features in the app landscape standard?
Which features should be raised well above other features in the app landscape standard?
Which features should be created that the app landscape has never offered?
If you recall, your value innovation benefits both you and your customers. The main value for you is to lower your cost structure in two ways:
By not building features that are assumed to be useful or important but actually aren’t
By not building features where existing apps appear to be highly competitive
In the second case, the Blue Ocean Strategy authors note that trying to win on those factors will “overserve customers, increasing...cost structure for no gain.”
The first two questions of the Four Actions Framework deal with the situations in the paragraph immediately preceding this one. The second two already surfaced in what Smule uncovered: that is, how to raise customer value and create new demand. Combining the answers to these questions, you will be able to plot a new value curve for your app by considering how to eliminate and reduce certain features, raising others, and creating new features from your assessment of alternatives. The result should be identification of an uncontested market space through a distinct value curve.
If you are having trouble grasping the ideas in Blue Ocean Strategy, let me describe it more succinctly.
You are forming a set of assumptions about what’s important to your customers by analyzing the app landscape. The initial competing factors for your strategy canvas represent the features in the existing apps and other solutions that help solve your customers’ problems today. Assessing complementary or alternative solutions and thinking about noncustomers will broaden your perspective. You’ll then be able to develop a set of ideas (i.e., the assumptions about your app) that will not only better serve customers, but also transition you to the “blue ocean” of uncontested markets.
Some of these concepts may have formalized the way you thought about your app landscape and how to make your app unique. Being dogmatic about using these tools is less important than applying this lens to your app. For example, even if you don’t create a strategy canvas, be sure you understand the competing factors for your app landscape and recognize that focusing on existing customers and competitors alone will keep you swimming in the “red oceans” of the highly competitive App Store.
Understanding the factors of competition for your app landscape and the value curve for your app is a crucial aspect of defining the assumptions about your app. However, you should not get lost in the formality of the framework. Just because you are thinking about your app in a structured manner doesn’t mean you should forget the very human aspects of the app development process.
You previously saw how touch transformed Apple devices and how this and the social element of Smule’s Sonic Lighter were game-changing additions. You need to recognize that your customers are people. Beyond offering the right set of features to them, you need to realize that they like to have fun and to laugh, they are engaged by content, they are enticed by attractive visualizations, and they like it when things are easy to use and work properly. I will address some of these points as I guide you through the process of building your app. For now, I want you to remember two things:
Your customers are emotional beings called humans.
Even the right set of features or assumptions alone won’t make your app successful; you’ll also need to properly execute (i.e., design and develop) them.
Position: CEO and co-founder
Background: Smule is a leading application developer focused on interactive audio media, producing such mega hits as the apps Sonic Lighter, Ocarina, I Am T-Pain, Glee, and Magic Piano.
Ken: When did you first come up with the vision for Smule? Did you know right from the start that you wanted to focus on a particular genre of apps and consumers or did that evolve over time?
Jeff: The company’s cofounder, Ge Wang, and I believed it was time to redefine what music meant, and that a commercial platform could substantially amplify some of the research in computer music at Stanford and Princeton. Music is inherently a social experience. There are opportunities now afforded by amazing new platforms such as the iPhone to explore the creative and expressive side of people, in the process forging new social experiences. Having said as much, our initial focus was to not focus and instead to experiment. We lacked conviction on whether our vision would be appealing to the masses. We also had several theories we wanted to test in the process. Yet the heart and soul of the company from inception is the exploration of a new social medium through expressive audio.
Ken: Discuss the first app Smule ever created. What were the biggest challenges and lessons learned from that experience? What are you doing differently now after having launched seven apps?
Jeff: Our first application was Sonic Lighter, the 19th virtual cigarette lighter in the App Store and one of the few paid lighters. Miraculously, Sonic Lighter catapulted to the #1 position in nearly every major App Store geographic market. I think people were fascinated with the ability of one iPhone to ignite another iPhone, in our case sending network instructions over sound via the built-in speaker and microphone. I also think people loved the globe view, now famous in our apps, where you could track actual ignitions of others across the world. It seemed there was some solace offered to people to see others igniting their flames. For a while, Paris dominated in kilojoules burned per day, but alas, Tokyo unseated Paris a few weeks later.
Ken: Looking across Smule’s suite of apps, including I Am T-Pain, Leaf Trombone, and Ocarina, you seem to have a recipe for success. Without revealing any Smule secrets, how have you built so many successful apps? Is there something in your process that helps you ensure there’s demand or interest for an idea you have?
Jeff: We found that our belief in the creativity of our users has been a winning formula. If we set the conditions right and give them a little nudge, it’s amazing what our users can do with our products. I think people are exploring music and exploring how they might express themselves, be it singing “I’m In Luv (Wit a Stripper)” along with T-Pain, or simply igniting their flame in the Quartier Latin. If people actually want to use our products and share that experience with others, then we have a winner.
Ken: When it comes to incorporating external perspectives (e.g., users or advisers) into developing an iPhone app, what is your advice to new iPhone app developers that don’t have something like the Smule brand behind them? That is, where did Smule start with finding these groups before there was a “Smule,” and how can new developers do the same?
Jeff: Well, we think a lot about how users are going to find us, and how they are going to find each other. If you are considering these issues after you’ve built your product, you are too late. If, instead, you are thinking about this before you write a line of code, then I think you have a good shot at truly empathizing with your users and exploring what experiences they might develop with the products. We also test this with actual users. In fact, this past winter, we were three months into a project we terminated after the feedback of the first user test. We probably ate $500,000 of development and art costs. [That was] not an easy decision, and thank goodness we had an understanding from our board of directors. But unless we believe we have a compelling experience, we don’t want to put our name on it.
Ken: Describe how Smule determines when an app has enough features to be ready to launch into (or be updated in) the App Store. How do you ensure that you don’t spend time building features that won’t help you sell more apps?
Jeff: We try to identify the most compelling use cases out of the gate, and...as soon as we can test these, we do. We then study our analytics data for all applications in a postmortem of sorts, constructing what we call a usage waterfall. This table of graphs helps us compare our hypothesis at launch to actual usage data. From this, we can take some of the learning and apply it to future products. For example, we were astonished to learn that our users of the Leaf Trombone cared little for the achievements, [and] instead simply wanted to go judge others on the world stage. We could have saved about a month of development time if we knew this in advance!
Background: Sophiestication Software is a small software design and development company, which is run by Sophia Teutschler, who describes herself as one of those “rare female developers.”
Ken: Your app, Articles, entered a category that already had other solidified Wikipedia companion apps. Despite that, not only did you proceed with launching Articles, but you were able to do so with incredible success. How did you identify the opportunity that there was space for another Wikipedia app?
Sophia: When I’m brainstorming new app ideas I always start with the question “What do I miss on my iPhone?”
The idea for a dedicated Wikipedia reader dates way back to early 2008, when I collected the first ideas for iPhone apps I wanted to make. A shopping list, a package tracker, a tip calculator, a Twitter client, a wiki app...nothing really groundbreaking was on my “want list.” Yet these were all apps that everyone would want to use.
I successfully implemented the ideas for the shopping list and the tip calculator. Over time, I lost the desire to implement some of the other app ideas, like the Twitter client and package tracker. I use great apps by other fellow developers now.
However, I never found a good solution for Wikipedia on the iPhone. Everything that was available was mediocre at best. I make apps, so the decision to fix the situation was crystal-clear to me.
Ken: What were some of the shortcomings you saw with other Wikipedia app options? What aspects did you want to improve or focus on less with Articles?
Sophia: Without any exception, it’s always the UI that bugs me with other apps. I’m not talking about the looks, but about the app’s behavior and interaction with the user.
There are many examples of how to improve a UI for use on the iPhone. One particular case for Articles is how it presents images. On Wikipedia, you usually tap on an image to open its dedicated page. There you are presented with an enormous amount of metadata you don’t really care about. The image itself, however, is still displayed in a rather small resolution. So, you have to tap on a thumbnail again to finally see it in full size. Yet it’s still presented with a bright white background and the blue Safari toolbars...sigh.
On Articles, tapping on an image simply zooms into the photo in full-screen mode. That’s the kind of simplified user experience I’m targeting.
Ken: Articles has a great app icon, a very polished design, and an intuitive user experience. Was this part of what you thought would make your app better? In general, what is your perspective and philosophy about designing iPhone apps?
Sophia: Making apps is my job, and my only job. This is what I’m doing all day long. I don’t want to waste my life doing something mediocre. I want to be proud of what I make and feel the joy when hard work finally pays out.
Some people paint pictures, others form sculptures. I make apps.
Ken: Articles exists on the iPhone and iPad. Discuss your considerations and concerns in developing the iPad versus the iPhone version. In your case, was creating the iPad app more of a design or development task?
Sophia: The iPad was not even announced when I started developing Articles. I hoped for a device like this, but it was far too early to tell how it could turn out.
Creating the iPad app was definitely a design and a development task. Finding a great design and coding up the necessary changes was a considerable job, but mainly due to the time constraints I had in order to hit the submission deadline to be in the iPad App Store on day one. Being there on day one is a chance you only get once in your life!
Articles is sold as two separate versions for the iPhone and iPad. Releasing the app as a Universal binary was, sadly, not possible in this case since I had to make use of iOS 3.2-specific features. So, I had to test it on an iPhone running OS 3.2, which was only available for the iPad at that time. Apple basically made the decision [of whether] I should go Universal or not with Articles for me.
Ken: How early do you include your customers in getting validation of and feedback for your apps? Do you show them nonfunctional concepts or only present them with a working app when it’s ready? How long before Articles went into the App Store had people been using the app?
Sophia: I usually start off by showing several early mockups to family and friends. I try to explain what I want to do, how this and that should work, and why it would be better compared to a solution that might already be available.
During development, I widen the audience with other fellow developers and app experts. I usually end up with about 50 people testing the app toward the end of the final development cycles. Developing Articles took rather long. A handful of people already had pre-release versions of the app back in July 2009. This feedback helped a lot for me to understand how people, besides me, use Wikipedia on their iPhones, and therefore helped to shape the UI to its final shape.
The first beta versions went out to testers about a month before the app finally hit the App Store. The app was pretty much usable at that stage.
Ken: Putting bugs aside, what is the key feedback you receive from those who look at or test your app? How does that impact what goes into the initial version you submit into the App Store?
Sophia: The key feedback is definitely about how each person uses the app and the iPhone in general. Some people love typing with the keypad in landscape mode; others solely keep it in their hand and navigate with their thumb. It might not sound important at first, but things like these help me to find the ideal UI for the majority of customers. Though it might be worthwhile to mention that I never intend to please every single one. That’s simply impossible.
Here’s what you learned in this chapter:
Apple’s unique approach to its devices—including offering a larger keyboard-less display with Multi-Touch capabilities—fundamentally altered the marketplace.
Although there are device-related features, the iOS provides a number of common frameworks and features that are available across devices. Knowing both the common elements and the device-related features is key to building your app.
iOS 4 brings a tremendous number of changes “under the hood,” but many of those changes have the largest impacts on consumers. Multitasking and the iAd are the most significant consumer-facing changes.
It’s not enough to want to create a unique app. Using the strategic framework in Blue Ocean Strategy will guide you through understanding the competing factors for your app landscape and help you identify a distinct value curve for how to innovate in the App Store.
Defining the assumptions of your app by using the tools and frameworks available in Blue Ocean Strategy represents one aspect of building a successful app. You’ll also need to properly execute those ideas once customers have validated that they are indeed correct.