PieMenus rely, once you have grown accustomed to them, on your MuscleMemory. You perform an action often enough that you can do it without thinking.

How about and example of this starting to go too far? The OperaBrowser can use GestureRecognition for closing a window:

	1. drag the right mouse button
	1. move right
	1. move left
	1. move right
	1. let go

It resembles shaking one's head. Sometimes I do this to the MozillaBrowser, and of course it doesn't work (''it will work once you install http://optimoz.mozdev.org/gestures/''). The point is that my brain has issued the command and my hand has carried it out, and this is fast and efficient.

Except when it doesn't work.

----

So, I imagine that changing the entries on PieMenus will cause huge confusion. Changing the sort order of the entries or inserting/removing entries would be the worst, since every item in the menu will have a new position.

Changing the meaning of one position will only affect that command or sub-menu.

----

'''Efficiency'''

I'm reminded of the RedBlackTree algorithm. It's a binary tree (PieMenus seem to have four to eight entries per node?), but the main point is the one attempts to keep all legs of the tree to similar sizes.

Actually, more important would be to keep related operations together, and most frequently used operations near the top of the tree. This departs from the RedBlackTree since most leaf nodes will be N levels down.

The problem is, your RedBlackTree can be shuffled if necessary, and it will still work just as efficiently. MuscleMemory requires a training period to reach maximum efficiency.

''I wonder how long it takes to TrainMuscleMemory, and what software can do to accelerate this without forcing the user to practise? -- DigressingOne''

DebianGnuLinux has some tools for generating menu structures, and I believe these have an assortment of heuristics which can be used for balancing up the tree sizes. http://packages.debian.org/menu -- MatthewAstley

----

'''Solutions'''

(ha)

Well, it sounds like PieMenus need to be ConfigurableUserInterfaces, with all the complications this entails and the usability problems that PerpetualBeginners have with reconfiguring their software.

* menus restricted to a closed set of operations (eg. physical directions, add/remove) seem to work well
** I offer the digression of non-quantized directions ... but I'm not sure where I'm going with this yet
* menus with operations which are SetInStone when the menu is created
* a "future expansion" sub-menu position (this is a kludge, and smells of NotDesignedRightFirstTime)

A simple alternative is making some items twice as wide as normal, and shrinking those items to accommodate more.