SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 31
  1. #1
    SitePoint Zealot PatrickSamphire's Avatar
    Join Date
    Jul 2006
    Location
    UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    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?

  2. #2
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    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.

  3. #3
    SitePoint Zealot PatrickSamphire's Avatar
    Join Date
    Jul 2006
    Location
    UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #4
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    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.

  5. #5
    SitePoint Addict
    Join Date
    Feb 2009
    Location
    Austin Texas
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PatrickSamphire View Post
    But that seems like a very poor way of navigating around a website.
    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.

  6. #6
    SitePoint Guru
    Join Date
    Mar 2004
    Location
    Earth
    Posts
    406
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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)

  7. #7
    Floridiot joebert's Avatar
    Join Date
    Mar 2004
    Location
    Kenneth City, FL
    Posts
    823
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Replace onmouseover with onclick ?
    Make sure the item to hover over leads somewhere meaningful when clicked ?

  8. #8
    SitePoint Zealot busylinks1's Avatar
    Join Date
    Nov 2008
    Posts
    160
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...

  9. #9
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by brothercake View Post
    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)
    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.

  10. #10
    SitePoint Member
    Join Date
    Mar 2009
    Location
    Toronto
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  11. #11
    SitePoint Zealot PatrickSamphire's Avatar
    Join Date
    Jul 2006
    Location
    UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by rshaffaf View Post
    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.

  12. #12
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,888
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    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.
    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.

  13. #13
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,888
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stevie D View Post
    There are two main usability issues with pure CSS menus.
    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.

  14. #14
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,888
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by rshaffaf View Post
    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.
    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.

  15. #15
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    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.

    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.

  16. #16
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by brothercake View Post
    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)
    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).

  17. #17
    Non-Member
    Join Date
    Mar 2009
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Talking

    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

  18. #18
    SitePoint Guru
    Join Date
    Mar 2004
    Location
    Earth
    Posts
    406
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    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.
    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.

  19. #19
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    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.

  20. #20
    SitePoint Guru
    Join Date
    Mar 2004
    Location
    Earth
    Posts
    406
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  21. #21
    SitePoint Enthusiast
    Join Date
    Mar 2009
    Location
    Timisoara, Romania
    Posts
    55
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Will be a great thing if you can do it. Good luck!

  22. #22
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,280
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    I've seen keyboardable dropdowns where the subs do become visible on :focus (of the particular submenu item, not the parent li). They do look a bit weird though, appearing out of nowhere without the rest of the subs showing. Of course, IE6 doesn't support :focus, but whatever.

    Quote Originally Posted by Patrick
    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.
    I wouldn't send people to a sitemap, but to a page with info about that theme/rubriek/whatever, and inside are further links.

    For instance I had a menu for an insurance page. If you chose Transport, but clicked on that menu choice (people who make the dropdowns appear by hover don't ever seem to think of clicking on the main link) get to the Transport page, which is about the three sorts we had: Cars, motorcycles/scooters, and boats. That page had small pieces of text about each sort of insurance and several clickie links to the individual pages-- they could choose to go directly to "get a quote" (one of the sub-sub menu items) or they could go to the "info/about/conditions" page (the other sub-sub menu item), each for that particular vehicle.

    Those who could get the dropdown to work could use it as a dropdown, but it wasn't required for anyone and the menu actually wasn't so deep that you had to click through pages of garbage to get to any particular page (esp since the menu was prolly a little too redundant-- instead of navigating through Transport, you could instead choose the Get a quote main menu item as well and then choose your type of insurance on that new page too.

    I think it was pretty nice, but even better was when I removed it entirely.

    I would never build a menu out of Javascript, and never will have that as a sole menu option until every single user agent out there supports it, and cannot be turned off by the user. Which will never happen so long as 12-year-olds continue to do Javascript attacks on lax websites (when they made that epilepsy support forum flash crazy colours so the users has seizures... those kids should all be dropped from tall buildings). Javascript can make things pretty, or make things fancy, or make things slow. Beyond that, I avoid it. I hate scripts making things dance and sing unnecessarily (MooTools, I'm talking to you) and that's reason #2 why I always surf with scripts off.

    An example of why I hate Javascript menus: http://opmaatverhuizingen.nl visit it with scripts off. Click on what you DO see at the top, and you'll get a nice advertisement for Open Cube, instead of the guy's business. That's just wrong on so many levels.

    And yes, I know that's not what brothercake is advocating. I'm not sure what he'd have in place of a main menu though. I don't see any problems with a main menu available for everyone. Letting people get to the subs pages can be done in so many different ways.

  23. #23
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    OpenCube is one business I have dealt with in the past. They use the old model of developing in the 1990's with poorly implemented JavaScript focused "solutions" which are so heavily encrypted to protect their code that you have no way to debug or resolve any issues with the projects. They are obtrusive and extremly heavy on the KB size.

  24. #24
    SitePoint Guru
    Join Date
    Mar 2004
    Location
    Earth
    Posts
    406
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    I'm not sure what he'd have in place of a main menu though. I don't see any problems with a main menu available for everyone. Letting people get to the subs pages can be done in so many different ways.
    I'd have a top-level navigation bar same as it is anyway, linking to pages from which all the submenu content is available - sub-index pages as it were.

  25. #25
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,280
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Ah, ok. I thought you meant "no menu" when no js. : )


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •