Price touch

Have you ever thought about how many times a day do you touch the touchscreen of your mobile device? Hundreds and hundreds of times, right? But what is the price of these touches? As a mobile application developer, 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 touchscreen of the device while I was working on the development. After that, I began to notice how intensively we use the touch screens of our mobile devices and how much it takes effort.

Gestures can be tedious.

Every touch, every swipe, every pinch, and every zoom requires physical movements. Your hand is moving, while the rest of it is trying to stabilize your wrist while you hold the device motionlessly with your other hand. Quite a lot of physical stress, compared to a normal mouse, where your hand moves less, your wrist rests on the rug, and your hand comfortably lies 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 was working on a project in which I investigated an advanced workstation for warships of the American fleet. It was a touchscreen 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 fatigue in my hands whenever I worked with the console. Not as extreme as when working with an entire workstation, but similar loads can be seen when working with mobile devices. This subjective “cost” of touching the device 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 an application with a schedule. Since I also developed such applications, I was interested to know which approach they chose. So I went to the app store and downloaded it to my device.

I clicked on the icon on my home screen. After the screensaver passed, I had two buttons. One - in order to see the schedule of events, and the second - to learn about other events, it seemed, not related to the first. I started to think whether I downloaded the application. I pressed the schedule button and began to study their design.

At first, I thought that the initial 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 press, 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 to just print the schedule of the event 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 counterpart, 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 the Atari 2600 video games, I downloaded an iPad application to revive those “classic” games again. Designers of the application preferred to display the game catalogs in the form of a carousel, that is, I had to “swipe” again and again to move between thirty games. And I asked myself, do I like to turn this carousel to play this or that game? I'm sure the development team seemed that this design looks good, but after prolonged use, it becomes burdensome. The updated version of the application added the ability to see a list of recent games and display games as a list from A to Z. This means that now it has become much easier for me to play Missile Command.

In a sense, it reminded me of the classic game Myst. 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 went seamlessly into each other as you moved. These restrictions were dictated by the technologies of their time. Each movement took a few seconds and sometimes you had to go through several such scenes to get to the place of interest.

Fortunately, game designers realized that since the sense of novelty from the game environment quickly disappears, users will want to skip all this beauty and get to the game itself. So they presented a “zip mode” that allows players to skip intermediate moves. What 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 funny, but quickly tires. How often do we ask to add this or that interaction, because it seems to us “cool” or “fun?” 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 the mobile device's sensors to understand the associated factors (such as time, place, movement, light levels, sound levels, etc.)

I recently studied another application for events, and was surprised at the number of taps that needed to be made to get to the schedule. Instead of making a narrowly focused application, the conference decided to use a solution based on an aggregator. I had to click a few times to get to the most important information: meeting schedules. Extra clicks encourage users to search for the “best” solution elsewhere.

Also, we must remember that our mobile devices have many sensors that can be used to improve user interaction. 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, extra pressure. How many lines of code and tests do you need to just show the current date and schedule?

“Looks cool!” Should never get in the way “Works well!”

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