Mobile User Experience: Patterns to Make Sense of it All (2014)

Chapter 8. Mobile App or Mobile Web

The Big Debate

Abstract

A critical discussion in mobile experience design is to decide whether to create a mobile website or mobile app; I call this the BIG debate. The goal of this chapter is to open the conversation about the advantages and disadvantages of each approach. Designers will gain the knowledge to complement these experiences and at the same time to learn the limitations of mobile user experience design. By presenting this argument, I give the mobile user experience designer the ability to have an informed view on both methods. The chapter also covers responsive web design as another choice, with its own advantages and disadvantages.

Keywords

mobile app; mobile website; responsive web design; apps store; monetization; API; HTML 4; user experience; device; debate

Introduction

Choosing to build either an app or a mobile website is one of the biggest debates. Like choosing a political candidate, each opposing side can get verbal, adamant, and emotional about their choice. Everyone you talk to will have an opinion. It might come as a friendly anecdote or as a stern rant; one way or another, you will hear every side from every different angle—if you haven’t already. I was once quoted as saying: “We are in the middle of a love-fest with mobile applications. Every brand feels the need to develop one, believing this is a mobile panacea—the easy route to be relevant, accessible, and cool.”¹

I will present you with advantages and disadvantages of both apps and mobile websites. An overview of each will help you make an informed decision; choosing the one you want to build will be up to you.

The Mobile App

One of the great things about the mobile app is that it created a buzz around the mobile, yet one of the bad things about mobile apps is that it created a buzz around the mobile. On three separate occasions I have had random people say to me, “Have you heard about these things call apps? I hear I can make money selling them….” (To be more precise about from whom I heard this: my mailman, a cab driver, my mortgage broker, and a salesperson at Best Buy.) It felt like each of them was trying to give me a stock tip. You can’t watch your favorite television show, read a magazine, or surf a website without being bombarded with an advertisement about an app: why you should be downloading it, why you need to own it, or why it’s better than another app. Putting the hype aside, let’s look at what building a mobile user experience for an app will mean to you.

Advantages

Built Using Native Code

One of the main advantages is that apps are built using “native code”; this means an app is built in a programming language that smartphones use to run other existing apps and its operating system. For iOS it’s Objective C and for Android it’s Java. As a result, your app gets access to using the processor and memory allocation. What does this mean to you? This means you can use the power of the phone’s processor and memory to run heavy calculations or functionality; for example, use an app to run a 3d game, rendering dynamic pages and running tools that require processing. As apps are installed on a device they do not require a network connection to open. You can read content, play a game, and interact with an app without being connected to the Internet; a plus when flying on a plane or travelling in areas with no signal or low signal strength.

Using Device Specific Features

Aside from using the processor and memory, you can also have easy access to some of the device specific features on smartphones. The app gives you access to the camera, accelerometer, GPS location, camera roll, contacts, and the different keypads/keyboards; all of which you can use when designing your mobile experience. Aside from the UI components, one of the other features you can design for is the use of app notifications. You can use notifications to remind, alarm, or even update your users about news, events, and updates; a great feature when you want to engage more with your user or promote more interaction with the app.

Design for Known Devices (iOS)

One of the features of working with an app Software Development Kit (SDK) is the power to build an app that will work seamlessly with the devices you are familiar with. This comes in the form of native code, but also in the framework for adding in UI features. The iOS SDK gives you placeholders for adding in all the icons, backgrounds, splash screens, and creating a presentation layer for building your app for an iPad app as well. It also gives you access to using their library of UI elements for the iPhone and iPad. This alone is a timesaver, by not requiring you to design a whole new set of UI elements and interactions.

Disadvantages

Design for Unknown Devices (Android)

One of the problems with Android is the wide variety of screen sizes and proportions. This problem grows exponentially when you have to build a native app that has to respond to all possible cases. This process becomes a logistical nightmare as you have to cut graphics and icons for every possible case you encounter. Not only do you have to refactor your UI for these cases, but you also have to test on every different OS version, manufacturer skin/flavor, and device. This is a problem that will consume your time when designing and building your experience. You need to account for this as part of your apps testing strategy; make sure you have also accounted for the time that it will take.

Pay to Play

On iOS you will need to pay a yearly fee to have access to the iOS SDK. Upon your first payment you will be able to download the iOS SDK to start working with software program Xcode. More importantly, you have the ability to build on your actual device and publish to the Apple app store.

