Pillars of a Mobile Strategy

In this chapter:

• What Does “Going Mobile” Mean?

• Outlining a B2C Strategy

• Outlining a B2B Strategy

• Summary

The modern era of mobile technology began with the release of the first Apple iPhone in the summer of 2007.

The mobile conquest of the world has been a “soon-to-be” matter for quite some time in the past decade. I still remember the first-ever mobile-related conference being held in Amsterdam in the summer of 2000—the Wrox Wireless Developer Conference. I was a speaker there, and the implicit message for attendees was “Mobile development is here—hurry up.”

There was no hurry, actually.

Only a couple of years later, Microsoft released ASP.NET with its own set of mobile controls for optimized mobile websites. Later, mobile frameworks such as Microsoft .NET Compact Framework and Java Micro Edition (J2ME) appeared; meanwhile, richer native operating systems such as Symbian also appeared. However, the mobile conquest of the world never happened—and perhaps hadn’t even begun—which begs the question: Why not?

The main reason is that the technology never reached a critical mass of users, and without that, developers and software houses had no good reason to address the mobile space. But when the Apple iPhone appeared, everything changed. Although the iPhone was not an entirely new idea, it was an extremely well-done implementation. And, more importantly, a lot of people (on the order of millions) liked it. That immediately created a breeding ground for new applications and gave mobile technology a new form and immediacy.

The lesson to learn from this is that software is the effect (not the cause) of the mobile phenomenon. People buy devices long before they have much compatible software to run on them. Therefore, a compelling device, bought by a critical mass of users, creates a compelling market for specific software over time.

Today, there are a few popular mobile operating systems and a growing number of users willing to pay to get nice applications to run on them. The popularity and convenience of mobile devices drives companies to create their own mobile applications that can reach their customers while they’re traveling. Mobile sites are still an excellent way to do that, but whether companies build mobile sites or mobile applications targeted to a particular platform (today, that would include iPhone, Android, BlackBerry, and Windows Phone), companies need to be part of the mobile revolution in much the same way they became part of the web revolution a decade ago.

What Does “Going Mobile” Mean?

This book is aimed at architects and developers who are willing (or need) to implement mobile solutions for customers. A solution, however, is not necessarily and not simply a mobile application. Today, and even more in the near future, a mobile solution will be created as a combination of a classic website for desktop browsers, a website specifically designed for classes of mobile devices (known as an “m-site”) and one or more applications for specific mobile operating systems.

The definition of a mobile solution is not carved in stone, for two excellent reasons. First, the mobile industry never sleeps; it churns out requirements and opportunities at an impressive pace, so any current definition of a mobile solution may change to incorporate new aspects in a matter of just one or two years. Second, a mobile solution applies to a particular business scenario. The business scenario ultimately determines the details of the solution and technologies, patterns, and platforms that architects and developers will deal with. As an example, you may need to add some Facebook applets or multiplatform desktop applications if the business has social networking implications. Similarly, you might restrict the range of mobile platforms to just one if you’re building a vertical enterprise-class solution for a single customer.

As I see things, going mobile is a far more serious task than simply writing an iPhone application. Companies investing in mobile need a strategy long before they need a mobile site or a set of mobile applications. This means companies must establish goals as well as review processes for achieving those goals—simply put, they must have a strategy.

To paraphrase the quote from Dwight Eisenhower at the beginning of this chapter, in mobile development, plans are useless, but planning is indispensable.

Toward a Mobile Strategy

So the first step for a company “going mobile” is to define a strategic plan. The strategic plan is more conceptual than it is an operational plan with comprehensive implementation details. The strategic plan is visionary; it identifies the future direction of the business. Outlining a mobile strategy essentially consists of reviewing the current business processes with regard to a few mobile axioms.

Three Mobile Axioms

Gone are the days in which a website optimized for a bunch of desktop browsers was the only way for a company to deliver an application. Today, there’s a growing demand for applications that users can reach from a variety of platforms and browsers. In the past, software architects once reached for the Holy Grail of multiplatform development—and we failed to grasp it. Now, as users increasingly demand multiplatform applications, failure is simply not an option.

Mobile axioms are statements about mobile applications that are self-evident and assumed to be true. You should have these concepts clear in your mind before you start planning your strategy:

• Provide your services through multiple channels.

• Look for new opportunities and new ways to provide your services.

• Aim at making your customers’ lives easier.

Like the web a decade ago, mobile is about new ways of doing both a selection of old tasks and entirely new actions. Mobile is highly attractive to users because they can get the services they need in a variety of ways and using a variety of devices. As a company, “going mobile” means being committed to making your customers’ lives easier through ad hoc and personal services.

The fundamental point, however, is that this challenge is not limited to just a few segments of the industry; it’s a global challenge.

Multiple Channels

As you can guess, going mobile likely involves significant investments on your side to restructure existing processes, implement new ones, and fix—or at least extend—a portion of your back end software.

Delivering services to a variety of channels is challenging. Mobile channels (tablets, devices, or mobile sites) are more personal and typically involve smaller amounts of information. Your existing back end must be able to serve these new requests effectively while preserving both scalability and performance, and while still ensuring at least the same level of security.

A good example of an application delivered through multiple channels is Facebook; other examples are airline booking and home banking services.

New Ways to Provide Services

Mobile is both about bringing existing services to people’s fingertips and about creating brand-new services. A mobile device is a personal device, so everything that shows up there is potentially “at your fingertips.” The real estate of a mobile device is considerably smaller than a laptop, but most applications and websites are padded with extra information (including menus and layout) that is not necessarily required. The advantage of a mobile solution in this context is that it can provide exactly what’s needed whenever the user needs it—instantly.

A mobile user is typically traveling around. Your application may query the user’s current location and use that information to offer new, unique, and tailor-made services. Location-aware services are really at the heart of the extra power of mobile applications. This is not so much because a desktop site is unable to detect the user’s location, but because a site can use the location details in much more compelling and useful ways when the user is out of the office. This is definitely an area to explore if your business is in any way related to location.

As an example, an application that provides information about transportation can use your location data to restrict search or sort results automatically, winnowing out nonessential data for other locations. The same concept applies to mass retail applications, which might notify users of special offers when they are close to a shop, or provide them with free coupons in a nearby shop that they can reach within a few minutes.

Simplify Customers’ Lives

I see more and more companies from a variety of industry segments strongly committed to making their customers’ lives easier and better. I believe that is a key challenge for attracting new customers and keeping existing ones. On the other hand, by not going mobile, you risk alienating customers from your brand.

As mentioned earlier, mobile applications are more personal than desktop applications. They’re often relatively simpler in terms of logic and complexity, and they often consume smaller amounts of information. That’s precisely what makes a customer’s life simpler—the application is more focused; ideally, it can handle more related information aggregated from multiple remote sources. Basically, an effective mobile application should be able to give users what they need at any particular moment.

Architecting the system around these new needs is the effort that companies should invest in. It’s not simply a matter of software architecture, though. Architects may be able to tell the best way of realizing an idea, but they can hardly identify what makes your users happier. In general, an appropriate analysis and prioritization of use-cases selects the range of features that—once implemented—put more information at the user’s fingertips and make life easier.

Mobility and the Industry

According to a Gartner report presented in the spring of 2010, mobility occupies a relevant position in the list of top priorities for chief information officers (CIOs) of various industry sectors through 2013. According to this report, transportation and retail are the industry sectors that are paying the most attention to mobility.

In these sectors, there’s a strong sentiment that it is an “either now or never” matter; there’s less and less space left for companies that hesitate or just skip going mobile. The mobile space is open for business (for now) and companies need to establish their presence as soon as possible. If they don’t, others will fill the gap and become your toughest competitors.

Also, according to Gartner, beyond transportation and retail, other sectors interested in mobility are healthcare, utilities, education, and—guess what—software publishers. Media and financial services are also there, lower on the list.

The trend that Gartner excerpts from CIOs’ priorities may be different from country to country; however, past history shows that a general trend is always a trend that applies worldwide (though at a different pace in various locations).

I can contribute my direct experience in Italy, where most leading mass retail companies are only now experiencing what many experts call the first stage of mobility—merely establishing a static presence. Typically, this process is initiated via nearly functionless mobile sites that go hand in hand with existing primary desktop sites. The next step usually involves adding a bit of context through proactive alerts, and advertising based on location, identity, or perhaps barcode recognition. Finally, the third level of mobility awareness concentrates on providing all-round services at users’ fingertips.

Defining a Mobile Strategy

Each business has its own mission, expressed as purposes and activities. A mobile strategy revisits and extends these purposes and activities in light of new devices and a new lifestyle. The mobile axioms should just inspire a realistic vision for the mobile business.

If this scares you, don’t worry: it’s nothing new—in fact, you’ve been there already, a decade ago. Although different in features and results, the mobile revolution follows the same pattern that the web revolution did. Early adopters content themselves with just being there and show customers they’re online. Then, executives start developing a new vision of the business and architects actually build it. It’s not a waterfall-like process; actually, it has a lot of inherent agility and looks like an intertwined process. In the end, every company ends up with what the management envisioned in their future—good and bad.

What Do You Want to Achieve?

Personally, I think that for most companies, embarking on mobile projects is not a choice related to gaining an immediate profit. Of course, that mostly depends on the type and size of company. If your business is selling ringtones, then naturally you expect profits from your mobile software right away. However, if your business is selling news, you might want to use mobile channels to make your readers’ lives easier, so long as you can add such services at a reasonable cost to you. With the all-free model becoming less affordable every day, going mobile and attracting readers with mobile device capabilities is an immediate expense that hopefully will help achieve better results in the medium term or in the long run.

With a strategy defined in terms of expectations and requirements (covering growth, profitability, and markets), you can look at your overall mobile technology strategy. All in all, there are two (not mutually exclusive) possible expectations: reaching the largest possible audience and improving the experiences of existing customers by building a rich, jaw-dropping application. Implementing each scenario may require a different set of concrete technologies, languages, and platforms. And each scenario may have different costs.

Reach Out to Users

You reach mobile users by making your application available on the devices they use. This apparently obvious, no-brainer statement hides all the complexity (and costs) of mobile development. Take a closer look at this statement, though, and you’ll find two huge questions whose actual implementation determines the actual level of complexity (and costs) of reaching out to users:

• Which devices are your customers using?

• How do you make your application available on all of them?

Before you can answer those questions, you need to think about this: What’s a mobile device, anyway?

According to one widely accepted definition, a mobile device is one that you might have with you at any time, can be used more or less instantly, is a personal item, and can be used to connect to a network. A laptop, for example, seems to match most of these requirements—except that you are hardly likely to take it with you when you go out for a walk or buy groceries—and laptops don’t usually start instantly. Cell phones mostly fall into the category of mobile devices (many cell phones have at least some browsing capabilities). Finally, smartphones and tablets match all the definitional requirements.

A mobile strategy also depends on the level of control you can exercise over the devices your users have. For example, if in your context, user means “employee,” then the company can decide to support just one mobile platform and focus development on that. If you think that user means “consumer,” however, then reaching out to a large audience usually means developing multiple similar applications for various devices. The same applies to scenarios where user means “employee,” but the company is giving its employees the option to use the device of their choice.

Deciding how to approach the technology is a delicate and critical point of a mobile strategy that I’ll address in more detail in the section Outlining a B2C Strategy later in this chapter.

Offer Rich Applications

If you know that a significant share of your users connect to your site using a particular mobile device, or if the content you’re offering can best be consumed on specific popular devices, then your mobile strategy should include the development of an ad hoc application optimized for that device. You don’t have to target each possible family of devices; instead, you can establish priorities and add new applications progressively.

Suppose that you own a radio station. You want to increase your audience so you can sell more ad slots. Most radio listeners are faithful, so despite the switch to mobile, they may well still be listening to their favorite radio station while out and about. They might be listening via radio-equipped MP3 players, original equipment manufacturer (OEM)–applications using the embedded radio system of a mobile phone, or Internet-based free radio programs. In all cases, users can listen, but they can’t interact and increase your site traffic. But if you can develop a specific mobile application and let listeners interact with your back-end systems via the web, consume streamed live music, access podcasts, traffic reports, news, submit feedback, blog, and more, you can gain interactivity and increase user participation.

Should you address all the major mobile platforms at the same time? That mostly depends on both your budget and management’s expectations. One common pattern is to build an iPhone application first, and then follow that up with an Android or iPad application. At a radio station, to continue with the example, a tablet device such as the iPad may add little extra value compared to an iPhone. So the second step in your strategy probably would be to develop an Android application, letting iPhone and iPad users share the same application.

