[Nautilus-list] Re: GNOME user environment brainstorming

[Havoc Pennington <hp redhat com>]

Tim Reilly <reilly zk3 dec com> writes:  
> >
> > - desktop is for:
> >    - user shortcuts to programs, etc.
> >    - showing removable devices
> >    - Trash, Home, Start Here icons
> 
> Hrm. I think the desktop is a terrible places to keep program icons,
> given the panel. Why? Because windows cover my desktop! It's hard to get
> to the desktop, which is the lowest level, when I've got a few windows
> open.

I've heard that Windows users tend to maximize an app, work, iconify,
pick a new app to maximize, work, etc. My experience is that this is
true. So they would see the desktop in between apps.

I agree there's a bit of a problem with the panel and desktop
overlapping as locations for shortcuts, especially since they behave
slightly differently. I don't know the best way to resolve that. 
 
> I think the panel is a great place for program shortcuts, as well. the
> panel is on top, flush to the edge, and is independant of the
> no-desktop/Nautilus/GMC choice.

FWIW we are basically going with "you run Nautilus unless you're an
advanced user." The only issue there is performance; but it will get
fixed over time.
 
> >- Remove bevels from desk guide, use a more "flat" appearance
> 
> I think that would be visually confusing.

This is for the inside of it, not the border. The problem is that the
bevels are kind of oddly doubled and are too obtrusive, concealing the
windows.
 
> Don't remove the KDE menus, IMO, because there's no other good way to
> get to those programs, if you use them.

There will be or should be, they should simply be in the main Programs
menu. Users don't care if it's a KDE app or not.
 
> >- with Panel submenu removed from main menu, the right-click menu on
> >  the panel should contain Properties... for customizing the panel,
> >  right now the right-click matches the foot menu, I don't think
> >  that's right - right-click is supposed to be a context menu.
> 
> I'm so sure this used to be the case, but I just tried it now and it
> worked as you described... I have no idea when this changed.

I was also really surprised, but I'm not sure if it changed or I just
had a strong expectation that right-click would be a context menu not
a main menu.

> >- make Run Program dialog have a browser CList that shows all known
> >  programs, with icons if any, and ability to sort by executable name, 
> >  human-readable name, by clicking headers. Probably not a tree, just
> >  an alphabetic list.
> 
> Hrm... I think I agree, but only if there isn't a speed penalty. If this
> would mean it takes 15 seconds to pop up the run dialog, then I'm
> against it.

Agreed, I had the same caveat about this.

Assuming the dialog is in the panel process, panel should already have
this stuff loaded so it should be fine. If not, we can make it
something you switch on once the dialog is up, maybe.

> >- Remove or configurably remove folder heading things from Programs
> >  menu, based on Calum's usability test
> >
> 
> ? I don't understand.

The menus have "headings" with the folder name. Calum's user testing
(I think it was his study) showed that people tried to select these
and were confused by them.
 
> >- Desk guide: allow dragging windows between desktops, show tooltips
> >  identifying the window you're hovering over.
> 
> I can currently drag windows using the middle mouse button, which I
> think works well. I agree with the tooltips idea, maybe even fill in the
> icon for the program, if possible.

The point about dragging is that you can't move a program to another
desktop via dragging.
 
> >- disable in-place menu accelerator changing by default
> 
> I think I'd prefer teaching the user some way to do this, rather than
> just hiding it.

I think it should be configured via some sort of dialog. The Sawfish
keybindings dialog should clearly have the same UI, too.
 
> >- Turn off text for toolbar icons by default?
> 
> Huh? No! The icons aren't always recognizable to the user, and they
> won't always want to use tooltips. Plus, the current icons are tiny and
> are small targets, the text helps to make then into large targets.

This was for Nautilus only; all the icons there are also in the menus,
was the thought. Right now Nautilus windows have a tendency to be
really big. But, granted this is visual appeal over usability most
likely.

> >These would all be converted to standalone dialogs, rather than
> >sitting in a control center. They'd be launched from the various
> >folders in Start Here.
> 
> I don't agree. While I agree they should be detachable, I think forcing
> them to detach ruins the "grouping" aspect of the gnomecc.

You mean the fact that you have categories in the tree to the left?

I don't think those are really needed if you halve the number of
capplets (as we should do), and most users find trees confusing.
 
> >- Panel capplet should let you do things such as add applets, etc.
> >  and do the non-global prefs (may require a little "pick the panel 
> >  to edit" widget, or a drag-and-drop approach)
> 
> I think I like this idea, but I need more explaination, possible
> pictures, about how you think this should be inplemented.

Not sure. One general idea would be a "pick the panel to edit"
feature, either via a small thumbnail of the screen that you click on,
or you actually click on the panel itself. Another idea is
drag-and-drop, e.g. you drag an applet to the panel you want it to be
on.
 
> >- all capplets: user testing and enhancement to make them really easy
> >
> >We need a list of what capplets make sense for User Preferences and
> >for System Settings.
> 
> System settings should be/might be/is what Ximian Setup Tools is for,
> correct?

That's right. We have our own Red Hat tools though, that integrate
with Red Hat Network and blah blah, so we would probably use those for
Red Hat Linux.
 
> >Miscellanea
> >===
> >
> >- destroy gnome-help-browser, use Mozilla/Nautilus/something always
> 
> The only problem is that Mozzie and Naut are very slow to start up, the
> last thing I want when I need help.

Maybe if Nautilus is already running it would work, or maybe someone
will write a g-h-b replacement eventually. Anyway g-h-b basically
doesn't work.
 
> >- make the Print Screen key take a screenshot
> 
> When "Print Screen" doesn't print the screen always befuddled me.  I
> don't screenshotting ever made sense. It's not like we can put a tooltip
> on the printscreen button, either.

It does a screenshot on Windows, everyone expects it to do that. No
one wants to actually print the screen anymore - it's an obsolete key,
may as well do something useful.
 
> If you don't mind me asking, what nationality is Havoc? I'm very sorry
> but I've wondered this for a long time, and being an X-Men/X-Force fan
> and not knowing where the name comes from, I always think of the comic
> character.
> 

It's just the English word Havoc. My parents are interesting people.

Havoc