Thanks to Robert for pointing out that oversized focusLength parameter values will screw up the rendering. I've fixed the problem and also added failsafes for oversized maxSize parameter values. It's recommended that you download version 1.01 here if you intend to use this component for your own projects.
-Sam

Thanks for all the feedback about the fisheye menu. I've received a few comments about the usability of fisheye menus, and wanted to respond by pointing out the research article cited in my previous post. A lot of research has gone into evaluating the advantages/disadvantages of fisheye menus vs. scrolling menus, including the original paper by Ben Bederson. Basically, fisheye views have a strong advantage in browsing scenarios, but scrollers have a slight advantage during goal-directed tasks (when user knows exactly what he/she's looking for). The focus length parameter is supposed to help the designer calibrate the trade-offs between focus and context, depending on the task.
Also, please note the fisheye menu component's "Focus Length" parameter, which allows you to specify how many full-sized menu items should appear near the mouse cursor. If you increase the focus length to 7 or higher, you'll be able to visually scan a large span of menu items without having to move the mouse.
To quote Ben Bederson, "The focus length parameter is important because it controls the trade-off between the number of menu items at full size versus the size that is used to render the smallest items. The fisheye menu dynamically computes the distortion function based on the available space and these input parameters. So, if the focus length is set to a large number (i.e., 20), then this will push the peripheral items to be very small, and as the user moves the cursor, there will be a lot of distortion. If, however, the focus length is set to a small number (i.e., 5), then there will be more room for peripheral items and they will all be a bit larger. Figure 2 shows this trade-off."
Many researchers have conducted comparative evaluations of fisheye menus and scrolling menus. The paper by Hollands et. al, cited in the previous post, is one such example. You can find related research either on the web, or at your nearest university library under the categories of "Human Computer Interaction", "computer science", "psychology", "human factors", and "cognitive science". Use the keywords "fisheye views", "fisheye menu", and "evaluation".
-Sam
View Demo
Download Source Code
PERSONAL NOTES
So I've read a lot of posts on the flashcoders mailing list lately, debating about the power vs. complexity of Macromedia components and whether we'd be better off with a thinner architecture. As a general rule in UI design, solid usability comes with a higher cost in development effort and testing, and Macromedia components are no exception to the rule. The architecture behind components such as the ListBox component allows Flash developers to extend the functionality of those widgets while re-using all of the coding efforts that made them so user-friendly in the first place. I think this fisheye menu demonstrates the extensibility of the Framework engineers' architecture. Not only is it usable, but it also smoothly inherits the FSelectableListClass functionality and integrates into the FUIComponent class hierarchy.
Flash developers might recognize fisheye menus from Joshua Davis' "Tsunami" special effect. Fisheye views have actually been around for much longer than Flash (Furnas, 1986). The main difference is in the mathematics and user interaction, which follow tighter constraints in a full implementation of fisheye distortion.
OVERVIEW
This implementation of the fisheye menu extends the original Listbox component. The Flash-based fisheye menu takes advantage of the natural vector scalability found in the SWF format, and adopts Macromedia UI Component techniques for quick development time and optimized run-time performance. The vertical distribution of menu items is based on the Sarkar-Brown distortion function. Menu items above the focus index are distributed with an inverted Sarkar-Brown function, and items below the focus index are distorted with a non-inverted function. Focus spanning is based on the design patterns found in Ben Bederson's Swing-based Java source code (http://www.cs.umd.edu/hcil/fisheyemenu/).
The fisheye menu is identical to the listbox component in every way, except for the vertical distribution of items. The fisheye menu supports all of the APIs, selection, multi-selection, and event-handling features found in the original Macromedia FListBox component. Four additional component parameters allow the user to customize the fisheye distortion effect:
COMPONENT PARAMETERS
Focus Length - Number of menu items shown at full size near the mouse cursor
Distortion - Degree of distortion in the Sarkar-Brown distortion function.
(Any integer greater than 0)
Max Size - Maximum height of a focused menu item
Highlight Border - Border color of the item under the mouse cursor.
REFERENCES:
Sarkar, M., & Brown, M. H. (1992). Graphical Fisheye Views of Graphs. In Proceedings of Human Factors in Computing Systems (CHI 92) ACM Press, pp. 83-91.
G. W. Furnas. Generalized fisheye views. In M. M. Mantei and P. Orbeton, editors, Proceedings of the ACM Conference on Human Factors in Computer Systems, SIGCHI Bulletin, pages 16--23, New York, U.S.A., 1986. Association for Computer Machinery. 10
Bederson, B. B. (November 2000). Fisheye Menus. In Proceedings of ACM Conference on User Interface Software and Technology (UIST 2000), pp. 217-226, ACM Press.
Hollands, J. G., T. T. Carey, M. L. Matthews, and C. A. McCann. "Presenting a Graphical Network: A Comparison of Performance Using Fisheye and Scrolling Views." Proceedings of the Third International Conference on Human-Computer Interaction. 1989. v.2. p.313-320.
Before I started building a Flash UI for the Movable Type blog, I needed a good collection of XML templates and parsers/converters. The first thing I built was an RSS converter, which allows you to asynchronously load an RSS feed, convert into a data object (for easier handling), and return the object to a callback method.
Here's a snippet from the internal documentation...
AUTHOR: Samuel Wan
DATE: May 2002
DESCRIPTION:
A factory object which parses an XML feed and returns the information
as a data object by passing the object as an argument to a callback
function in the specified callback target. Only works with RSS 0.91
or earlier. For complete documentation, refer to the Actionscript in
the first keyframe of the RSSDataFactory movieclip.
EXAMPLE:
this.receiveRSSObject = function(rssObject)
{ trace("Channel Title: " + rssObject.channels[0].title);
for(var i = 0; i < rssObject.channels[0].items.length; i++)
{ trace("Item Title: " + rssObject.channels[0].items[i].title);
}
}
rssObj = new RSSDataFactory()
rssObj.parseFeed("http://www.samuelwan.com/information/index.xml",
this, "receiveRSSObject");
My final paper in SI688 focused on tools for non-programmers to design interfaces. Much of this research seemed academic at the time of writing, but in these past few years, we've seen a surge of designers who have incorporated Flash technology into their skillset. As a result, what used to be a theoretical problem has now become an industry-level market: how to build a UI design environment which accomodates a wide range of programming skill levels. The final assignment required the interpretation of HCI research to a real-world technology, and I chose Flash MX as the most promising UI design tool in our industry.
Note: We had a 2000 word limit for the final paper, otherwise I would have written much, much more. Since graduation, I've continued reading and researching along the same lines of thought. One day, I hope to contribute to Flash, or some kind of UI design technology, so that the general populace, rather than a small niche of specialists, will have the ability to design powerful interfaces within their own abilities.
1. Flash-controled multi-user robot: Talked with the engineer behind the RCXDirect.jar toolkit for Java, he's generously adding some code to expand the number of motors controlled in a single byte-array command packet. Soon... real soon now. I'm also deciding between the xCam2 or a more expensive but higher quality wireless minicam for the robot. Have already bought an RCA video-USB reception converter from DLink for 60 bucks.
2. Flash interface to Movable Type: This weekend, will finish the XML template for index and archives. The current template outputs *everything*, which makes the download feed too heavy. I will break up the feeds into main index, sub-category, and article-specific. I'm also thinking of adding some code to parse the image tag in HTML.
3. Putting my course work online: The first thing I'll post online next week is my final paper for the course "Psychology of Information Systems". The paper is entitled "Interface Design Environments For Non Programmers". In the paper, I apply recent research in human-computer interaction from the Norwegian University of Science and Technology and Carnegie Mellon University
Svanaes to analyze the past evolution and future direction of Flash technology. My favorite homework assignment from grad school :)
4. OOP Actionscript: Well, the book is more or less finished, and the technical editors (Andreas Heim, Dave Yang) are poring through every line of code with their usual rigor and high standards :) I keep thinking up new topics that seem absolutely necessary for the book, but I'll probably write them on my own time and post online for people who have bought the book, since we're pushing the publisher's page-count limit already.
5. We have been accepted to present a project at SIGGRAPH, involving the new real-time video/audio/data server technology from Macromedia.
All this stuff going on while looking for a full-time job, and I thought I was going to get a summer vacation :-)
-Sam
The last chapter has been written for our book on OOP Actionscript. It was entitled "Using Components". Instead of discussing how to use every single component in every single situation, I focused on a more practical issue: how to get components to communicate with each other as a cohesive user interface. After all, this book is written at an intermediate level with a concentration on problem solving with Flash.
We've got a website setup for our book, and we'll start posting details and news on the new website next week. I'm off to celebrate with some good sushi and do a wild "Sam finished the last chapter" dance down South University Street. :-)
Tutorial on java data types
Using the Internet Protocol as a learning model
Java Streams (Sun Tutorial)
Java Object Serialization Protocol (too big for lejos JVM, but a good example nonetheless)
Lejos API Documentation (Lejos is the mini Java Virtual Machine implemented for the Mindstorms RCX Brick)
Turns out writing your own simple protocol with Java.io isn't so hard after all. It's actually not so bad when using the lejos JVM's java.io implementation. I can send basic data now, so next thing to do is figure out a tight, simple protocol for specifying method calls and method parameters. In other words, a basic web service model, but skinny ;-)
Now I've got a whole new level of appreciation for real engineers who actually design communication protocols for a living. Phew...
I've got a flash interface that sends commands through Flash remoting to the CFMX/JRun server. However, the RCXDirect Java package has a limited set of commands which don't allow you to send commands to two motors in a single transmission. The resulting delay between commands to motor A and motor B means that it takes quite a bit of luck to get the robot to move in a straight line via the Flash interface.
Looks like I'm going to have to write my own protocol in Java.io.
Oy...

