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
- Just show all menu items in a pie, and try to somehow make all the
labels readable, at least on mouseover.
- Only show the first 8 items, ignoring the rest.
- Only show the first 7 items, and make the 8th a "More..." item,
spawning a submenu.
- 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.
- If there are more than 8 items, just show a linear menu instead.
These all have obvious problems associated with them, as follows:
- Messy, very small targets to hit, possibly nasty drawing code.
- Making certain menu items unreachable is not an acceptable strategy.
- 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.
- 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.
- 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:
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. *