The Cost of a Touch
Have you ever thought about how often you touch your mobile device during a single day? Hundreds and hundreds of times, right? But what is the cost of all this touching? As a mobile application developer, I interact with my mobile devices a lot—touching, swiping, pinching, and zooming. One trick I've adopted is adding secret shortcuts to skip past portions of my app so I do not have to keep touching my device while I am developing. This led me to consider the amount of touching we all do with our devices, the physical toll it takes, and our overall user experience with mobile devices and their applications.
Gesturing Can Be Tiring
Every touch, every swipe, every pinch, and every zoom requires quite a bit of physical motion. Your hand moves while the rest of the arm is working to stabilize the wrist and you are holding the device steady with the other hand. That is a lot of physical exertion compared to using a typical mouse, where your hand moves less, your wrist is probably resting on a wrist pad, and your arm sits comfortably on a chair arm. Your other hand is not even needed. So, you can start to see how much more effort using a mobile device can be. To be clear, I have not performed any controlled experiments to measure the exact level of effort—I am pulling from anecdotal evidence and personal experience.
Years ago I worked on a project that was exploring an advanced workstation on-board U.S. Navy warships. It was a touch-based workstation that used four separate monitors spanning more than 4800 pixels in width. Although we paid close attention to our users’ interactions with the system, I can still recall the fatigue in my arms whenever I worked on the console. Although not as extreme as an entire workstation, a similar physical toll can be noticed in our usage of mobile devices. This subtle “cost” of touching the device can have a negative impact on how users feel about your application. So how do we go about eliminating unnecessary gesturing and movement?
Remember the User’s Prior Selections
Last year, a big pop-culture convention released a mobile schedule application. Since I also create these types of applications, I was very interested in how they approached it. So I went to the app store and found the link to download it to my device.
I taped on the icon on my home screen. After the splash screen dismissed, I was presented with two buttons. One to display the schedule for the convention, and another button to learn about a different, seemingly unrelated convention. I was left wondering if I had downloaded the correct application. I pressed the button for the convention and began exploring their design.
At first I thought the initial screen was just poorly designed by having the other convention’s “ad” appear button-like. Then I relaunched the app and once again I had to tap on the button to see the schedule. A wasted touch, another moment where a user might decide that this app is too troublesome to use. Why did I need to keep repeating this interaction every time I wanted to use this app? The printed guide started to look better and better after each use.
Make It Easy To Skip Ahead (Especially When Lists and Sequences May Be Long)
Your application may not have a physical analog like this app did, but odds are there is a similar application or two in the app store that your user can easily switch to. Think about each interaction in an application and its cost. Look at your design and ask: “Does the user need to perform this interaction?”
As someone who grew up playing video games on an Atari 2600, I downloaded an iPad app to relive all those “classic” games again. The app’s designers chose to display the game catalog in a carousel, meaning that I had to swipe again and again and again to cycle through the 30-or-so titles. I found myself asking if I really wanted to cycle through the list to play a certain game. I am sure this design looked great at first to the team, but after continued use, one could feel the burden. In an updated version of the app, the ability to list the games from A-Z and recently played was added. Which means, it is now a lot easier for me to go play Missile Command.
In some ways I was reminded of the classic CD-ROM game “Myst”. For those who have never played it (it has been ported for the iPad), it was a beautifully pre-rendered 3D puzzle game. However, in its initial version you were not allowed free movement. Rather, you jumped from fixed node to fixed node. Each scene would cross dissolve from one to another as you moved through the environment. This stretched the limits of the technology of the time. Each movement took a few seconds and sometimes you needed to traverse multiple nodes to reach the actual point of interest.
Fortunately, the game designers understood that once the novelty of seeing the environment wears off, the user will want to zip past the “eye-candy” and get to the business of playing the game. So, they introduced a “zip-mode”, allowing the player to bypass the intermediate nodes. I have always found this to be one of the game’s most brilliant features. I am sure that the QA team did as well.
The Atari app’s rotation carousel is much like the intermediate nodes in Myst–fun to see the first time, but bothersome after that. How often are we asked to add an interaction because it appears “cool” or “fun?” What is the cost of having that interaction? How many touches will your user have to make to reach the desired information?
Take Advantage of Device Sensors To Understand Context (Such As Time, Place, Movement, Light Levels, Sound Levels, etc.)
I was recently reviewing another conference application, and was amazed at the number of touches I had to perform to find the event schedule. Rather than have a dedicated application, the conference decided to use an aggregator-based solution. I had to tap several times just to get the critical piece of information: the conference schedule. Wasted touches encourage users to seek a “better” solution elsewhere.
We should also remember our mobile devices have a wide range of sensors on them that can be used to better the experience. It doesn’t have to be something like geo-location that can make the difference. It can be as simple as understanding what day it is.
I was attending a 5-day-long conference not so long ago, and although its mobile app brought me straight to the conference schedule, it failed to auto-select the correct day. Thus, every time I wanted to see that day’s schedule, I had to touch the button for the correct day. Again, wasted touches. How much code and testing would it have taken to simply look at the day value and display the current day’s schedule?
“Looks Cool!” Should Never Interfere With “Works Well!”
Hopefully this collection of observations has given you some points to consider as you design and build your next mobile app. And if you ever find yourself wishing for a shortcut in your app, then either design one and add it, or, better yet, improve the design and remove the need for a shortcut.
I would like to thank Dr. David Hogue, James Polanco, and Rob Huddleston for their help with this article.
Touching hand image courtesy of Shutterstock
ABOUT THE AUTHOR(S)
Chris Griffith is a Staff Engineer in the User Experience group at Qualcomm, focusing on prototype development. He has been a writer for O'Reilly's InsideRIA and peachpit.com. In addition, he is also an Adobe Community Professional and has published several applications for both iOS and Android. When he is not coding, Chris is either spending time with his family or out sea kayaking.