Re: [Usability] merging applets

[Matthew Paul Thomas <mpt myrealbox com>]

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/