Tambin disponible en Espaol


The digital magazine of InfoVis.net

Why pie menus aren't ubiquitous?
by Don Hopkins [message n 125]

In the last issue InfoVis.net asked Don Hopkins why pie menus, that are more efficient than the traditional linear menus, haven't become ubiquitous, being used only in some applications like video games and some experimental advanced software. Here's his answer.

Don Hopkins graduated in Computer Science in the University of Maryland and worked as research programmer for Ben Shneiderman. Later he worked during three years in a small team with Will Wright developing the well known and awarded game The Sims, for which he is best known. Don was kind enough to answer our question.


Why pie menus, that are more efficient than the traditional linear menus, haven't become ubiquitous, being used only in some applications like video games and some experimental advanced software?

Don Hopkins: 

There are many different answers, and here are a few I've been trying to address. 

Technological Friction:

Most popular user interface toolkits are difficult (though not impossible) to extend with new components. Most application designers stick to the built-in widgets instead of creating their own, because it takes lots of work to design and implement a new widget, and most people are on a deadline, and have more important things to do than design non-standard widgets.  

With varying success, component technology tries to address some of the problems of extending toolkits with new widgets that weren't part of the original design. 

Years ago, I implemented pie menus as an ActiveX control, but they require you to install and run a binary program. I distributed the source code so people who didn't trust the binary could compile it themselves, but very few people know how to do that. 

So later on, I implemented pie menus as a Dynamic HTML Behavior Component, which plugs into Internet Explorer. It's written as an XML file with JavaScript code in it, that can be automatically downloaded from the web, and included on any web page. What the JavaScript can do is restricted so it's more trustworthy than a binary ActiveX control, anyone who wants to can see the source code, and nobody needs to compile it in order to use it. DHTML Behavior Components solve many problems of the original OLE/ActiveX controls. 

But DHTML Behavior Components are a non-standard extension to Internet Explorer on Windows, and aren't supported by the Mac version of Explorer, Mozilla, or other browsers. Mozilla has its own XUL extension mechanism, that has been used to implement an amazing variety of widgets like pie menus and gesture recognition systems.

Both component systems have their advantages and disadvantages, but neither is standard. I haven't used Mozilla’s XUL, so I can’t compare the two. I like Dynamic HTML Behavior Components, because I've used them for many things besides pie menus, and they've worked quite well. One important thing about Behavior Components is that they can be scripted in any language, not just JavaScript. And they’re nicely integrated with XML and Dynamic HTML. It would be great if there was a W3C standard for multilingual software components that both Internet Explorer and Mozilla supported on all platforms, but now that's a pipe dream. 

The Temptation of Low Hanging Fruit: 

Flash is a popular but proprietary standard, which would be a great platform for implementing pie menus. But most Flash users are not programmers, and most Flash presentations are not made out of reusable components. I’ve seen many “one-off” Flash presentations and web pages that looked and acted like pie menus, but used meticulously hand-made graphics and were not reusable. Tools like Flash and Director tempt people into implementing interfaces like pie menus again and again the quick-and-easy one-off way, instead of once and for all the hard way. 

However, a good Flash programmer could implement a nice reusable Flash pie menu component class, which allowed non-programmers to plug in graphics and animations and trigger built-in behaviors, and could be configured by xml. Maybe somebody's already done this, but if not, it would be fun and make lots of people happy. 

Resting on your Laurels and Not Invented Here Syndrome:

Years ago I used to be hopeful that Apple might add pie menus to their user interface design, making them built-in and easily available to application programmers. But after they sued Microsoft, all user interface innovation stopped at Apple, and it started going downhill from there. 

The lowest point was when the QuickTime 4.0 player earned its dubious place in the User Interface Hall of Shame: 

Unfortunately, I now believe that it's extremely unlikely Apple will ever incorporate pie menus into their interface. They didn't learn any lessons from the mistakes of QuickTime 4, but instead carried the mistakes into OS/X and amplified them. The overblown icon dock bar is the perfect example of what I mean, dancing around, while the window frames are still suffering with only one lower-right resize corner. It has been many years since Apple gave up on user interface design, and now they only concentrate on superficial graphics design.  

