Being Proactive on Touch Event UIsWeb Design & Development
An ever-evolving swarm of APIs and integrations are allowing user interfaces to become more interactive across devices. These make it possible for developers to use the same application or website across all devices and all methods of interaction. While this is a great advancement, it does pose one major issue: the standardization of touch and click events.
The growing issue of websites being built without supporting both touch and click is a problem as devices are getting smarter and becoming more integrated. Touches, swipes, clicks, double-clicks, holds, drags, hovers, focus states, and active states are all methods designers and developers use to let users interact with their products. All of these actions should be thought through, and they must be cohesive throughout the experience regardless of what device the user is operating. The solution I’m providing is making simple design decisions ahead of time instead of tacking on more frontend code that will take more resources to create.
A Little Background
Some time ago, HTML5 Rocks' Chris Wilson and Paul Kinlan handed out some instructions on how to combat the issues of supporting both touch and click events in this article.
In their article, they say:
“Supports touch” is not the same as “doesn’t need mouse support.”
And this is true. We need to support both but without limiting interaction among all the new devices out there that have the ability to operate with different tools.
They also suggested three methods for solving UI issues.
- Implement "touch and hold" as a secondary click.
- Make the UI take two single touch events to complete the click (one for hover and one for click).
- Use a "Help Mode" to explain how to use the UI you've created.
All of these solutions are reactive instead of proactive about the UI. But, we can be proactive and solve most of these issues through good interaction design.
In some cases, we won't even need the support of the interaction on touch devices as long as we hint to the user that there is an interaction without impeding their experience with our product. This is a case where we build familiarity with the user.
I'll try to create a quick example of the philosophy behind generating familiarity.
Think of video games. Some video games give a tutorial on how the mechanics work throughout the entire game. This strategy gets the user ready to play but can be a lot of information up front. Another strategy is to give the user mechanics throughout the game so they can use their skills to play the game as they wish. This technique is practical in the web because we let the user discover how they can operate the site on their own. All we do is drop hints. These types of interactions and learning give good end-user experiences.
Example - Let's say a website has a photo that, when hovered, shows a text overlay with important information on it including a link to another page.
Now, a designer's simple solution would be to just show the overlay if a user is on a touch device. The problem with this technique is the photo loses its intent and may get drowned out all together behind the text. Now, let's look at HTML5's example on how to solve this case:
- Touch and hold to reveal the hover.
A user wouldn't know to hold the photo unless there is some text or hint toward this interaction. Also, the user loses the intent of the photo if their finger is over it while they wait for something else to appear. There is no familiarity and this action would never get noticed.
- Two touch events to activate the hover and then to activate the link.
This isn't perfect because the user must use two actions instead of one. Familiarity also isn't built up for the user so they wouldn't know that this type of interaction would occur. To help this solution though, you can create an element that lays on top of the image (a plus icon for example) that hints at an interaction. The user clicks, or touches, the icon to display the overlay and does the same with the link to go to the next page. It's still two actions instead of one, but this technique pinpoints the user's interest and clues them in on where more information lies.
- Create a "help mode" or some kind of hint that directly tells users how to operate our product.
Telling people what to do gives you a bad rep. If you have to tell someone how to work your product, you've probably missed some key elements in your design process. Remember, always design your product so that anyone can use it on their own without additional direction.
Being proactive will help you solve these issues before they arise. Remember, that it IS still the same site no matter what device you're using, so let's think of some design elements that all devices have already standardized.
- Transition (Animation)
These factors will always render similarly, no matter what device or browser a visitor is using. All we have to do now is leverage them to hint at interaction before any action ever occurs.
Let’s go back to our example.
What if we used a parallax effect that displays our overlay once the image reaches the middle of the view port? What if it just displays after so much time? What if it was faded out until something else hinted at it? None of these solutions require anything more than what's probably already in the framework (if they do, then what's wrong with adding a simple plugin?). Just create a function that calls on touch-enabled devices before an experience issue arises. The key is to keep it subtle enough to keep the user's experience intact and not distract them from their call-to-action with messy animations and flashy effects. Animation can be your greatest asset, but it can also be your greatest weakness if done incorrectly.
Devices are getting complicated to cater to, and it takes a lot of developer hours to maintain that level of interactivity while keeping users happy. Instead, you could be making smarter design decisions to eliminate those issues before they begin.