On Wednesday 10 September 2003 16:36, Jesper Fruergaard Andersen wrote:
> On Friday 05 September 2003 20:06, Jason Stubbs wrote:
> > > I would really hate that. Then I would have to look for an other disto
> > > again. For some reason distos always seem to become more and more
> > > "userfriendly", that is harder and harder to use if you don't want to
> > > use the shiny gui interface they always seems to come up with.
> >
> > You are wrong. 'userfriendly' does not imply harder to use (for power
> > users). Just because all those that have tried so far have failed,
> > there's no logical step to say that it's impossible. Compare MS
> > Exchange's method
>
> It does not imply but it seems to be that way in practice.
>
> > of
> > configuration with Sendmail's - yes, we have postfix now but sendmail
> > fits what I'm talking about better. Exchange's interface is easy to use
> > and will set everything you want correctly - if the program doesn't work
> > the way you want it to it's due to a bug in the server, not the
> > interface. Sendmail will do everything you want it to but you have are
> > much more likely to make a configuration error.
> >
> > Most people will say to this, "but Sendmail is more powerful!" What's
> > that got to do with the price of fish? Exchange's real configuration lies
> > partially in the registry and partially in configuration files (in a
> > non-text format), either in it's application directory or active
> > directory. From a programming perspective, isn't attaching a user
> > interface on to the configuration files just as hard for either? With
> > postfix, parsing and configuring it from a gui would be much easier than
> > either.
>
> Whether you use text files or non-text files to store the configuration
> does not make much of a differenct if you want to write a gui on top of it.
> What to note is that the gui is enfact on top of the configuration file so
> at best you can hope not to loose any expressive power. To keep the
> expressive power of the configuration files you can try to immitate the
> structure of the file in the gui, for a more complex program the probably
> will not make a good gui. To make a good gui you probably have to
> restructure it somehow and then make some more or less complex translation
> back to the configuration file. In that process you will probably loose
> some expressive power. That is anyway how it seems to be in practice. Only
> some part of what the program is capable of doing can be configured from
> the gui, that is the part that the GUI writer fount to be most important.
> But ofcause as long as the gui supports you every need to the program that
> is fine and I do prefer a gui to some simpler programs.
> Then there is the issue of being able to do the configuration by some other
> programe. It is i lot easier to make a script that outputs a configuration
> file that a script that interacts with a gui.
> Then you could just have the configuration files with the gui on top and
> let the the people that want a gui use the gui and the rest can just modify
> the configuration file by hand. That might be a good solution. The problem
> is that the way the translation from the gui to the configuration file
> often is implemented is by making some intermediat configuration file that
> maps closely to the gui and translate that to the real configuration file
> and as this approach gets implemented through out the system the system
> becomes very dependent on those intermediat configurations files and it
> becomes hard to be allowed, by the system, to edit some of the
> configuration files by hand.
>
> > The point of userfriendlyness is not to limit users in what they can do
> > so that they don't trip over themselves. The point is to make all options
> > available (and easily understandable) and prevent configurations that
> > meaningless in the domain of the application.
>
> That is one way to define userfriendlyness and it has some good points to
> it. For one it does not in any way imply that a gui is the better choise
> over a text file.

All very good points! I think we agree - guis are good but their current 
implementations suck. That's about it innit? ;-)

Jason

--
[EMAIL PROTECTED] mailing list

Reply via email to