A few days ago I was idly browsing the web when I ran across a nice little DHTML animation that zoomed in on text as you moved your mouse around it. The effect reminded me of the Fisheye Menus developed by Ben Benderson at the University of Washington. I remember reading about the concept years ago and thought was a great little bit of UI innovation. Well, one thing led to another, and shortly thereafter a Flex component popped out.
Try out a demo below…

I’ve been poking and prodding it in my spare time, and decided it’s far enough along to put out for anyone to play around with. So without further ado, here’s the Fisheye component v0.1. It’s available under the MIT Open Source license, so feel free to use it or modify it in your own applications.
1D Demo
2D Demo
Download Source
A couple of notes:
Flash vs. Flex
One important goal with this component, as with a bunch of things I’ve been working on lately, is to help the community see how you can merge the best of what flex gives you (productivity, development process, consistent component model) with the best of what people have been doing in flash for years (rich, highly interactive, fluid, etc). The SDK’s GUI components provide a lot of value, but they’re really just the tip of the iceberg of what’s possible with Flex. Hopefully these kinds of demos whet your appetite.
Item Renderers
The Fisheye component is based around the concept of itemRenderer factories, just like the flex list and charting components. The goal is to use composition to separate behavior from content, so you can reuse the basic fisheye effect across many different applications and uses. Take a look at the source and see how it’s done.
states as a contract
I’m experimenting a bit in this component with the idea of using view states to communicate state information form the component to its item renderers. In addition to telling the Fisheye component what to use as its item renderer, you can tell it what state to put the renderer in when it’s hilighted or selected.
It’s a nice idea, but it’s complicated by the fact that there’s only one state variable for each component. With this approach, for example, you couldn’t have the fisheye menu use states as a contract and have the item renderer itself use states to control whether or not it’s expanded or collapsed.
For what it’s worth, we actually identified this limitation when we designed states for Flex 2. We sacrificed this use case in favor of the simpler approach on the belief it would make it easier to understand and use in the more general case. I’m still hoping we can find a way to get the functionality in the next release.
Separating layout from intent
The Fisheye component uses a pattern that’s been coming up a lot lately where the intended layout of the component is not the same as the actual layout.
In this case, the fluid animation as you move the mouse across the component is built by migrating the actual layout of the renderers towards the intended layout (as determined by the mouse position) over time. Over and over again, I find myself writing layout routines that update external structures rather than the components themselves, and update routines that use a variety of algorithms to reconcile them.
It’s come up enough now that I think I’ll try pulling it out into a reusable ‘mixin’ for my next project.
Styling
I borrowed the styling used in the explorer from a mockup by one of the excellent designers on the Adobe Experience Design team, Ty Lettau. Thank god for designers.
Limitations
I’m a little embarassed to point out the original Fisheye Menu as an inspiration for this, since at this point I’ve really only copied the form and not the function. The Fisheye menu is intended as an alternate way to present a large list of information on one screen without having to resort to paging or scrolling.
But this Fisheye component doesn’t make any attempt to fit the contents to its space on screen. RIght now the layout is determined entirely by the value of its styles.
In the next version, I hope to have it dynamically adjusting those values to keep the items constrainted within the component’s bounds.
Useful?
Personally, I think the real promise of Flex is in the marriage of the productivity of the platform with the expressiveness of flash. But I’m curious what you think. Where should the flex team be spending its time in the next releases? On features that make it easier to build ‘expressive’ content like this? Or elsewhere, on other things? Like what?