Re: Epiphany 1.3.2

[Bryan Clark <bclark redhat com>]

On Thu, 2004-07-15 at 17:54 +0200, Roberto Piscitello wrote:
> Since I'm new to the list, I can't start but saying hello everybody!
> 
> Il gio, 2004-07-08 alle 19:03, Marco Pesenti Gritti ha scritto:
> > On Thu, 2004-07-08 at 15:35, Reinout van Schouwen wrote:
> > > On Wed, 7 Jul 2004, Christian Persch wrote:
> > > 
> > > >         * Append new tabs to the end instead of grouping them (Marco)
> > > 
> > > Nooo! Why was this necessary? Adding a new tab next to the currently
> > > opened one is one of the nice icing-on-the-cake features that makes ephy
> > > such a joy to use!
> FWIW, count me too on the Nooo! side.
> 
> > Well, it's a tradeoff. I think appending at the end is the intuitive
> > behavior (I actually did a mini test on this and everyone I asked was
> > expecting to have the tab added at the end). Personally the few times I
> > used tabs I was a bit confused by the the grouping behavior, even if I'm
> > sure when you get used it feel sort of natural ...
> I use tabs a lot, and can say it's natural and even logical (for me, at
> least:) that tabs related to the page I'm reading get opened close to
> it.
> Why should I want it to open 10 tabs further, maybe out of the screen?
> Would that be more intuitive?  Remember that opening a tab via
> middle-click doesn't switch (and it's right) to that tab.
> 
> PROs of tab-grouping:
>  - new tabs (which probably are the ones you'll read next) are easier to
> reach;
>  - related tabs are automatically grouped and not spread around the tab
> list.
>  - new tabs always appear on-screen, even if you have tens of them;
> 
> CONs of tab-grouping:
>  - Mozilla or Firefox behaves differently:
>         Uhm... not a good point for me.
>  - gedit (or gnome-terminal, etc...) behaves differently:
>         FALSE. Gedit does/can not have click-to-open-a-related-tab; it
>         only uses tabs (and puts them at the end) to open a new document
>         or an existing one given its URI.  In that situation Ephy
>         already behaves exactly the same way: it puts its tab at the end
>         and makes it the current one.

The difference in behavior here is an issue with the HIG not specifying
a standard tab behavior.  

While tab grouping is a nice thing to have, in its current
implementation it is confusing to users where the tab will appear next.
Having tabs appear at the very end is the most expected behavior.
Perhaps we can do better but I think a better interaction model needs to
be worked out before we try to group tabs for people.

> 
> So I really can't see any clear problem caused by tab-grouping.
> However I see some usability issues opened by its remotion:
>  - if there are many (where many=7 on my 1024x768 screen) tabs open, new
> tabs are opened "out of the screen", so the user doesn't get any
> feedback of them getting created and loaded.
>  - the user keeps scrolling back & forth the tab list to get to his new
> tabs; this can be _very_ annoying if you have many (>7) tabs, because
> the arrows to scroll the list are small and difficult to hit.
>  - related tabs are spread around the tab list.
> 
> In my experience 7 is not that many tabs.
> 
> > What we are losing in the tradeoff is the ability to create subgroups of
> > tabs, but is that such a common use case ?
> I think it is, at least for me.
> > You can already create
> > multiple groups of tabs using windows...
> It depends on your navigation habits and necessities.
> 
> In conclusion, I think that, without tab-grouping, Ephiphany loses more
> then that (what?) it gains.  I hope you revert your patch.
> 
> Thanks a lot for your work.  Keep on rocking guys!
> 
> Ciao,
>   robepisc