Re: [Epiphany] load new tabs in background

["Steve Salazar" <eagsalazar hotmail com>]

>From: Marco Pesenti Gritti <mpeseng@tin.it>
>To: Steve Salazar <eagsalazar@hotmail.com>
>CC: epiphany@mozdev.org
>Subject: Re: [Epiphany] load new tabs in background
>Date: 04 Jun 2003 09:16:54 +0200
>
>
> > Slightly off the subject but relevant, why not include an optional "UI 
>study
> > module" in epiphany that people can turn off like the feedback agent in
> > mozilla?  This thing would just keep statistics on which preferences get
> > used at all and what they get set to.  That way instead of just wild
> > speculation/theory on inclusion/exclusion of configuration options, all 
>you
> > have to do is just include an option for a release or two, see if/how it
> > gets used and then if it is like 90% one way you just fix the preference 
>as
> > a default and remove it.  If it is 50/50 then you leave it in as an 
>option.
> > Then ui decisions like this can be based on actual experimental data
> > (radical notion I know).  I think as long as the reason for including 
>such a
> > module were made plain up front, most people would be really excited 
>about
> > it.  You could even have a page on the epiphany web site which posts 
>running
> > statistics.  That would be cool.  Aside from the option to turn this 
>module
> > off,  the whole thing could be totally transparent to a user since it 
>would
> > not require their interaction to send the info and the data transfered 
>would
> > be very small.   This module could even only be enabled for pre-1.0 
>releases
> > or other experimental versions.
>
>There are two reasons because I think this would not work:
>
>- People that test pre releases are not a representative subset of our
>(potential) user base, so the statistics would be wrong
>- An interface is not a sum of elements, but a system. A simple "keep
>just pref that most people like" is not likely to work, even with good
>statistics. Statistics would need a more complex evaluation.
>
> > Another somewhat relevant and somewhat offtopic question: why are 
>options
> > removed from the browser and not just removed from the preferences ui so
> > that they can still be set by expert or highly motivated users using 
>gconf?
>
>Hidden prefs have a cost too, even if lower then visible prefs. There is
>some manteinance cost and, way worst, there is the risk to not fix real
>problems because there is a work around for it. (that works only for a
>small subset of our userbase)
>
>Marco
>


I think the key word here is "potential".  Even the bulk of inidividuals 
using mozilla on their stock redhat 9 are not this "potential" user base you 
speak of.  Almost all people who use linux at all are one of a) geeks (99% 
of all epiphany users), b) engineers who use linux as their engineering 
workstation (everyone at my work), c) software developers, d) checkers at 
Burlington Coat Factory who don't have web browsers installed anyway.  Of 
coarse thinking about the future is smart but not at the expense of the 
preferences of the entirety of your current user base.

In any case, I agree with your points; especially about the risk for things 
to go unfixed if a hidden pref exists.  However, the potential issue can be 
minimized via the same vigilance that keeps the ui clean despite a constant 
barrage of requests for new features.  I do understand the desire to keep 
the primary ui utra clean and simple but I don't really understand why this 
precludes the existence of a powerful and flexible featureset just below the 
surface.  Of course each new feature, even if hidden, has a cost but that 
cost just needs to be weighed on a case by case basis.  eg 1) hidden pref to 
rotate my viewing window by 90% - bad idea, or 2) hidden pref to allow me to 
select where new tabs go (especially since which is the better option is 
debatable, people do care, and it was previously implemented) - good idea.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail