WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 13 months ago

#23731 new enhancement

Use jQuery Menu Aim to improve responsiveness of our admin menus

Reported by: markjaquith Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: ui, javascript Cc:

Description

This is a fantastic read: http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown

And it resulted in an MIT-licensed jQuery plugin that we should absolutely consider using to improve our menus: https://github.com/kamens/jQuery-menu-aim

Attachments (3)

23731-POC.diff (13.4 KB) - added by Otto42 2 years ago.
Proof of concept - testing the idea
23731.patch (13.4 KB) - added by ocean90 2 years ago.
23731.2.patch (13.4 KB) - added by ocean90 2 years ago.

Download all attachments as: .zip

Change History (23)

comment:1 @petskratt2 years ago

absolutely. and pls make sure it is easy to be used also outside admin (current component designation for this ticket) - in themes etc. been waiting for it 5 years, from the moment I learned about the triangle rule when disassembling a dysfunctional mega-menu

comment:2 @scribu2 years ago

I'm not sure how well this would work with the minimized menu, since it's so narrow.

Last edited 2 years ago by scribu (previous) (diff)

comment:3 @simonwheatley2 years ago

I think this is a great idea (and after I drew a diagram of how this would make her less frustrated on the Internet, so does my wife). Can/should we run some tests?

comment:4 @rzen2 years ago

I am fully in favor of this. It could be used to benefit both back- and front-end UX (after we educated theme makers, naturally).

@Otto422 years ago

Proof of concept - testing the idea

comment:5 @Otto422 years ago

No better way to see it than to try it, so here's a testing-the-idea patch against trunk. It seems to work but needs some adjustment on the leaving-the-menu and a few other minor things. But, in general, it does seem like something of an improvement.

See 23731-POC.diff for test patch.

comment:6 @Otto422 years ago

Playing with it a bit, I find a slight improvement on the "Comments" menu (which has no submenu) by using rowSelector: "> li" instead. This makes it activate on the comments menu, which can cause it removes the currently open menu (like Pages) when the movement is in the "wrong" direction.

Tweaks like that, along with adjusting the timing, could be a real improvement.

comment:7 @simonwheatley2 years ago

  • Cc simon@… added

comment:8 @ocean902 years ago

  • Cc ocean90 added

@ocean902 years ago

comment:9 @ocean902 years ago

23731.patch uses rowSelector: "> li.menu-top".

Seems like the deactivate event isn't fired when the submenu will be left with the mouse. To solve this I have added the menu.on( 'mouseleave', part.

comment:10 @wycks2 years ago

  • Cc bob.ellison@… added

+1 these speed changes really make a diff

comment:11 @TJNowell2 years ago

  • Cc tom@… added

comment:12 follow-up: @markjaquith2 years ago

ocean90 — With your patch applied, I find that it's not forgiving enough, when moving diagonally. Also, menus sometimes get stuck closed, and require a hover over another top level item to reset them.

comment:13 follow-up: @Otto422 years ago

Instead of using the mouseleave directly, try using the enter and exit functions that the menuAim adds instead.

comment:14 in reply to: ↑ 13 @ocean902 years ago

Replying to Otto42:

try using the enter and exit functions that the menuAim adds instead.

I tried exit, but exit was also fired, when I moved the mouse in the triangle where the submenu should be still visible. Could be a bug in menuAim.

comment:15 @Otto422 years ago

Oh, nevermind, I see what you were doing. I missed that the mouseleave was on the menu as a whole. Yes, the exit will fire when the menu item is left, even when inside the triangle, so that would be the wrong thing to use.

@ocean902 years ago

comment:16 in reply to: ↑ 12 @ocean902 years ago

Replying to markjaquith:

ocean90 — With your patch applied, I find that it's not forgiving enough, when moving diagonally. Also, menus sometimes get stuck closed, and require a hover over another top level item to reset them.

Does 23731.2.patch a better job?

Edit:
Not good enough. Since the menu hasn't the full height as #adminmenuback, it's hard to move the mouse to the last submenu without closing it directly.

Last edited 2 years ago by ocean90 (previous) (diff)

comment:17 @markjaquith2 years ago

Better in some ways, but not quite forgiving enough, and yeah, the bottom menu is tricky.

Also, it would be nice if we didn't lose the jQuery hover intent stuff for when someone is hovering a submenu and they go off the bottom for a short moment.

comment:18 @azaozz2 years ago

The "triangle" idea is pretty good: delay hiding the submenu if the mouse is travelling in that direction. This only applies to somewhat wide vertical menus (does not work/is not needed for the folded admin menu and the toolbar).

The implementation (menu-aim.js) needs a bit more. For example doing $(document).mousemove(mousemoveDocument); is pointless and slow. Not tracking mouse move speed also makes this feel not as good as the current menu.

Don't think this is a replacement for hoverIntent, rather see it as an enhancement built into hoverIntent.

comment:19 @mercime2 years ago

  • Cc mercijavier@… added

comment:20 @jeremyfelt13 months ago

  • Focuses ui javascript added
Note: See TracTickets for help on using tickets.