Hover effects on smart phones/touch screen devices

I’ve only just started to think about usability on touch screen devices, such as smart phones or iPod Touch. For example, drop-down menus. These normally work by hovering over a menu option. Can you actually do that on a touch-screen device? If not, how would you deal with providing the same usability on a touch screen device.

In his recent article about Mega Drop-Down Menus, Jakob Nielsen suggests:

Don’t bother making the drop-down itself accessible. Instead, make each top-level menu choice clickable, leading to a regular Web page where you present all drop-down options in plain, fully accessible HTML.

But the that method seems to cancel out any benefits of having a dropdown, and in any case, it is only relevant to dropdowns rather than any other kind of hover.

So, can hover effects work on touchscreens (and if so, how)? If not, what are the best ways of dealing with the functionality of hover on a touchscreen device?

What Jakob is suggesting does not remove the benefits of a dropdown menu, remember that dropdown menu’s are not achievable in IE6 without the use of JavaScript (suckerfish) because IE6 cannot use pseudo classes such as :hover on anything except an anchor link. And as many people decide to disable JavaScript for security reasons you should always make sure that there is an alternative to the dropdowns.

All of those base menu links (which trigger the dropdown) which you would usually apply a # or #top anchor link, you should simply link to a copy of the websites SiteMap so that users who cannot make use of the dropdowns will simply be able to click and be redirected to an index of all the pages the dropdown includes. Remember that having a sitemap is beneficial for SEO and is considered a must have these days, so you will not be any worse off for improving your dropdown by including the functionality for those who cannot use dropdowns you provide.

But that seems like a very poor way of navigating around a website. Okay, I admit that I’ve never been convinced by drop-down menus anyway, but if the only way of making them accessible is to send users via a sitemap, that seems to make them even worse.

A more useful procedure might be to have all the links on the page, then remove them with javascript for standard browsers and have them in the drop-down for normal sites. Although I have no idea how that would impact screen readers and the like.

Anyway, drop-down menus were really only my jumping-off point. I guess I’m more interested in whether anything else you can achieve with hover effects can be implemented on touch-screen devices.

Any technique which relies upon JavaScript (dropdown menus and content altering alike) has one single problem; about 8% of people (according to recent statistics) have JavaScript disabled. So what might happen is you will end up a broken website design, but if by default you have all the links visible (using a different organisation method) and then for JavaScript disabled browsers essentially swap the style across to a dropdown menu, that would work perfectly without requiring a SiteMap.

Honestly it is all about progressive enhancement, making sure that all of your functionality is accessible but enhanced when the required technology is enabled. :slight_smile:

Says you. Most e-commerce sites work like this.

Go to newegg, ignore the dropdown menus, and try to get to the subcategory. When I click “PCs and Laptops,” I get a main category page with some promos on it, and the same menu as the dropdown on the left hand side.

If you look at Amazon with javascript disabled, they default to the old-fashioned left hand nav with headings for category names and links for subcategories.

Just because it’s not the fastest way doesn’t mean it doesn’t work. And if you’re not sold on dropdowns, why not go another route?

I’m not used to using mobile devices, but I think it’d be easier to use drilldown navigation and feel like you’re getting somewhere, than scrolling down a long series of links.

Please please don’t use pure CSS menus - they have appalingly bad usability. Much better to have JS driven menus which degrade to no menus at all without scripting (and have useful top-level links, as Jakob suggests)

Replace onmouseover with onclick ?
Make sure the item to hover over leads somewhere meaningful when clicked ?

So, can hover effects work on touchscreens (and if so, how)? If not, what are the best ways of dealing with the functionality of hover on a touchscreen device?

I think touchscreen mechanism didn’t allow you to call this kind of any event…
How can it possible that you move you finger above the touchscreen and it takes you fingure’s movement…
Touchscreen can not locate position untill unless you touch the screen as clear for its name touchscreen…

So it is likly to be impossible to call a hover effects on this kind of devices…

and user knows about this kind of limitations for these devices and they are use to this thing that when they click on the menu link only then they can see dropdown menu’s other links…

So didn’t need to be worried…

If you code the pure CSS menus properly they do not have appalling usability and until someone shows me a study which can state the otherwise, I will continue to use them in preference to a JavaScript enforced menu. :slight_smile:

I would suggest replacing the onmouseover event with an onclick event. This way, a user would touch the link to activate the hover menu, then touch their final selection.

I’ve used this technique when I have long lists of entries with fly-out preview information where hover events would create too much chaos on the page. For each entry in a list I include an icon which activates a fly-out menu when clicked. Clicking a close button on this fly-out cancels it.

It wouldn’t be much of a jump to apply this same idea to a menu, where you would also require a cancel button, and then a list of new destinations.

On a touch screen, the user’s only option, and first instinct would be to select an option by touching which fires the first click event. When presented with a secondary list it would make sense to then just touch and select another.

Just my 2 cents.

This sounds like a very good idea. Thanks.

There are two main usability issues with pure CSS menus.