Version 2: A lightweight and simple mobile robot. I came up with this design by myself to improve IR reception and boost speed. The rear caster wheel is lighter adapation of an idea from the Core Mindstorms programming book. The next version will have better support structures to hold a wireless mini video camera.
Now that I can control the robot via flash, the next step is to design a user interface to control the robot motors. The design problem has the added twist of operating with a slight delay after each command, due to the infra-red send/confirm cycle. So, the user interface has to accomodate the delay by presenting the delay as an aspect of the human-computer interaction. Also, I'd like the UI to incorporate a visualization of the two motors' direction and power, so that the user intuitively understands that he/she is steering simply by controlling two motors, rather than a third steering wheel column. I've got some ideas, will publish the Flash interface once it's done.
It's official! You can talk to lego robots with Cold Fusion!!! Many many thanks to Jeremy Allaire and Jody Zhang for tips, many thanks to the LeJOS team for writing the Mindstorms JVM. Most of all, thanks to the guy who wrote the RCXDirect package, Tim Rinkens! You can read more about Tim Rinkens' wonderful java package here: http://rcxtools.sourceforge.net/rcxdirect/e_index.html
I think the high point of the day was when I sent my browser to http://localhost:8500/webrover/test.cfm , and my robot suddenly smacked into the wall on other side of the room. It scared the heck out of my cat! *sniff* The little webrover is all grown up and running around :)
For anyone interested in how I finally hacked the code to send a command from a Cold Fusion webpage to a Java object to my Lego robot, keep reading...
There are two ways to communicate with the lego via I-R. The first way is to write your own protocol and use the java.io package in the lejos operating system. The second way is to use a pre-written toolkit called "RCXDirect". I'm going with rcxdirect because it's perfect for remote control. However, RCXDirect requires a binary executable written in C, called "rcxsend.exe", as well as cygwin.dll. Under ordinary circumstances, you just put a copy of the rcxsend.exe into any java application that requires rcxdirect. When I rebooted everything and ran my code in a .cfm page, the code would try to contact the IR tower but nothing happened. It wasn't until I got into DOS, ran the cfstart.bat to force all system messages onto the screen, that I saw the following message:
Program "C:\CFUSIO~1\runtime\servers\default\rcxsend.exe" not found!
RCXDirectConnect: motor packet: failed
05/17 12:55:10 user FileServlet: init
So, I put a copy of rcxsend.exe and cygwin.dll into that directory. The motors start revving up now, but I wondered about the purpose of this default folder. I downloaded from sourceforge the source code which creates the infra-red connection, and figured out how the original programmer found the path to rcxsend.exe:
private static String sendPATH = System.getProperty("user.dir") +
((new File("rcxdirect")).isDirectory() ?
(File.separator + "rcxdirect"):"");
According to the java API docs, "user.dir" is a System property which returns a string path to user's current working directory. But why is "runtime/servers/default" the current working directory? I opened up the cfstart.bat file, and saw these commands:
setlocal
cd ..\runtime\servers\default
..\..\bin\jrun -start default
endlocal
I can think of three easy ways to run executable files from cold fusion: 1) Put all executables in a common directory and add the directory to your PATH environment variable (in Windows). 2) Modify the batch file to start from a custom directory, such as "runtime\servers\samuel_stuff" 3) If you're using java, just modify the path instead of relying on System static properties. I think option #2 is probably safer, since you won't have to make any changes to the environment variables or the actual code.
Conclusion: The debugging feature works really well in CFMX, but if you want to see more descriptive system messages about your Java code, you should run the batch file from command line rather than double-clicking on the batch file. Anyways, I hope I can claim dibs on being the first person to hook up a mobile robot to Cold Fusion :)
I will upload code and instructions soon. For now, must finish working on the book.
***Sam does a funky victory dance with his robot***
I've learned how to instantiate Java objects in CF, but for some reason, I can't instantiate the RoverController class. I suspect it has to do with bad classpaths, or the fact that a dependent package relies on an executable file and local drivers to communicate with the I-R tower. I can call the same object in a test application to start the motors, so I know the RoverController class works. I can also call methods on non-Lejos classes from CFObject, so I know that the CFMX->Java bridge works.
An easy way out would be to write a socket server Java application that accepts commands on a local port, so that the Java object in CF could send commands to that port. However, it's not a clean solution and I'd rather get the CF object to work, for long term benefits with other pieces of code.
My theory turned out to be correct. Used a bigger wheel and removed the two-gear drive. The higher torque on the big wheel gives the robot a serious speed boost! When I activated the motors from my laptop, it flew across the room before I could even turn around. I saw someone's article on building a something like a transmission gear system, but it would be too heavy and large for my purposes (need to save some room for the wireless camera).
The new robot chassis supports the brick at a slightly off vertical angle for maximum IR reception.
Bigger wheels also led to the problem of a wider axis. Lack of steering mechanisms prevented my robot from relying on the motor direction alone to change directions. I found the solution in a description of a caster wheel mechanism, which you'll find in most shopping carts and rollers.
-Sam
Finished chapter on textfields. It's the most comprehensive and longest chapter in the book. Whew.
Robot's not fast enough, I'm redesigning the chassis to position the brick vertically for better I-R reception, and adding bigger wheels to take advantage of the motor's relatively under-used torque.
I'm continuing to document my progress in linking the lego robot to some macromedia technologies.
At this point, I'm quite comfortable with the leJOS API and laptop->IR->robot communication through custom java applications. Now I'm going to tackle the project from the opposite direction, starting with CFMX and JRun.
So far, I've got CFMX and JRun installed as a standalone server. I'm currently learning how to create Java class instances via the cold fusion CFObject tag, and call methods on the Java class.
Today's documentation: "Using Java and J2EE elements in Cold Fusion MX application"
http://www.macromedia.com/desdev/mx/coldfusion/articles/java.html
Status update on several projects:
1. Begin uploading homework from my graduate school days in human-computer interaction (I graduated 2 weeks ago).
Status: Requires more time than I thought, because each homework involves a lot of background reading of research papers, and I have to include some explanation on the context of the homework assignment
2. Build a Flash-based blog interface.
Status: I'm sure someone else has started working on this, but I still intend to build a Flash UI for movabletype. I'm talking with a few other Flash hackers about an XML standard (like RSS 2.0) for collating all blog sources into a feed inside the Flash MX authoring environment.
4. Flash-controlled Telerobotics - Integrating Lego Mindstorms robotics with Cold Fusion MX, Flash Remoting, and another unannounced Macromedia technology.
Status: I currently have a lego robot running the leJOS java virtual machine, and have some Java applications on the laptop to send commands over the infra-red tower. I've also learned how to use the Behavior/Arbitrator design pattern for simple artificial intelligence, but AI's not needed for telerobotics. Many thanks to Jody Zhang and Jeremy Allaire for tips on JRun/CFMX/Flash integration, I hope to have a working prototype soon (need to buy a wireless camera too).
5. Actionscript OOP Book from New Riders Press.
Status: We're kicking ass on this book. It's a little bit delayed due to the amount of thinking involved. I've even learned a lot from reading Branden Hall's draft chapters on OOP design patterns. Tonight, we came up with a new design pattern specifically suited for Flash development. Basically, the Flash editor allows you to define instances of visual objects before run-time. Many design patterns rely purely on class definitions that instantiate other classes, so these patterns don't work well in a pre-run-time instance definition environment like Flash. We came up with something better as we were brainstorming on a solution I proposed in my textfield chapter. My textfield chapter will end up 3 times longer than its original length. The solution was so good that Branden re-wrote part of his chapter on Actionscript OOP. Well, I don't want to overhype anything, so I'll just stop here.
This site will feature more Flash source code, lego/Flash integration, and HCI topics soon.
-Sam
I bought Brian Bagnall's book, "Core Lego Mindstorms Programming" at the Borders bookstore a few blocks down the street. Following the instructions in the book, I over-wrote the RCX firmware on the MindStorms brick with the latest leJos Java operating system. I compiled and uploaded a simple java program through the IR port (command-line, sigh).
Started tapping the bumper sensor of my rover, and lo and behold, the LCD panel starts displaying an incrementing integer for each tap on the sensor. Wow. On to phase 4...
Note: References to buttons, motors, and sensors must go through global static class variables in leJos. The device is straightforward and simple, so static references save memory, according to the book.
-Sam
Finished outlining the chapter on textfields, now I'm taking a break and going back to the mxrover project.
I've built a Mindstorms robot with touch sensor and two servo motors for mobile steering. I've figured out the Logo programming interface (they force you to go through the tutorials, I had to manually authorize myself to skip them, arrgh), but the programming tools are quite limited. I'm now going to over-write the firmware with the leJOS JVM to gain more control and faster authoring tools with Java, hopefully will have Phase 2 finished in 30 minutes.
-Sam
I'm starting to compile resources for learning Java and related subjects. From what I can tell of the new Macromedia technologies, people will start paying more attention to how Flash, Actionscript, Cold Fusion, and Java all work together (although Actionscript Remote allows you to call Java components on the server-side with Actionscript syntax instead of using Cold Fusion code).
Best free book for learning Java:
Bruce Eckel wrote the best book on learning Java. He's also posted it for free download.
Resources for learning Web Services with Java:
Sun Microsystem's "Java Web Services Tutorial"
Embedded and Networked Java:
http://pandonia.canberra.edu.au/java/jini/tutorial/Jini.xml
Lego Mindstorms leJOS Java Operating System:
http://lejos.sourceforge.net/utilities.html
Ah... you can see where I'm going with this, right? ;-)
-Sam
As an interface technology for the web, Flash is superior to all other technologies in terms of developer speed, flexibility, distribution, and media compatibility. However, I'm interested in interfaces that extend beyond the web browser and web server. I am busy writing an Actionscript book, but for a few hours each day, I plan to investigate how to integrate Macromedia technologies and electronic devices. Hopefully, the project will start showing results in a couple of weeks. Stay tuned to the new telerobotics category for more details... in the meantime, I'll continue to post entries into the other categories as well.
I've downloaded a 30-day trial of Fireworks to handle all the screenshots for our book on Actionscript programming, so that I don't have to use Photoshop anymore. Happily, I've discovered that fireworks handles cropping and editing in a much faster workflow compared to Photoshop (drag and click, wow), so it's perfect for my task. Even the interface is identical to Flash MX's interface. I plan to learn more about Fireworks MX and I'm considering buying it after I finish writing the book.
-Sam
Thanks for posting all the helpful feedback in the comments section. I get an email notification of each comment, and I just realized I've been responding directly by email. Instead, I should have been posting my responses directly to the comments sections so that everyone else can see the answer as well. Doh!
From now on, I'll email a direct response as well as post the resonse on my website's comments section. If you want a direct email response, please make sure to include your email address in the comments form. I can't promise to respond to all questions immediately because I've got a tight deadline on a new OOP Actionscript & Components book with Branden Hall. However, I will make sure to respond to all comments/questions eventually.
Your comments are great... they really help me focus on what people want to learn. Keep posting, thanks :)
-Sam
Someone really needed a piechart with dynamically settable values. Since I wrote the piechart components, I figured I was responsible for demonstrating a solution.

Download Source (885kb, zip)
All images, source code, and animation copyright by Samuel Wan, 2000-2002. The contents of these files may be studied for educational purposes. Redistribution of any part of the source code is not permitted.
From the looks of the Flash structure and code, it looks like I originally wrote this in Flash 4. I remember writing it in Flash 5, but probably got them confused because I built this file during the Flash 5 beta.