On Aug 11, 2006, at 5:34 AM, Alan Horkan wrote:
> ...
> Since there is a redesign planned I will take this opportunity to say I
> actually like the menu based approach and I hope it can be preserved
> as an option. Microsoft Windows has an option which allows the
> Control Panel items to appear as a submenu rather than a single menu
> leading to a
> control panel.
(So did the Mac's System 7 and later, though you could either go into
the submenu, or just select the submenu title to open the "Control
Panels" folder window.)
> Once you do know what you are looking for having the control panel
> items directly in the menus does speed up the process a little.
> ...
The Windows control panel is slower than a menu only because the
Control Panels window, and the individual control panels, are separate
windows, so they load separately and you have to close both of them
once you're done. An alternative approach would be to embed the control
panels into the same window as is used to choose the one you want, as
is done in Mac OS X. For a long time I've thought the OS X approach was
rather silly, but I've just sat down to do the Goms algebra on it.
With a menu, where
m = time to enter the menu (e.g. "System"),
s = time to enter the submenu (e.g. "Preferences"),
p = time to find an applet in the submenu,
r = time for the computer to open the applet you chose, and
g = the number of times you guess the wrong category,
time to access the category you want = (m + s + p + r)(g + 1).
With a single control panel that has an index of categories, where
r = time to open the control panel,
p = time to find a category in the control panel, and
i = time to return to the list of categories,
time to access the category you want = m + r + g(i + p + r).
Assuming that p is roughly equal for each approach, and r is roughly
equal for each approach, the difference is:
time(access via menu) - time(access via single control panel)
= ((m + s + p + r)(g + 1)) - (m + r + p + g(i + p + r))
= (m + s + p + r + gm + gs + gp + gr) - (m + r + p + gi + gp + gr)
= (s + gm + gs) - (gi)
So even if you knew exactly which category contained the option you're
looking for (g = 0), the menu would be slightly slower than a single
control panel:
= (s + 0m + 0s) - (0i)
= s
And whenever you take two or more guesses to find the correct category,
a single control panel would be very much faster (given that i would be
as simple as clicking an omnipresent "Show Categories" button or
similar). I suspect that g is quite large at the moment, first because
of poor naming and grouping ("Sessions" being perhaps the worst
example), and second because of the seemingly arbitrary distinction
between "Preferences" and "Administration".
(This formula is a bit simplistic, because r might differ substantially
between the two approaches. Or the control panel might be a lightweight
shell with panels that load individually inside it, with that loading
taking substantial time, but probably still not as much as a full-blown
applet. On the other hand, the formula also doesn't take into account
the time taken with the menu to move from the "Preferences" submenu to
the "Administration" submenu, and vice versa, when you're not sure
which one contains the category you want.)
Efficiency is only one aspect of usability, and there might be other
reasons to keep using separate applets (ability to show multiple
categories simultaneously? substantially different ideal window widths?
ease of extension?), but none that I can think of stand out as being
particularly important.
--
Matthew Paul Thomas
http://mpt.net.nz/
_______________________________________________
Usability mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/usability