One is IE6 - unless you use some scripting, then anyone stuck with IE6 will get no drop-down menu at all. Obviously, you’ve provided an alternative method of navigation as standard good practice, but it’s still not ideal for one visitor in seven to be missing out on the drop-down menu.

The other is latency - as Jakob explains in his article, with pure CSS, moving the mouse over or away from the target spot instantly triggers the menu to appear or disappear. This means that menus may come and go very quickly while the user is just mousing around the page. By using Javascript, you can enforce a ‘holding period’ of maybe half a second, which means that users have to hold the cursor over or away from the target area for at least that time before a change is triggered. The latency period is small enough that users are unlikely to notice a delay, but long enough that an accidental pass of the mouse across the target area won’t have any effect.

It’s up to you whether those are compelling reasons. I try to avoid using Javascript except where it is absolutely essential, but I can see there may be a case for using it here - partly depending on the nature of your site, of course.

Just to clarify - the kind of menus that are being recommended are designed as Pure CSS but then have a Javascript layer running on top that (a) makes it work in IE6, (b) gives some latency to improve the user experience, and optionally (c) gives a funky slide or other animation when showing and hiding the drop-down.

The Pure CSS menu will function exactly as per the spec if Javascript isn’t running, just without IE6 or the hair-trigger pause.

That’s all very well, but is it sufficiently obvious and intuitive to users how the menu set-up works? People are used to :hover menus now, and they are much more common on the web than menus where you have to click to activate the sub-menu.

While it is true that IE6 remains an issue I prefer to take the perspective that while JavaScript menu’s rely on JavaScript for any functionality, at least pure CSS menu’s will maintain their dropdown status with scripting disabled (which is all the more common these days). If you weigh up IE6 dependence (applying a bit of “backup” JavaScript) against complete reliance upon scripting (which is quite obtrusive) there is a clear advantage to using CSS menus with the additional JavaScript layered on top.

I think perhaps we are looking at things the wrong way, what would make better sense and meet all of Jakob’s latency issues progressively would be to use pure CSS menu’s (for browsers which inherently support it), this provides scripting disabled browsers to take advantage of the dropdowns, then layer some unobtrusive JavaScript over the CSS dropdowns which 1) force the menus to stay visible for a specified latency period (against the browsers natural inclination to trigger instant closure) and to address the issues with IE6. This method goes in line with your and my perspective that JavaScript should only be used when essential (or to provide “layered” functionality) rather than as a default. :slight_smile:

PS: You Ninja’d that post in before I finished mine! Yes that was what I was recommending :lol: as opposed to total reliance on JS using the pure CSS with layered JavaScript.

Just to clarify Stevie D, it was brothercake’s comment that I took issue with, by stating “JS driven menus” he was implying that the menu’s should be reliant on JavaScript and if JS is unavailable to degrade to having no menu’s at all. Which of course as we both came to the same conclusion is not the right way to go about things, much better to take advantage of the natural layers of the web to USE those pure CSS driven menu’s however providing JavaScript to deal with those little issues which could inhibit the user experience (which is exactly what JavaScript was created for, helping improve the interactivity and behaviour of a website).

I think perhaps we are looking at things the wrong way, what would make better sense and meet all of Jakob’s latency issues progressively would be to use pure CSS menu’s (for browsers which inherently support it), this provides scripting disabled browsers to take advantage of the dropdowns, then layer some unobtrusive JavaScript over the CSS dropdowns which 1) force the menus to stay visible for a specified latency period (against the browsers natural inclination to trigger instant closure) and to address the issues with IE6. This method goes in line with your and my perspective that JavaScript should only be used when essential (or to provide “layered” functionality) rather than as a default.

PS: You Ninja’d that post in before I finished mine! Yes that was what I was recommending as opposed to total reliance on JS using the pure CSS with layered JavaScript.kjkfjvlkfdgvlkrd

Yes that’s exactly what I’m implying. Pure CSS menus have the following issues:

  • no latency, which means “drive-by” triggering, and the need for ultra-precision mouse movement to navigate them
  • menus can’t be triggered with the keyboard, because the trigger elements aren’t keyboard accessible so :focus doesn’t help
  • menus can’t be repositioned dynamically to stay inside the window

Without these features, dropdowns are so difficult to use, that you really are better off not having them at all. It’s not a case that scripting makes menus better; its a case that scripting makes menus feasible at all. Why make your users fight to use your interface, when you can just degrade to a simple, clean interface that isn’t a struggle?

Pure CSS menus are an interesting test case - a proof of concept - but that’s all they are. They’re not suitable for production use.

Wrong, Pure CSS menus are for production use, they just require a bit of behind the screen non-obtrusive JavaScript, the difference between your view and mine is that you want to force everyone to have JavaScript enabled to have any kind of navigation, where as I simply say, use pure CSS but layer the JavaScript on-top so there is no reliance on it being available to at least have basic functionality.

No, the difference between our views is that I believe awkward unuseable interfaces should not be thrust upon users, whereas you seem to believe that’s okay :stuck_out_tongue: