16

I see here a lot and lot of comments that now some things are one click further away than they used to be. And at the same time I see there will be no rolling back. And I don't really care who is right, but I think I might have an idea for small compromise:

Could you maybe make a top bar auto-expand it's goodies on mouse over? I mean, when someone holds a mouse over inbox icon, why not to show that inbox, without additional click? That way things will suddenly be one click closer, as many users seem to want, without any changes to top bar's look.

Of course they should auto-hide when mouse is taken away, unless they were clicked to open - then they should stay. And auto-expand should be suspended if other piece is click-expanded. And if user clicks hover-opened icon, it should not close, it should count as click-opened now. In other words, click-open should continue to work, and should take precedence over hover. That way clicking would continue to work as it works now, and tablet users will see no difference.

The delay before displaying elements should be as short as conveniently possible. Probably like the one used to expand established user's card. But it should also work OK with no delay at all. That's not the point of this request.

screenshot with freehand circles

Improve this question
22
  • 1
    There is a duplicate out there....
    – juergen d
    Commented Dec 6, 2013 at 8:36
  • @juergend wasn't able to find. If you can, please vote to close, and I'll gladly upvote original.
    – Mołot
    Commented Dec 6, 2013 at 8:36
  • 2
    @juergend I still think mine is more detailed and slightly different in minuscule details, but I added my close vote, and will continue there.
    – Mołot
    Commented Dec 6, 2013 at 8:45
  • 3
    The questions are related but not duplicates. I think some of the reasoning behind a lack of hover-action was for tablet users.
    – Duncan Jones
    Commented Dec 6, 2013 at 8:55
  • 2
    @Duncan But I'm not against clicking. I think clicking should work as it works now. Adding hover does not prevent click action.
    – Mołot
    Commented Dec 6, 2013 at 9:21
  • @Gilles I mean that when you hover mouse over icons in my freehand circles, let's say an inbox, then inbox should get expanded as if you clicked that icon. And delay should be long enough to prevent expanding when you just move your mouse there accidentally, on the way from the site to the browser's controls, but no longer. Like the delay you get with tooltips. Nothing is supposed to change it's place, things are supposed to appear and disappear. If my language is not clear, sorry. I did my best, feel free to edit with language clarifications if you can do better.
    – Mołot
    Commented Dec 6, 2013 at 9:41
  • 2
    Ah I see. I'm changing my opinion to NOOOOOO!!! Not a delay until something happens. It means the sequence is move the mouse, wait, the good stuff happens. Take out the wait.
    – Gilles 'SO- stop being evil'
    Commented Dec 6, 2013 at 9:44
  • @Gilles Have you taken out the wait time for tooltip from your browser? ;) But I don't care about the delay, really. I could upvote answer saying "OK, but without the delay". I described it with delay as all on-hover things here happens with it now. Hover mouse over my avatar under the question, please. That's exactly the same delay I'm talking about.
    – Mołot
    Commented Dec 6, 2013 at 9:48
  • 4
    No delay means annoying people with it flashing up unexpectedly. With a delay means having to delay open, as well as closing (incase accidentally moving mouse out the area briefly) - basically, all that extra effort and calculation and all the delays to interaction, you're not really saving the user any actual time at all. Just keep a click - everyone knows how that works, it works on all devices.
    – JonW
    Commented Dec 6, 2013 at 10:09
  • 2
    Also - it's definitely not a dupe of that - it's a different interaction; having the hover-to-open effect after a user has already clicked to interact with one control means the user has already chosen that they want to interact with those controls. Similar situation, but it's definitely different (says the UX.StackExchange mod!)
    – JonW
    Commented Dec 6, 2013 at 10:12
  • 1
    @JonW With delay around 0.1s I think I am saving a bit of time - it's easier to move cursor around at moderate speed until what I want is opened, than to click and hope I don't miss-click. Many people here said click target is too small. You are not one of them, and this feature is for them. But as I wrote, I do want to keep click intact. I want to add to it, not to change it. I can live with the way it is now, but as I was seeing here on this meta, for many it's irritating. What is now already proven in real life test to be a not-good-enough UX for some user.
    – Mołot
    Commented Dec 6, 2013 at 10:34
  • 1
    @Mołot: There's an interesting post on ux.se about this sort of thing - top answer has some great points: ux.stackexchange.com/a/10410/3865
    – JonW
    Commented Dec 6, 2013 at 11:01
  • @JonW but it also ignores the fact that click target is too small to conveniently click, and it seems at least 48 people thinks it is. So there is a need for an improvement, and while this one is not great, no denying it has flaws, it's the best I was able to think of. I'll gladly upvote any alternatives :) Feel free to link us to them.
    – Mołot
    Commented Dec 6, 2013 at 11:04
  • @Mołot: But hovering requires more precision than clicking. You have to get it into the right area and hold it there for the right amount of time, not moving your mouse out of the way by mistake. Perhaps a better solution is to increase the overall size of the content area itself (which I see that linked answer sort of suggests too - by adding back in the username).
    – JonW
    Commented Dec 6, 2013 at 11:07
  • 1
    FWIW, the delay-on-mouseover is sometimes referred to as "hoverIntent", and there's a decent jQuery plugin for it (of course!): cherne.net/brian/resources/jquery.hoverIntent.html -- as can been seen in the code (github.com/briancherne/jquery-hoverIntent/blob/master/…), the "tons of calculation" bit is a little overstated. I am not intending to endorse or reject the idea in the OP, just speaking to the actual lack of difficulty implementing non-twitchy mouseover/mouseout events on menus and such, based on velocity rather than strictly a timer.
    – Chris
    Commented Dec 6, 2013 at 18:13

