The Responsive Hover Paradigm

15 Comments

Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

  1. Patrick H. Lauke

    Internet Explorer 10 on Windows 8 uses the aria-haspopup attribute to simulate hover on touch devices

    note that this behavior has been removed in IE11 now.

    We can cover keyboards with our friend :focus

    but this only works if the :hover was applied to a focusable element, and if the bits that you then interact with aren’t child elements of that element. so, for instance, in the touch/hover switcher example, even keyboard users need to change to the touch variant, as the hover one simply doesn’t do anything when just focussing with the keyboard (as the hover effect is applied to the div (so can’t focus, so that extra :focus state never happens). even if we added a tabindex=-1 on the div to force keyboard focusability, as soon as the user tabs to get to the actual “Add to cart” button, :focus is lost again and the user tabs to the now hidden button.

  2. Patrick H. Lauke

    In response to Shane’s comment:

    there must be a nicer way by detecting the input device?

    As we move to devices that are multi-input (Win8 laptops or Chromebooks with both a touchscreen and traditional mouse/trackpad/keyboard, plus any upcoming input modalities like Kinect-style cameras etc), it’s increasingly difficult to make assumptions about what input a user will first of all HAVE on their device, and second which input they will USE.

    “A priori” one should assume that a user has all sorts of inputs at their disposal. You can only say that yes, a user has a touchscreen, once you get the very first touch-specific event (either a touchstart, or a pointer event of type touch/stylus). After that, it’s still not to say that the user will continue using that input modality exclusively. But this problem is not new…there’s not been any way to determine if one is a keyboard-only or mouse user, so we’ve ideally had to code for both situations. So, the same way, we should make sure our sites/web apps work with all types of inputs. It’s not a technical challenge I’d say (particularly once we have Pointer Events supported in most browsers – already in IE, soon in Firefox and Chrome – which homogenise the event handling in an input-agnostic way, but also allow to determine the type of an input if we want to run specific code based on different modality), but mainly a problem/challenge of design/UX.

  3. Jenn Lukas

    Thanks for everyones thoughtful responses so far! I think my character count would have to jump up to 100,000 if I wanted to cover all caveats and awesomes about hovers, so appreciate everyone jumping in to share their knowledge as well! <3 internet community!

    The points Patrick brought up on :focus not covering all of keyboard is super important! That word was actually supposed to be a link to Dave Rupert’s great guest article on eff yeah hovers covering where you can and can’t use :focus. I highly recommend everyone read his post

    http://fuckyeahhovers.tumblr.com/post/53291253894/fuck-yeah-keyboard-focus

    And that’s what happens when you only link one short word. #doh I’ll remember to link more words next time! I’ll ask the crew here to get that link back in the article.

    Double @Patrick H. L.:
    about aria-hidden:

    note that this behavior has been removed in IE11 now.

    Really? Dang. I thought that was just in the preview mode?
    http://msdn.microsoft.com/en-us/library/ie/dn265029(v=vs.85).aspx

    +++ thanks for answering Shane’s question!! #highfive

    @Christian K: In part 3, the first example I show is actually an example of a bad hover pattern. Sorry if that was unclear! I am suggesting however, that the Twitter handle (in this case @jennlukas) is the most important part as that clearly conveys to readers that it is a link to Twitter. I don’t think the bio part is necessary content and can be omitted to both users just reading the screen with no hover and for touch users. The bio is unnecessary – unless of course this is a site for specifically Twitter bios, then you would probably need it! :) Content between devices and size doesn’t always have to be the same, it depends on the content.

    @ Bob and Prisca: so glad you enjoyed it and can use it to help find solutions that fit your needs!!

    Yay great conversations about hovers!

  4. Bob Monsour

    Clear and timely! Thanks for the great piece. I was just doing some layout sketches today and having a self-debate about my main menu items and the whole touch/mouse conundrum. With your help, I think I’ve got an appropriate solution.

  5. Christian Krammer

    Dear Jenn! I actually meant the second example in chapter 3 in my original comment.

    However when you say
    bq. The bio is unnecessary – unless of course this is a site for specifically Twitter bios, then you would probably need it! :) Content between devices and size doesn’t always have to be the same, it depends on the content.

    Why do you think content is necessary or interesting for one group (no-touch) and not for another (touch)? And if it’s unimportant why not just omit it for both groups? These are assumptions you simply can’t make as a developer but should be made by the user.

  6. Craig Freeman

    Great review of the state of hovers, though I would have liked to see Pointer Events discussed.

    I agree with Patrick – I’m particularly looking forward to Pointer Events maturing (the first iteration leaves something to be desired) and would love to see widespread adoption. Yes, I’m sure there will be a paradigm shift in how we create/use websites, but that’s kinda what I like about this field. Ever-changing and improving!

  7. Jenn Lukas

    @Christian K: Sorry I missed the second part of your comment! By all means, I agree that I’m not sure that this switcher is the best solution for all/any of our sites. How did you feel about the text size switchers that used to exist? I think that they didn’t solve everyone’s problem, but it helped. I love the idea of a website that just works. But with how things change all the time, sometimes we need to hack things. Whether that’s CSS browser hacks or polyfils or having users manually fill in their locations or providing switchers to meet multiple peoples needs. I think in general, erring on the side of touch is the safest and best bet. But sometimes web designers are going to be move adventurous and I think the more we brainstorm ways to support that, the better!

  8. prisca

    What a great article – thank you, Jenn.
    I love working with hovers – was a sad day when I realised that touch screens came along and changed the game. Great links and examples.

    And thanks for your comment, Patrick ~ very useful :)

  9. Chris

    > note that this behavior has been removed in IE11 now.

    Actually aria-haspopup=true has not been removed, IE11 on Surface still shows e.g. dropdown menus if they use aria-haspopup=true. Menus like this also work with a long tap which was the only way to do in IE11preview. But it seems the complaining about this unexpected and undiscoverable behaviour lead to readding the actually quite nice aria-haspopup thing. I wished Safari and Chrome would add it too as it is explicit and not somehow random like current mobile Safari does it.

  10. Andy Griffin

    On a few of my sites I’ve designed the menus to respond to both hovers and clicks (including touches). So the menu will open and close on mouseover/mouseout, respectively, but also toggles on click. Then you can save yourself the trouble of designing extra pages that duplicate the navigation.

  11. Brian LePore

    Anyone remember when it was best practice to include a little arrow to indicate that the navigation element had a drop down? I’ve done this on one site and was able to add touch events that mobile users access the navigation that was enabled based on hover. Wasn’t THAT hard …

    I cannot believe I never heard about the aria-haspopup attribute!

  12. Brian Swisher

    Some proclaim the importance of content for good reason. Content is what users are seeking. If you’ve got it and it’s really good, excellent! If you have it and it’s just on par with others, then decorative flourishes and visual images might convince users that yours is the go to source. But if you’re content is no good, then no amount of visual flourish will convince users otherwise.

    Some encourage methods like mobile first also for good reason as well. Users are aggressively using mobile or non-desktop devices to access the web at a rapid rate. There will be a point in the future where the desktop web user will be in the minority. The web experience is officially in the process of being disrupted. The music industry was disrupted by MP3s. The movie industry is getting disrupted by things like UltraViolet. Both industries initially reacted by rejecting the disruption. We knew that would’t work.

    We should avoid rejecting the web disruption. There are new constraints to be considered, but constraints can be effective tool for creativity. It’ll force us to realize new and better UI conventions, that I’m certain of.

  13. Christian Krammer

    Basically a good introduction to hover effects. However there are two issues in my eyes:

    1. In chapter 3 you have this avatar image and a hover reveals a bio. But as we all know, you shouldn’t hide content from “mobile” (read “no hover”) users – but that’s exactly what you are doing here. That’s also the reason why I often think twice if I add a hover effect to anything. Because what’s it worth, if mobile users – a share steadily growing – can’t see it? And often making a good hover effect can be quite some work.

    2. You suggest a solution where the user can choose between touch and hover, but that’s a choice you shouldn’t pass on to the users; some may even not know, what that is about. In my eyes a site should “just work” – and that’s an option that makes things way to complicated for users.

Impress us

Be friendly / use Textile