On Android, all the necessary software is free and can be downloaded online. It uses the software program, Eclipse for Android development; existing Eclipse users only need to install the Android SDK and they are ready to go. This is a plus as most software developers already have Eclipse installed. Having access to the Google Play store will cost you a small fee for your Google account to have rights to publish on their app store. With this flexibility you can publish different apps from multiple Gmail accounts; not a bad idea if you want to publish app as different brands. Each Gmail account will be charged that small fee. So yes, you will have to pay to Play … no joke.

The App Store

Once you have built your app and tested it, now you have to deal with the app stores themselves. This is a much larger task than it seems.

■ The app approval process on iOS—the dreaded approval process that terrifies children and is the topic of scary campfire stories. … Truthfully, if you design to the human factor guidelines, you will be fine. The scary part is not the approval process, it’s actually the inconsistency of it. Give yourself a month to get your app approved. In most cases, if you push an update after your first release it may get approved faster than your first release. With no guarantee on how long it will take for your app to get approved and no documentation on the process for approval onto the app store you will need to give yourself ample time for this review and approval process (schedule about a month, if not more).

■ The app approval process on Android—well there is NONE. Anyone can post an app; it takes 15 minutes to add a description and some images. Why is this a disadvantage? If anyone can post up an app, then anyone can impersonate you or your company. With no approval or review process it’s the wild, wild west of app distribution. By having this process too open, many malware and viruses have made it into android apps on Google Play posing as legitimate apps.

■ Discoverability—Apple and Google advertise that they have millions of apps on their app store. If you have a game or great app that you want to get noticed, then you are also competing with a few million other people who want to do the same. Trying to raise your discoverability in the app store is considered a black art; no documentation or guidelines exist.

■ Monetization—Want to sell your app for $1? You need know that Apple or Google will take a percentage of your sale, 30% for every dollar you make selling your app. Planning to sell subscriptions, newsstand magazines, or to support an app purchased? The same economics apply.

Mobile Misconceptions for Mobile Apps

1. You will make a pile of money selling apps—In reality, no one will become a millionaire selling apps. Most developers will never make a dime or break even. The mobile app has become the new gold rush of the 21st century. And, like the gold rush, there are booms and busts. Focus on designing an app that fulfills a purpose and need for users, not on the idea of selling it to make a dollar.

2. Making an app is easy—Making an app is building a piece of software. Think of it as that analogy, because it is true. If you are a nontechnical designer, most SDKs will not make sense … remember it’s a complicated piece of interactive software you are building here.

The Mobile Web

The mobile web has long been considered a backup solution for mobile designers. It has long been overshadowed by the mobile app. One of the big reasons was the fact that the first mobile websites looked more like websites from 1995 than a modern-day mobile experience fit for a smartphone. The mobile web has long suffered from competing with sexy slick apps and the technology limitations of html. But, the story of the mobile web is not over yet; its popularity is now increasing with the rise of HTML5 and responsive web design. The next chapter of the mobile web is just starting.

Advantages

Everyone has a Browser

The key advantage of the mobile web is that every smartphone has a browser installed. With the browser there is no need to download, install, or register to an app store. There is no need to create different applications for operating systems; your mobile website will open across all devices, browsers, countries, and operating system versions. By using the browser you can have you mobile website open from other websites, open through a link in an email, and open through a mobile ad.

No Special Code to Build

Building your experience for the mobile web requires no special programs to install or SDK to buy, it is based on the good old html code. It is easy to change and much easier to find someone who can build your experience for you. HTML5 in combination with CSS 3.0 gives us the use of elastic layouts and some new and improved aesthetic features for us to use (transparencies, gradients, drop shadows, and more).

The use of HTML5 also gives us the access to APIs (Application Programming Interface) that allows us to enable a smartphone’s specific feature. We can now call a specific keyboard (i.e., web keyboard, number keyboard, available to iOS, but limited in Android) and the dialer. It also gives us access to load page components or elements into the phone’s local memory. We can use this feature to download heavy page components into the phone’s cache. This gives your user the ability to read content offline and to not have to download your mobile site every time they visit; improving the performance and paving the way for the creation of more elaborate experiences. This new fusion of software and website is referred to as a “web app.” Want to provide geo-location data for your user to use in their web experience? Now you can! You can design your experience around accessing the phone geo-location data and use functions to request the smartphone’s current location as well.

No Need to Push Updates

