Touch Price

Original author: Chris Griffith
  • Transfer
Have you ever thought about how many times a day you touch the touchscreen of your mobile device? Hundreds and hundreds of times, right? But what is the price of these touches? As a developer of mobile applications, I interact a lot with my mobile devices - I do all these “swipes”, “pinches”, and “zooms”. I thought of adding hidden shortcuts to skip certain steps in my application, so that I would not have to constantly click on the device’s touchscreen while I was developing. After that, I began to notice how intensively we use the touch screens of our mobile devices and how much it takes.

Gestures can be tiring



Every touch, every “swipe”, every “pinch”, and every “zoom” requires physical movements. Your hand moves while the rest of it is trying to stabilize your wrist while you hold the device motionless with your other hand. Quite a lot of physical stress, compared with an ordinary mouse, where your hand moves less, your wrist rests on the rug, and your hand lies comfortably on the arm of the chair, and the other hand is simply not needed. So you see how much effort a mobile device might require. To be honest, I did not conduct any experiments to accurately measure these efforts - I proceed only from personal experience and observations.

A few years ago I worked on a project in which I researched an advanced workstation for warships of the American Navy. It was a touch-controlled workstation that used four separate monitors, with a total resolution of more than 4800 pixels wide. Despite the fact that we paid close attention to the interaction of users with the system, I still remember the tiredness in my hands every time I worked with the console. Not as extreme as when working with an entire workstation, but similar loads can be noticed when working with mobile devices. This subjective “cost” of touching the device’s screen can negatively affect how users react to your application. So what can we do to avoid these unnecessary gestures and movements?

Remember user actions



Last year, a major pop cultural event released a schedule app. Since I was also developing similar applications, I was interested to know what approach they took. So I went to the app store and downloaded it to my device.

I clicked on the icon on my home screen. After the screen saver passed, two buttons were revealed to me. One - to see the schedule of the event, and the second - to find out about other events that seemed unrelated to the first. I began to think whether I downloaded the application. I clicked on the schedule button and began to study their design.

At first, I thought the home screen was so poorly designed because it would display ads for other events in the form of buttons. Then I restarted the application and I had to press the button again to see the schedule. Extra pressing, another moment when the user can decide that using this application is too troublesome. Why did I have to repeat this action every time I wanted to use the application? The idea of ​​simply printing the event schedule began to seem more and more attractive to me.

Give the opportunity to skip a step (especially when lists or sequences are too long)



Your application may not have a physical analogue, as in the previous case, but most likely the application store has one or two similar applications that the user can easily switch to. Think about each user interaction with the application and its cost. Look at the design of the application and ask yourself: “Should the user perform this action?”

Like many who grew up on Atari 2600 video games, I downloaded the iPad app to revive those “classic” games. Designers of the application preferred to display the catalogs of games in the form of a carousel, that is, I had to “swipe” again and again in order to move between thirty games. And I asked myself if I like to spin this carousel to play this or that game? I am sure the development team thought that this design looks good, but after prolonged use it becomes onerous. In the updated version of the application, the ability to see the list of recent games and display the games in a list from A to Z was added. This means that now it has become much easier for me to play Missile Command.

In a way, it reminded me of the classic Myst game. For those who have never played it (it was ported to the iPad), it was a beautiful 3D quest. In its first version, it was impossible to move freely. Instead, you moved from one fixed point to another. Each scene fades into one another as you move. These limitations were dictated by the technology of their time. Each movement took several seconds and sometimes it took several scenes to get to the place of interest.

Fortunately, game designers realized that since the sense of newness from the gaming environment quickly disappears, users will want to miss all this beauty and start directly to the game. So they introduced a “zip mode” that allows players to skip intermediate moves. Which always seemed to me one of the best features of this game. I am sure that the QA-team also thinks so.

The carousel in Atari applications is like intermediate moves in Myst - at first it’s funny, but it quickly tires. How often do we ask you to add this or that interaction because it seems to us to be “cool” or “funny?” What is the cost of this interaction? How many touches does your user have to do to get to the desired information?

Use the capabilities of your mobile device’s sensors to understand related factors (such as time, place, movement, light levels, sound levels, etc.)



I recently studied another app for events, and was surprised at the number of clicks that had to be done to get to the schedule. Instead of making a narrowly targeted application, the conference decided to use an aggregator-based solution. I had to click several times to get to the most important information: meeting schedules. Extra clicks encourage users to look for the “best” solution elsewhere.

Also, we must remember that our mobile devices have many sensors that can be used to improve user experience. It does not have to be something like geolocation. It may just be information about what day it is.
Not so long ago, I was at a five-day conference, and despite the fact that her mobile application regularly showed the schedule of events, it could not automatically indicate the current day. So every time I wanted to see the schedule, I had to press a button to get the correct date. And again the extra clicks. How many lines of code and tests are needed to simply show the current date and schedule?

“Cool looking!” should never interfere “Works well!”



I hope this collection of observations will help you in developing the next application. And if in your application you need a shortcut for quick action, then create it, or, best of all, improve the design and get rid of the need for a shortcut.

Also popular now: