Chapter 3: Considerations in Designing for Mobile and Touch Devices

Mobile devices are very different from desktop or laptop computers. They differ in both the way they are used as well as where they are used. Phones and tablets are mostly used to consume information, whereas computers are also used to create information.

Modern smartphones contain some of the most advanced technology available for consumers, including very high-density displays and sensitive multi-touch capable touch screens. On the other hand, the devices still fall short in many other aspects like available memory and CPU power. The device capabilities bring both opportunities and challenges when it comes to user interface design.

It’s not all about technology, either. Mobile devices serve a different purpose in their users’ lives. They are also used in very different surroundings than the more traditional computing devices. Without understanding the limitations and opportunities of both the technology and the use context, creating good user interfaces is difficult.

Designing for Mobile

Not all Android devices are mobile phones, but the vast majority is. It is safe to assume that if you are building an Android app it will be running on a phone. In order to successfully target phones, it is necessary to look into the limitations that mobility brings into the game.

Use context of mobile devices

Mobile devices are used, as the name suggests, on the move. The environment is noisy and users are interrupted all the time. Often, an app on a mobile device is one of many stimuli fighting for the user’s attention. They might be walking in a busy city pedestrian area, driving a car, or listening to a school lecture. In most cases the mobile app design cannot demand the user’s full attention.

To support users without forcing them to concentrate requires a good user interface. The interface must be intuitive, and all the controls must be clearly visible. Navigating a complex menu structure won’t be possible when you’re distracted.

When you’re designing your app’s user interface, do not overestimate the importance of your app to the users. Think about your app as the secondary function, and keep asking yourself if the app’s interface is usable even if the users only glance at the screen.

Mobile multitasking

Sometimes users will interrupt the use session just to pick it up few minutes later. Think about a scenario where a user is reading a newsfeed from a mobile app in public transportation and must transfer from one vehicle to another. The user is likely going to be in the middle of reading something when she arrives to her stop and places her phone into her pocket or purse. She is likely to pick the phone up again once the transfer is complete. The app must remember where the user was and allow her to continue as if there were no pause.

A similar situation is when a user receives a phone call. Imagine if you had to start a game from the beginning just because your gaming session was interrupted by an incoming phone call. It would not be acceptable. Apps must remember their state and prepare for interruptions. Again, don’t think that your app is the only one the user is going to be using or even the most important one.

Device constraints

Mobile devices suffer from many constraints. They have small screens and limited controls. The devices don’t have much processing power or a lot of memory. Even on the latest generation smartphones with more powerful CPUs and more memory, running apps is very different from doing so on a desktop or laptop.

In a low-memory CPU environment a badly designed app will stand out and not in a good way. An app performing CPU-heavy operations in the background will cause other applications to become non-responsive.

It is worth taking the time at the beginning of the project to think about your app’s hardware requirements. Could you, for example, move some tasks to a server and use the mobile app only for displaying the results?

Battery power is not endless

Mobile devices run on batteries, and that battery power is limited. People rely on their phones, and the phone must have power when it is needed. In some cases not having sufficient battery power can lead users into serious or even life-threatening trouble.

Apps must be optimized to conserve battery life. Any app that drains the battery will quickly be thrown out and very likely receive harsh ratings in the app market. And don’t think that users are not going to notice; they are. The Android operating system provides a very handy way for users to check what is going on if they suspect that something is draining the battery faster than it should be (see Figure 3-1). You can find this screen on any Android phone running 4.0 or newer.

Figure 3-1: Android battery status screen, including battery consumption per app.

Source: Android

Different apps consume battery differently. When starting to design an app take a moment to think about what kinds of tasks your app is going to perform in order to satisfy the user’s goals. Table 3-1 shows an overview of the relative battery consumption of different operations. I’m leaving games and gaming technology out from this consideration, as they are totally different beasts when it comes to battery consumption.

Tip: For more information about gaming and other more power-hungry apps, look at the Android NDK documentation online at http://developer.android.com/tools/sdk/ndk/index.html.

Table 3-1 Different Operations and Their Estimated Effect on Battery Consumption

