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.
Drop-down menus
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.
Horizontal menu prototype. Can you find which option has a drop-down?
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?
The expanded drop-down menu.
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.
This is how your horizontal menu should behave.
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.
What happens after the drop-down menu is expanded?
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
You can have a mouse over candy on your menu. However touch-screen users won't see it.
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.
Visual information upon click will be visible to both mouse and touch-screen users.
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.
Delicious.com carousel. Static.
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.
When you put the mouse over it, you'll see that there's more to it than meets the eye.
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?
Size and Proximity: Which one do you think is more suitable for a touch screen user? If it's good for the finger, it's good for the mouse.
Placement: Remember that on a touch screen, the user's hands hide everything below the elements. Here are some examples of elements that clearly don't work.
Final considerations
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).
13 Comments
http://www.longchamppliable.biz…
jbzapdtpvu…
Hello everyone! Together today to discuss the global consumption of high-quality shoes
tom shoes for women retail west poland verdict shop offer tescovisitor running designer taiwan promotional imports annual reports drives falling pricing year sports outsourcing 2013 cheap Toms shoes sale on toms outlet store leading
Actually the CSS hover on a drop down menu works with Safari on iPad touch screen by just a figure touch to open the drop down menu.
Here are a few of the web sites we advise for our visitors
Here is a superb Weblog You may Find Exciting that we Encourage You
Improve your sites google rank! http://goo.gl/YzNKa seo vps http://goo.gl/YzNKa
This is what I looking for! Thank you!
Very good
Nice article mate, very clear and straight to the point. Thanks.
Holy heck – that is EXACTLY why I just came here to make a suggestion. It is super frttirausng to use the drop down menus. Especially since I totally didn’t know that there were subcategories under all of the other category pages since the ‘all posts’ one that is the default doesn’t show subcategories.Even knowing that they all had subcategories, I gave up trying to find ‘suggestions’ and just went to the sticky so I could get here that way.
Nice article!
Good summary, thanks!
Hello! efkddfd interesting efkddfd site! I’m really like it! Very, very efkddfd good!