Add hoverintent support

I don't see a usability problem with the current hover behavior. However, if someone steps up to implement and test this, I'll be happy to review any patches posted here. Please assign this issue to yourself, if you are working on a implementation.

If no one works on this issue until April 1st, I'll mark this issue won't fix.

please try out the hoverIntent demos at http://cherne.net/brian/resources/jquery.hoverIntent.html

The hoverintent is great. Maybe it is easy to implement.
But since admin_menu is rather thin and at the very top of the page, I feel it is not really needed. Your hardly ever cross that area unvoluntarily. What would be more interesting is to find a way to keep the nested menus easier accessible - I miss them very often trying to press. Maybe a similar script could help, making it stay for one or two seconds, so you get a second try?

@eigentor: If you mean mouseout delays, that has been added to Admin Menu 5.x-2.2, released on 2007-01-08.

But since admin_menu is rather thin and at the very top of the page, I feel it is not really needed. Your hardly ever cross that area unvoluntarily

I completely disagree. Due to the menu's orientation and dimentsions, it often occupies 95 to 100% of the screen-width (not browser width) and 20 or 30 pixels vertically. That means that every time the user moves the mouse from the browsers page-area to the browser's toolbar, menu, url bar, bookmarks or search box, the mouses passes over (albeit not for long) admin_menu. The menu pops up and distracts them from their task. This occurs frequently in an average browsing session. Having a delay on mouse-out exaggerates this issue because the distraction lingers for even longer.

A mousein/onhover delay would help resolve this issue, but then you don't want to delay the showing if the user is actually intending to open the menu, and not just passing over. hoverIntent deals with this issue effectively.

hoverIntent would be definitely cool.
Moving the mouse from the browser's viewport to the buttons or location bar hovers the admin_menu bar and thus shows a menu, which can be a real (although not major) annoyance.
AAMOF, I'd say admin menu is a perfect use case for hoverIntent.

However, supporting hoverIntent is probably a snap for js-based menu, but I think admin_menu is currently css-based (:hover), and only uses js for IE6...
Hmm. Wasn't there a discussion about Suckefish menus ? :-)

Better title.

I love this module and use it constantly, but would like add my vote for a short delay before a mouse-over activates the dropdowns. I find it more than distracting - the drop-downs are often in the way of something I'm trying to get to on the page.

HoverIntent is beautiful!

Brushing the cursor over the menu should no longer drop the menu down, yet when you move the cursor to one of the menu items it will drop down seemingly instantly. I've only tested the patch with Firefox 3 on Ubuntu, so other tests are welcome.

This patch uses the minified hoverIntent.

The patch was actually created against 6.x-1.1, I'll see if I can get up a 6.x-dev version shortly.

Glad to see progress here. :)

However, please use an uncompressed version of hoverintent for now. Compression as well as minifying is generally left up to site maintainers who need to optimize performance.

Updated patch against 6.x-dev with uncompressed hoverIntent.js.

Woops, in a rush...

Nice work. Patch works on FF3, IE7 and Google Chrome on XP. Opera is a bit intermittent, but I don't think this is anything admin menu can fix. Looks more like an issue with the plugin. Bit more testing, and this might be RTBC.

Thanks. I just noticed that the menu will always pop up the first time you hover over it after a refresh, I think it may be due to a conflict of interest with the existing JS.

Found a fix with the help of cdale.

It turns out the CSS hover state was being triggered before the JavaScript had a chance to take effect. To get arround this we've used JS to add a new class so we can override the CSS hover state with #admin-menu li.hoverintent:hover > ul, this still allows the menu to drop down with or without JS enabled.

Tested in Fx 3, IE6, IE7 and Opera. It works exactly the same across the board.

Woohoo! I'm so excited this is finally implemented. Applies to admin_menu DRUPAL-6--1 and works like charm; http://www.youtube.com/watch?v=5qAdCaWeBpA

This is a huge step forward. A shame Superfish (which had support for this & more built in) couldn't have been used earlier (http://drupal.org/node/132981).

Which version of jQuery does this require? Does it work with a stock Drupal 5?

Erm. For whatever reason I do not see a difference after applying this patch (in Firefox 3 on Windows, that is). Of course I cleared all caches and stuff. No matter at which speed I'm moving over the admin menu, the menu item is hovered/displayed.

Fixed case in CSS comment. (minor)

Hmmm. It worked everywhere for me. Can you check if hoverIntent.js is loading into the page correctly by calling it from firebug once the page has loaded? Can you also verify your browser has loaded the modified file by checking it's source code via firebug? Do you have js-compression turned on?

Yes, yes, even checked both.

Note that the drop downs don't appear in Firefox 3.1 nightlies.

Hm. Firefox 3.0.3. I'll give it another shot.

Odd. And no errors? You've got firebug's console turned on? How frustrating.

Sun, D5 or D6?

I don't think jQuery 1.0.4 would be up to the task.

A big +1.

I have tested this on Drupal 5 and it works really well! (You need jquery_update 2 and backport admin_menu.js.)

