Slashdot Mirror

I've been developing touch screen talking pie menus on handheld devices, like the Pocket PC. Pie menus work very well with touch screens, but of course the way they track and display and give feedback has to be adapted to the quirks of small touch screens. Talking pie menus give you audio feedback with a speech synthesizer, so they don't require a lot of visual attention and hand-eye coordination.

Talking pie menus make it possible to use an application without looking at the screen! That's important for mobile applications like GPS navigation systems, which people use while driving (despite all the warnings again it).

-Don

Take a look and feel free: http://www.piemenu.com/

I just did not feel free from taking a look. Am I doing something wrong?

"SimFaux is an interactive Faux News TV simulation, which I just published on the Huffingtonpost Contagious Festival. It's written entirely in OpenLaszlo, and features simulated characters (Dick Cheney, George W Bush, Arianna Huffington, Bill O'Reilly, and more to come), streaming video, sound bites, talking points, slanted surveys, meaningless graphs, dynamic keywords, pie menus, and several channels with different split screen layouts. All the content is tagged with keywords, which it uses to decide what to play next. There's an "About" channel that explains more.

Technically, it's an open-ended data-driven AJAXian web application written in OpenLaszlo (JavaScript + XML that runs in Flash), so it's easy to add more content and plug in new behaviors. (I plan to add some mini-games like Tick-Tack-Faux and Hangman!) I'm regularly adding more characters, video, talking points, sound bites, surveys, etc. So please check back again later for the latest breaking news and propoganda!

-Don

I'll start by comparing screen corners to pie menus:

To quote Tog on Fitts' Law: "The time to acquire a target is a function of the distance to and size of the target." He points out that "the screen edge is, for all practical purposes, infinitely deep."

But the advantage of "screen corners" is just an indirect and wasteful application of Fitts' Law, which pie menus exploit much more directly, efficiently and flexibly than "screen corners". Tog's "screen corner" argument is just an ex post facto application of Fitts' Law: an after-the-fact rationalization, not the reason they originally designed the menu bar that way. If Fitts' Law was really the reason Apple designed their menu bar that way, then why aren't there four menu bars, one at each edge of the screen? Apple never mentioned Fitts' Law in their infamous menu bar patent.

Pie menus "slices" are better than "screen corners" or "menu bars" because:

Screen corners and edges are static and fixed in number, so they only enable a small fixed number of global commands at once.

Pie menus are dynamic and context sensitive, so each pie menu can have multiple slices, with a different set of functions associated with each, including submenus. The screen only has four corners and four edges, but pie menus are extremely reliable with eight items, and can support up to 12 items reliably.

Pie menus also support submenus, so you can have an infinite combination of pie menu items, depending on the context you click on, instead of just four screen corners or four menu bars.

Each pie menu item is easier to hit than any screen corner, because every pie slice target area starts directly adjacent to the cursor and extends all the way out to the screen edge, and beyond!

Screen corners and menu bars flaunt Fitts' Law by requiring you to physically move the mouse a large distance, and they usually leave the cursor far away from the object you're manipulating.

Pie menu target area "slices" extend all the way out to the edge of the screen and beyond, so their area is quite large, but you don't have to actually move all the way to the screen edge to select them. You simply move the cursor outside of the small inactive area in the pie menu center. Each "slice" target area starts out directly adjacent to the cursor, in a different direction, and occupies a large area extending out to the edge of the screen.

Fitts' Law relates the target seek time and error rate to the target area and distance from the cursor. The bigger the target and the closer the target, the faster the seletion and fewer errors. Pie menus maximize the target area and minimize the target distance, so consequently they minimize both the speed and error rate, as Fitts' Law predicts.