Operation	Battery Consumption
Using a network when connected to WiFi	Medium
Using a network when on a good coverage cellular network	Medium
Using a network when on a bad coverage cellular network	High
Using a Bluetooth	Medium
Using a GPS	Medium
Using a cellular location	Low
Using an NFC (near-field communication)	Low
Preventing the screen from turning off	High
Using a microphone	Low
Using the camera	Medium
Waking up the phone when in sleep to perform any operation	High (not including operation cost)

Rapid innovation

Even with these limitations, the smartphones and tablets on the market today represent some of the latest and best innovation available to consumers. Mobile technology is also one of the fastest moving technology fields. Nokia N95, a popular smartphone released in 2007, had a 2.6-inch display with a 320x240 pixel display. Samsung Galaxy Nexus, released in 2011, has an impressive 4.65-inch HD display with 1280x720 pixels. The Nokia N95 shipped with a 332MHz processor while the Galaxy Nexus ships with a 1.2GHz dual-core CPU accompanied by a 304MHz GPU.

It is a full-time job to keep up with all the new technology introduced into mobile devices. A mobile app project starting now and shipping in six months might need more than one change on the way to support new operating system versions or even new technologies.

Tip: The mobile market is a land of opportunities. All the change might feel intimidating, but the fact is that you don’t need to worry about building support for many of these new technologies right away, and the user device base is replaced relatively slowly. It is worth it, however, to keep your eyes open and follow the news. Some new innovation might solve the problem you have been struggling with.

Network connection will drop

Most mobile devices have one or more ways to connect to the Internet. Many modern phones also support multiple generations of cellular data connections. Although the newer networks provide faster data speeds they often offer smaller coverage while the networks are still being built. By default phones usually try to use the most modern technology they support and drop back to the older networks if the coverage gets too weak.

To an app a change of network appears as a short connection drop. Mobile network coverage is inherently unstable due to varying traffic load and connection drops and your app must be prepared to handle them.

Think of the different ways you can help users with connection problems without requiring actions from them. If your user wants to download a large file, for example, make sure the app will automatically try again later in case of a network connection drop and will continue the download instead of restarting it.

If your app deals with any kind of media, this connectivity problem is emphasized. Take care to design your buffering algorithms and caching to support an optimal user experience.

Data is not free

An important point to keep in mind when designing mobile apps is that data transfer is not free. Many, if not most, users have limited data plans. Going over the data limits either lowers the users’ data speed or ends up costing dearly. Your app should try to limit data transfer only to necessary operations. Because the data-carrier plans have become more and more complicated and the risk of getting massive bills is getting higher, users are becoming more aware of app data usage. Google has reacted to this by providing users a way to view and control their data usage per app (see Figure 3-2). If your app appears on this list without an obvious reason, it is likely that users will uninstall it and rate it poorly in the Google Play.

For any long-running data downloads you must provide the users with a way to cancel them. Users must feel like they are in control. You will learn about managing background tasks in Chapter 9.

Many, in practice almost all, phones have support for a WiFi connection. A WiFi connection is more stable, cheaper, and faster than a cellular connection. If your app does data-heavy operations you should let users decide if they’re performed on WiFi only or also on the cellular networks. It is possible to detect when a user enters or leaves a WiFi network, and start and stop operations accordingly.

Figure 3-2: Users can view data usage per app and restrict the apps using Android tools.

Source: Android

Even on WiFi, you should use data operations carefully. Remember that data transfer bandwidth is shared between all apps. Whenever your app is using part of it, other apps won’t be able to utilize it fully.

Passionate users and opportunities

Techies have always been passionate about their particular choice of technology. It has always been Amiga vs. PC, Windows vs. OS X, Xbox vs. Playstation, and so on. Mobile ecosystems are no different. Mobile fans are even louder and more active. They love to show off their device of choice and the coolest apps they have. People wear clothes with operating system logos and line up outside stores for days to be the first ones to get their hands on the latest release. I am one of those people. I have an Android logo on my laptop cover.

This user passion creates great opportunities for app designers and developers. Create a unique app with an exceptional UI and the users will do a big part of the marketing for you. Popular apps spread like viral videos on the Internet. Mobile news blogs are hungry for topics, and one of the great topics is a new app that is worth talking about.

