this is actually the plan. Seth is currently working out the layout, 
to my knowledge he wants to integrated user preferences and system 
settings into a top level menu i believe (i think, he plans to call 
it settings) ccing usability (and hence seth...)

Setting 2.2 milestone

Eew, I hope he's not going to call it Settings, we argued that one to
death when we were deciding whether to call Preferences 'options',
'settings' or 'preferences'  :)

hmm while i like the term preferences better as well....but he's going
to include both the desktop preferences, and other system settings
capplets (distro stuff etc) in this top level menu, if i remember
correctly. but I'll leave the terminology issue to you guys :)

Here are seth's two proposals as posted on desktop-devel in august. 
-------------------------------------------------------------------
mandatory disclaimer:
I should note that he hasn't further commented on this, and he may or
may not still agree with this proposal.
--------------------------------------------------------------------

for reference see this thread:
http://mail.gnome.org/archives/desktop-devel-list/2002-August/msg00515.html

Seth Said:
------------------

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

Take a look at this screenshot:

http://linuxserver.serveftp.net/linux/preferences.png

just a quick usability note:

1. s/desktop preferences/preferences

two word menu titles are bad

2. I think a more thorough solution as seth had suggested is needed,
ie i think this needs to be a 2.4 type of change that is more well
thought out.

I agree that it needs to be really well thought out for 2.4 

but i think that we really need to make some improvement for 2.2

Actually, scratch that - i think that we should start working on a
really great structure as seth details for gnome 2.4

*** Bug 101215 has been marked as a duplicate of this bug. ***

What about extending "Actions" menu as described in bug #98222 ?
I think it would be nice and comfortable to use if gnome developers
would add two more actions - "change Desktop preferences" and
"configure the system" (action names could be under discussion) to the
actions menu of gnome-panel. When user chooses "configure the system"
action then GNOME Control Center (nautilus with system-settings:///
location ) should be displayed also when user chooses "change Desktop
preferences" - nautilus with preferences:/// location should be displayed.

Or, if we rename "Actions" to "Desktop" (bug 89874)
we could have Desktop -> Preferences

But I don't know how well that would work with
Seth's Ideas. I really like Design B.
I organised by own menu like that and it really
makes so much more sense that sepporating out
tools into root and user tools.

I think it's bad idea rename "Actions" to "Desktop".
It's clear to understand Actions->Open Recent, or Actions->Configure
the System, because "Actions" is task-oriented menu and it should be
for often used tasks, like Open Recent document, Searching and
managing files, browsing Internet and so on.

Logical consistency is much less important than probability of
recognition when they want an item inside a particular menu. People do
not recognize "Actions" as being a viable option for containing things
like "logout".

Ok, back on topic: Seth, have you got any plans on implementing the
Settings menu for 2.4 or will it have to wait for 2.6? I had a go
at it myself and organised the control-center and gnome-system tools
into Desktop, Hardware, Network, Servers and System and it really
does make a hell of a lot more sense that way.

Can provide a patch against HEAD if anyone is interested...

I'd rather wait for 2.6, because I'd like to do some more testing and
some more thinking about the menu structure before we change it.

For example, Desktop->Settings->Desktop seems crazy to me. Plus, now
these aren't desktop settings, because they also contain system
settings and stuff... So I'm not sure "Desktop" is the best place to
root them.

A big problem here is that RH doesn't want to use a menu panel. So....
without that we get too many  levels of submenu :-(

But redhat has that patch that make applications not be a sub menu,
which i think we should have for the foot menu btw..

Currently in gnome all configuration stuff is mixed between
"Applications"->"Desktop Preferences" and "Applications->System Tools" (for
example, a launcher for the Login manager (gdm) setup or various system
configuration utilities from gnome-system-tools are here). I think this is bad,
because it's hard to find how to configure various desktop or system settings.

I suggest to move submenu "Desktop Preferences" from "Applications" to "Actions"
menu and rename it to "Configure the Desktop". Also launchers of system
configuration tools (like gdmsetup, network-admin, time-admin or users-admin)
should be moved from "Applications->System Tools" submenu to  newly created
"Actions" -> "Configure the System" submenu.

Configuring various system or desktop preferences (settings) is an action, not
an application, so why to keep this in Applications submenu still ?

Mantas' idea seems very logical to me. Thinking logicaly if I would want to
configure my desktop I would expect to click on some specific "action" e.g.
"Configure sound events..." or "Configure desktop theme...". And this kind of
menu items belong to "Actions" menu.

And the current situation with system tools is a mess. I have no idea what do
gnome-system-tools have in common with "Terminal", "System monitor" or File
Roller and why they are in the same menu, that's why they should be wiped out
from "Applications -> System Tools" menu. GST does the same work as "Desktop
preferences" menu items do, just it's action scope is system wide instead of
being 'per user' configuration tools. The mess should be cleaned up as far as
possible. Now users might be confused where to go and what to click on.

bug 161613 has new discussion on this very old topic.  Perhaps this should be
marked as a duplicate of that and a summary be moved over to there.

The new menu layout in HEAD fixes this problem (see bug #161613).