Wednesday, December 13th, 2006
Building a Fish Eye Menu
Alexei White has written a post on Building a Fish Eye Menu in which he goes over iterations of his development of a fish eye component.
- Iteration 1 - Proximity Detection and Scaling
- Iteration 2 - X-Axis “Zoomingâ€
- Iteration 3 - Alignments Left, Right, and Center
- Iteration 4 - Labels and Menu Item Activation (Bouncing)
- Iteration 5 - Container Object and Y-axis Zooming
Are people into less conventional UI components like Fisheye, or are they strictly eye-candy with no practical role in enterprise software?
I know there are still things that Fisheye can use in the way of functionality. It would be nice, for example, to have vertical orientations for the menus, and also to be able to attach traditional drop-down menus to each element. I would also like to see context menus and groupings.
4.4 rating from 52 votes
The only study I’ve seen that indicates fisheye widgets are better is one where they tweaked drop down menus to have several hundred ordered entries (e.g. countries of the world alphabetically). Fisheye menus were shown to be better than both submenus and scrolling options and (I believe) slightly better than the multi-column dropdown used in programs like the old Netscape navigator.
For the dock, the size and lack of ordering leads me to believe that the only benefit of zoom is being able to spot the mouse position. I preferred my popup folders of aliases on OS 9.
As for non-typical widgets in general, there are plenty of good widgets that aren’t about eye candy. The zoomed out mini-map on yahoo and google maps, for example, provides context to the main view. The address autocompleter on current webmail apps isn’t typical elsewhere, but it’s quite useful. I have my own set of custom widgets, which tend to revolve around autocompletion. e.g. Many to Many relationships tend to be troublesome for widgets, particularly when the number of choices on one side is large. My InputList widget mixes an OL for removing/displaying active relationships with an autocomplete box for adding relationships.
Good stuff. Nice to see someone’s thoughts on building something like this from a user experience / interaction perspective. (Pity there’s no live demo to play with just yet.)
Here’s an live example of a Flex Fisheye component I posted a while back:
Flex fisheye
And a 2D version, for packing larger numbers of items into a small space:
Flex 2D fisheye
In addition to the points Alexei raises in his excellent writeup, the example addresses a few other issues:
* limited space Most implementations of the fisheye/dock effect I’ve seen zoom up the items based on distance from the mouse, and either overlap, cluttering the display, or simply take up more space to account for the larger items. This effect works in some situations, but more often than not, the fisheye needs to play within a fixed allocated space in the UI. This implementation adjusts the parameters of the zooming/falloff equation to make sure that the items always fill exactly the space provided.
* predictability Many fisheye implementations — especially those that try and deal with limited space — have little or no correlation between the location of an item in its ‘rest’ state and the location of that item when zoomed in. As a result, when the user tries to mouse over an item in the list, they inevitably find that the item ends up somewhere other than where they expect it, and have to re-hunt to find it once the fisheye is actively zooming. The mosue location to activate an item should be identical to the location the user sees it at when the fisheye is at rest.
* direction and alignment Alexei addresses the question of alignment, but vertical fisheyes that can align top, middle, and bottom are valid as well.
* 2D The original intention of the fisheye research cited by Alexei is to help users quickly search through a large number of items presented in limited detail, then refine their selection with additional ‘zoomed’ detail quickly. While a 2D fisheye component presents other usability challenges (i.e., in my opinion fast searching of a sorted list in wrapped 2D layout is harder than a 1D layout), it can be used for fast visual scanning of much larger amounts of data than its 1D counterpart.
More details, and source, available here:
Fisheye Components
Ely Greenfield
Architect, Flex SDK.
Dojo has a working Fisheye widget too. http://www.dojotoolkit.com/dojo/demos/widget/Fisheye.html
Hey Ely. I’ve seen your fisheye implementation in the past and its amazing. The 2D presentation is interesting because you have to affect items in the peripherie (non-zoomed items) as well as those in focus because of the limited space. The result is you can’t use your peripheral vision to scan items along the edges because they’ve been zoomed right out of view.
I agree with you completely about predictability. The important thing there is if people make really quick gestures to grab a menu item, they don’t want to have to wait to see where the new position is. I’m getting better at this:
Couple demos:
http://blogs.nitobi.com/alexei/media/demos/feye1/2.html
http://blogs.nitobi.com/alexei/media/demos/feye1/1.html
Hey, cool, live demos!
They feel really nice and responsive. They do seem to suffer from predictability though…I imagine the more items you add, the more offset the zoomed position of an item would be from the unzoomed position. You’re right about the loss of periphery, but that’s the price I think you have to pay if you want to combine predictability and constraints (either size, or alignment).
I built a fisheye menu that is much more simplistic, maybe someone here can get use out of it. It just swaps images and expands, and adds a caption underneath the image. http://marcgrabanski.com/code/fisheye-menu/
aa