On the other hand, users are very demanding. They know what they want, and they’re not happy with badly built apps. If your app’s design doesn’t fit on the Android platform, users are going to reject it. Users will frown upon an iOS design on an Android app.

Mobile operating system blogs have thousands of followers, and they are all hungry for big headlines. The best blog posts, from the blog’s profit point of view, always puts at least two mobile operating systems head to head. Anything with “Android vs. iOS” in the headline is guaranteed to bring in a lot of viewers and inbound links. Understanding the user passion and everything that relates to it is vital.

Native apps versus web apps

Writing a platform-specific app is not the only way to reach mobile users. Although this book covers native Android apps (native meaning that they are built using Android SDK or NDK), another very good approach is to build a mobile web app. A web app runs in the user’s browser and is, therefore, much less tied to the platform. iOS and Android use the same WebKit-based browsers, so building a web app that works well on both of the largest mobile platforms isn’t impossible.

The mobile web app sounds great! Why not simply forget the native app idea and write web apps and target all platforms at once?

The choice between native and web is a very important and should be carefully considered at the beginning of any project. The answer to this question depends a lot on the type of project. There is a place for each solution. As a rule of thumb an app that is used fairly irregularly is best implemented as a web app, and any app that is going to be used very frequently will be better as a native app.

A regularly used service that has two competing service providers, only one of which provides a native app, is most likely going to see the most Android users moving toward the service provider that has taken the time to implement a platform-specific Android app.

There are also technical issues that can affect the decision. A web app won’t have access to all the platform APIs and, therefore, won’t be able to utilize all device capabilities. Although HTML5 APIs are catching up, they still lag behind. A web app won’t be able to use Android notifications and will have limited offline capabilities.

Hybrid apps with HTML wrappers

PhoneGap, Titanium Appcelerator, and few other frameworks provide a way to build something that is between a web app and a native app. They let developers write the app code using web technologies like HTML and JavaScript. Some frameworks then try to compile the code into a native app code and some other frameworks simply wrap the web app into a web browser container, in essence turning the web app into an app that looks like it is running natively.

Although there’s a promise of a platform-independent solution I advise a careful evaluation of this kind of framework. Even if the code runs on iOS, Android, and other platforms, it doesn’t mean that the apps are good. User experience guidelines of each platform differ greatly. You’d still have to design and implement the app for each of the target platforms separately to reach an acceptable result.

I advise caution with these multi-platform frameworks. Delivering acceptable application quality might be more difficult than you expect.

Designing for Touch Interfaces

Users have been using their computers with a mouse and keyboard for a long time now and have became very good at it. Users have learned that double-clicking icons launches apps, right-clicking things pops up menus, and holding the mouse button allows them to select areas or drag things around. Power users have learned to use keyboard shortcuts to operate without having to move their hand off the keyboard.

Things have been changing lately. Mouse and keyboard interaction is nearing the end of the road. A new primary control paradigm has taken the smartphone industry by storm. Nearly all smartphones now ship with touch screens as the main user interface. A touch screen is a much more immediate control mechanism. On a touch screen, you no longer have a disconnect between the physical controls and the UI itself. On a touch interface, you can directly touch the items you want to manipulate. That’s why touch interfaces are sometimes also referred to as natural interfaces.

IMPLEMENTING Gestures

Users control touch-based interfaces with gestures. A gesture is like a drawing on the screen that the operating system or the app interprets as a command to perform an action. Gestures vary from very simple one-finger gestures to complex multi-finger gestures. Simple gestures include tapping a user interface control and panning or scrolling a screen by dragging a finger on a control surface. More complex gestures including tapping and holding or drawing by dragging letters. Multi-touch gestures include a two or more finger swipe or multi-finger pinch or spread.

Table 3-2 describes the basic gestures supported by the Android platform. The icons in this table are used in later chapters to refer to these touch gestures.

Gesture discovery

A touch-based interface creates a new set of usability problems. How do users discover gestures that you put into your apps? Basically, there are only two naturally discoverable actions on a touch UI. Users tend to tap on things that look like buttons or links, and they drag UI components so make them pan or scroll. Everything beyond these two must be learned.

