Re: Proposed: gnome-system-tools

[Havoc Pennington <hp redhat com>]

On Tue, 2004-07-20 at 01:30, Jeff Waugh wrote:
> <quote who="Havoc Pennington">
> 
> > Reiterate 
> > http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00161.html
> 
> Is that "should not go in until these issues are resolved", or a reminder
> that we really desperately need to resolve these issues? :-)
> 

Two points:

1. Anything end-user oriented should be sucked into control center and
designed top-down as part of control center, not kept separate.

If there are tools targeted toward *admins* we should consider those as
a separate module and the interaction design should be done with admin
as audience.

So "date and time" should probably be in the control center. "Boot
loader" is an admin thing, or just "geek power tools"; same for
"runlevel."

"Network" is more ambiguous, though the way we're approaching it at Red
Hat (see Dan's NetManager thing in CVS among other pieces) is to "just
work" with no config in the dhcp case, you would still need a control
panel for static IP and so forth. The control panel should be clearly
specified as admin-targeted or end-user-targeted and maintained with a
hard line on that.

For network profiles, probably you want to associate a profile with some
kind of "signature" (heuristic way to identify a network) and switch the
profiles automatically when those networks are joined (and then when no
network is joined switch to Offline mode).


2. The second point is the specific proposed top-down design, which does
not include all the stuff that's in g-s-t, but does include some of it.

Basically the proposed list of preferences is a roadmap for what prefs
we want to have (for users, it ignores admins), so the way to eval g-s-t
is to include the parts that get us further along the roadmap
(optionally arguing with the roadmap first, but the roadmap argument
should be done holistically/top-down by presenting an entire alternate
roadmap, not piecemeal). We could also add a separate roadmap for admin
functionality.

There has to be an overall design for *all* the user's preferences,
which of them are in control panels, which are elsewhere, and so forth.
The argument on what to have should be done looking at the whole list
and whole plan, and then the implementation should iteratively move
toward the result.

Havoc