In the world of apps that require an app review process and an app update, the mobile web is updated when and how you want. Your mobile site is always updated and each user always gets the most recent version. As a result, you can update the mobile web with small changes on a regular basis; compared to an app. This is a huge cost and time saver compared to the time needed to push app updates through the review process.

Monetization is all You

The best thing about the mobile web is that access is free. This allows you to sell subscriptions and access to your paid mobile content without giving a percentage of profits to anyone. This alone has caused some online magazines, like The Financial Times, to switch from apps to mobile websites. By using the feature that saves data to the device’s local cache, this allows their mobile site to download content to the user’s phone from offline reading—the power of a “web app!”

Disadvantages

Redirects are Still a Problem

One of the main problems with the mobile web is defining the redirects from your desktop website to the mobile version. A redirect is a piece of code on your website that allows you to change the flow of traffic and point to a mobile version based on the incoming device’s operating system. Some redirects allow you to use a user-agent string² from the device to make this choice while others use JavaScript to resize the page; both require you to keep constantly updating this method as new devices and screen sizes get introduced. If you want to redirect only iPhone 5 users to a different experience, with the current methods available this will be a difficult task. As you can tell there is a lack of consistent format and method to redirect your traffic to different mobile experiences.

Multiple Mobile Sites

Regardless of the redirect, you will still need to define how many different mobile websites you will need to build and design for. Will you create a m.website for your mobile experience (no standard dictates if it’s a m.website.com or mobile.website.com)? Will you create a site for iPhone and Android separately (iphone.website.com versus android.website.com)? And now add the next level if you want to add a tablet website. Does the tablet redirect to your desktop experience or do you create a t.website? Imagine having to do one change to the UI and then having to replicate that change over and over again on all of these different versions. As you can tell, juggling all of these different versions, user experiences, and code bases creates a logistics nightmare for you.

Not all Mobile only Features are Available as APIs

HTML5 has opened up a whole new world by allowing us to use APIs to connect to the mobile device, but at the same time, new API features have just started to trickle in. While apps are already using device-specific features like the accelerometer, rotating the device, use of the camera, and access to the camera roll for some time, mobile web experiences are still catching up. Even though some of these APIs have been available to the desktop web for some time (geo-location, camera), they do not consistently work across all mobile platforms and browsers. There are amazing features to use in your mobile website, but they require you to do more work in researching their compatibility before designing them into your mobile experience.

Responsive Web Design

Responsive web design has given the mobile web its second wind. It has created a new excitement and helped spark new conversations about designing for the mobile web again. The premise is simple; use HTML5 and CSS to create elastic and flexible layouts for your web design. Using CSS, you can set the sizes and width to scale and shrink web pages. The same website that is your desktop site can become your mobile site and then your tablet site. One code base, an optimized experience for each device size.

Advantages

Say Goodbye to Redirects and Say Hello to Break Points

Responsive web design (RWD) uses what is called “break points”³ to set widths for each screen size. When a browser or device senses the screen width, the RWD page will scale itself to the set width. This allows you to create a smartphone, tablet, desktop, and other experiences using the same web page. The goal is use break points to create a fixed set of widths, start by creating a smartphone and desktop width first; any widths in between are scaled using elastic and flexible page elements. This allows you to scale your web page to create multiple different screen size experiences, letting the browser do all of the heavy lifting for you.

No Need to Learn Another Piece of Software

The power of RWD is that it uses existing code in HTML5 and CSS 3.0. There is no need to learn a new language or download software. Like using traditional HTML for the mobile web, all you need is to learn the new break point patterns, and away you go. Building a simple page that can scale around multiple break points can be done very quickly.

Disadvantages

RWD = More Work at Your End

The power of RWD is also its weakness. Adding multiple break points is great in theory, but will now require you to change how you design for those widths. Remember that not every experience will fit perfectly, so you will have to tailor and optimize your experience as you build your website. Taking this into account, here are three things you will need to change.

1. Design for components and not screen widths—When developing RWD pages, all of the page elements and components you design will have to be flexible as well. Forget fixed widths, fixed layouts, and unique UI elements that are constrained; every element on the screen will have to be designed in percentages and flexible widths. Be prepared to wireframe and describe what each individual component will look like as its scales.

2. Change your team’s thinking and process—The process and workflow that your team uses will have to change. Gone are the days of a waterfall development schedule, where individuals finish their work right after each other. To get your RWD project working correctly you will need to tie your development, design, and user experience team closely together. This will force a tight collaboration that is necessary to catch all of the changes that arise from trying to match and optimize screen widths. Forget about having a separate mobile and desktop team; both will need to be working and thinking on the same page. The hardest part of this will not be developing the RWD site, but it will be convincing your team to change their thinking and process of how they approach a RWD project.

