Re: Configuration

On Thu, 4 Mar 1999, Walt Armour wrote:
> On Wed, 3 Mar 1999, Gleef wrote:
> > On Wed, 3 Mar 1999, Scott Tyson wrote:
> [snip]
> > >
> > > I think people are forgetting some of the goals associated with the
> > > GNOME Environment.  If Linux is to make inroads into the desktop
> > > market as a viable alternative to windows it must be just as easy to
> > > use for the layman.
> > 
> > First off, helping Linux make inroads into the desktop market was
> > never one of the goals of GNOME.  To quote the GNOME Manifesto:
> > "Gnome is an Open Source desktop environment built from components
> > that meet the Open Source guidelines in full."  Basically, we want to
> > write an excellent desktop, that is both powerful and easy to use.
> > Leave worrying about market share to the companies.
> > 
> I don't know about you but I don't care to develop in a black hole.  If I
> don't know where my application is going or who may be using it then why
> am I writing it?  To fill some personal need?  Perhaps, but then I'm not
> going to worry about making it an OSS project.

I'm not saying not to care about who uses it.  I've seen projects whose
goal was to make a good program, I've seen projects whose goal was to
crush so-and-so, and I've seen projects whose goal was to copy so-and-so.
Generally, the program produced was better if focus is kept on making the
program good, rather than focussing on the other guy.  Of course making
the program good includes keeping an idea of the target user, and what
they want to do.  I doubt Balsa's target users want a clone of Outlook.

> Sure, I may leave the commercial marketing to Red Hat and the like but I
> still am going to do my part to "market" Linux as a geenral desktop OS.
> Based on my experience and skill set that makes my part the development of
> general applications that Joe User will want to use.

That's fine.

> > Secondly, yes GNOME should be easy to use for the layman.  However,
> > keep in mind that a computer is a complex thing, getting more complex
> > all the time.  What this means is that _configuring_ a system will
> > never be a trivial task, not in Linux, not in Windows, not in MacOS.
> > I would call email filtering, regardless of where it's done, a
> > configuration issue.
> > 
> I disagree with your first statement.  I sincerely hope to see the day
> where configuration of an end-user system is a trivial task.  The blind
> assumption that configuration is hard and will always be that way is what
> keeps configuration hard.  Keep in mind that I'm talking about end-user
> configuration here (e.g. applications) not OS level global settings, BIOS,
> and other such things.  And I believe that is what we should focus on
> here:  how easy can we make it to configure a mail client?

Personally, I hope configuration is never a trivial task.  The ideal
configuration complexity varies directly with system flexibility.  What
this means is to make a system trivial to configure, you must make it
inflexible.  This is regardless of whether the system is an application,
an OS, or a toaster.  That's not to say you can't make an inflexible
system HARD to configure, but you certainly can't make a highly flexible
system trivial to configure.

That being said, systems like Procmail some unnecessary complexity, and a
lot of seldom-used complexity, that can be avoided with a good frontend,
so it can be made easier to configure.

> > Most laypeople deal with this by buying preconfigured machines for
> > their home, and having the IS department configure their desktop
> > machines at work.  This is why the iMac has been selling so well, not
> > because it's easy to configure, but because 99.9% of the configuration
> > is already done for you.
> > 
> > We should definately try to make configuration issues more accessible
> > to laypeople, and provide tools to make things as easy as possible,
> > but it will never be truly _easy_.
> Agreed to the first point.  Again, on the last point, I think this is a
> poor assumption.  I feel that it should be our goal (and possibly every
> developer's goal) to make configuration easy.  Again, remember the level
> of configuration we are discussing here.

Configuration needs to be as easy as possible, but I don't want to see
useful features dumped just because it will make configuration harder.
I'm saying that beyond a certain point, configuration can't be made
easier without dumping flexibility.  That being said, your point below has
convinced me that having some filtering features built into Balsa would be
a good thing for some users, and additional flexibility could easily be
added by using Procmail with Balsa, without Balsa requiring Procmail be
installed to access some common filtering features.

> > > Think of it this way.  I would not want my father messing with
> > > procmail/fetchmail for email reading/filtering.  It might be a
> > > powerfull and flexible setup but it is far to cryptic and different
> > > from what he is used to.  Linux mailers have to drop the old school
> > > unix mailer persona and embrace what programs like Eudora and
> > > Calypso (my persnal fav for windows mailer) and Outlook Express
> > > offer.
> > 
> > We also shouldn't reinvent the wheel, like most Windows mailer
> > programs do.  Rather than having Balsa do the mail filtering itself,
> > and rather than forcing users to figure out the difference between
> > ":0" and ":0c", why not have Balsa give an easy to use and understand
> > GUI tool to edit and create .procmailrc files.  It would be easier to
> > write than a full-featured filtering system, and more useful in general.
> I think a tool like this would be nice but I don't feel we can leave it as
> the final solution.  As we mentioned before if Balsa includes filtering
> you don't have to use it.  But I don't think we should cut out a
> potentially large number of users by requiring procmail for a function
> that is found in the majority of commercial email clients.

True, there's nothing preventing a user from using something like Procmail
anyway, regardless of whether or not Balsa does filtering.  There will be
users who just can't get Procmail on their system, and they needn't be
left in the cold.

Gotta go

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]