Re: extra menus on panel

[Dion Detterer <diond healey com au>]

Dan Kaminsky wrote:
> 
> >Adding extra folders by default to demonstrate that it's possible is
> >akin to arguing that we do it because we can.  Leave the customisation
> >to the user.
> >
> >Am I making sense?
> 
> You're making sense.  In fact, I had agreed with this statement before.  But
> then I realized that if it's not obvious to a user how to do something, and
> if it's not brain-dead easy, it just won't get done.

absolutely.


> I'm no newbie user on windows.  *MY* desktop is a mess, and my start menu is
> a disaster.  Obvious nature and utter simplicity are really necessary, even
> for the expert level users.
> 
> One of the nice touches about having menus residing on the panel, even for
> someone like me who *hates* the idea of menus residing on the panel, is that
> it should be alot easier to configure the gnomeprint's submenu.  Simply add
> the folder to the panel, be it by drag and drop or some kind of
> aesthetically pleasing version of the checkbox paneler or something I
> haven't even thought of yet.
> 
> The panel thus recieves the additional role of folderholder :-).

This is why I suggest the panel include all the functionality of a
folder, and then some.  If that works out to be illogical (I can't think
of any reason off the top of my head) then at least have both folders
and the panel be subclasses of a generic container class, although I
don't think this is as appropriate.


> I don't think we should leave things out of the panel because we might be
> overfilling it, nor just "because we can".  Our basis for excluding things
> from the panel should only be--does it confuse and slow the user?

Ideally, after customisation, the user should have the panel holding
items that are used time and time again, grouped by task, with a single
folder containing everything else, to be used as a last resort. 
Including more than one folder by default unnecessarily complicates the
customisation process, since most users (I suspect) would not want
generic, non-task-specific folders cluttering up the panel-space.

MISC | TASK1 | TASK2 | ... | TASKn | ... (clock)

for example, makes the first decision easier as to "how do I start my
given task?" than does

MISC | APPS | GAMES | TASK1 | TASK2 | ... | TASKn | ... (clock)

Sure, it makes it easier to do general tasks, but at the expense of
slowing common tasks.  It's far easier for the user to build upon the
foundations of the default than it is to modify the default first.


> Conversely, our basis for including things from the panel should only
> be--does it explain to and speed up the user?
> 
> Having at least one folder available, and having the interface somehow state
> how that folder was *made* available, will speed up the user interface
> because it will reduce the user's desire to place applications on the
> desktop.  What should please you, Dion, is that by making it easy to see how
> the folder was added, it's also made easy to see how an app is subtracted.

The user needs to

1) Recognise the panel as a subclass of 'folder'

2) Make the mental link that "I can add folders to folders, therefore, I
should be able to add folders to the panel."

Step 2 is easy once step 1 is performed.  The only way I can see that
step 1 occurs (without requiring the user to modify the default) is
either by the user right-clicking the panel and noticing an "add folder"
method (along with all other properties and methods of folders, plus
some unique to the panel), OR by including a brief GNOME-newbie
introduction.

-Dion.