Re: "Desktop preferences" as a top-level item

[Seth Nickell <snickell stanford edu>]

Here are what I believe to be the design considerations of note:

1) Try to keep the number of items in each menu below 8 for scannability
(even 8 is a little higher than ideal)
2) Avoid ambiguous categories which will require users to think
carefully before choosing one
3) Minimize sub-menu depth
4) Use the term "preferences" in order to match the familiar name
"preferences" suggested for Applications
5) Provide clear seperation between items that require administrator
access and those that normal users can play with to their heart's
content
6) Root all settings in the same general area to maximize familiarity
(and avoid confusion) for users familiar with environments such as
Windows and MacOS which owing to their primarily single-user focused
design do not distinguish much between settings requiring admin access
and those which do not
7) Provide convenient and obvious access common/important/used-by-novice
items
8) Make it possible to add new items without necessitating major changes
or invalidating other requirements (BUT, note that we shouldn't add a
lot of new items anyway, still there will be some; we don't want
KControl!)

Note that not all these items have equal importance.

Here is how the current design fairs:

(1) is not kept very well. (2) is generally done with the possible
exception of "Advanced" which tends to contain cracky or unusable
applets. (3) is done "ok", but not great. (4) is kept. (5) is kept. (6)
isn't followed at all. (7) is sort of met since the most important menus
are in the top-level...however since (1) is not kept well they are sort
of lost in a flood of less important items. (8) is not met well without
creating a bunch of new categories.

In post-mortem analysis I think we gave too much precedence to using the
term "preferences" (4), at the cost of rooting settings in the same tree
(6) (since we didn't want to create an extra level of submenus, i.e.
constraint by (3), but we did want non-admin-access-needing settings
seperate (5)). I think using "preferences" is far less important than
the actual structural need suggested by rooting settings in the same
tree, and I think that was the root of the design problems.

Design A:

A new top-level menu be created for settings (named the most familiar
word we can find, I suspect that's "settings"). Setting's structure is
as follows:

Settings
   |-> Desktop -> (or "Personal")
   |-> Servers ->
   |-> Computer -> (or "System")
   |---------------
   |-> Background
   |-> Font
   |-> Sound
   \-> Theme

Desktop-> contains the remaining items currently stored in "Desktop
Preferences".

Servers-> allows configuration of Web servers, FTP servers, etc.

Computer-> contains non-server items that affect all users of the system
(and consequently require administrator access to change).

How design A fairs:

(1), keeping items per menu low, is kept very well. (2) is kept
tolerably well (at least, no worse than before, though I agree that
Servers and Computer can be a little unclear at first, I think they
become clear enough based on the items in them). Because "Settings" is
on the menu bar we maintain a reasonable sub-menu depth (3). (4) is not
met in this design. (5) is well met, though not so well as in the
previous design (under which *all* items in the preferences menu could
be changed w/o admin access). (6) is well met. (7) is well met as the
most common and relevant to novice user item's have been placed in the
top level menu, and with a low total item count. (8) is better met by
keeping the number of items in each category fairly low, and providing
more structure.

This design uses a "trick" to split the otherwise large desktop
preferences category in a manner that does not cause usability problems
owing to ambiguous categories. Problems arise when you have two
ambiguous categories at the same level where the user could imagine
their item of interest being in either category. This requires the user
to think more than is ideal about which category the item might be in,
and sometimes they will "miss". This is annoying. However because most
users end up scanning all items in a particular menu *anyway* before
descending into a category (unless they are on autopilot, in which case
these things aren't much of a concern anyway because they can "feel"
where the item is), splitting a category potentially "ambiguously"
between a menu and a sub-menu of that menu is *much* less of a usability
problem than splitting between two sibling sub-menus.

Design B:

Design A still relies on menu categories for differentiation between
admin-access items and non-admin-access items. This may be killing a
mosquitoe with a sledgehammer since we find a number of places where our
desired categories conflicts with this. An obvious example is that it
would be nice to have a "Hardware" sub-menu....but....a couple items
(mouse, keyboard, and eventually display with XRR) can be changed on a
per-user basis. If we find a different technique for designating "admin
only" pages we will be more free in choosing categories. 

I suggest using a standard "locked" icon (probably the same icon as RH
uses for their PAM launch-apps-as-root tool?) overlaying
admin-access-only items like an emblem. This suggestion predicated on
the base size for panel menu icons being increased. In the case where it
applies to a whole category (say, "Servers", only the category would
need the emblem, not every item in the category (reduce noise).
Alternatively we could use a very distinct stylistic scheme (use more
geometric shapes, B&W, that sort of thing) for admin requiring stuff.

Settings
   |-> Desktop->
   |-> Hardware->
   |-> Network-> (or "Internet")
   |-> Servers->
   |------------
   |-> Background
   |-> Font
   |-> Sound
   \-> Theme


There are things I don't like about Design B, but I think its promising.
I'll be trying to extend it later, but this message is already 3x too
long.

-Seth

On Thu, 2002-08-29 at 13:57, Havoc Pennington wrote:
> 
> Seth Nickell <snickell stanford edu> writes: 
> > "Desktop Preferences" is too long to be a toplevel item, we could put it
> > in as "Preferences". I don't have a major objection to this, and agree
> > that its conceptually cleaner than having Preferences under
> > "Applications". Nils and I originally had something like this but shied
> > away for various reasons (mostly that we felt it was promoting
> > preferences to greater prominence than was useful). In retrospect I
> > think its better to put it in a top level.
> 
> I'd appreciate when rethinking this item some consideration of where
> systemwide config tools go, and where server config tools go (our
> "System Settings" and "Server Settings" in Red Hat). Everyone is
> bitching about the current layout which is:
> 
>  Preferences 
>  System Settings
>  Server Settings
> 
> mostly they seem to want those three as submenus of a single toplevel
> of some kind.
> 
> Putting Preferences in the toplevel menubar seems to make things
> worse. (Not that Red Hat Linux is using the menu panel anyway right
> now, but, if we were.)
> 
> Havoc
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list