I’ll return to this point in a moment and address it more specifically in the next chapter, but keep in mind that mobile applications don’t necessarily mean iPhone or Android applications. A mobile site can be as functionally rich, and it is usually more cost-effective.

B2C and B2B

The full spectrum of mobile applications falls into one of these two categories:

• Business-to-Consumer (B2C)

• Business-to-Business (B2B)

A third label is worth mentioning, though: Consumer-to-Consumer (C2C). Although not terribly relevant at the current stage of the industry, C2C provided the spark for the whole mobile revolution. The mobile revolution we’re experiencing these days would probably have remained on hold for another 10 years without a lot of (initially) independent developers who enthusiastically embraced iPhone and Android programming and built clever applications (regardless of their usefulness). Some of these developers capitalized on the success and exposure of a single application to build a business and help the mobile revolution thrive.

Going B2C or B2B poses different challenges and drives different implementation choices. For example, in a B2C scenario, a key decision is about how to make the application available and get consumers to notice it—whether it’s a free or paid application. In some cases, the question is a no-brainer (the app pretty much has to be free). In other cases, a more sophisticated model that offers a free (but perhaps feature or time-limited) version of the application is offered to entice users to purchase the full-feature paid version. In still others, consumers can select either an ad-supported version or an ad-free paid version.

In contrast, in a B2B scenario, you have a fixed number of users to reach. Here, your focus is on enabling users to return what you expect quickly, effectively, and securely. Security and middleware, in fact, are usually far more important in B2B scenarios.

Development and Costs

Developing mobile applications is neither cheap nor quick. Many companies find this surprising when they approach mobile projects. But mobile development is only apparently similar to web or Windows development; the two have different programming frameworks and often different (and uncommon) programming languages. Furthermore, mobile suffers from the lack of a consolidated set of patterns. Another reason that raises costs for mobile is the need to produce different user interfaces (often both layout and images) for different devices. This has never been a requirement for web or desktop applications. All these factors currently make mobile development significantly more expensive and time-consuming than web development, although time will help alleviate some of these issues.

It is commonly believed that outsourcing development is preferable to having in-house development, largely because in-house development means that you first need to invest in training. It’s one thing to train a team of developers on ASP.NET and then have them build three sites in a row. But it’s quite another to train a team on three different mobile platforms and then have them build the same application three times from scratch—once for each relevant platform you plan to address.

Outsourcing allows you to eliminate in-house training costs and speed up development. In return for this, however, you must pay more for the outside expertise. It’s worth exploring some of the reasons that make mobile development more expensive than many executives think at first.

Targeting Multiple Platforms

The mobile ecosystem is populated by several different platforms, each of which has its own more-or-less unique set of features and capabilities. The most popular platforms today are iPhone, iPad, Android, Windows Phone, and BlackBerry. The list of platforms, however, doesn’t end here. Other platforms that you are likely to encounter or need to consider are Symbian, Windows Mobile, Meego, Bada, QT, and webOS. And when you begin to look at using tablet devices, the range of platforms that you may need to take into account grows even more, because there are tablet-specific variations of the aforementioned platforms, including Android Honeycomb, BlackBerry PlayBook, and the upcoming Windows 8.

Each platform has its own operating system, its own programming application programming interface (API), and its own set of programming guidelines. Often, each mobile platform requires applications be written in a specific programming language, such as Java, Objective-C, C#, or C++.

So does this mean that you must port or develop your application from scratch for each of these platforms?

Frankly, very few applications (e.g., content providers) need to address all these platforms. More typically, applications target a subset of no more than three or four of them. If it is crucial for your business to reach the largest possible audience, even those running on low-end devices, then you might want to look at HTML—specifically HTML5—to build a website optimized for mobile devices (i.e., an m-site). As you’ll see in more detail in the next chapter, m-sites are often the first option that you should consider when targeting multiple platforms is a true business necessity. M-sites, however, are not free of device issues either. In the end, building a mobile site can be considerably more complicated than building a website.

Addressing the Device Fragmentation Issue