I eventually gave up trying to convince parochial institutions like Apple, Microsoft and Sun to incorporate pie menus into their standard user interface designs, because they no longer care to innovate, and their designs are completely grid-locked in reactive politics having nothing to do with the needs of users. 

Computer Games as an Instrument of Social Change:

Of all different types of software, computer games have the most potential to experiment with innovative, non-standard user interface designs. (Unfortunately with games in the rut of Quake, this potential is usually squandered.) Real-time games require the kind of quick, fluid interaction that pie menus make possible, so it's not surprising that they have shown up in many games, in various creative forms. 

That’s why I jumped at the chance to port SimCity to Unix, and redesigned the user interface with pie menus.  At the time (early 1990s), Unix workstations had huge screens and were extremely fast, compared to typical PCs.  So SimCity on a Unix workstation ran extremely fast, which amplified the importance of having a quick responsive interface that didn’t slow you down. The large screen made it tedious to move the cursor back and forth between the city editing tool palette, and the place on the map you were editing. 

Fortunately, the pop-up pie menus made it quite quick and easy to switch between editing tools (bulldozer, park land, residential zone, power plant, etc). So you could actually play SimCity with pie menus in full-screen turbo-mode, like a twitch game!  Then I developed a multi player version of SimCity that several people could play together over the network, and collaborate to build and manage the city in real time! 

Nowadays, ordinary PCs are even more powerful with bigger screens than the Unix workstations of the time, so pie menus are being used in more popular applications than before.  This led me to work at Maxis on The Sims, and where I developed the character animation system, and the pie menus in the game that control the people’s behavior. When you click on an object in the Sims dollhouse, a pie menu pops up with the current Sim’s head in the middle, looking around at the actions they can perform with the object, text labels spread around the head in a circle.  

The Sims is essentially a time management game, which you can run at slow, medium or fast-forward speed, or pause, so pie menus were essential for smooth game play. Pie menus worked well for The Sims, because they supported the quick, continuous style of play required by the game design. 

Pie menus are especially useful for real time massively multi player games like The Sims Online, that don’t have a “pause” button.  If you have to wrestle with an inefficient user interface, you miss things that are going on in real time, because the rest of the virtual world doesn’t freeze while you pop up a menu (a horrible user interface technique popularized by Apple: freezing during ui dialogs).  

An efficient user interface should reliably support mouse-ahead, as pie menus do. You shouldn’t always have to look at the menu on the screen each time you use a common menu, as linear menus require of you. Your attention is a precious non-renewable resource, and the menu system shouldn’t squander it and distract you from other more importing things.

Convincing the Skeptics: 

Simply describing the idea of pie menus or explaining Fitts’ Law does not work for everyone.  Some people get it instantly because it’s obvious to them, but to other people it’s not obvious, and they think it’s a crazy idea.  But unfortunately most nay-sayers won’t bother to do more than a simple thought experiment, or they reflexively reject anything new or unfamiliar.  

The best way to convince open-minded people is to enable them to try pie menus first hand. But close-minded people will never be convinced, and by all means they should use linear menus, which will slow them down and keep them busy making mistakes, so in the long run they will cause less harm with their close-minded ways.  Fortunately it’s not just a subjective question – it’s easy to empirically demonstrate that pie menus are faster and more reliable than linear menus.  For those open-minded people who may doubt and require proof, I’ve developed the “fasteroids” game so they can measure for themselves if pie menus are faster than linear menus.

Links of this issue:

http://www.infovis.net/printMag.php?num=124&lang=2   Number 124 about Pie Menus
http://www.donhopkins.com   Don Hopkins personal page
http://www.infovis.net/printRec.php?rec=persona&lang=2#Shneiderman   Ben Shneiderman
http://optimoz.mozdev.org/piemenus/   Pie Menus in Mozilla
http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/qtime.htm   User Interface Hall of Shame award for QuickTime
http://www.piemenu.com/fasteroids.html   The Fasteroids game
© Copyright InfoVis.net 2000-2018