Take pinch-to-zoom as an example. It feels natural now as you have seen and used it, and you have started to understand that you probably can use the gesture to zoom maps or large documents in and out. But how do you know that this is possible without trying it first? Imagine having a new app that you have never tried before in front of you. The app has a map component as part of a screen. Will you be able to use the pinch-to-zoom gesture, or will you have to use some other method? Lack of visual clues makes it difficult to understand what your options are.

Pinch-to-zoom wasn’t always the way developers controlled zoom on touch devices. Before multi-touch capable devices, users did something else. Sony Ericsson used a novel zoom control on their devices before Android gained multi-touch support. On the Sony Ericsson device a user first had to long press the image he wanted to zoom and then without lifting the finger move it up to zoom in and down to zoom out. On Nokia’s Maemo, the operating system zooming was also done with one finger. In their approach zoom was done by moving a finger in a spiral pattern either clockwise to zoom in or counter-clockwise to zoom out.

I bet that both of these methods made perfect sense to the team who came up with the idea and implemented it. Neither of them felt natural, and they didn’t catch on. Pinch-to-zoom, on the other hand, feels natural, and that is now the de-facto standard for the zoom gesture.

What will happen if you take the gesture interface even further and keep inventing new ways to use gestures? What if someone decides to implement pinch-to-zoom on a list component? How would users find out how to use it without the developer having to tell them?

Probably the best way to get users to understand available gestures is by convention. Although new conventions arise slowly, it’s better to use existing and established conventions when possible. For example, maps should always allow pinch-to-zoom. Tabbed user interfaces should let users navigate between tabs by swiping. You’ll learn more about Android-specific user interface paradigms in Chapter 11.

Gesture confusion

As designers keep inventing new and more creative ways to use gestures in apps, developers run into another problem. How does the app detect the correct gesture? Some gestures are very similar. The best example of two gestures that can cause confusion when used on the same app are swiping and panning.

Consider an ebook reader app as an example. The app supports two gestures that are relevant in this example. One gesture is the horizontal swipe to change to the next or previous page. The other gesture involves panning by dragging when a page doesn’t fully fit on the screen.

Let’s assume that a user is reading a page and zooms in. Now, a full page of the book doesn’t fit on the screen, and the panning gesture can be used to reveal different parts of the page. What happens if the user uses a swipe gesture instead? The swipe gesture and panning gesture are identical at the start. Only after the user has performed the gesture beyond the start can the gestures be differentiated using velocity and direction. How can the app differentiate between the user’s intention to pan the page and swiping to change the page?

The short answer is that you should try to avoid using conflicting gestures in same component. Take gestures into account early in the design process and prototype them.

React to gestures immediately

Your interface must react to its users’ gestures immediately. The users must have immediate visual feedback that the gesture is working. It will make the user interface feel more responsive but also helps both with gesture discovery and avoid gesture confusion.

A bad, and unfortunately common, example of implementing gestures is waiting until the user finishes a swipe gesture before performing the action. In other words, consider an ebook reader app whereby the users must finish swiping horizontally before the app shows the page change animation. Users will have hard time finding the gesture and learning how to use it. A better and correct way to implement the same gesture would be that the page change animation follows the user’s finger from the start of the gesture to the end. In other words, when the user starts moving his or her finger on the page, the page starts changing. The page moves with the same pace as the user is moving his finger. This way there’s no room for misunderstanding; your users are more likely to figure out this gesture on their own.

Touch interface, not so natural interface

As discussed in the previous sections, providing a touch interface doesn’t mean that users will have any easier a time figuring out how to use it. Calling it a natural interface is a bit misleading. Human beings are used to manipulating three-dimensional objects that have different weights, sizes, textures, and many more properties they can sense. Touch screens still lack most of these properties, and users struggle to understand different metaphors. Touch interfaces do require the same amount of design work as any other interaction method. Be careful not to think of the touch interface as a shortcut.

Summary

Mobile devices are used differently and in different settings than computers and laptops. When designing a mobile app, you must always remember that your users probably won’t give your app their full attention.

Mobile devices also have limitations that computers don’t have. Limited computing power and battery life, as well as connectivity problems, all bring challenges to the design process.

The main control interface of most mobile devices is the touch screen. The touch screen creates a new set of challenges, but also provides many design opportunities. Touch-based user interfaces can be very powerful as long as you take their limitations into account from the beginning.