Pie menus have been empirically proven to be 20% faster than the linear menus, and about half the error rate ("A Comparative Analysis of Pie Menu Performance"; by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman; Proc. CHI'88 conference, Washington D.C.)

Screen corners are worse than pie menus, because they actually have smaller target areas than pie menu slices, and actually maximize the distance from the cursor by putting the target as far away from the cursor as possible.

Tog claims the screen edge target area is "infinitely deep", but in practice you never move the cursor an infinite distanc

I'll start by comparing screen corners to pie menus:

To quote Tog on Fitts' Law: "The time to acquire a target is a function of the distance to and size of the target." He points out that "the screen edge is, for all practical purposes, infinitely deep."

But the advantage of "screen corners" is just an indirect and wasteful application of Fitts' Law, which pie menus exploit much more directly, efficiently and flexibly than "screen corners". Tog's "screen corner" argument is just an ex post facto application of Fitts' Law: an after-the-fact rationalization, not the reason they originally designed the menu bar that way. If Fitts' Law was really the reason Apple designed their menu bar that way, then why aren't there four menu bars, one at each edge of the screen? Apple never mentioned Fitts' Law in their infamous menu bar patent.

Pie menus "slices" are better than "screen corners" or "menu bars" because:

Screen corners and edges are static and fixed in number, so they only enable a small fixed number of global commands at once.

Pie menus are dynamic and context sensitive, so each pie menu can have multiple slices, with a different set of functions associated with each, including submenus. The screen only has four corners and four edges, but pie menus are extremely reliable with eight items, and can support up to 12 items reliably.

Pie menus also support submenus, so you can have an infinite combination of pie menu items, depending on the context you click on, instead of just four screen corners or four menu bars.

Each pie menu item is easier to hit than any screen corner, because every pie slice target area starts directly adjacent to the cursor and extends all the way out to the screen edge, and beyond!

Screen corners and menu bars flaunt Fitts' Law by requiring you to physically move the mouse a large distance, and they usually leave the cursor far away from the object you're manipulating.

Pie menu target area "slices" extend all the way out to the edge of the screen and beyond, so their area is quite large, but you don't have to actually move all the way to the screen edge to select them. You simply move the cursor outside of the small inactive area in the pie menu center. Each "slice" target area starts out directly adjacent to the cursor, in a different direction, and occupies a large area extending out to the edge of the screen.

Fitts' Law relates the target seek time and error rate to the target area and distance from the cursor. The bigger the target and the closer the target, the faster the seletion and fewer errors. Pie menus maximize the target area and minimize the target distance, so consequently they minimize both the speed and error rate, as Fitts' Law predicts.

Pie menus have been empirically proven to be 20% faster than the linear menus, and about half the error rate ("A Comparative Analysis of Pie Menu Performance"; by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman; Proc. CHI'88 conference, Washington D.C.)

Screen corners are worse than pie menus, because they actually have smaller target areas than pie menu slices, and actually maximize the distance from the cursor by putting the target as far away from the cursor as possible.

Tog claims the screen edge target area is "infinitely deep", but in practice you never move the cursor an infinite distanc

I'll start by comparing screen corners to pie menus:

To quote Tog on Fitts' Law: "The time to acquire a target is a function of the distance to and size of the target." He points out that "the screen edge is, for all practical purposes, infinitely deep."

But the advantage of "screen corners" is just an indirect and wasteful application of Fitts' Law, which pie menus exploit much more directly, efficiently and flexibly than "screen corners". Tog's "screen corner" argument is just an ex post facto application of Fitts' Law: an after-the-fact rationalization, not the reason they originally designed the menu bar that way. If Fitts' Law was really the reason Apple designed their menu bar that way, then why aren't there four menu bars, one at each edge of the screen? Apple never mentioned Fitts' Law in their infamous menu bar patent.

Pie menus "slices" are better than "screen corners" or "menu bars" because:

Screen corners and edges are static and fixed in number, so they only enable a small fixed number of global commands at once.

Pie menus are dynamic and context sensitive, so each pie menu can have multiple slices, with a different set of functions associated with each, including submenus. The screen only has four corners and four edges, but pie menus are extremely reliable with eight items, and can support up to 12 items reliably.

Pie menus also support submenus, so you can have an infinite combination of pie menu items, depending on the context you click on, instead of just four screen corners or four menu bars.

Each pie menu item is easier to hit than any screen corner, because every pie slice target area starts directly adjacent to the cursor and extends all the way out to the screen edge, and beyond!

Screen corners and menu bars flaunt Fitts' Law by requiring you to physically move the mouse a large distance, and they usually leave the cursor far away from the object you're manipulating.

Pie menu target area "slices" extend all the way out to the edge of the screen and beyond, so their area is quite large, but you don't have to actually move all the way to the screen edge to select them. You simply move the cursor outside of the small inactive area in the pie menu center. Each "slice" target area starts out directly adjacent to the cursor, in a different direction, and occupies a large area extending out to the edge of the screen.

Fitts' Law relates the target seek time and error rate to the target area and distance from the cursor. The bigger the target and the closer the target, the faster the seletion and fewer errors. Pie menus maximize the target area and minimize the target distance, so consequently they minimize both the speed and error rate, as Fitts' Law predicts.

Pie menus have been empirically proven to be 20% faster than the linear menus, and about half the error rate ("A Comparative Analysis of Pie Menu Performance"; by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman; Proc. CHI'88 conference, Washington D.C.)

Screen corners are worse than pie menus, because they actually have smaller target areas than pie menu slices, and actually maximize the distance from the cursor by putting the target as far away from the cursor as possible.

Tog claims the screen edge target area is "infinitely deep", but in practice you never move the cursor an infinite distanc

The harsh reality of AJAX (besides the obvious fact that it has sucky graphics) is that it's extremely difficult to write code that runs the same in all browsers, and you have to relentlessly test against each different browser on every different platform that you plan to support. Flash has no such problem, because it's identical across all platforms.

The lowest-common-denominator graphics AJAX can support across all browsers are crude and clumsy. Google maps has to bend over backwards and depend on the server to draw a diagonal line with transparent PNGs on Firefox, but it can't use transparent PNGs on Internet Explorer, so it has to use non-standard VML instead. It can't simply do everything in terms of SVG or PNG or VML: it actually has to support BOTH PNG and VML, but can't take advantage of vastly superior SVG since it's not commonly deployed nor well supported! All that rube-goldberg technology, just to draw a stupid line.

AJAX applications require a huge amount of extra work to develop, and even more to maintain, because of the necessity of dealing with evolving browser incompatibilities. And the end result simply isn't worth all the effort, since the lowest-common-denominator graphics and the resulting user interfaces are so crude and limited.

For example, Pie menus should pop up in round and arbitrarily shaped windows, but it's impossible to even draw a circle with DHTML, let alone a spokes and speech bubbles!

AJAX practices must balance on a randomly swerving rasor's edge: the intersection of what works on all browsers at the time of implementation. But all the browsers are constantly evolving in different directions, so today's hacks and kludges you're forced to use to work around bugs in today's various browsers will make your application fragile, complex and hard to maintain, and it will probably break in future browsers. AJAX forces you to artificially limit yourself and refrain from using technologies like SVG, VML and PNG, or else you have to actually implement simple things like diagonal lines with several different technologies at once, sniff the browser, adapt at run-time, and fall back to server side rendering!

Maybe Google has the resources to develop and matintain several different ways of drawing a diagonal line over a map, but most companies and independent developers don't have as much human and computer resources to flush down the toilet on such a simple problem of drawing lines. Flash already solves that problem quite nicely thank you, and it's the most ubiquitous RIA platform that exists today, with open source development tools like OpenLaszlo.

-Don

The harsh reality of AJAX (besides the obvious fact that it has sucky graphics) is that it's extremely difficult to write code that runs the same in all browsers, and you have to relentlessly test against each different browser on every different platform that you plan to support. Flash has no such problem, because it's identical across all platforms.

The lowest-common-denominator graphics AJAX can support across all browsers are crude and clumsy. Google maps has to bend over backwards and depend on the server to draw a diagonal line with transparent PNGs on Firefox, but it can't use transparent PNGs on Internet Explorer, so it has to use non-standard VML instead. It can't simply do everything in terms of SVG or PNG or VML: it actually has to support BOTH PNG and VML, but can't take advantage of vastly superior SVG since it's not commonly deployed nor well supported! All that rube-goldberg technology, just to draw a stupid line.

AJAX applications require a huge amount of extra work to develop, and even more to maintain, because of the necessity of dealing with evolving browser incompatibilities. And the end result simply isn't worth all the effort, since the lowest-common-denominator graphics and the resulting user interfaces are so crude and limited.

For example, Pie menus should pop up in round and arbitrarily shaped windows, but it's impossible to even draw a circle with DHTML, let alone a spokes and speech bubbles!

AJAX practices must balance on a randomly swerving rasor's edge: the intersection of what works on all browsers at the time of implementation. But all the browsers are constantly evolving in different directions, so today's hacks and kludges you're forced to use to work around bugs in today's various browsers will make your application fragile, complex and hard to maintain, and it will probably break in future browsers. AJAX forces you to artificially limit yourself and refrain from using technologies like SVG, VML and PNG, or else you have to actually implement simple things like diagonal lines with several different technologies at once, sniff the browser, adapt at run-time, and fall back to server side rendering!

Maybe Google has the resources to develop and matintain several different ways of drawing a diagonal line over a map, but most companies and independent developers don't have as much human and computer resources to flush down the toilet on such a simple problem of drawing lines. Flash already solves that problem quite nicely thank you, and it's the most ubiquitous RIA platform that exists today, with open source development tools like OpenLaszlo.

-Don

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

The whole point of SVG and VML are that they are dynamic scriptable graphics formats, not just that they're represented by XML. Like Flash, you can use them to write user interfaces and games and data driven interactive graphical displays of dynamic XML documents.

It's impossible to automatically convert dynamic SVG or VML documents that use JavaScript, which covers most interesting uses of those technologies. Otherwise you might as well be using GIF.

-Don

-Don

What are these Fasteroids, anyway???

The goal of Fasteroids is to help the space ship blast away the asteroids. But its real purpose is to compare the selection speeds and error rates of directional "pie menus" versus traditional "linear menus". The actual point of the game is to give you a fun and fair way to test drive and compare pie menus and linear menus for yourself.

When you click the left button in the black space, a pie menu or a linear menu will pop up. You should select the bright yellow item with four stars, and it will fire four blasts, which will help destroy the asteroids. But if you select any of the other items, that is considered an error, so it will only fire one blast.

The menu style changes every round. Some rounds, the menu will be a pie menu, and other rounds it will be a linear menu. Some rounds, the menu items will be randomized, and other rounds they will be constant.

If you would like to share your results, please press the "Send Statistics to PieMenu.com" button, and your selection times and error rates will be reported to PieMenu.com. It will show the overall results and how you results compare. Don't worry -- it doesn't send any personal information, just the details of the measurements summarized in the table, including the selection count and time for each test type, menu type and menu item.

And What are Pie Menus???

Pie Menus are a naturally efficient user interface technique: directional selection of pie slice shaped targets. The cursor starts out in the center of the pie, so all targets are large, nearby, and in different directions. Fitts' Law explains the advantages of pie menus, relating fast selection speed and low error rate to large target size and small distance. Pie menus are easy for novice users, who just follow the directions, and efficient for experienced users, who can quickly "mouse ahead" once they know the way.

To learn more about pie menus, please visit Pie Menu Central!

For the complete credits, as well as some swell entertainment, please don't forget to read the fine print.

-Don

What are these Fasteroids, anyway???

The goal of Fasteroids is to help the space ship blast away the asteroids. But its real purpose is to compare the selection speeds and error rates of directional "pie menus" versus traditional "linear menus". The actual point of the game is to give you a fun and fair way to test drive and compare pie menus and linear menus for yourself.

When you click the left button in the black space, a pie menu or a linear menu will pop up. You should select the bright yellow item with four stars, and it will fire four blasts, which will help destroy the asteroids. But if you select any of the other items, that is considered an error, so it will only fire one blast.

The menu style changes every round. Some rounds, the menu will be a pie menu, and other rounds it will be a linear menu. Some rounds, the menu items will be randomized, and other rounds they will be constant.

If you would like to share your results, please press the "Send Statistics to PieMenu.com" button, and your selection times and error rates will be reported to PieMenu.com. It will show the overall results and how you results compare. Don't worry -- it doesn't send any personal information, just the details of the measurements summarized in the table, including the selection count and time for each test type, menu type and menu item.

And What are Pie Menus???

Pie Menus are a naturally efficient user interface technique: directional selection of pie slice shaped targets. The cursor starts out in the center of the pie, so all targets are large, nearby, and in different directions. Fitts' Law explains the advantages of pie menus, relating fast selection speed and low error rate to large target size and small distance. Pie menus are easy for novice users, who just follow the directions, and efficient for experienced users, who can quickly "mouse ahead" once they know the way.

To learn more about pie menus, please visit Pie Menu Central!

For the complete credits, as well as some swell entertainment, please don't forget to read the fine print.

-Don

What are these Fasteroids, anyway???

The goal of Fasteroids is to help the space ship blast away the asteroids. But its real purpose is to compare the selection speeds and error rates of directional "pie menus" versus traditional "linear menus". The actual point of the game is to give you a fun and fair way to test drive and compare pie menus and linear menus for yourself.

When you click the left button in the black space, a pie menu or a linear menu will pop up. You should select the bright yellow item with four stars, and it will fire four blasts, which will help destroy the asteroids. But if you select any of the other items, that is considered an error, so it will only fire one blast.

The menu style changes every round. Some rounds, the menu will be a pie menu, and other rounds it will be a linear menu. Some rounds, the menu items will be randomized, and other rounds they will be constant.

If you would like to share your results, please press the "Send Statistics to PieMenu.com" button, and your selection times and error rates will be reported to PieMenu.com. It will show the overall results and how you results compare. Don't worry -- it doesn't send any personal information, just the details of the measurements summarized in the table, including the selection count and time for each test type, menu type and menu item.

And What are Pie Menus???

Pie Menus are a naturally efficient user interface technique: directional selection of pie slice shaped targets. The cursor starts out in the center of the pie, so all targets are large, nearby, and in different directions. Fitts' Law explains the advantages of pie menus, relating fast selection speed and low error rate to large target size and small distance. Pie menus are easy for novice users, who just follow the directions, and efficient for experienced users, who can quickly "mouse ahead" once they know the way.

To learn more about pie menus, please visit Pie Menu Central!

For the complete credits, as well as some swell entertainment, please don't forget to read the fine print.

It takes one button and expands it out (like flower petals) into multiple buttons.

You seem to have independently discovered or reinvented the pie menu, also known as the circle menu or radial context menu.

There are assorted demos here

Despite some evidence that pie menus are easier to use than more common schemes, they've never caught on. It might be because they are not as compact as other types and so page designers trade off some usability to make better use of screen space. Also, they don't scale well to a large number of options.

Still, you might think that with the human hand a a model of a radial selection device, pie menus would be more popular. However, even in the physical world, levers, switches, sliders and rows of buttons are more common than radial devices. The same objections for UI design on the screen seem to apply to physical devices.

It takes one button and expands it out (like flower petals) into multiple buttons.

You seem to have independently discovered or reinvented the pie menu, also known as the circle menu or radial context menu.

There are assorted demos here

Despite some evidence that pie menus are easier to use than more common schemes, they've never caught on. It might be because they are not as compact as other types and so page designers trade off some usability to make better use of screen space. Also, they don't scale well to a large number of options.

Still, you might think that with the human hand a a model of a radial selection device, pie menus would be more popular. However, even in the physical world, levers, switches, sliders and rows of buttons are more common than radial devices. The same objections for UI design on the screen seem to apply to physical devices.

Since usability guru Jakob Nielson wrote Flash: 99% Bad in 2000, a lot has changed about Flash. He worked with Macromedia to improve Flash's usability, and he sells a report with 117 design guidelines for Flash usability. So yes, it is possible to develop usable applications in Flash.

OpenLaszlo is an open source language and set of tools for developing full fledged rich web applications, which are compiled into SWF files that run on the Flash player. Laszlo/Flash is presently much more capable of implementing high quality cross platform user interfaces than dynamic AJAX/HTML/SVG currently is.

Laszlo is a high level XML and JavaScript based programming language. It's independent of Flash in the same way that GCC is independent of the Intel instruction set and Windows runtime, because they both compile a higher level language, and can target other runtimes and instruction sets.

Currently Flash is the most practical, so that's what Laszlo supports initially, but it can be retargeted to other runtimes like SVG, XUL, Java or Avalon, once they grow up and mature. But right now Flash is the best way to go, because of its overwhelming installed base and consistency across multiple platforms.

The problem with SVG is that it's extremely spotty and inconsistent across the different browsers and plug-ins and cell phones that implement it. So the lowest common denominator is very very low indeed. Dynamic HTML has the same inconsistency problems but with much worse graphics, and it's that horrible inconsistency that forces cross-browser web applications to be so clumsy and hard to use -- because they must restrict themselves to the lowest common denominator. But Flash is consistent across all platforms, and it has high quality graphics.

I've written complex, rich interactive web based applications in both SVG and Laszlo, and I like them both. I've also used Microsoft's VML, which enabled animated vector graphics inline with html many years ago, and Dynamic HTML Behavior Controls, which work pretty well, but only in Explorer, so they're a dead end.

SVG is wonderful, but it's lost its steam: too little, too late. Adobe, once its main proponent, has totally forgotten about it, and they're quite unlikely to put any more effort into it, now that they've bought Macromedia. Batik development has been stalled, and it's slow because it's "100% Pure Java". SVG has some nice advantages over Flash, but it will never beat Flash's 98% penetration.

I'd love to see SVG get its shit together, but it's going to be a long time the way the companies that were once sponsoring it like Adobe, Canon and Kodak, have appearently given up and gone on to other things. I'd love for somebody to prove that I'm wrong, but Flash has kicked SVG's ass in the market.

Once there's a fast, stable, full featured, ubiquitious SVG renderer (like Firefox may someday support), it will make a lot of sense to target it with the Laszlo compiler. But SVG is a huge complex standard, and it will take a lot of work to completely implement it in Firefox.

But there's a much more interesting and efficient route than building everything including SVG and the kitchen sink into a web browser, and that's to factor out and develop a reusable open source Flash-compatible SWF player,

Since usability guru Jakob Nielson wrote Flash: 99% Bad in 2000, a lot has changed about Flash. He worked with Macromedia to improve Flash's usability, and he sells a report with 117 design guidelines for Flash usability. So yes, it is possible to develop usable applications in Flash.

OpenLaszlo is an open source language and set of tools for developing full fledged rich web applications, which are compiled into SWF files that run on the Flash player. Laszlo/Flash is presently much more capable of implementing high quality cross platform user interfaces than dynamic AJAX/HTML/SVG currently is.

Laszlo is a high level XML and JavaScript based programming language. It's independent of Flash in the same way that GCC is independent of the Intel instruction set and Windows runtime, because they both compile a higher level language, and can target other runtimes and instruction sets.

Currently Flash is the most practical, so that's what Laszlo supports initially, but it can be retargeted to other runtimes like SVG, XUL, Java or Avalon, once they grow up and mature. But right now Flash is the best way to go, because of its overwhelming installed base and consistency across multiple platforms.

The problem with SVG is that it's extremely spotty and inconsistent across the different browsers and plug-ins and cell phones that implement it. So the lowest common denominator is very very low indeed. Dynamic HTML has the same inconsistency problems but with much worse graphics, and it's that horrible inconsistency that forces cross-browser web applications to be so clumsy and hard to use -- because they must restrict themselves to the lowest common denominator. But Flash is consistent across all platforms, and it has high quality graphics.

I've written complex, rich interactive web based applications in both SVG and Laszlo, and I like them both. I've also used Microsoft's VML, which enabled animated vector graphics inline with html many years ago, and Dynamic HTML Behavior Controls, which work pretty well, but only in Explorer, so they're a dead end.

SVG is wonderful, but it's lost its steam: too little, too late. Adobe, once its main proponent, has totally forgotten about it, and they're quite unlikely to put any more effort into it, now that they've bought Macromedia. Batik development has been stalled, and it's slow because it's "100% Pure Java". SVG has some nice advantages over Flash, but it will never beat Flash's 98% penetration.

I'd love to see SVG get its shit together, but it's going to be a long time the way the companies that were once sponsoring it like Adobe, Canon and Kodak, have appearently given up and gone on to other things. I'd love for somebody to prove that I'm wrong, but Flash has kicked SVG's ass in the market.

Once there's a fast, stable, full featured, ubiquitious SVG renderer (like Firefox may someday support), it will make a lot of sense to target it with the Laszlo compiler. But SVG is a huge complex standard, and it will take a lot of work to completely implement it in Firefox.

But there's a much more interesting and efficient route than building everything including SVG and the kitchen sink into a web browser, and that's to factor out and develop a reusable open source Flash-compatible SWF player,

Since usability guru Jakob Nielson wrote Flash: 99% Bad in 2000, a lot has changed about Flash. He worked with Macromedia to improve Flash's usability, and he sells a report with 117 design guidelines for Flash usability. So yes, it is possible to develop usable applications in Flash.

OpenLaszlo is an open source language and set of tools for developing full fledged rich web applications, which are compiled into SWF files that run on the Flash player. Laszlo/Flash is presently much more capable of implementing high quality cross platform user interfaces than dynamic AJAX/HTML/SVG currently is.

Laszlo is a high level XML and JavaScript based programming language. It's independent of Flash in the same way that GCC is independent of the Intel instruction set and Windows runtime, because they both compile a higher level language, and can target other runtimes and instruction sets.

Currently Flash is the most practical, so that's what Laszlo supports initially, but it can be retargeted to other runtimes like SVG, XUL, Java or Avalon, once they grow up and mature. But right now Flash is the best way to go, because of its overwhelming installed base and consistency across multiple platforms.

The problem with SVG is that it's extremely spotty and inconsistent across the different browsers and plug-ins and cell phones that implement it. So the lowest common denominator is very very low indeed. Dynamic HTML has the same inconsistency problems but with much worse graphics, and it's that horrible inconsistency that forces cross-browser web applications to be so clumsy and hard to use -- because they must restrict themselves to the lowest common denominator. But Flash is consistent across all platforms, and it has high quality graphics.

I've written complex, rich interactive web based applications in both SVG and Laszlo, and I like them both. I've also used Microsoft's VML, which enabled animated vector graphics inline with html many years ago, and Dynamic HTML Behavior Controls, which work pretty well, but only in Explorer, so they're a dead end.

SVG is wonderful, but it's lost its steam: too little, too late. Adobe, once its main proponent, has totally forgotten about it, and they're quite unlikely to put any more effort into it, now that they've bought Macromedia. Batik development has been stalled, and it's slow because it's "100% Pure Java". SVG has some nice advantages over Flash, but it will never beat Flash's 98% penetration.

I'd love to see SVG get its shit together, but it's going to be a long time the way the companies that were once sponsoring it like Adobe, Canon and Kodak, have appearently given up and gone on to other things. I'd love for somebody to prove that I'm wrong, but Flash has kicked SVG's ass in the market.

Once there's a fast, stable, full featured, ubiquitious SVG renderer (like Firefox may someday support), it will make a lot of sense to target it with the Laszlo compiler. But SVG is a huge complex standard, and it will take a lot of work to completely implement it in Firefox.

But there's a much more interesting and efficient route than building everything including SVG and the kitchen sink into a web browser, and that's to factor out and develop a reusable open source Flash-compatible SWF player,

Since usability guru Jakob Nielson wrote Flash: 99% Bad in 2000, a lot has changed about Flash. He worked with Macromedia to improve Flash's usability, and he sells a report with 117 design guidelines for Flash usability. So yes, it is possible to develop usable applications in Flash.

OpenLaszlo is an open source language and set of tools for developing full fledged rich web applications, which are compiled into SWF files that run on the Flash player. Laszlo/Flash is presently much more capable of implementing high quality cross platform user interfaces than dynamic AJAX/HTML/SVG currently is.

Laszlo is a high level XML and JavaScript based programming language. It's independent of Flash in the same way that GCC is independent of the Intel instruction set and Windows runtime, because they both compile a higher level language, and can target other runtimes and instruction sets.

Currently Flash is the most practical, so that's what Laszlo supports initially, but it can be retargeted to other runtimes like SVG, XUL, Java or Avalon, once they grow up and mature. But right now Flash is the best way to go, because of its overwhelming installed base and consistency across multiple platforms.

The problem with SVG is that it's extremely spotty and inconsistent across the different browsers and plug-ins and cell phones that implement it. So the lowest common denominator is very very low indeed. Dynamic HTML has the same inconsistency problems but with much worse graphics, and it's that horrible inconsistency that forces cross-browser web applications to be so clumsy and hard to use -- because they must restrict themselves to the lowest common denominator. But Flash is consistent across all platforms, and it has high quality graphics.

I've written complex, rich interactive web based applications in both SVG and Laszlo, and I like them both. I've also used Microsoft's VML, which enabled animated vector graphics inline with html many years ago, and Dynamic HTML Behavior Controls, which work pretty well, but only in Explorer, so they're a dead end.

SVG is wonderful, but it's lost its steam: too little, too late. Adobe, once its main proponent, has totally forgotten about it, and they're quite unlikely to put any more effort into it, now that they've bought Macromedia. Batik development has been stalled, and it's slow because it's "100% Pure Java". SVG has some nice advantages over Flash, but it will never beat Flash's 98% penetration.

I'd love to see SVG get its shit together, but it's going to be a long time the way the companies that were once sponsoring it like Adobe, Canon and Kodak, have appearently given up and gone on to other things. I'd love for somebody to prove that I'm wrong, but Flash has kicked SVG's ass in the market.

Once there's a fast, stable, full featured, ubiquitious SVG renderer (like Firefox may someday support), it will make a lot of sense to target it with the Laszlo compiler. But SVG is a huge complex standard, and it will take a lot of work to completely implement it in Firefox.

But there's a much more interesting and efficient route than building everything including SVG and the kitchen sink into a web browser, and that's to factor out and develop a reusable open source Flash-compatible SWF player,

Since usability guru Jakob Nielson wrote Flash: 99% Bad in 2000, a lot has changed about Flash. He worked with Macromedia to improve Flash's usability, and he sells a report with 117 design guidelines for Flash usability. So yes, it is possible to develop usable applications in Flash.

OpenLaszlo is an open source language and set of tools for developing full fledged rich web applications, which are compiled into SWF files that run on the Flash player. Laszlo/Flash is presently much more capable of implementing high quality cross platform user interfaces than dynamic AJAX/HTML/SVG currently is.

Laszlo is a high level XML and JavaScript based programming language. It's independent of Flash in the same way that GCC is independent of the Intel instruction set and Windows runtime, because they both compile a higher level language, and can target other runtimes and instruction sets.

Currently Flash is the most practical, so that's what Laszlo supports initially, but it can be retargeted to other runtimes like SVG, XUL, Java or Avalon, once they grow up and mature. But right now Flash is the best way to go, because of its overwhelming installed base and consistency across multiple platforms.

The problem with SVG is that it's extremely spotty and inconsistent across the different browsers and plug-ins and cell phones that implement it. So the lowest common denominator is very very low indeed. Dynamic HTML has the same inconsistency problems but with much worse graphics, and it's that horrible inconsistency that forces cross-browser web applications to be so clumsy and hard to use -- because they must restrict themselves to the lowest common denominator. But Flash is consistent across all platforms, and it has high quality graphics.

I've written complex, rich interactive web based applications in both SVG and Laszlo, and I like them both. I've also used Microsoft's VML, which enabled animated vector graphics inline with html many years ago, and Dynamic HTML Behavior Controls, which work pretty well, but only in Explorer, so they're a dead end.

SVG is wonderful, but it's lost its steam: too little, too late. Adobe, once its main proponent, has totally forgotten about it, and they're quite unlikely to put any more effort into it, now that they've bought Macromedia. Batik development has been stalled, and it's slow because it's "100% Pure Java". SVG has some nice advantages over Flash, but it will never beat Flash's 98% penetration.

I'd love to see SVG get its shit together, but it's going to be a long time the way the companies that were once sponsoring it like Adobe, Canon and Kodak, have appearently given up and gone on to other things. I'd love for somebody to prove that I'm wrong, but Flash has kicked SVG's ass in the market.

Once there's a fast, stable, full featured, ubiquitious SVG renderer (like Firefox may someday support), it will make a lot of sense to target it with the Laszlo compiler. But SVG is a huge complex standard, and it will take a lot of work to completely implement it in Firefox.

But there's a much more interesting and efficient route than building everything including SVG and the kitchen sink into a web browser, and that's to factor out and develop a reusable open source Flash-compatible SWF player,

They can limit the number of pie items to a default of 8, and the overflow items are put below as linear menu items by default, or you can specify the default direction for overflow items. If you limit the number of pie items to 0, then the menu functions as a normal "pull down" linear menu.

Linear items can also be layed out above, below, to the left, or to the right of the pie menu, so it supports "pull up", "pull right" and "pull left" menus as well as "pull down".

Here is an extreme example of a pie menu with lots of extra linear items in all four directions, that popup up other variations of pie and linear menus. Here is the XML that defines the hybrid pie menu layout.

-Don

They can limit the number of pie items to a default of 8, and the overflow items are put below as linear menu items by default, or you can specify the default direction for overflow items. If you limit the number of pie items to 0, then the menu functions as a normal "pull down" linear menu.

Linear items can also be layed out above, below, to the left, or to the right of the pie menu, so it supports "pull up", "pull right" and "pull left" menus as well as "pull down".

Here is an extreme example of a pie menu with lots of extra linear items in all four directions, that popup up other variations of pie and linear menus. Here is the XML that defines the hybrid pie menu layout.

-Don

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

X makes you do input-processing application-side, but that doesn't really introduce an inefficiency.

You are quite incorrect, sir.

The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!

The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.

So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? Then any trivial application (like the clock) could incorporate a fully functional graphics editor (so you could edit the graphics used for the face and hands). You could use a customizable clock over a slow network connection, because it would not have to send the same complex graphics commands each second to redraw the face and hands -- in fact the entire clock could run in the window system itself without requiring another process like XClock.

Am I crazy for suggesting incorporating a graphics editor into the window server, just for a silly clock? Well why not? It's been done before.

The HyperLook user interface system, which was based on NeWS, had a fully functional PostScript graphics editor component that ran in entirely within the NeWS server.

You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.

Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.

HyperLook illustrates why I think it's important to be able to download code into the user interface and process input locally.

But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.

You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.

X is simply not useable over a low-bandwidth link such as a cell phone, compression technology or not. The ultimate compression technology is executable code, which is the basis of NeWS architectures.

If you can convince app developers to write their code in Javascript, than more power to you.

What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. I've written many JavaScript components and applications that incorporate them, and I love it. Fasteroids, Run-On-Sentence and Pie Menu Schema Editor are some simple examples, but it's easy to write much more complex desktop applications, and even entire desktop windowing interfaces, in JavaScript.

But that's where I was getting at with the Lisp comment. To be

Pie menus are a naturally efficient way to operate a tilt-sensitive user interface. Scrolling up and down through one-dimensional linear menus with a device that can tilt in any directions is a waste of the device's potential.

Here's a cool research paper from Sony's Computer Science Labs, about "tilting pie menus". I love it! I can't wait till all cell phones can sense tilt. Tilt control rocks!

Tilting Operations for Small Screen Computers
By Jun Rekimoto, Sony Computer Science Laboratory, Inc.
More details: Tilting Operations for Small Screen Interfaces (Tech Note)
HTML version from Google

-Don

The SVG comittee decided against the use of nested sub-elements to describe paths, because it would have such a huge overhead in the size of the file and especially all the dom elements that would be required to represent and expose it.

Where did they get this idea? From VML, which was Microsoft's previous attempt at a vector graphics markup language, which is still built into the browser. VML actually has a bunch of good ideas in it, and it can be included inline on the web page.

Here's an example of a game called "Fasteroids" that I wrote in JavaScript and VML, that only runs in Internet Explorer of couse. I recently rewrote Fasteroids for SVG, which was pretty straightforward, but I haven't posted the source to that yet. I've also implemented pie menus for SVG. Ask me if you're interested.

http://www.piemenu.com/fasteroids.html

-Don

Pie menus enable multiple functions on a single touch-screen button, so you can not only touch, but also stroke up, down left or right. They're fast, reliable and easy to use with your finger instead of a pen, and with only one hand. You get much more functionality out of the same amount of screen space, so the resulting remote control interfaces are less cluttered and more functional.

You can touch the pause button and stroke down to stop, touch the program description and stroke up to switch to the channel, stroke left and right to page to the previous and next programs, stroke down to link to the index, etc.

I'm currently developing a ConnectedTV skin editor, that will let you create your own remote control interfaces with custom buttons and graphics, program them with any IR command, and bake your own pie menus.

The skin editor isn't available yet, but I'm interested in hearing from people who would like to beta test it, and who have opinions about what it should do. I'm especially interested in hearing from Pronto users: not only is ConnectedTV much cheaper than Pronto because runs on your existing Palm, but it also has useful features like the pie menus and the personalized TV guide, integrated with a universal remote control. So you can take your Palm with you wherever you go (like the kitchen, bathroom, school or work), and browse the ConnectedTV guide any time you want.

A free two week trial of ConnectedTV for the Palm is available at Connected.TV.

-Don

It's unfortunate that some people have to discredit the open source community by spreading misinformation instead of trying to learn the truth. You can't fight effectively against something you don't understand, especially if the lies you believe make you think it's much worse than it is.

You're repeating a bunch of common misconceptions about ActiveX that Netscape and Sun spread in their battle against Microsoft. Unfortunately, the foolish wing of the Open Source community worshiped anything Netscape and Sun said as gospel, because they believed that their enemy's enemy is their friend.

ActiveX is not tied to Windows. It runs just fine on the Mac, Unix and other platforms. I successfully used it on the Mac in 1996. Mozilla has an open source clone of COM/ActiveX called "XPCOM", which you're using right now if you're running Mozilla.

Your claim that "the [ActiveX] security is next to nonexistent" is false, and you're spreading misinformation, which does more harm than good to the open source community.

ActiveX certainly does have quite an elaborate security model. So does Java, but it's different. ActiveX lets you implement components in any language, even Java, so the capabilities of the ActiveX control depend on the language in which it's implemented. So there's another layer of security, that Java is lacking.

ActiveX controls implemented in C++ (like this implementation of pie menus can make Win32 calls, but by default the browser is set up to require user confirmation before running the control. ActiveX components can be packaged with cryptographically signed certificates, and the user can manage which certificates they trust, reject, accept, etc.

ActiveX controls implemented in JavaScript (like this implementation of pie menus are restricted to the safe capabilities of JavaScript running in the browser. Those can download and run without requiring confirmation from the user, just like any other JavaScript code or Java applet. So it's no less secure than Java and JavaScript.

Your opinion that open source makes component technology unnecessary is extremely naive, and simply wrong. Obviously you have never written a a portable program to the gnu specification with a configure script, or looked into how that sausage factory works. Are you actually proposing doing that stuff at run-time??!

If Sun had understood the problems that ActiveX/COM was addressing, instead of ignoring them on purpose, Java would have been much more useful: easier to integrate with code written in other languages, easier to use as a plug-in application scripting language, easier to switch between different VMs, easier to write native extensions. But Sun's goal is to lock you into using "100% Pure Java", so they weren't interested in solving those problems.

Sun has finally tried to solve some of these problems (with belated and questionable success), but that was only AFTER getting their ass kicked by Microsoft and their noses rubbed in their own filth. Not only did Microsoft's Java VM beat the pants off of Sun's, but it was also deeply integrated with COM, so you could write COM components in Java, and use COM components from Java.

Sun was broadsided by the deep level of integration that Microsoft achieved with their Java VM, because Sun never even bothered to learn about COM, nor did they want to address any of the problems that COM solved. That's why Sun pushes RMI instead of CORBA, and had to be dragged kicking and screaming to web services.

In a nutshell, the problem that COM solves is integrating components written in different langua

It's unfortunate that some people have to discredit the open source community by spreading misinformation instead of trying to learn the truth. You can't fight effectively against something you don't understand, especially if the lies you believe make you think it's much worse than it is.

You're repeating a bunch of common misconceptions about ActiveX that Netscape and Sun spread in their battle against Microsoft. Unfortunately, the foolish wing of the Open Source community worshiped anything Netscape and Sun said as gospel, because they believed that their enemy's enemy is their friend.

ActiveX is not tied to Windows. It runs just fine on the Mac, Unix and other platforms. I successfully used it on the Mac in 1996. Mozilla has an open source clone of COM/ActiveX called "XPCOM", which you're using right now if you're running Mozilla.

Your claim that "the [ActiveX] security is next to nonexistent" is false, and you're spreading misinformation, which does more harm than good to the open source community.

ActiveX certainly does have quite an elaborate security model. So does Java, but it's different. ActiveX lets you implement components in any language, even Java, so the capabilities of the ActiveX control depend on the language in which it's implemented. So there's another layer of security, that Java is lacking.

ActiveX controls implemented in C++ (like this implementation of pie menus can make Win32 calls, but by default the browser is set up to require user confirmation before running the control. ActiveX components can be packaged with cryptographically signed certificates, and the user can manage which certificates they trust, reject, accept, etc.

ActiveX controls implemented in JavaScript (like this implementation of pie menus are restricted to the safe capabilities of JavaScript running in the browser. Those can download and run without requiring confirmation from the user, just like any other JavaScript code or Java applet. So it's no less secure than Java and JavaScript.

Your opinion that open source makes component technology unnecessary is extremely naive, and simply wrong. Obviously you have never written a a portable program to the gnu specification with a configure script, or looked into how that sausage factory works. Are you actually proposing doing that stuff at run-time??!

If Sun had understood the problems that ActiveX/COM was addressing, instead of ignoring them on purpose, Java would have been much more useful: easier to integrate with code written in other languages, easier to use as a plug-in application scripting language, easier to switch between different VMs, easier to write native extensions. But Sun's goal is to lock you into using "100% Pure Java", so they weren't interested in solving those problems.

Sun has finally tried to solve some of these problems (with belated and questionable success), but that was only AFTER getting their ass kicked by Microsoft and their noses rubbed in their own filth. Not only did Microsoft's Java VM beat the pants off of Sun's, but it was also deeply integrated with COM, so you could write COM components in Java, and use COM components from Java.

Sun was broadsided by the deep level of integration that Microsoft achieved with their Java VM, because Sun never even bothered to learn about COM, nor did they want to address any of the problems that COM solved. That's why Sun pushes RMI instead of CORBA, and had to be dragged kicking and screaming to web services.

In a nutshell, the problem that COM solves is integrating components written in different langua

I guess mouse gestures will be there with IE 6.5 or IE 7.0 .. Opera was the 1st implementator in the browser world, there's a plugin for Mozilla and it's a great feature.

Opera was not the first browser with gestures. HyperTIES supported gestures in the form of pie menus with full mouse-ahead display pre-emption, which I developed at the University of Maryland Human Computer Interaction lab during 1988-1991, under the direction of Ben Shneiderman. All this and more was demonstrated in the ACM SIGGRAPH Video Review "All The Widgets", a video tape of user interface techniques produced by Brad Myers for the ACM SIGGRAPH Video Review (CHI'90 Special Issue #57). Here's a streaming quicktime excerpt from the All the Widgets.

Mozilla was not the first browser with a pie menu plug-in. In 1997 I developed a pie menu ActiveX plug-in for Internet Explorer in C++ (which is not just limited to the browser, but plugs into any application supporting OLE/ActiveX). Here's a streaming quicktime demo of ActiveX pie menus. Here's the ActiveX Pie Menus web page, with the binary ActiveX control, the free open source code, and a description of pie menus.

Several years later (about a year before Mozilla's Optimoz), I developed another pie menu plug-in for Internet Explorer, implemented in JavaScript, using Dynamic HTML for rendering, and XML for defining the nested tree of pie menus. You can embed arbitrary HTML in the XML pie menu description to control the appearance, and you can write JavaScript handlers not only to handle the menu selections, but also to provide rich dynamic feedback (by modifying the dynamic html and style properties in the fly, in response to mouse motion and clicks).

Here is the JavaScript Pie Menus web page, with links to examples, documentation, etc.

But MS has a dillema: to use mouse gestures a user has to read the documentation and memorize what action does what, ( it's a power user tool), but I think reading the docs and memorizing cryptic mouse movements is a bit too much to ask from the average IE user!

That dilemma dones't apply to pie menus. Pie menus are a visible "self revealing" style of gesture recognition, that prompt the user with directions, as opposed to invisibe "self concealing" gesture recognition that has no way to prompt the user.

Pie menus are easy for novice users, because they pop up and show all of the possible directions in an intuitive way. They're also efficient for expert users, because you can "mouse ahead" without looking at the screen. Novice users quickly and easily learn to be experts, because the expert mouse-ahead gesture is the same motion and direction as the novice gesture, unlike pull-down menus with function key shortcuts. Learning to select the third "Paste" item on the pull-down "Edit" menu with the mouse does not train you to press Ctrl-V, which is a totally different gesture, so pull-down menus don't support rehearsal.

The other reason that pie menus are fundamentally better that conventional gesture recognition systems, is that they totally cover 100% of all possible gesture space with meaningful, predictable behavior. Gesture space is the space of all possible gestures, between the beginning of the gesture (pressing down the mouse button, touching the pen to the screen, whatever), to the end of the gesture (releasing the button). The computer has to analyze that gesture and decide what to do, and it's a good thing if does what the human intended more often than not.

When using a handwr

I guess mouse gestures will be there with IE 6.5 or IE 7.0 .. Opera was the 1st implementator in the browser world, there's a plugin for Mozilla and it's a great feature.

Opera was not the first browser with gestures. HyperTIES supported gestures in the form of pie menus with full mouse-ahead display pre-emption, which I developed at the University of Maryland Human Computer Interaction lab during 1988-1991, under the direction of Ben Shneiderman. All this and more was demonstrated in the ACM SIGGRAPH Video Review "All The Widgets", a video tape of user interface techniques produced by Brad Myers for the ACM SIGGRAPH Video Review (CHI'90 Special Issue #57). Here's a streaming quicktime excerpt from the All the Widgets.

Mozilla was not the first browser with a pie menu plug-in. In 1997 I developed a pie menu ActiveX plug-in for Internet Explorer in C++ (which is not just limited to the browser, but plugs into any application supporting OLE/ActiveX). Here's a streaming quicktime demo of ActiveX pie menus. Here's the ActiveX Pie Menus web page, with the binary ActiveX control, the free open source code, and a description of pie menus.

Several years later (about a year before Mozilla's Optimoz), I developed another pie menu plug-in for Internet Explorer, implemented in JavaScript, using Dynamic HTML for rendering, and XML for defining the nested tree of pie menus. You can embed arbitrary HTML in the XML pie menu description to control the appearance, and you can write JavaScript handlers not only to handle the menu selections, but also to provide rich dynamic feedback (by modifying the dynamic html and style properties in the fly, in response to mouse motion and clicks).

Here is the JavaScript Pie Menus web page, with links to examples, documentation, etc.

But MS has a dillema: to use mouse gestures a user has to read the documentation and memorize what action does what, ( it's a power user tool), but I think reading the docs and memorizing cryptic mouse movements is a bit too much to ask from the average IE user!

That dilemma dones't apply to pie menus. Pie menus are a visible "self revealing" style of gesture recognition, that prompt the user with directions, as opposed to invisibe "self concealing" gesture recognition that has no way to prompt the user.

Pie menus are easy for novice users, because they pop up and show all of the possible directions in an intuitive way. They're also efficient for expert users, because you can "mouse ahead" without looking at the screen. Novice users quickly and easily learn to be experts, because the expert mouse-ahead gesture is the same motion and direction as the novice gesture, unlike pull-down menus with function key shortcuts. Learning to select the third "Paste" item on the pull-down "Edit" menu with the mouse does not train you to press Ctrl-V, which is a totally different gesture, so pull-down menus don't support rehearsal.

The other reason that pie menus are fundamentally better that conventional gesture recognition systems, is that they totally cover 100% of all possible gesture space with meaningful, predictable behavior. Gesture space is the space of all possible gestures, between the beginning of the gesture (pressing down the mouse button, touching the pen to the screen, whatever), to the end of the gesture (releasing the button). The computer has to analyze that gesture and decide what to do, and it's a good thing if does what the human intended more often than not.

When using a handwr

I guess mouse gestures will be there with IE 6.5 or IE 7.0 .. Opera was the 1st implementator in the browser world, there's a plugin for Mozilla and it's a great feature.

Opera was not the first browser with gestures. HyperTIES supported gestures in the form of pie menus with full mouse-ahead display pre-emption, which I developed at the University of Maryland Human Computer Interaction lab during 1988-1991, under the direction of Ben Shneiderman. All this and more was demonstrated in the ACM SIGGRAPH Video Review "All The Widgets", a video tape of user interface techniques produced by Brad Myers for the ACM SIGGRAPH Video Review (CHI'90 Special Issue #57). Here's a streaming quicktime excerpt from the All the Widgets.

Mozilla was not the first browser with a pie menu plug-in. In 1997 I developed a pie menu ActiveX plug-in for Internet Explorer in C++ (which is not just limited to the browser, but plugs into any application supporting OLE/ActiveX). Here's a streaming quicktime demo of ActiveX pie menus. Here's the ActiveX Pie Menus web page, with the binary ActiveX control, the free open source code, and a description of pie menus.

Several years later (about a year before Mozilla's Optimoz), I developed another pie menu plug-in for Internet Explorer, implemented in JavaScript, using Dynamic HTML for rendering, and XML for defining the nested tree of pie menus. You can embed arbitrary HTML in the XML pie menu description to control the appearance, and you can write JavaScript handlers not only to handle the menu selections, but also to provide rich dynamic feedback (by modifying the dynamic html and style properties in the fly, in response to mouse motion and clicks).

Here is the JavaScript Pie Menus web page, with links to examples, documentation, etc.

But MS has a dillema: to use mouse gestures a user has to read the documentation and memorize what action does what, ( it's a power user tool), but I think reading the docs and memorizing cryptic mouse movements is a bit too much to ask from the average IE user!

That dilemma dones't apply to pie menus. Pie menus are a visible "self revealing" style of gesture recognition, that prompt the user with directions, as opposed to invisibe "self concealing" gesture recognition that has no way to prompt the user.

Pie menus are easy for novice users, because they pop up and show all of the possible directions in an intuitive way. They're also efficient for expert users, because you can "mouse ahead" without looking at the screen. Novice users quickly and easily learn to be experts, because the expert mouse-ahead gesture is the same motion and direction as the novice gesture, unlike pull-down menus with function key shortcuts. Learning to select the third "Paste" item on the pull-down "Edit" menu with the mouse does not train you to press Ctrl-V, which is a totally different gesture, so pull-down menus don't support rehearsal.

The other reason that pie menus are fundamentally better that conventional gesture recognition systems, is that they totally cover 100% of all possible gesture space with meaningful, predictable behavior. Gesture space is the space of all possible gestures, between the beginning of the gesture (pressing down the mouse button, touching the pen to the screen, whatever), to the end of the gesture (releasing the button). The computer has to analyze that gesture and decide what to do, and it's a good thing if does what the human intended more often than not.

When using a handwr

I guess mouse gestures will be there with IE 6.5 or IE 7.0 .. Opera was the 1st implementator in the browser world, there's a plugin for Mozilla and it's a great feature.

Opera was not the first browser with gestures. HyperTIES supported gestures in the form of pie menus with full mouse-ahead display pre-emption, which I developed at the University of Maryland Human Computer Interaction lab during 1988-1991, under the direction of Ben Shneiderman. All this and more was demonstrated in the ACM SIGGRAPH Video Review "All The Widgets", a video tape of user interface techniques produced by Brad Myers for the ACM SIGGRAPH Video Review (CHI'90 Special Issue #57). Here's a streaming quicktime excerpt from the All the Widgets.

Mozilla was not the first browser with a pie menu plug-in. In 1997 I developed a pie menu ActiveX plug-in for Internet Explorer in C++ (which is not just limited to the browser, but plugs into any application supporting OLE/ActiveX). Here's a streaming quicktime demo of ActiveX pie menus. Here's the ActiveX Pie Menus web page, with the binary ActiveX control, the free open source code, and a description of pie menus.

Several years later (about a year before Mozilla's Optimoz), I developed another pie menu plug-in for Internet Explorer, implemented in JavaScript, using Dynamic HTML for rendering, and XML for defining the nested tree of pie menus. You can embed arbitrary HTML in the XML pie menu description to control the appearance, and you can write JavaScript handlers not only to handle the menu selections, but also to provide rich dynamic feedback (by modifying the dynamic html and style properties in the fly, in response to mouse motion and clicks).

Here is the JavaScript Pie Menus web page, with links to examples, documentation, etc.

But MS has a dillema: to use mouse gestures a user has to read the documentation and memorize what action does what, ( it's a power user tool), but I think reading the docs and memorizing cryptic mouse movements is a bit too much to ask from the average IE user!

That dilemma dones't apply to pie menus. Pie menus are a visible "self revealing" style of gesture recognition, that prompt the user with directions, as opposed to invisibe "self concealing" gesture recognition that has no way to prompt the user.

Pie menus are easy for novice users, because they pop up and show all of the possible directions in an intuitive way. They're also efficient for expert users, because you can "mouse ahead" without looking at the screen. Novice users quickly and easily learn to be experts, because the expert mouse-ahead gesture is the same motion and direction as the novice gesture, unlike pull-down menus with function key shortcuts. Learning to select the third "Paste" item on the pull-down "Edit" menu with the mouse does not train you to press Ctrl-V, which is a totally different gesture, so pull-down menus don't support rehearsal.

The other reason that pie menus are fundamentally better that conventional gesture recognition systems, is that they totally cover 100% of all possible gesture space with meaningful, predictable behavior. Gesture space is the space of all possible gestures, between the beginning of the gesture (pressing down the mouse button, touching the pen to the screen, whatever), to the end of the gesture (releasing the button). The computer has to analyze that gesture and decide what to do, and it's a good thing if does what the human intended more often than not.

When using a handwr

I guess mouse gestures will be there with IE 6.5 or IE 7.0 .. Opera was the 1st implementator in the browser world, there's a plugin for Mozilla and it's a great feature.

Opera was not the first browser with gestures. HyperTIES supported gestures in the form of pie menus with full mouse-ahead display pre-emption, which I developed at the University of Maryland Human Computer Interaction lab during 1988-1991, under the direction of Ben Shneiderman. All this and more was demonstrated in the ACM SIGGRAPH Video Review "All The Widgets", a video tape of user interface techniques produced by Brad Myers for the ACM SIGGRAPH Video Review (CHI'90 Special Issue #57). Here's a streaming quicktime excerpt from the All the Widgets.

Mozilla was not the first browser with a pie menu plug-in. In 1997 I developed a pie menu ActiveX plug-in for Internet Explorer in C++ (which is not just limited to the browser, but plugs into any application supporting OLE/ActiveX). Here's a streaming quicktime demo of ActiveX pie menus. Here's the ActiveX Pie Menus web page, with the binary ActiveX control, the free open source code, and a description of pie menus.

Several years later (about a year before Mozilla's Optimoz), I developed another pie menu plug-in for Internet Explorer, implemented in JavaScript, using Dynamic HTML for rendering, and XML for defining the nested tree of pie menus. You can embed arbitrary HTML in the XML pie menu description to control the appearance, and you can write JavaScript handlers not only to handle the menu selections, but also to provide rich dynamic feedback (by modifying the dynamic html and style properties in the fly, in response to mouse motion and clicks).

Here is the JavaScript Pie Menus web page, with links to examples, documentation, etc.

But MS has a dillema: to use mouse gestures a user has to read the documentation and memorize what action does what, ( it's a power user tool), but I think reading the docs and memorizing cryptic mouse movements is a bit too much to ask from the average IE user!

That dilemma dones't apply to pie menus. Pie menus are a visible "self revealing" style of gesture recognition, that prompt the user with directions, as opposed to invisibe "self concealing" gesture recognition that has no way to prompt the user.

Pie menus are easy for novice users, because they pop up and show all of the possible directions in an intuitive way. They're also efficient for expert users, because you can "mouse ahead" without looking at the screen. Novice users quickly and easily learn to be experts, because the expert mouse-ahead gesture is the same motion and direction as the novice gesture, unlike pull-down menus with function key shortcuts. Learning to select the third "Paste" item on the pull-down "Edit" menu with the mouse does not train you to press Ctrl-V, which is a totally different gesture, so pull-down menus don't support rehearsal.

The other reason that pie menus are fundamentally better that conventional gesture recognition systems, is that they totally cover 100% of all possible gesture space with meaningful, predictable behavior. Gesture space is the space of all possible gestures, between the beginning of the gesture (pressing down the mouse button, touching the pen to the screen, whatever), to the end of the gesture (releasing the button). The computer has to analyze that gesture and decide what to do, and it's a good thing if does what the human intended more often than not.

When using a handwr

Pie Menu Instructions

By Don Hopkins (don@DonHopkins.com)

How To Choose With Pie Menus

Mouse Control

There are two ways to use a pie menu with a mouse: with or without holding down the mouse button. You can start by going "click move click", but with experience, you'll learn to go "press move release". The relaxed "click move click" way to use pie menus is to click the button (press and release without moving), move the cursor, then click the button again. The accelerated "press move release" way is to press down and hold the button, move the cursor, then release the button.

When you first pop up a pie menu, the cursor begins in the menu center, and the selection depends on the direction you move. Each pie menu "item" is shaped like a slice of pie, arranged around the cursor in different directions. The center of the pie menu is an inactive area, which doesn't select any items: so you can click once to pop up a pie menu, then click again in the center without moving, to cancel.

The further out from the menu center you move the cursor, the more precisely you control the direction, and the easier it is to select a particular item. You can move the cursor far out to the edge of the screen, for very exact control.

It doesn't matter what path you take to select a pie menu item, the only thing that counts is the direction between the first and final click. This allows you to reselect different items any time before the final click, by moving the mouse around to different slices of the pie.

Mouse Ahead

If you click the button, the pop-up window will appear on the screen instantly. But if you hold the button down and move, the menu display will be pre-empted until you pause. Once you're familiar with the directions, you can press the button and move without hesitating, selecting from the menu very quickly.

You can "mouse ahead" through a pie menu, by smoothly pressing, moving, and releasing the button without hesitating, and the window will never be displayed on the screen!

Even before its window pops up, an invisible pie menu gives you instant feedback by changing the cursor shape to show how many items there are, and which item is selected.

If you want to be sure of the selection, just stop moving, and the pie menu will pop up. You can always change the selection by moving around the menu.

With experience you will be able to reliably "mouse ahead" and even select items from nested pie menus, without looking at the screen.

Nested Menus

A pie menu can have any number of submenu levels arranged in a nested tree. Any item can pop up another pie submenu, that itself can contain items with submenus.

Clicking in an item with a submenu pops it up, centered on the cursor, on top of the previous menu. Clicking again in the center of the submenu cancels the whole tree. But clicking the other button goes back to the previous level.

When you press the other button down, the cursor moves back to the current menu center. When you release the other button in the menu center, you go back to the previous menu, positioned in the same place you were when you left it. But you can also move the cursor out of the menu center before releasing the other button, and you will stay at the current level. This is convenient if you just want to get back to the menu center and select another item.

Scrolling Menus

Pie menus may be limited to a certain number of slices (like 8), so that the pie slices are wide and easy to select. If there are extra items, then they are clustered into groups of the same number outside of the pie. You can select any of the extra items by pointing directly its label.

Each group of items is arranged like a compact pie menu of the same number of items (or fewer). You can scroll the pie menu to any group by clicking in the center of the group, and the menu will center on the labels. The "Page Up" and "Page Down" keys also scroll the pie from group to group.

Keyboard Controls

Pie menus support several keyboard accellerators.

Escape or Delete: Cancels the entire menu tree.
Backspace: Moves back to the previous menu in the tree.
Home: Centers the menu on the current cursor position.
Return: Selectes the currently highlighted item, or cancels the menu if nothing is highlighted.
Arrows: Points to the top, bottom, left, or right slice. If you press two orthogonal arrows at once, it points to a diagonal slice.
Numeric Keypad: Selects the item in the direction of the key on the keypad. The 5 key selects the menu center.
Tab: Select the next pie menu item. Shift-Tab selects the previous.
Page Up: Scroll to the previous menu item group.
Page Down: Scroll to the next menu item group.
First letter of a menu item: Typing the first letter of a menu item selects the first item that begins with that letter. Typing that letter again selects the next and subsequent menu items beginning with the same letter.

-Don http://www.piemenu.com/PieMenuDescription.html

A Description of Pie Menus, By Don Hopkins (don@DonHopkins.com).

Pictures of Pie Menus. [See the web page http://www.piemenu.com/PieMenuDescription.html for illustrations.]

ActiveX Pie Menu Features: The ActiveX Pie Menu component is designed to be robust, general purpose, and easy to integrate into all kinds of web pages and user interfaces. The graphical layout is dynamic and adaptive, and the look and feel can be adjusted in many ways, but pie menus come with reasonable defaults, so they should work well in a wide range of situations.

ActiveX pie menus support any number of items per menu, and arbitrarily nested submenus.

The items can be layed out in reading order (left to right, top to bottom), as well as circular order (clockwise or counter-clockwise).

The number of pie slices can be limited to a user-friendly even number like eight or four, so the slices are always big and easy to select. Extra items are grouped into clusters above and below the pie menu, with the same number of items. You can select any extra item by pointing directly at its label. You can also scroll the pie menu up and down the "totem pole" of clusters, centering the pie on any group, so the items in that group are very easy to select, and the other groups are compact clusters further away from the cursor.

This helps you to mentally chunk items into a few recognizable groups: instead of a tall undifferentiated column of items, you have several stable clusters of eight (or fewer) items. One of the groups is the pie part of the menu, which you can page between groups, and the others groups are displayed as more compact (but harder to select) rectangular menu labels. You can scroll the pie menu from group to group, by pressing the Page Up and Page Down keys, or clicking in the center of a cluster.

Pie Menus come with a set of property pages for easy configuration, that user interface designers can use to create and edit pie menus with tools like Visual Basic.

You can plug pie menus into web pages, by configuring them with HTML properties, and programming them with JavaScript or Visual Basic Script.

You can also plug them into applications supporting ActiveX controls, with tools like Visual Basic, Visual C++, Java, and the ActiveX Control Pad, interactivally configuring them via tabbed property sheets.

There are seven tabbed property pages for documentation, menu outline editing, menu property editing, visual menu tree previewing, font selection, color selection, and image selection.

Simple nested menu description format. Just type the menu items into a text editor or html property as an indented outline, with optional tags for overriding default layout properties and actions.

The indentation of the outline specifies how the items are grouped into submenus, as you would expect. You can use a semi-colon to separate a list of items at the same level of indentation.

Each menu item can have a label as well as an optional action string (that defaults to the label), that may be used as a convenient argument to the menu handler. This is so you can have a descriptive label meaningful to the user, as well as an associated numeric or symbolic action meaningful to the menu handler.

Intelligent dynamic menu layout. Menus are automatically sized and layed out so they're as small as possible with no items overlapping.

Several user interface styles with dynamic window shapes. As well as popping up in traditional rectangular windows, pie menus can also pop up in pie shaped round windows, minimal blob windows, thought balloons, speech balloons, and spoked windows.

Dynamic window shape tracking. The popup windows can dynamically reshape during tracking, to hide all but the selected menu item, reducing clutter. This feature can be enabled or disabled for speed.

Visual control over font, point size, foreground color, background color, light and dark beveled edge colors. Preview property page for browsing the menu tree and seeing how each menu will look.

Beveled edges around any shape of window. This makes overlapping menus easier to see, and fits in nicely with the Windows desktop. This feature can be enabled or disabled for speed.

Mouse-ahead display pre-emption. You can quickly click through nested submenus without popping them up on the screen. The popup delay can be adjusted, which defines how long the cursor must be still before the menu pops up.

Double buffered flicker-free drawing. Menus are drawn into an offscreen buffer, so there is no flashing on the screen. This feature can be enabled or disabled for speed.

When you use a pie menu, preview and selection events are sent to the web page or application. Event handlers can track when an item is selected, when the selected item changes, and whenever the direction or distance changes, to provide continuous feedback of the selection.

Defered menu layout and window creation. Menus are not layed out and windows are not created until the menu is actually used.

Graphical background and target images. You can specify bitmaps to use as the menu background and the target window. Or you can use solid color backgrounds.

Press down and drag, as well as click-up operation. Supports quick "press-move-release" interaction, as well as "click-move-click" interaction, so you don't have to hold the button down.

Supports all three mouse buttons, IntelliMouse wheel, and keyboard. You can pop pie menus up under program control, or in response to any of the three mouse buttons, and even pop them up and navigate all the items and submenus from the keyboard.

Sub-menu browsing is supported, so you can click the other button to pop down a submenu and go back a level, or cancel the whole menu tree.

Pie menus are not patented, proprietary, or restricted. You are free to use them in your own products and web pages. The source code is free, and you may modify it or use it for any purpose you want, provided that the copyright is left intact.

If you make any changes, you are encouraged but not required to send them back to xardox@mindspring.com so they can be integrated back into the official source code.

If you find any bugs, want to suggest new features or enhancements, or would like to find out more about pie menus, please look at the pie menu web page at http://www.piemenu.com.

If you have problems, please check the web page to make sure you're got the latest version, then send email to the author, don@DonHopkins.com.

If you use pie menus on your web page or in a product, I would enjoy seeing it, and would appreciate it if you sent me the URL or a copy of your product.

I've written some papers about pie menu design, available on the pie menu web page, and I'd like to link to other people using or writing about pie menus, so please send me any interesting URLs.

-Don http://www.piemenu.com/PieMenuDescription.html

A Description of Pie Menus, By Don Hopkins (don@DonHopkins.com).

Pictures of Pie Menus. [See the web page http://www.piemenu.com/PieMenuDescription.html for illustrations.]

ActiveX Pie Menu Features: The ActiveX Pie Menu component is designed to be robust, general purpose, and easy to integrate into all kinds of web pages and user interfaces. The graphical layout is dynamic and adaptive, and the look and feel can be adjusted in many ways, but pie menus come with reasonable defaults, so they should work well in a wide range of situations.

ActiveX pie menus support any number of items per menu, and arbitrarily nested submenus.

The items can be layed out in reading order (left to right, top to bottom), as well as circular order (clockwise or counter-clockwise).

The number of pie slices can be limited to a user-friendly even number like eight or four, so the slices are always big and easy to select. Extra items are grouped into clusters above and below the pie menu, with the same number of items. You can select any extra item by pointing directly at its label. You can also scroll the pie menu up and down the "totem pole" of clusters, centering the pie on any group, so the items in that group are very easy to select, and the other groups are compact clusters further away from the cursor.

This helps you to mentally chunk items into a few recognizable groups: instead of a tall undifferentiated column of items, you have several stable clusters of eight (or fewer) items. One of the groups is the pie part of the menu, which you can page between groups, and the others groups are displayed as more compact (but harder to select) rectangular menu labels. You can scroll the pie menu from group to group, by pressing the Page Up and Page Down keys, or clicking in the center of a cluster.

Pie Menus come with a set of property pages for easy configuration, that user interface designers can use to create and edit pie menus with tools like Visual Basic.

You can plug pie menus into web pages, by configuring them with HTML properties, and programming them with JavaScript or Visual Basic Script.

You can also plug them into applications supporting ActiveX controls, with tools like Visual Basic, Visual C++, Java, and the ActiveX Control Pad, interactivally configuring them via tabbed property sheets.

There are seven tabbed property pages for documentation, menu outline editing, menu property editing, visual menu tree previewing, font selection, color selection, and image selection.

Simple nested menu description format. Just type the menu items into a text editor or html property as an indented outline, with optional tags for overriding default layout properties and actions.

The indentation of the outline specifies how the items are grouped into submenus, as you would expect. You can use a semi-colon to separate a list of items at the same level of indentation.

Each menu item can have a label as well as an optional action string (that defaults to the label), that may be used as a convenient argument to the menu handler. This is so you can have a descriptive label meaningful to the user, as well as an associated numeric or symbolic action meaningful to the menu handler.

Intelligent dynamic menu layout. Menus are automatically sized and layed out so they're as small as possible with no items overlapping.

Several user interface styles with dynamic window shapes. As well as popping up in traditional rectangular windows, pie menus can also pop up in pie shaped round windows, minimal blob windows, thought balloons, speech balloons, and spoked windows.

Dynamic window shape tracking. The popup windows can dynamically reshape during tracking, to hide all but the selected menu item, reducing clutter. This feature can be enabled or disabled for speed.

Visual control over font, point size, foreground color, background color, light and dark beveled edge colors. Preview property page for browsing the menu tree and seeing how each menu will look.

Beveled edges around any shape of window. This makes overlapping menus easier to see, and fits in nicely with the Windows desktop. This feature can be enabled or disabled for speed.

Mouse-ahead display pre-emption. You can quickly click through nested submenus without popping them up on the screen. The popup delay can be adjusted, which defines how long the cursor must be still before the menu pops up.

Double buffered flicker-free drawing. Menus are drawn into an offscreen buffer, so there is no flashing on the screen. This feature can be enabled or disabled for speed.

When you use a pie menu, preview and selection events are sent to the web page or application. Event handlers can track when an item is selected, when the selected item changes, and whenever the direction or distance changes, to provide continuous feedback of the selection.

Defered menu layout and window creation. Menus are not layed out and windows are not created until the menu is actually used.

Graphical background and target images. You can specify bitmaps to use as the menu background and the target window. Or you can use solid color backgrounds.

Press down and drag, as well as click-up operation. Supports quick "press-move-release" interaction, as well as "click-move-click" interaction, so you don't have to hold the button down.

Supports all three mouse buttons, IntelliMouse wheel, and keyboard. You can pop pie menus up under program control, or in response to any of the three mouse buttons, and even pop them up and navigate all the items and submenus from the keyboard.

Sub-menu browsing is supported, so you can click the other button to pop down a submenu and go back a level, or cancel the whole menu tree.

Pie menus are not patented, proprietary, or restricted. You are free to use them in your own products and web pages. The source code is free, and you may modify it or use it for any purpose you want, provided that the copyright is left intact.

If you make any changes, you are encouraged but not required to send them back to xardox@mindspring.com so they can be integrated back into the official source code.

If you find any bugs, want to suggest new features or enhancements, or would like to find out more about pie menus, please look at the pie menu web page at http://www.piemenu.com.

If you have problems, please check the web page to make sure you're got the latest version, then send email to the author, don@DonHopkins.com.

If you use pie menus on your web page or in a product, I would enjoy seeing it, and would appreciate it if you sent me the URL or a copy of your product.

I've written some papers about pie menu design, available on the pie menu web page, and I'd like to link to other people using or writing about pie menus, so please send me any interesting URLs.

-Don http://www.piemenu.com/PieMenuDescription.html

A Description of Pie Menus, By Don Hopkins (don@DonHopkins.com).

Pictures of Pie Menus. [See the web page http://www.piemenu.com/PieMenuDescription.html for illustrations.]

ActiveX Pie Menu Features: The ActiveX Pie Menu component is designed to be robust, general purpose, and easy to integrate into all kinds of web pages and user interfaces. The graphical layout is dynamic and adaptive, and the look and feel can be adjusted in many ways, but pie menus come with reasonable defaults, so they should work well in a wide range of situations.

ActiveX pie menus support any number of items per menu, and arbitrarily nested submenus.

The items can be layed out in reading order (left to right, top to bottom), as well as circular order (clockwise or counter-clockwise).

The number of pie slices can be limited to a user-friendly even number like eight or four, so the slices are always big and easy to select. Extra items are grouped into clusters above and below the pie menu, with the same number of items. You can select any extra item by pointing directly at its label. You can also scroll the pie menu up and down the "totem pole" of clusters, centering the pie on any group, so the items in that group are very easy to select, and the other groups are compact clusters further away from the cursor.

This helps you to mentally chunk items into a few recognizable groups: instead of a tall undifferentiated column of items, you have several stable clusters of eight (or fewer) items. One of the groups is the pie part of the menu, which you can page between groups, and the others groups are displayed as more compact (but harder to select) rectangular menu labels. You can scroll the pie menu from group to group, by pressing the Page Up and Page Down keys, or clicking in the center of a cluster.

Pie Menus come with a set of property pages for easy configuration, that user interface designers can use to create and edit pie menus with tools like Visual Basic.

You can plug pie menus into web pages, by configuring them with HTML properties, and programming them with JavaScript or Visual Basic Script.

You can also plug them into applications supporting ActiveX controls, with tools like Visual Basic, Visual C++, Java, and the ActiveX Control Pad, interactivally configuring them via tabbed property sheets.

There are seven tabbed property pages for documentation, menu outline editing, menu property editing, visual menu tree previewing, font selection, color selection, and image selection.

Simple nested menu description format. Just type the menu items into a text editor or html property as an indented outline, with optional tags for overriding default layout properties and actions.

The indentation of the outline specifies how the items are grouped into submenus, as you would expect. You can use a semi-colon to separate a list of items at the same level of indentation.

Each menu item can have a label as well as an optional action string (that defaults to the label), that may be used as a convenient argument to the menu handler. This is so you can have a descriptive label meaningful to the user, as well as an associated numeric or symbolic action meaningful to the menu handler.

Intelligent dynamic menu layout. Menus are automatically sized and layed out so they're as small as possible with no items overlapping.

Several user interface styles with dynamic window shapes. As well as popping up in traditional rectangular windows, pie menus can also pop up in pie shaped round windows, minimal blob windows, thought balloons, speech balloons, and spoked windows.

Dynamic window shape tracking. The popup windows can dynamically reshape during tracking, to hide all but the selected menu item, reducing clutter. This feature can be enabled or disabled for speed.

Visual control over font, point size, foreground color, background color, light and dark beveled edge colors. Preview property page for browsing the menu tree and seeing how each menu will look.

Beveled edges around any shape of window. This makes overlapping menus easier to see, and fits in nicely with the Windows desktop. This feature can be enabled or disabled for speed.

Mouse-ahead display pre-emption. You can quickly click through nested submenus without popping them up on the screen. The popup delay can be adjusted, which defines how long the cursor must be still before the menu pops up.

Double buffered flicker-free drawing. Menus are drawn into an offscreen buffer, so there is no flashing on the screen. This feature can be enabled or disabled for speed.

When you use a pie menu, preview and selection events are sent to the web page or application. Event handlers can track when an item is selected, when the selected item changes, and whenever the direction or distance changes, to provide continuous feedback of the selection.

Defered menu layout and window creation. Menus are not layed out and windows are not created until the menu is actually used.

Graphical background and target images. You can specify bitmaps to use as the menu background and the target window. Or you can use solid color backgrounds.

Press down and drag, as well as click-up operation. Supports quick "press-move-release" interaction, as well as "click-move-click" interaction, so you don't have to hold the button down.

Supports all three mouse buttons, IntelliMouse wheel, and keyboard. You can pop pie menus up under program control, or in response to any of the three mouse buttons, and even pop them up and navigate all the items and submenus from the keyboard.

Sub-menu browsing is supported, so you can click the other button to pop down a submenu and go back a level, or cancel the whole menu tree.

Pie menus are not patented, proprietary, or restricted. You are free to use them in your own products and web pages. The source code is free, and you may modify it or use it for any purpose you want, provided that the copyright is left intact.

If you make any changes, you are encouraged but not required to send them back to xardox@mindspring.com so they can be integrated back into the official source code.

If you find any bugs, want to suggest new features or enhancements, or would like to find out more about pie menus, please look at the pie menu web page at http://www.piemenu.com.

If you have problems, please check the web page to make sure you're got the latest version, then send email to the author, don@DonHopkins.com.

If you use pie menus on your web page or in a product, I would enjoy seeing it, and would appreciate it if you sent me the URL or a copy of your product.

I've written some papers about pie menu design, available on the pie menu web page, and I'd like to link to other people using or writing about pie menus, so please send me any interesting URLs.

Mouse gestures in the form of pie menus have been around for a while now. See, for example:

• piewm -- a tvtwm-based window manager for X.
• Don Hopkins' pie menu site.

You can even find pie menus in real life -- look at home entertainment appliance remotes.

"Touch Tuning" with ConnectedTV is like speed dialing with the remote: you can forget all those channel numbers, and easily operate ConnectedTV with one hand.

One handed operation is an extremely important feature for a universal remote control, which should be purposefully designed into the user interface from the day one.

Like Mozilla and The Sims, ConnectedTV features "pie menus," which enable you to quickly and reliably select several different commands from one button by stroking in different directions, without using (and losing) the stylus. Pie menus make ConnectedTV more powerful per square inch than physical remotes that only support one function per button.

The buttons are big enough to easily select with your finger, and have useful functions in different directions. For example, stroking left or right scrolls to the previous or next page. You can stroke up on the name of a show to find out more about it, or stroke down to watch it, and ConnectedTV sends the numbers to change the channel, without you having to know or press any digits.

ConnectedTV also functions as a hot list and spam filter, so you can easily mark and find your favorite shows, while hiding shows you don't like. It's much better than the slowly scrolling on-screen guide, because it doesn't block the tv screen, you can take it anywhere with up to two weeks of guide, and use it at your own pace.

ConnectedTV is indispensable if you have hundreds of digital cable or satellite channels, because you can filter out the channels and shows you don't like, and mark your favorites so they're easy to find whenever they're on.

-info@Connected.TV

"Touch Tuning" with ConnectedTV is like speed dialing with the remote: you can forget all those channel numbers, and easily operate ConnectedTV with one hand. ConnectedTV features "pie menus," which enable you to quickly and reliably select several different commands from one button by stroking in different directions.

ConnectedTV is indispensable if you have hundreds of digital cable or satellite channels, because you can filter out the channels and shows you don't like, and mark your favorites so they're easy to find whenever they're on.

-info@Connected.TV

ConnectedTV for the Palm is a universal remote control integrated with a personalized television guide, that's designed to be easily used with one hand.

Like Mozilla and The Sims, it features "pie menus", which enable you to easily and reliably select several different functions from each button, without using (and losing) the stylus. Pie menus make ConnectedTV more powerful per square inch than physical remotes that only support one function per button.

The buttons are big enough to easily select with your finger, and have useful functions in different directions. For example, stroking left or right scrolls to the previous or next page. You can stroke up on the name of a show to find out more about it, or stroke down to watch it, and ConnectedTV sends the numbers to change the channel, without you having to know or press any digits.

"Touch Tuning" with ConnectedTV is like speed dialing for the remote control. It also functions as a hot list and spam filter, so you can easily mark and find your favorite shows, while hiding shows you don't like. It's much better than the slowly scrolling on-screen guide, because it doesn't block the tv screen, you can take it anywhere with up to two weeks of guide, and use it at your own pace.

-info@Connected.TV

They are provably faster and more reliable than linear menus, and you can run this experiment and prove it to yourself if you don't believe me or any of the research papers that have been published over the years:

Fasteroids is a free game that lets you compare pie menus with linear menus. Take the pie menu challange! Fasteroids tracks your selection speed and error rate, so you can compare pie menus and linear menus for yourself.

-Don

Adaptive user interfaces have their own problems: instability, unpredictability, violating the principle of least astonishment.

Generally it's not a good idea to change user interface properties like the slice width, direction or order out from under the user, because that interferes with the training effect of muscle memory. It's much more important that the user be able to learn the menus and mouse-ahead reliably, than having menus automatically adapt to the user's usage patterns.

Computers are notoriously stupid and often make the wrong decisions about adapting, introducing changes that hurt more than they help. Adaptability is really an AI problem.

Certain directions (the primary ones up/down/left/right, depending on the input device and handedness of the user) are easier to select than others (like the diagonals). So it's a good idea for the menu designer to use those for the most important items. But it depends heavily on the meanings and functions of them items and the usage patterns of the users. And the computer is incapable of making such high level decisions and aesthetic judgement calls.

Giving the user the ability to easily edit the menus themselves is a much more reasonable approach than automatically and unpredictably rearranging the menu behind the scenes without the consent of the user (the so called "adaptive" approach).

-Don

The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.

One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.

For NeWS, I implemented a "SoftMenu" editable subclass of pie menus (that also could mix into linear menus), that enabled the user to edit, cut and paste menu items. But it was quite dangerous because you could really confuse things by pasting emacs commands into the terminal emulator, etc.

The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.

I used HyperLook to port SimCity to Unix, which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode.

Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).

For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.

-Don

The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.

One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.

For NeWS, I implemented a "SoftMenu" editable subclass of pie menus (that also could mix into linear menus), that enabled the user to edit, cut and paste menu items. But it was quite dangerous because you could really confuse things by pasting emacs commands into the terminal emulator, etc.

The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.

I used HyperLook to port SimCity to Unix, which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode.

Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).

For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.

-Don

What objective facts are your personal beliefs based on, or are they purely subjective? Question: How do you know that your personal beliefs are not merely a perception of knowledge than true knowledge? Answer: subject your theories to experimentation.

Have you performed any emperical experiments to determine if pie menus have an advantage over linear menus?

I'm sorry your personal belief contradicts my own emperical experience. In all the experiments I have ever done, and all the ones other people have done that I have read about, pie menus have been proven to be faster than linear menus.

Here are a few references to experiments measuring the usability of pie menus.

So it's not at all subjective or based on personal belief. The effect of Fitts' Law is quite easily measured, which should eliminate the need for resorting to the exposition of subjective personal beliefs.

Here is one such experiment that you can try for yourself (which requires Internet Explorer). Fasteroids is a free game that lets you compare pie menus with linear menus. Take the pie menu challange! Fasteroids tracks your selection speed and error rate, so you can compare pie menus and linear menus for yourself.

-Don

What objective facts are your personal beliefs based on, or are they purely subjective? Question: How do you know that your personal beliefs are not merely a perception of knowledge than true knowledge? Answer: subject your theories to experimentation.

Have you performed any emperical experiments to determine if pie menus have an advantage over linear menus?

I'm sorry your personal belief contradicts my own emperical experience. In all the experiments I have ever done, and all the ones other people have done that I have read about, pie menus have been proven to be faster than linear menus.

Here are a few references to experiments measuring the usability of pie menus.

So it's not at all subjective or based on personal belief. The effect of Fitts' Law is quite easily measured, which should eliminate the need for resorting to the exposition of subjective personal beliefs.

Here is one such experiment that you can try for yourself (which requires Internet Explorer). Fasteroids is a free game that lets you compare pie menus with linear menus. Take the pie menu challange! Fasteroids tracks your selection speed and error rate, so you can compare pie menus and linear menus for yourself.

-Don

Once you know the direction of the pie menu item you want, you can quickly select it without even looking at the screen, by mousing ahead. It's like using a keyboard accelerator, but without moving your hand from the mouse to the keyboard and back. The accelerated action is exactly the same as the unaccelerated action, only faster.

But selecting from a linear menu is not rehearsal for using the keyboard accelerator, because typing on the keyboard is a completely different action than selecting from the menu with the mouse, so you have twice as many actions to learn. To use the keyboard accelerator, you have to learn a completely new command that has nothing to do with the menu, and interrupts the flow of mouse actions.

It takes at least a second to move your hand between the mouse and keyboard and readjust, so it's important to provide keyboard equivalents for commands you'll be using while typing. I'm not suggesting removing keyboard accelerators when adding pie menus. Pie menus have their own built-in accelerators (mousing ahead without looking), that is extremely easy to use if you're already pointing and clicking with the mouse (which is the case with a game like The Sims, that doesn't use the keyboard very much).

Of course there's no reason why you couldn't assign traditional keyboard accelerators to individual pie menu items. The ActiveX pie menus have full support for keyboard navigation, so you can select and navigate and use all their features from the keyboard as well as the mouse.

Four item and eight item pie menus map very nicely to the arrow keys and numeric keypad. The ActiveX pie menus can automatically limit the maximum number of items per pie menu to eight, and let you page up and down through arbitrarily long menus in groups of eight items at a time, with the mouse or keyboard.

The newer JavaScript Pie Menus for Internet Explorer don't support keyboard navigation yet. Here's a description of many of the features of the older ActiveX pie menus, which are fancier but don't integrate with the web page as nicely or support dynamic HTML rendering and XML configuration like the newer Javascript pie menus.

-Don