Re: GNOME user environment brainstorming
- From: Havoc Pennington <hp redhat com>
- To: James "M." Cape <jcape ignore-your tv>
- Cc: nautilus-list eazel com, gnome-2-0-list gnome org, Calum Benson <calum benson ireland sun com>, Anna Dirks <anna ximian com>, Joakim Ziegler <joakim ximian com>
- Subject: Re: GNOME user environment brainstorming
- Date: 06 Jun 2001 17:17:55 -0400
James "M." Cape <jcape ignore-your tv> writes:
> Global User Levels are something I dislike, though there is no hard
> evidence that I've seen either for or against this particular method of
> handling things, here are some problems I see with the concept:
My general thoughts here would be:
a) Nautilus and desktop should be consistent; if they're in
Nautilus, they should be in the rest of the desktop
b) we have a rather unique problem in free software, which is that I
can't just go in and e.g. remove most of the Panel or Sawfish
preferences options, though I think they should mostly die.
So we need a way to turn off most of the weird prefs by default.
> 3.) It hides preferences and features from users in a way not easy to
> override.
> If there is a pref or feature that is not in the user's currently
> selected userlevel, they will almost certainly conclude that the feature
> isn't there. If they do know about user levels, but like their interface
> as-is, they would need to go to the selector and select "Advanced", then
> enable the feature they want, then go back to "Basic", and repeat this
> procedure. And just imagine how many questions and feature requests will
> flood in because of users who are not familiar with the user level
> system ("How do I do X, I used to be able to...").
>
> 4.) The user must think of everything in terms of user levels.
> "Ok, X isn't available here, I need to go to a completely different
> section of the UI, switch to a different user level, and then come
> back." If the user does not think in this fashion, then they are stuck
> with the example in #3. Plus, it's pretty obvious that related
> preferences should be grouped together, but user levels breaks that.
I think user levels as used by Nautilus affect *only* the prefs
dialog, not the UI features. That addresses at least part of your
objections, right?
The value I see in user levels is:
- let advanced users turn on what I affectionately term the
crack-smoking options
- without destroying the prefs dialog for normal people
Personally I like nice simple defaults as on the Mac, I don't get a
kick out of using bizarre features and feeling 37337, despite being an
"advanced user." ;-) But the nature of the world is that we can't just
remove those options without causing people to get all
irritated. Witness the initial reaction from many quarters when
Nautilus came out.
My view of the user levels is maybe something like:
- Beginner: no way to screw anything up or confusingly modify
defaults; available prefs are things like colors
- Intermediate: things that are reasonable to change but
are maybe confusing
- Advanced: most of the prefs we have now ;-)
> I believe that a better method to handle advanced preferences is the one
> taken by MacOS, the disclosure triangle. The little right-pointing arrow
> that expands a dialog, prefs pane, or whatever to show more complicated
> options. The advantages of this approach are:
>
Fair enough. I'd love to hear rationale for the Nautilus approach
vs. this one from the Nautilus developers.
I do think it's bad to have user levels for Nautilus that only affect
Nautilus though, so if we go with the disclosure triangle I'd like to
remove the user level stuff from Nautilus.
One possible issue with the disclosure triangle is that I think we're
talking maybe 10 reasonable preferences for Sawfish, vs. 300 or so
prefs that it has now that someone will whine about if you remove.
Perhaps there are other ways to deal with that.
> > Windows has My Computer in addition to the start menu which contains
> > things like Control Panel, Dial-up Networking, etc.
>
> The only thing I've ever seen anybody use My Computer for is opening
> files, and that simply because they were told to do so by someone who
> didn't feel like explaining Windows Explorer. I've gone to the control
> center from the "Settings" submenu on the Start Menu.
>
> Basically, I don't think a "Start Here" special folder would solve much,
> since we'd still have to fix the menu structure anyways, the user cannot
> find everything they will need through this folder, and the menus will
> still almost always be faster. But really, this does need to be
> user-tested. The Best of "Start Here" vs. The Best of The Menus.
Of course you can have both Start Here and the menus, though perhaps
it isn't useful.
> > - Joe Smith's Preferences
> > (user preferences, such as fonts/colors; this would replace
> > control center with a folder full of icons a la Windows/Mac, and
> > we'd want to rename dialogs from things like "Theme Selector" to
> > things like "Fonts & Colors")
>
> I'd like to suggest it simply be called "Preferences", for reasons in
> the "My Identity" section below (plus it'd help tech support in the
> future to be able to say "go to Preferences" rather than "go to 'Your
> Name`s' Preferences")
I've been leaning in this direction after getting annoyed at
netflix.com addressing me by name. ;-)
> > - System Settings
> > (using Darin's prefs vs. settings distinction; systemwide
> > settings that can be gotten wrong, vs. user prefs that
> > can't. e.g. dialup networking setup, time and date, etc.
> > Probably would contain Red Hat specific tools in our
> > distribution, but Ximian Setup Tools could also go here)
>
> Well, I'm not sure I like this distinction (I'd prefer a single
> "Settings" or "Preferences" UI item to splitting them into pieces, items
> which require root perms to unlock/change can be done so in a manner
> similar to MacOS X.)
The point isn't root perms, it's whether it affects only you or all
users. One reason for the split is to disable system settings
on e.g. a workstation in a computer lab, though this could also
be done via a filter on the single folder.
The sorting here will be done by keywords in .desktop files, so it's
easy to compress the two folders later or experiment with different
ways of organizing them.
> > - Programs
> > (start browsing programs here - would have a folder hierarchy as
> > with Programs panel menu)
>
> If a busted programs menu is one of the reasons that we need a "Start
> Here" folder, how does this solve it...? :-)
Well there are two menus:
- panel menu (foot menu)
- programs menu
The programs menu lists all programs. My argument would be that there
is no way to organize 200 programs that's any good, basically. Though
we could do a lot better.
So an organization like Start Here that breaks out some of the
"special" things that we really want users to find is useful. This
reorganization could also go on the foot menu. But then you still need
a Programs submenu/subfolder with the exhaustive catalog.
Start Here and the foot menu could be more or less redundant,
you could put the stuff from Start Here on the foot menu toplevel.
Though we were thinking of making the foot menu primarily a Favorites
menu, with nice defaults that would be similar to what's in Start
Here, and an easy way to change them.
User testing would definitely be good, we need a first iteration to
test though...
> > - Network Server Configuration
> > (Red Hat specific probably; Apache, Bind, etc. config tools.
> > jrb argues that it should not be split from System Settings,
> > the argument for the split is that System Settings is oriented
> > toward all users, this folder contains tools for admins
> > doing server config)
>
> I'd call it "Services", personally, since Apache, Bind, etc. are all
> services (and "System Settings" covers things like host name, etc.).
That sounds like a good idea.
>
> > - Favorites
> > (Shared with Panel, a folder full of things that would appear in
> > panel Favorites menu - unclear how it interacts with Favorites
> > emblem)
>
> I'd like to add "Recent Documents" to the list of special folders. It
> should be a subdir of the Desktop which contains links to recently
> opened documents. (gnome-vfs may be able to help us with this in the
> future, perhaps through a gnome-vfsd -- which will also let us do all
> sorts of cool things, such as monitor which apps have which files open,
> and present the user with a single, integrated "these documents unsaved"
> dialog when they logout, an advanced feature not present in any current
> GUI AFAIK.)
Agree, the hard part of both of these things of course is that they
require application support...
> I have personally seen users who asked to borrow my computer to check
> something on the Internet double-click on a panel button, then do it
> again, and again, and again (since Xalf doesn't have the ability to
> change the cursor when it is over another window). They are then
> surprised by 8 windows showing up one after another. :-) I say make all
> launchers respect a single pref for double/single click.
Lots of implementation work to make panel launchers behave like icons
(with group selection, cut/copy/paste, etc.) but it might be kind of
nice.
Thanks for the comments, made me rethink some things. Wish we had more
time to write mockup code for the various options and try them
out. :-( Will probably do some user testing (we ran our first Red Hat
user test on Monday, not on GNOME but it will be in the future).
It won't be as much as we'd like though.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]