This makes the admin menus work much more like menus in the OS. That is, a lot more clever and with a lot less frustration.

To select a sub menu item now in Admin menu you must carefully drag the mouse first to the left and the down. With this patch you can drag diagonally, the shortest way. Instead of constantly missing my target, it just works!

The Admin menu is so incredibly useful it more than deserves this kind of attention to user experience details.

> I have tested this on Drupal 5 and it works really well!

Did you mean Drupal 6? I'm surprised that the patch even applies to D5.

> Did you mean Drupal 6? I'm surprised that the patch even applies to D5.

Yes, Drupal 5. I of course needed to apply the code from the patch manually. As I mentioned you need jquery_update version 2 and you need to backport admin_menu.js from Drupal 6.

Thank you very much for the patch. This is a great usability improvement.

Sun, have you been able to get this working in your sandbox? Did you ever work out what the issue was?

It would be great to get this committed.

Unfortunately, not yet, but I'll try again. This patch needs to be re-rolled against latest 6.x-3.x.

Rerolled for DRUPAL-6--3.

I removed the CSS, since it appeared to be unnecessary.

Bevan, see my comment above at http://drupal.org/node/220100#comment-1116838

With your patch, hoverintent will not initiate the first time you hover the menu. You can test this by reloading the page and sweeping your mouse from left to right along the menu. The first time you do this the menu will drop down as if hoverintent wasn't there, however on the second attempt hoverintent will take effect.

#16 provides a solution to this problem.

Ah, I see. Thanks for that Rowanw. I was worried I might be reintroducing a bug by removing that code, but I didn't notice that bug and didn't understand the inline comments.

This version of the patch fixes that issue, though in a different way to #16, since it appears that no-JS is not supported in admin_menu v3. Therefore the simplest solution is to entirely remove the offending CSS.

It appears there is more CSS in admin_menu.css that is redundant now that admin_menu does not support JS-less browsers. However that should be dealt with in a separate issue.

I have only tested this in FF3 Mac and Safari 3 Mac, since I first want to get some approval from Sun or another maintainer that we are going in an acceptable direction with this, and that admin_menu 3 will indeed not support JS-less browsers.

Hm. What makes you believe that admin_menu no longer supports pure-CSS rendering without JS? That should (and must) still work. If it does not, then we need to fix it (in a separate issue) - however, it worked in my recent tests.

In general, I'm a bit concerned about the amount of JS we are adding/loading for admin_menu, especially in context to other desirable features for 3.x.
So - since this actually requires (more or less) a one-line change only, next to loading an additional JavaScript file, I wonder whether we could simply make this feature depend on http://drupal.org/project/hoverintent being installed? Note, just a thought.

The entire menu structure is added solely via AHAH – which requires javascript. How did you anticipate a JS-less version might work?

We could do this optionally depending on the presence of hoverintent, however we'd need to rewrite that module for drupal 6 and the new jQuery versions and techniques. Further, this feature is so beneficial to the user-experience, that it would be a waste to add it conditionaly. Hoverintent isn't really very big. concatenating and minifying javascript has a significant impact on performance if you (or others) are concerned.

It would be great to get this in. I know Sun doesn't consider that there is a usability problem at the moment, but I think adding hoverintent support would be massive improvement.

This is an improvement for any flyout menu, I've read an article on usability that welcomes couple hundred ms wait on hover.

Personally I find the instant flyout very annoying, usually the menu flies out when I'm trying to switch tabs in Firefox. I have a lot of modules installed so the settings menu is very long, that one is particularly disruptive, you can't ignore when something so big unexpectedly flashes before you (my mind is on the next tab already but flashing forces me to divert attention.)

When might this get included?

I think that hoverIntent does more than just add a 200 ms pause before activating the hover. I think it analyzes the speed and acceleration of the mouse cursor to determine whether the user was targeting the element it is currently hovering over or not.

Sun; Where is the 3 branch at? Where is this feature at? How can we get this into admin_menu?

Sun and I worked this out and I rerolled the patch accordingly. Attached, along with a renamed hoverintent file with CVS $Id$ tag.

Tested the latest patch in IE6, IE7, IE8 and the latest version of Firefox and Opera - it works correctly for each browser.

woohoo!

Subscribe. This would be nice.

It works correctly on Mac OS X (Firefox & Safari).

Hmmm.... Tried to reach someone of you in IRC.

I was about to commit this, but then tested... I think we want to apply hoverIntent to the (first) top-level items only? At least in my testing, I had to "wait" for second- and third-level menus to appear?

I vote for the first level only ;)

Yes - that delay on the second level items is not nice!

At the risk of confusing things, a script at http://blog.threedubmedia.com/2008/08/eventspecialhover.html (that HoverIntent's author Brian Cherne has mentioned himself recently) works better than HoverIntent; also because it measures average speed, the delay it introduces on the second level items is very natural - better than no delay, and better than the current HoverIntent delay.

Could we think of using this instead of HoverIntent?

I think eventspecialhover is a better solution to the second-level hover issues. I'll re-roll the patch if there is consensus

