Tuesday, June 23rd, 2009

ProtoFish: advanced hover menu

Category: Component, Prototype

ProtoFish is an advanced hover menu based on Prototype, written by Peter Slagter. You can easily add a delay to your menu (on mouseout) and choose your own hover class. All ProtoFish menu’s will respond to users who use the TAB-key to navigate through your page.

It is trivial to use. Once you load up the script (requires Prototype 1.6+) you can:


  1. document.observe('dom:loaded', function() {  
  2.       new ProtoFish('my-menu', '400', 'hover', false);  
  3. });

where the four parameters are:

  • Menu id (In the example: my-menu)
  • Delay before closing the menu (In the example: 400 ms)
  • The classname to add when hovering over menuitems (In the example: hover)
  • Whether or not the menu should remove .active classnames when your visitor hovers over the menu (In the example: false)

Posted by Dion Almaer at 5:05 am

2.8 rating from 64 votes


Comments feed TrackBack URI

Well, the fallacy here is that a menu like that should not work with tabbing but with arrow navigation – much like any menu like this in real apps behaves.

That way the YUI menu is still the only free menu system that supports assistive technology, works for keyboard users and is fully styleable. Yes, it is more code to write, but it works for people and has been tested by people. Personally I think it is time to switch from “amount of code” to “amount of human impact” to judge the quality of a solution.

Comment by ChrisHeilmann — June 23, 2009


It’s generally a good idea to refrain from absolutes, your comment being a good case in point. Dojo also contains a free menu system that supports assistive technology, works for keyboard uers and is full styleable.

It’s likely that there are others also.

Comment by sos — June 23, 2009

@sos true, I’ve seen some great work in Dojo around ARIA and support of AS. If you know more good examples, please do show links.

Comment by ChrisHeilmann — June 23, 2009

If you scroll down so the menu is at the bottom of your browser, the menu displays outside your viewable area. You should pop it up inside the viewable area, so you don’t have to scroll to use it.

Comment by ebdrup — June 23, 2009


Re: links, you can always take a look at the nightly tests, e.g. http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Menu.html

Comment by sos — June 23, 2009

I don’t really understand why not more Ajax developers have implemented something like we’ve done with our SlidingMenu – http://ra-ajax.org/Docs.aspx?class=Ra.Extensions.Widgets.SlidingMenu – which I think is a far superior navigation menu to all others I’ve seen out there.
Kind of like a clone of the iPhone settings aplication…

Comment by ThomasHansen — June 24, 2009

@ThomasHansen Your demo breaks the back button, which is something of a usability no-no.

Comment by timdown — June 24, 2009

What do you mean “breaks the back button”…?
I just clicked the link, tested the menu and clicked back and that’s where I am commenting from…?

Comment by ThomasHansen — June 24, 2009

@ThomasHansen, I guess he means that navigating the menu does not introduce elements in the browser history.

To me, your iPod-like-menu looks nice, but has very poor responsiveness. I select an option and it takes a lot of time to open it. (Firefox 3.0.11, WinXP) Oh, that and I think that that kind of menu works well on the iPod, where you can, with a gesture go back a level. But having to use the breadcrumbs to navigate back to an upper level kind of detracts from the whole experience.

Comment by Venkman — June 24, 2009

Thank you for the compliment :)
The reason why it feels slow is mainly because it’s deployed at a server in Norway and every “selection” triggers an XHR request towards the server. If deployed on a fast server in your own country (or some place which is not the “outer rims” – like Norway) it will feel way more responsive…
As for me (I am in Norway) I get about 350MS for XHR requests to finish up, which I think is acceptable for this type of logic…
All though it could run way faster then that too, I’ve seen it at less then 50MS, but this depends upon how heavy the server-logic running to load up the menu is. For this solution it requires dynamically loading UserControls and all sort of “advanced stuff”…
The reason why it goes to the server is because the child menu items are being dynamically built. This means among other things that you could have *millions* of MenuItems without increasing the initial load time at all, letting the user navigate inwards in “infinity”. Imagine something like this for instance for Yahoo Categories or http://dmoz.org and you get the reasons why we built it like that.
So if you use FireBug to inspect the DOM tree you’ll see that all though this particular sample have the File and Edit menus being rendered “statically” (part of original DOM and markup), the “Window” node is being dynamically built on server only when *requested* by the user. try navigating LONG into the “Window” menu items hierarchy and you’ll understand this…
Also check out the code (C#) by looking at the “Code” tab…
Regarding why we built it like this is because where I work now (as a consultant) we needed something that was a “tree structure” but at the same time a “navigation structure”. And a conventional TreeMenu didn’t feel right to use as navigation (we started out with this one; http://ra-ajax.org/Docs.aspx?class=Ra.Extensions.Widgets.Tree – in fact, but it didn’t “do justice” towards the domain problem)
And we could have implemented only the “back button” like the iPhone have done, but we felt for a normal website the full breadcrumb was more right since on the iPhone the only reason I think they have not used a complete breadcrumb is (I suspect) because of lack of physical space on the device…
Regarding “preserving the history” when clicked – if Venkman is right, I don’t really see the relevance. Would you do that for an Ajax TreeView or like for instance the Ajax Menu in this main article…?
Does the Ajax Menu in the main article do that…?
Does *any* Ajax menu do that…?
Sure when you actually do a “navigation” by clicking a LinkButton or something within the Menu one could (and probably should) somehow preserve the history, but not for expanding and such which this really is a demonstration of…

Comment by ThomasHansen — June 24, 2009


First, I was looking at the wrong thing: I was clicking on links in the class browser widget at the top of the main content, which is not directly relevant here (though I would expect clicking things in that to stay in the browser history).

Second, I wouldn’t expect the sliding menu widget to add items in the history until you actually navigate to a new page from it, you are right.

My apologies. I replied too quickly and dismissively, and I was not specific enough in describing my issue.

Comment by timdown — June 24, 2009

Hahahaha…!! ;)
Get it, and you’re probably right yes :)

Comment by ThomasHansen — June 24, 2009

ProtoFish has been updated with ARIA keyboard best practices for menu’s, and with some other minor usability improvements.

Also, due to its popularity, we’ve decided to give it it’s own home @ http://protofish.procurios.nl/.

Thanks for the comments!

Comment by pesla — July 14, 2009

Leave a comment

You must be logged in to post a comment.