3. User experience design needs to evolve—Gone are the days of designing a set of wireframes and walking away. When working on a RWD project, expect to be heavily involved throughout the entire project. As break points and screen widths are being built you will need to come back and redesign wireframes and workflows. As pages get scaled, you will need to wireframe page components in different widths. Your user experience design process will need to become more interactive and require you to design on the fly as changes happen. As you design more complex RWD experiences, it will require you to do more complex planning at your end; so give yourself more time and budget.

Rethink Your Fancy Web Design

RWD creates a scenario that limits some of your design choices. Because you will need to create a design that works across all different widths, you have to design to a specification that will work regardless of the width. I have had two such experiences that I would like to share.

1. I worked on a RWD website that was designed to use the Parallax effect; an effect in web design that layers images and elements over each other as the screen scrolls. This fancy effect was perfect for the design and user experience of this particular website. When planning the development and user experience it appeared like it would be very difficult to add. This effect does not work properly on most smartphone browsers or even tablets. As a result it came down to a simple design decision, choose the parallax effect or RWD, but not both.

2. The next example of a RWD site included a nice java script carousel. It became apparent that the carousel we liked did not scale well and neither did the AJAX script that ran it. RWD will require you to rebuild and upgrade all of your existing AJAX tools and code libraries. In some cases, code and dynamic elements you once used on the desktop will not translate well to the new mobile web experience.

Performance Problems—The Double-Edged Sword

The last disadvantage and most important one, is what I refer to as the “double-edged sword” of responsive design. If you are using the same website for the desktop, the tablet, and mobile, wouldn’t the actual size of the website be exactly the same? If you guessedYES you are right. RWD opens exactly the same website in all three scenarios. For example, if the size of your website (including JavaScript, images, CSS, and html) is 5mb (extreme case) it will open the same size website both on a mobile device and a tablet. Not a big deal if you are on your desktop connected to Wi-Fi, but this is a huge impediment to your mobile users who are on a 3G connection. Why is this critical? If your website opens in 5 seconds on your desktop, expect it to open over 15 seconds on your mobile device. At that point you will have some very unhappy or nonexistent users.

Fixes exist to optimize for mobile, but these require more work at your end.⁴ Tricks like compressing your CSS, adding java script to change your image sizes,⁵ and stripping out any images in favor of CSS are different routes you can take. Regardless of any tricks, hacks, or new code you add; this requires you to add another layer of complexity onto your mobile experience. The great solution that would have worked across all platforms and sizes now adds more work on planning, designing, and even coding.

Mobile Misconceptions for the Mobile Web

1. It’s small, so it’s easier—Think again. The mobile browser is less forgiving. Mobile websites may be smaller, but they require more planning to get them right.

2. Responsive design will fix all my problems—RWD works when you can hit the reset button and create a brand new experience from scratch. Trying to force it into your current desktop or mobile experience is difficult. At times it will be easier to start from scratch, but not everyone has this luxury.

The Triple Play

I first heard the phrase “the triple play” to describe Bank of America’s mobile strategy. The triple-play strategy provides their customers access to online banking through their mobile app, mobile websites, and SMS text messaging. One way or another, their services will be available to any of their customers’ different mobile choices.

I love the analogy of baseball for the triple play. The metaphor of creating the perfect scenario for getting all three outs: make a play that covers all of your bases and all of your customers. Now ask yourself, do you want to make a play/strategy that covers all of your own customers?

I love reading mobile anecdotes about customer usage; two-thirds of smartphone users say a mobile-friendly site makes them more likely to buy a company’s product or service or 74% say they’re more likely to return to the site later if it’s mobile optimized.⁶ What about the remaining one-third or 26%? Will they go to a mobile app or desktop site?

Why leave customers or their revenue on the table? Like the triple play, why choose a strategy that requires you to select either an app or a mobile website; why not choose both? Good user experience tells us to talk to your customers. Making the right choice of what to design for should not be based on the weather forecast or an opinion; it should be based on your own unique customer feedback. Choosing how to design your experience and for what platforms should be secondary compared to creating a mobile strategy first. Once you create a strategy, then you can fill in the details; are you a mobile app only player, are you building with RWD, or are you going to build both? Listen to your users and customers, create a plan, and then make the choice. Once you have a plan in place, then you can come up with a name for your strategy.