+1 for eventspecialhover from me too.

Here is a patch for eventspecialhover - hopefully it will apply okay - let me know if it doesn't work for you.

The same patch but applies and conforms to http://drupal.org/patch/create.

The method of special event hover doesn't seem to be as effective as hoverIntent to me. But I'm not sure if this is because it's difficult to intentionally simulate realistic behaviour, because FF tabs are next to the admin menu links, or it's just not as effective.

The patch is far simpler than the hoverIntent one, though it wouldn't be difficult to employ a similar technique as special event hover, which is to rename $.fn.hover to $.fn._hover and rename $.fn.hoverIntent to $.fn.hover. I wouldn't recommend this though, since it will affect other users of jQuery.hover(), possibly adversly (though probably for the better in many/most cases).

Both libraries solve the problem and I'd be happy with either getting in. hoverIntent seems to do a better job IMO.

Remember you can alter the parameters of eventspecialhover if you don't like it's current behaviour. I'm happy too though for either to get in. If you prefer hoverIntent Bevan, why not do a patch for it that fixes the 2nd level issue?

patrickharris, I don't think that it is an issue, since not using hoverIntent on those results in flashing all the items you pass over on your way to your destination; which is part of the problem we are trying to solve. I guess it's a matter of opinion, which I think is affected by how fluent you are with your pointing device and how used to the flashing menus you are.

Temporarily bumping to critical to get attention from maintainer.

This alternative patch does what hoverIntent does without requiring another plugin. It is set to shorter timers than hoverIntent uses by default. For my feeling, a short timer is fine; mostly the problem (to me) is having the menu come up when the mouse swipes over it, but if it stays there for even a few milliseconds it should open. I set it to 100. I played with it at 75, too, and I kind of like it, but the difference is pretty minimal.

This also reduces the hover out delay to 300ms; 400ms felt excessive to me.

Oooh, that helps a lot. I used it against 1.x and it applied there, too. I would set it to wait just a touch longer, but not too much. It still caught a few trips to the address bar but not as many.

Michelle

come on, Merlin, give us 250 :)

250 is too long to me, at least. Maybe I'm just impatient. Could see splitting the difference. =)

Merlin's patch doesn't apply for me with 6.x-3.x-dev:

Event Special Hover works well enough, but I've been using HoverIntent for over seven months without any problems, so I feel more comfortable with it.

I'm interested in testing Merlin's code but it doesn't look like it incorporates the main benefit of HoverIntent - which is that you don't have to wait for the menu to expand.

@Rowanw: The patch is against 1.x

Michelle

Sorry yes. I was directed here and I didn't notice the thread was for 3.x; my patch is against 1.x.

I'm interested in testing Merlin's code but it doesn't look like it incorporates the main benefit of HoverIntent - which is that you don't have to wait for the menu to expand.

Really? In the demos I saw I had to wait rather a long time for it to expand.

HoverIntent only fires when your cursor slows down to a set speed, so as soon as you get your cursor into position it should fire the event. People naturally slow down when hovering over a link anyway so they don't realise there's a 'delay'. There are two examples on the HoverIntent page - one's on default settings, the other has a 200ms interval which takes longer to fire.

Ah. Well, the delay in mine is so short that there's no real sense of waiting.

I just have to chime in to all the naysayers here that the usage statistics say different-- admin_menu is 6th on the list of most installed projects. Sixth! Moreover, all the projects above it have been included in core or are discussing/working toward core inclusion. It's also consistently in the 'top rated' and 'top downloaded' categories at drupalmodules.com. Sorry, but if we're going by the 80/20 rule here a handful of naysayers would be clearly in the '20' category. I'm quite confident that in this case the '80' will be disabling the core toolbar module and installing admin_menu but time, and usage statistics, will tell.

Yes I know these numbers are not absolute, but they can sure be used as a rough gauge. I have no clue of the details of the "not for novices" pronouncement (including the when, where, how, and who said it) so this is completely nonpartisan gut reaction on my part, but had it not been for some 'expert' pronouncement or the d7ux project, one has to wonder if this would even need to be a discussion.

And on a completely different tack, with all the important work to be done on core drupal, it seems really quite the waste of time to reinvent the wheel when an enormously successful tried and true contrib project, which has already worked out many of the same issues, is just waiting in the wings. It really leaves me head scratching.

Of course I don't yet contribute to core to this is all a big 'imo'-- take it or leave it.

@WorldFallz: Are you sure you're on the right issue? I know what you're talking about but I don't see how this relates to adding hoverintent? Did you get some tabs mixed up?

Michelle

Yep-- and then i accidently deleted it instead of unpublishing it. Sorry about that-- fat-fingering all over the place it seems. :-(

@WorldFallz: That's ok. :) Your point is very valid and I agree with you... just a little misplaced. :)

Michelle

Where is the right issue for what WorldFallz was talking about? I'd like to catch up :)

Didn't mean to stir the hornets nest, but you can see my post in it's proper context over at #543914: Administration menu or admin_menu should be in core. We now return you to your regularly scheduled issue....