8

The behavior of the site switcher, inbox and achievements drop-downs in the new top bar seems inconvenient and unintuitive to me. I would like to propose a change to it.

Expected behavior:

  • Every drop-down menu opens when clicked, and closes when clicked again. If any drop-down menu is clicked while another menu is open, the previously open menu should be closed and the new one should be opened.

  • The drop-down menus in the new top bar are not hover menus. They should not be affected in any (non-cosmetic) way by hovering the mouse cursor over them.

Current behavior:

  • Every drop-down menu opens when clicked, and closes when clicked again (as expected).

  • If the help drop-down on the right is clicked while one of the left-hand side drop-downs (site switcher, inbox or achievements) is open, or vice versa, the previously open menu is closed and the new one is opened (as expected).

  • When one of the left-hand side drop-downs is opened, the other two magically turn into hover menus: hovering the mouse cursor over them opens the new menu and closes the previously opened one. This feels inconsistent and unexpected to me.

  • As a side effect of the above, if one of the left-hand side menu icons is clicked while another menu is open, both menus close!

The last effect is, IMO, the most annoying one. It's most easily noticeable on touch screens, where touching the icon immediately triggers a click without any preceding hover period. However, it's possible to observe this effect on conventional desktops too, since, depending on network latency, some of the menus can have a brief delay before they fully open when hovered over for the first time.

Ps. If the current behavior is kept, it might help if the styling was changed to make it clearer that clicking one of the menu icons "activates" all of them. It would still be annoying on touch-screen devices, though.

Improve this question
10
  • 6
    The magic hover behaviour was annoying me as well. I use the keyboard shortcuts, and if I then accidentally move my mouse I suddenly am looking at a different menu. Rather annoying.
    – Martijn Pieters
    Commented Dec 14, 2013 at 11:45
  • 1
    I don't dislike the current design (but I don't love it enough to really care one way or another). But I'd hardly call the behavior inconsistent. The behavior is very similar to Windows menus. Once one is open, all of the menus in the menu bar turn into hover menus.
    – psubsee2003
    Commented Dec 14, 2013 at 11:59
  • @psubsee2003: Does Windows do that on touch screens too? (I honestly don't know, having never used any version of Windows on a touch-screen device.) Also, AFAIK, Windows menus don't have any noticeable loading delay when first opened. Still, good point; that's probably what the current behavior is supposed to imitate.
    – Ilmari Karonen
    Commented Dec 14, 2013 at 12:06
  • @IlmariKaronen can't speak for touch screens either, I've never used Windows on a touch device in the current generation (I used Windows Mobile 5? once upon a time). I'm referencing the hover via Desktop versions of Windows. The help menu is obviously not consistent, but the other 3 are behaving exactly like Visual Studio is (which is what I have open at the moment).
    – psubsee2003
    Commented Dec 14, 2013 at 12:09
  • "This feels inconsistent and unexpected to me" - why? What OS have you been using? Windows and KDE and Gnome works that way.
    – Mołot
    Commented Dec 14, 2013 at 12:30
  • @Mołot: JavaScript menus on the web generally don't, though. And the top bar isn't really a very good imitation of an OS menu bar, with its "webby" design and frankly rather slow responsiveness. Indeed, it hadn't even occurred to me that it might be trying to imitate one, before psubsee2003 suggested it above. (Ps. If the current behavior is kept, it might help if the styling was changed to make it clearer that clicking one of the menu icons "activates" all of them. I just edited the post to add that.)
    – Ilmari Karonen
    Commented Dec 14, 2013 at 12:37
  • The menus work fine and consistently for me. They respond similar to Windows UI menus and I have no problem with it. I also don't find that I can open two menus at the same time (as mentioned in your sentence: if one of the left-hand side menu icons is clicked while another menu is open, both menus close!). How did you do it?
    – ADTC
    Commented Dec 15, 2013 at 8:27
  • 1
    I think I understand how you get your last problem in the touch screen. I usually have the same issue with hover menus on touch screen phones, where it's sometimes impossible to get the menu to pop up without following the link. I think SO can change this so that clicking will only close the menu if it is already open. Otherwise it should open the menu and close other menus.
    – ADTC
    Commented Dec 15, 2013 at 8:31
  • 1
    The top bar behaved in the way you expected, until someone came up with an idea that resulted in the current behavior. So this is now a counter feature request against the other one. It is just hard to satisfy everybody.
    – Antony
    Commented Dec 15, 2013 at 8:52
  • @ADTC: That was a bit poorly phrased: instead of "both menus close", I should've written something like "both menus end up closed". I suspect what's actually happening on touch screens is that the clicked icon indeed gets both a hover and a click event in quick succession, causing it to open for an imperceptibly short time and then immediately close again.
    – Ilmari Karonen
    Commented Dec 15, 2013 at 13:28

1 Answer 1

Reset to default
3

Most of the problems mentioned are due to StackExchange menus emulating GUI menus. In Windows, and other GUI like KDE and Gnome, when a menu is clicked, moving to other menus will close the currently opened one and open the one pointed to. This is exactly how StackExchange menus behave and it is consistent.

However, for touchscreen users who do not have the ability to "hover" the mouse pointer over something (except on very recent special hardware that can detect finger hover), StackExchange could fix the last problem of all menus disappearing when the user attempts to open a different menu.

For this problem, I propose that StackExchange should only close the menu tapped on if it is already opened. In the event that another menu was open, tapping should close that menu and open the menu that was tapped on.

It may be necessary to time this as the operating system could send both a "hover" signal and a "click" signal in quick succession when the touchscreen user taps on the menu icon, which could be misinterpreted. The time delay between hover and click could be checked, and if it is less than a certain threshold, the above mentioned behavior could be used instead of the present behavior.

Improve this answer

You must log in to answer this question.

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