If you felt frustrated by desktop browser fragmentation—too many different browsers to optimize webpages for—you have never explored the mobile jungle. Each device—and by device I don’t simply mean smartphones—has its own browser, and each browser has its own user agent string, which changes for each version and operating system update. And, of course, the actual set of capabilities can change for each device as well. The screen size is probably the most important capability to take into account because of real estate and pixel density.

The dimension of the device fragmentation problem is far larger with mobile browsers than with desktop browsers. When it comes to mobile site development, you have thousands of different device models to take into account, not just a few dozen smartphones, often with a pre-fixed set of capabilities. How can you approach such a task?

Writing a set of pages (if not the entire site) on a per-device basis is simply not feasible. The one-size-fits-all approach is viable, but it comes at the cost of leaving a lot of older devices behind and giving up on advanced features that smartphones have. This is typically not good enough for companies whose success depends on online content, such as social networks, or media and news companies. The alternative is multiserving, which basically consists of three points:

• Group devices in classes based on their capabilities

• Build a version of the site for each class of devices that you intend to support

• Define a strategy to serve the right site for each connecting device

That’s easy to say, but how can you determine the capabilities of a given device? How can you know the size of the screen, the operating system, the quality of video codecs, whether the device supports graphic processors or certain HTML features (e.g., file upload and CSS gradients), the availability and accuracy of location services, and even much more specific capabilities, such as image inlining (the ability to display images from page-embedded Base64-encoded strings)?

For some of these capabilities, such as screen size, you can ask the browser itself. In fact, forums are full of questions about how to determine effectively the “real” size of a screen on a particular device and model. For other capabilities, such as image inlining, there’s just no way to make such a query. You just must know it.

About 10 years ago, Luca Passani had the vision of starting a community-driven project aimed at collecting reliable information about the effective behavior of mobile devices. He created the WURFL project, short for “Wireless Universal Resource File.” Today, WURFL is a centralized database that stores detailed information (more than 500 different capabilities) about more than 15,000 mobile devices and mobile browsers. Today, WURFL is managed by ScientiaMobile (http://www.scientiamobile.com) and made available through both commercial and open-source licenses.

Multiserving takes mobile development to a new level of complexity, but this is where WURFL shows its value: WURFL makes multiserving manageable. Multiserving is inherently expensive, but using WURFL can make it considerably less expensive.

I’ll return to the topic of mobile site development in Chapter 4 and cover WURFL features in detail in Chapter 6.

Looking for Best Practices

If you are building a desktop website, you can rely on a number of tutorials, widgets, articles, books, and posts that give you guidance. The same isn’t true for mobile software.

The importance and complexity of mobile site development is not yet perceived in its entirety. Too many developers (and, worse, architects) succumb to the siren call that m-sites are simply standard websites with different Cascading Style Sheets (CSS) and layout.

Turning to native mobile applications, all you can find are official API references, long and staid official guidelines in the form of white papers, and a ton of useful tips and tricks scattered in a variety of question/answer sites (such as StackOverflow). This is largely because mobile applications are relatively new and the entire space is fragmented; very few developers who program for iPhones know (or are interested in) Android or Windows Phone development. Furthermore, the stereotypical iPhone/Android developer considers mobile sites old-fashioned.

The bottom line is that when you are facing mobile development for business (for example, say your boss told you that you have to build an application in just a few weeks), you have no good place to look for common practices. Even when you can figure out most common practices, it’s tough to know whether those common practices are also best practices.

The Marketplace Tax

Finally, development of mobile applications is subject to appstores. Apple made this model popular with i-tools (such as the iPhone, iPod Touch, and iPad); Microsoft took the same route with Windows Phone (and seems to be inclined to forge ahead with it in Windows 8); Google (for Android) and RIM for BlackBerry left their appstores optional for developers.

The role of appstores is crystal clear: they are there to protect users who buy or download applications from an appstore to their devices. The appstore owner guarantees the quality of published applications. For developers, getting approval from the appstore owner requires more effort to ensure the quality of the final product—which is not a bad thing for consumers. For companies, the appstore model means that there’s an extra distribution cost, which I like to call the “marketplace tax.” Companies have to pay to gain the right to distribute even free applications, and for paid applications, they typically have to provide about 30 percent of the app’s revenue to the appstores.