2 Answers 2

Reset to default
4

I appreciate the suggestion, but for the reasons JonW elaborated in his answer, I just don't think it would be a good idea. When you start mixing hover and click there are a lot of edge cases, and when you fix one you create another.

However, I think the other idea has merit, and plan on marking it "status-planned". Don't require a click to switch between sites, inbox, and Achievements on the new topbar

Improve this answer
2
  • That other issue means the menus will basically work as they do on desktop apps - view the menubar in Firefox- menus don't open on hover - however once you click one to open it (such as 'File') and move over to the next one they all open when you hover. That's a far better interaction and a good compromise between hover-lovers and click-lovers.
    – JonW
    Commented Dec 6, 2013 at 16:02
  • As long as it's addressed somehow, I don't mind which way it went :) I posted before I seen the other one, and if all my post did was to bring recognition and attention there, I'm happy.
    – Mołot
    Commented Dec 6, 2013 at 18:48
5

Posting an answer as it's all going on in comments and should be an answer instead.

Hovering isn't as user-friendly as you'd think it is, we asssume it's a good option but it comes with many negatives, namely:

  • flashes of opening/closing items when hovering over them by mistake
  • hovering and then moving the mouse out the way closes it when that might not be required.
  • If you add a delay to counteract this issue that means when the mouse is out of the area it's covering up some content on the main page - and you probably want to see the content instead of the menu at that point.
  • Hovering requires more precision to interact with than a click does as it requires the user move their mouse there, keep it in one place and then move the mouse down to the option they want, all the while keeping it within the small boundry area of the item to stop it closing on them.
  • Hovering doesn't work on touch devices - I know there are workarounds for this - allowing click to open for some devices and hover for others - but that needs user agent detection, or CSS variations and it's still not guaranteed to trap all devices (as I found from experience).
  • You have to determine the optimal delay time between hovering and displaying - just enough so that users don't start clicking it thinking nothing is happening but no so fast that it starts flashing around when rolling over it.

Most of the issues are going to be around adding in the correct delay period, but this delay period is going to be percieved differently for different users.

Also, they might start clicking it instead of hovering; so what do you do in this situation - they've hovered, then think they need to click so they do so, but then menu has since opened due to the hover delay period - now what? Do you close the menu?

  • Clicking the menu item again closes it - that's going to annoy users who didn't notice that it had opened via hover and have clicked thinking it's going to open.
  • Clicking the menu doesn't open it - that's going to annoy people who want to dismiss it as clicking to open/close is a pretty common pattern.

Mixing in hover and click together as different interaction methods for the same control is always going to throw up situations like this, so it's safer to pick one and stick with it than try to compromise and offer multiple ones to try to please everyone.

There's a discussion on UX.StackExchange about the benefits of hover menus if you (or anyone else) is interested. This is a slightly different case, but it's still useful anyway.

Are hover menus in headers easy to use?

Basically - introducing hover-interactions brings more problems than it solves.

Improve this answer
7
  • "now what? Do you close the menu?" - I have already clarified that part in question. I guess you wrote it before you had a chance to read that clarification. And again - I respect your disagreement, but there are dozens (quite literally) of people here that does not think clicking as implemented now to be useful, and looking at vote counts more people finds clicks as they are wrong than right, so just sticking to them is not so good answer. If something fails to work, it should be improved or supplemented, shouldn't it?
    – Mołot
    Commented Dec 6, 2013 at 11:35
  • 2
    OK, seen your update. However I still see issues with it - if it's been opened via hover accidentally and the user moves away that means it's going to stay open even though the user didn't want it to be, thereby proving a distraction away from the main page content. My overall point is that people may think they want it to work on hover, but in practice that's going to kick up a load more issues. If the question was 'it shouldn't open on hover initially, but once clicked and opened then moving left to right to inbox, reputation and back those should hover open' then I'd be with you.
    – JonW
    Commented Dec 6, 2013 at 11:42
  • There is an alternative request you already know about, that describes what's in your last comment, isn't it? Feel free to salvage anything from my post (like images) to improve it if you want. I will not turn this one into a dupe. If it'll be declined, so be it.
    – Mołot
    Commented Dec 6, 2013 at 11:47
  • 1
    @Mołot "dozens", please understand your sample size there. It's very small, consists of power users who are involved in meta, and is a very, very tiny fraction of the millions who use our sites. Statistically you get people who dislike something responding more than those who like it - and that's what you see here, the small percentage who do like hover and are looking for it. You are however perfectly welcome to use a user script to modify the behavior any way you like.
    – Nick Craver Mod
    Commented Dec 6, 2013 at 11:53
  • @NickCraver there is significantly less people on metas than on main sites, so your argument about sample sizes is perfectly valid to decline each and every feature request, no matter up/downvote ratio ;) (Note, I'm not saying it's wrong). But with this closed as duplicate, it's a moot issue now, anyway.
    – Mołot
    Commented Dec 6, 2013 at 11:57
  • How about simply having a setting to turn hover on and off?
    – ike
    Commented Dec 6, 2013 at 15:37
  • 3
    @ike: I think one of the most terrifying words you can say to a developer is 'simply'.
    – JonW
    Commented Dec 6, 2013 at 15:59

Not the answer you're looking for? Browse other questions tagged .