Designing mouse over events to be compatible with touch screens
1 March 2012, by Rui Oliveira in Web Development | 3 Comments
Mobile devices with touch-screens are starting to be more and more popular. When you’re building your site or web app, you should take this in consideration when designing the interface. Some people might use a mouse, other will use the fingers. This two have different needs and limitations, but with a little planning you can make the most of both.
First of all, when designing a drop-down menu, the trigger should have a visual hint, to let the user know that there’s one. It’s usually a small triangle, or arrow.
Upon clicking the option, or sometimes on mouse over, the menu expands. How should it behave in order to provide the best experience for mouse and touch-screen users?
Most of the options that trigger drop-down menus that I see online, usually behave differently upon mouse-over and click. Typically mouse-over expands the menu and clicking takes you to a different page. In this case, a touch-screen user will never see the menu.
Most of the times, the click on the option that expands the menu is really unnecessary, because it just takes you to a page with a more or less complex list of the drop-down menu options. It just adds one more step.
As I state on the picture above, you should trigger your menu with a mouse over or click. This approach will be acceptable for mouse and touch-screen users, providing real shortcuts for both.
As any normal drop-down menu, you can close it with the mouse out event. It’s an expected behavior for a mouse user. But what if you don’t have a mouse? How can you close the menu if it doesn’t have the option you were looking for?
The answer is simple: Another click on the same button, or anywhere else on the page, should close it. This closing behavior can also be hinted by the change of the icon on the button, as you can see on the picture.
Be careful when using a time out to close your menu. You can program it to close after, let’s say, 5 seconds. This time can be more than enough for some people to check if the menu has the options they’re looking for, while others might find it too short. This kind of events should be tested and only be used if there is a real advantage – most of the times there isn’t.
Mouse over candy
Remember that the mouse over effects can’t be seen by a touch-screen user. These can be used for visual hints only when using a mouse. Fancy menus like like the Lava Lamp Menu, for instance, don’t look that good on a tablet.
Fancy mouse over effects, like the Lava Lamp Menu, can be transformed to work on touch screens, as long as they work with mouse over and click. However, if upon clicking you load another page, the effect won’t be visible because a new page is loaded. This transformation only makes sense if you use Ajax calls or other kind of dynamic update without reloading the menu itself.
Active states and mouse down effects are also advisable. These provide a response to the user action. It could compensate for the lack of a mechanical response that you have on a physical button or keyboard. By having a down state, you remove the doubt of the user’s mind: “Did I really tapped it?”.
This is more important when your site takes more time to respond. When the user taps something, he expects a result. If nothing happens straight away, he’ll tap again, and again, and again, sometimes with disastrous results. The down state can help prevent this.
Mouse over exploration
You should never rely on mouse over alone to reveal or help navigation. On the image below there’s an example of a carousel used at Delicious.com.
Without a mouse over you don’t have any clue that you can scroll it. In a carousel like this, you should allways have the arrows on each side, to serve as visual hint for the user, to let him know that there’s more information. A mouse user would click the arrows, and a touch screen user could tap the arrows or drag to scroll.
Another good hint would be if the carousel scrolled automatically from time to time, which it doesn’t.
Different behaviors for different platforms
If you want, you can detect the OS or system that’s accessing your site and deliver different contents/behaviors for each one. On the carousel pictured above, one could detect the access through a mobile device and display the navigation arrows.
I really don’t agree with this way. Your user might be accessing your site or web app on a tablet and later access it through his computer. If you change things, the way it works or the visual language, you’re creating a barrier. You shouldn’t make your user learn it, or try to figure it out again.
You could argue that when using an iPad or Android Tablet or PC, people do things differently on each one to get to a result. That is true, mostly for native apps. What I’m talking about in this article, applies to web sites and web apps, and in this case, you should always try to use web conventions. When users access something through a browser, they expect some behaviors, and these are different from what they expect from native apps.
Finger sized elements
Another thing to take into consideration, is that a finger is not as precise as a mouse cursor. When creating your clickable elements think about two things:
Size and Proximity: Your elements should be big enough and sufficiently far apart for a finger to tap them without error.
Placement: Is your element correctly positioned so that it is usable by a touch screen user?
Tablets, smart phones and even some desktop computers have touch screens, and these are starting to be a more usual way to get to websites or web apps. When the users use their fingers, there’s no mouse over, and you shouldn’t cripple the navigation because of it. Do not rely on things like tool tips to explain what a certain icon does. Everything should be clear and self explanatory.
Good usability is invisible. People use it without thinking about it or without having to stop to ask for directions. So make your layouts and interfaces so clear and transparent that they become invisible (but beautiful).