Matt Gemmell

My new book CHANGER is out now!

An action-thriller novel — book 1 in the KESTREL series.

★★★★★ — Amazon

Dealing with long menus in pie form

source 3 min read

One of the classic issues with pie menus is that they don't scale well 
for menus with large numbers of items (and by "large numbers", we're really 
just talking about menus with more than about 8 or so items, which 
are very common indeed). So, how do we solve the problem of pie-ifying 
long menus? This post discusses a few possible approaches.
First, let's assume that 8 is the ideal maximum number of displayed items 
in a pie menu. We make this assumption because research supports this 
conclusion (feel free to check out the studies for yourself, starting 
at <a href="http://www.piemenus.com/">piemenus.com</a>; I'll wait here 
til you're done).



So, the issue is how to deal with menus which have more than 8 items. 
Several approaches spring to mind after even briefly thinking about the 
problem:
  1. Just show all menu items in a pie, and try to somehow make all the labels readable, at least on mouseover.
  2. Only show the first 8 items, ignoring the rest.
  3. Only show the first 7 items, and make the 8th a "More..." item, spawning a submenu.
  4. As above, but make the "More..." item spawn a concentric ring of a further 7 items, and so on; or, just spawn concentric rings automatically, if necessary.
  5. If there are more than 8 items, just show a linear menu instead.
These all have obvious problems associated with them, as follows:
  1. Messy, very small targets to hit, possibly nasty drawing code.
  2. Making certain menu items unreachable is not an acceptable strategy.
  3. This would certainly work, though it introduces additional artificial levels into the existing menu hierarchy, possibly psychologically demoting the later menu options. It does, however, directly support the principle of making more 'dangerous' menu options (which tend to be further down in linear menus) harder to reach by accident.
  4. Concentric rings not only make slices harder to hit by making distance significant as well as angle (destroying one of the main benefits of pie menus), but also aren't scalable at all. Only so many additional rings will fit on the screen, then we have the same problem all over again. Concentric options are only really suitable for controlled scenarios where the maximum number of items is known in advance.
  5. Fair enough, and guaranteed to work, but rather misses the point. Also, it feels like just admitting defeat and giving up.
Of all of those, I'd say that only the "More..." submenu concept and the 
fallback use of linear menus have any merit in the general case, and I'm 
not intellectually satisfied with just using linear menus. All the same, 
I feel there's still another approach which may have some validity. In 
the absence of an existing standard term (I've not seen this anywhere; 
it just seemed a natural enough approach when it occurred to me), I call 
it <em>slice spooling</em>.



Slice spooling is the radial equivalent of linear menu spooling. We've 
all seen this before:
screenshot
The little arrow at the bottom is the significant part. When a linear 
menu becomes too tall to fit onto the screen, it grows a little arrow 
at the top and/or bottom; hovering over such an arrow causes the menu 
to scroll additional items into view, scrolling items out of sight at 
the opposite end. We've all used this a thousand times, and it bears 
little further explanation. It also, admittedly at the expense of being 
particularly easy to navigate with accuracy, neatly solves the problem 
of long menus. I think that a radial equivalent of the "spooling arrows" 
on linear menus may be a valid approach to solving the same problem 
with pie menus.



I envision a long menu having its first 7 items displayed, with the 
8th slice being special; a "spooling slice". It would be divided into 
two equal segments (down its radial centre, naturally), each with 
such an arrow, and hovering the mouse over either one would spool out 
additional slices in the relevant direction.



Visually, it would need to be quite distinct, perhaps outset slightly 
to draw attention to its special nature, looking a bit like it was 
sitting "over" the pie, i.e. nearer to the user than the pie itself. 
The image of a read/write head over a disk platter springs to mind, 
though of course the spooler's visual representation would be nothing 
so complex. Maybe just a darkened slice, split down its radial centre, 
with appropriate arrows in each half.



Now, granted this does destroy the ability to memorise the angle of 
a given menu command in its pie, since all items in such a menu can 
potentially move around the circle, but it does offer an equivalent 
gain: the ability to be triggered directly via a scroll-wheel, or 
a trackpad with a 
<a href="http://www.ragingmenace.com/software/sidetrack/">specialised scrolling area</a>, 
or other similar devices. The scroll-wheel, as well as spinning 
through the visible options, would actually spin the pie through the 
spool, which could potentially make a spooled pie reasonably fast 
to navigate. The use of acceleration based on position and/or 
duration of hover could also speed navigation for those without a 
dedicated scrolling mechanism.



I'll try to create a UI mockup of a spooling slice sometime soon, 
but hopefully you get the idea; it's a common sort of device in 
the real world, including on the front of my washing machine, in 
fact. I'm opening the concept up to discussion, and indeed the 
general issue of coping with long menus in a radial context. *

* Pun intended, Firefox users.