Re: [evolution-patches] 57653 & 57654 : toolbar and sidebar visibility

[Not Zed <notzed ximian com>]

On Tue, 2004-05-04 at 17:42 -0400, William Jon McCann wrote:
> Hi Rodney,
>
> Rodney Dawes wrote:
> > The "sidebar" here isn't a typical "sidebar" as in other applications,
> > such as web browsers or file managers.   It is a core piece of the
> > interface, and the sole method of accessing your data.   Without the
> > sidebar displayed, the user loses the ability to change components in
> > the application window, switch folders, enable/disable calendars, or
> > see important information about the current folder, such as the number
> > of mails that are in it.
>
> So you have raised a few issues.  I'll try to respond to them.
>
> First, the default is that the sidebar should be visible.  The user 
> would have to make a decision to hide the sidebar.  It is a decision 
> that is easily reversed.
>
> *While* the sidebar is hidden:
>
> 1. "the user loses the ability to change components in the application 
> window"
>
> I believe strongly that the inability to switch components except by the 
> component buttons is a bug.  We should have individual menu items in the 
> GNOME menus and possibly a way to switch components from the evolution 
> shell menus.
>
> It is really odd to tell users that they need to start up the mail 
> program to access the calendar.
Still, with this patch they can't.  So that functionality must exist in the minimum before we go allowing the user to hide it.

> 2. "the user loses the ability switch folders"
>
> This only applies to the mail component.  It is possible that the user 
> of the mail component will never hide the sidebar.  Then again they may 
> wish to use the full screen width to view their messages in the preview 
> pane.
>
> Thunderbird and Mozilla (suite) Mail have the same issues and both allow 
> you to hide the sidebar.
They probably have a 'go to folder' thing as well though.  In 1.5 as above, we have no such functionality.  And its a bit harder to do than it was, since the shell doesn't track all folders and their views anymore.

Since I presume this patch is done via the shell, and is global, the 'not hiding it in the mail component' argument is pretty weak.  Well, if you could even change components without it anyway.
> 3. "the user loses the ability enable/disable calendars"
>
> True.  But only while the sidebar is hidden.  The advantage is that the 
> user can maximize the size of the calendar content.
>
> I think most people will not diddle around with sources that much.
Well again, the functionality needs to be there first in an alternate manner.  FWIW I find the current calendar selection thing really difficult to use.  IMO having virtual folders or 'views' would make it nicer - its quite painful to setup a specific view of several folders and then change that to another set.
> 4. "the user loses the ability to see important information about the 
> current folder"
>
> This is a touchy one, right?  I'll just say that most applications solve 
> this problem in different ways.  This problem is mostly an artifact of 
> the nature of application suites.
>
> This mostly applies to the mail component.  That is really the only 
> place where you *need* such info displayed.
>
> Seems to me that the info that is shown for the calendar would be better 
> displayed in the window title.  Especially, since as it is it takes up 
> around one third of my screen width.
I actually don't see this as much of an issue.  Really.  Once you're in a folder and using 'go to next unread', you really don't give a rats toss about how many are there until you've read them all.  And there's always folder properties.
> > If we are going to allow hiding the sidebar in this manner, then we need
> > some way to access these pieces of information while it is not visible.
> > The user needs to know where new mail is, or what calendars are in view.
>
> Agreed.  The difference is that they don't *need* to see these things 
> all the time.
Exactly.  The folder tree thing isn't actually a very good way to do it anyway.  If you only use 2-3 folders, then its a waste of space, and if you have more than about 10 folders it's really awkward to use (if you have a bigger screen/smaller fonts, it goes up, but it still doesn't scale).
> > The user needs to be able to switch components in the main UI. 
>
> If this is true, then it is still possible in the default mode when the 
> sidebar is visible and could also be made available in the shell menus.
It should be easy to put into the menu's.  It needs to be done anyway so they can be keyboard accelerated.
> > I am very
> > skeptical of how allowing the user to disable the sidebar improves on
> > the usability of evolution for a large group of people at all.
>
> Being skeptical is probably the right attitude!  I such discussion can 
> only improve the result.
>
> It is a dramatic usability improvement for users with small displays.
>
> Allowing the user to reducing the amount of information on screen at any 
> one time improves usability (aka focus).
Think of it as "spatial evolution"? :)  I think exactly the same arguments could be made against the Nautilus changes ...
> > It is
> > understood that you like the idea, and are a very advanced user of the
> > application, but I don't think it makes sense for most of the people out
> > there.
>
> I don't believe that how I use evolution is so different from most people.
Everyone seems to use it their own way.  And i'm quite proud evolution gives you the freedom to do that, without bogging you down in options.

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.