Re: [Evolution] Evolution 2.0 UI proposal

[Brett Johnson <brett fc hp com>]

Anna, thanks for taking the time to reply.

On Tue, 2003-07-15 at 15:52, Anna Marie Dirks wrote:
> UI redundancy is absolutely not the same thing as a complete waste of
> space. :) That information in the toolbar reinforces for the user which
> folder has been selected.

Sorry, I shouldn't have said "complete waste", as I'm sure there's
somebody out there that likes it (wink wink, nudge nudge ;o).  Maybe I'm
just weird, but I do find it annoyingly redundant to have the folder
selected and highlighted in the left pane, and then for evo to use such
a large amount of screen real-estate to simply repeat the same
information, and then to not allow for any way to turn it off.  But I
suppose this is another discussion entirely ;o)

                            V(into the toolbar)
> Integrating the search bar would force the app to be prohibitively wide.
> (For example, if I want to make the Evolution window the minimum width
> such that all toolbar buttons in the Mail component are showing, then
> the window needs to be about ~750 pixels wide, assuming that I use a
> 10pt font) If we want the app to be semi-usable on smaller screens, then
> we do not have the space to add the searchbar to the toolbar.

Well, if evolution would simply honor the gconf/gnome "toolbar_style"
preference setting, the user could turn off the (again, annoyingly
redundant IMO) text next to the toolbar icons, the entire toolbar
(including the search widget) could be visible on a 640x480 screen, and
this would no longer be a problem.  But I'll grant you that the search
widget doesn't really belong in the toolbar for consistency reasons
anyway, so it should probably simply be embedded in the
tab/button/whatever views in some consistent place (just like it
currently is in evolution 1.4).

> So, I am not necessarily totally against the tab idea, even though it
> might sound that way. My concerns and a proposal are as follows: 

And I (amusingly enough ;o) am not necessarily totally _for_ the tab
idea either (I just haven't come up with or seen any other dynamic view
switching paradigm that works any better and/or is less confusing).  I
find the array of buttons concept to be rather non-intuitive and
confusing, and I suppose I just kind of have this auto-immune allergic
response to the idea of gratuitously re-inventing a widely used and
commonly understood UI element (like tabs).

> Concerns: 
> * Given that the toolbar items change as you change component, we would
> need to enclose the toolbar within the tab as well if we wanted to
> confine component-related changes to the area within the tab. This
> strikes me as a fairly odd UI. 

Do you mean having the toolbar inside the tabs is odd, or do you mean
having the toolbars change as you change tabs is odd?  If it's the
former, I agree wholeheartedly.  Toolbars decidedly do *not* belong
inside a tab.  If the latter, why is that any more odd than having the
toolbar change depending on what button you click (or depending on what
folder you have selected, as in the current evolution ui)?

> Note that the fact that the toolbar changes from component to component
> is a significant difference between Evolution and Galeon. In Galeon, the
> same set of toolbar items apply to any given webpage; in Evolution, it
> doesn't make much sense to show the Reply/Forward (etc) buttons in the
> Calendar. 

I think that having the toolbar change with context is a pretty widely
understood concept.  I mean, word processors change their toolbars
dynamically as you move the cursor down the page.  I really don't see
this as an odd behavior (but, as I said before, it's entirely possible
that I'm just the one that's odd ;o)

> * We are hoping to make Evolution easily pluggable, so that people can
> install an arbitrary number of components. (There is already work being
> done to develop a News reader component, an IM component, etc.) As such,
> it has hard to tell how many components any user might have within her
> Evolution. 

Which brings up another argument for a tabbed interface -- Tabs have a
pretty well understood mechanism for expansion (i.e. they can shrink to
fit more on the screen, or there can be arrows on the right/bottom to
indicate hidden tabs).  How would you handle an increasing number of
plugins with the button array concept? (/me thinks you're going to have
to re-invent/modify yet another common UI element to do this).

> If we use tabs to allow you to switch between them, then as
> the number of components grows, the distance that you have to move your
> mouse to activate a given component also grows. If we lay out the
> buttons in a matrix,then the distance that your mouse has to travel
> between the folder tree and any given button (or between nav buttons) is
> much smaller. Less mousing == good. :)

Less mousing is generally a good thing (which is why I'm all in favor of
providing hotkeys to switch tabs with ;o).  But once your hand is on the
mouse, moving it a little more distance doesn't seem all that arduous to
me (especially when compared to the annoyance of having to use the mouse
to do something that should be easily doable with a keyboard shortcut,
like navigating to the next mail folder which contains unread messages,
for example <hint, hint> ;o).

In any case (and regardless of the outcome), it's great to have these
kind of discussions, as it ultimately makes evolution a much better
piece of software!  Thanks for soliciting comments/ideas, and thanks
even more for listening to and considering them!  And thanks a *lot* for
evolution, it's a fantastic piece of work!

Cheers!
-- 
Brett Johnson <brett hp com>
   -  i  n  v  e  n  t  -