Comments on: ProtoFish: advanced hover menu

By: pass4sure

pass4sure — Mon, 01 Mar 2010 02:20:01 +0000

Pass4sure is a leading study materials provider for IT Exams, especially designed for IT candidates who want to pass any IT exams offering study materials for many famous IT certifications, like Cisco, Microsoft, IBM, Sun, compTIA, HP, etc. Pass4sure also introduces some promotions, such as its Points for gift and Affiliate Program.The Most Popular exams List :640-816 642-415 642-072 642-357 PK0-002 650-180 350-018 642-145 N10-004 220-601 642-611 352-001 1Y0-A11 642-973 SK0-002 650-621 350-029 650-393 640-822 642-873 646-363 1Y0-A05 640-802 Click Passforsure to get more information!

By: pesla

pesla — Tue, 14 Jul 2009 09:49:23 +0000

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!

By: ThomasHansen

ThomasHansen — Wed, 24 Jun 2009 15:24:03 +0000

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

By: timdown

timdown — Wed, 24 Jun 2009 12:38:28 +0000

@ThomasHansen

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.

By: ThomasHansen

ThomasHansen — Wed, 24 Jun 2009 12:14:32 +0000

@Venkman
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…
.
@timdown
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…

By: Venkman

Venkman — Wed, 24 Jun 2009 11:05:56 +0000

@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.

By: ThomasHansen

ThomasHansen — Wed, 24 Jun 2009 09:32:51 +0000

@timdown
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…?

By: timdown

timdown — Wed, 24 Jun 2009 08:52:46 +0000

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

By: ThomasHansen

ThomasHansen — Wed, 24 Jun 2009 06:21:59 +0000

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…

By: sos

sos — Tue, 23 Jun 2009 22:05:41 +0000

@ChrisHeilmann,

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

By: ebdrup

ebdrup — Tue, 23 Jun 2009 18:44:36 +0000

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.

By: ChrisHeilmann

ChrisHeilmann — Tue, 23 Jun 2009 18:21:34 +0000

@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.

By: sos

sos — Tue, 23 Jun 2009 14:36:34 +0000

@ChrisHeilmann

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.

By: pesla

pesla — Tue, 23 Jun 2009 14:03:10 +0000

@ChrisHeilmann
You’ve got a good point. I’d like to add that this is only an initial release, the arrow navigation and other features (as well as fixing a bug with shift+tab) will be added in an update.
Updates will be published on the website and through Twitter. :)

By: ChrisHeilmann

ChrisHeilmann — Tue, 23 Jun 2009 13:13:08 +0000

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.

By: fcaldera

fcaldera — Tue, 23 Jun 2009 12:54:28 +0000

I wrote a related article one year ago about unobtrusive javascript delay applied to pure CSS menus a proof-of-concept and without libraries (you can take a look at this demo), in which I used the delay just to wait some milliseconds for unwanted "onmouseout".