[OT] Debian mailinglists

[Bart Silverstrim]

Derek Broughton wrote:
> Marcin Kasperski wrote:
> 
>> Are you sure answering 100 questions is less error-prone than
>> locating this single tweak you need to change and changing it?
> 
> Why should a config tool ask 100 questions?  Or even 5?  A good config tool
> shouldn't need to be more complicated that editing - ie, search, change,
> done.

Because you have config tools that configure only, i.e., give you 
configuration options in a graphical layout rather than a text editor, 
then there are applications (or configurators) whose aims are 
goal-oriented and thus lend themselves to a wizard interface or 
wizard/guide aspect of the configurator.

I.e., you want to set up a mail server. If you're familiar with what 
you're doing, going in and adding an alias on an already working Postfix 
system isn't that difficult.

For first time setup, a wizard would lend itself well...your domain 
name, are you a forwarder, what network(s) you should allow relaying 
for, etc.  Thus, it would ask questions to make sure you don't overlook 
something.

My personal preference is to have a tool that you can open a wizard for 
particular task-oriented goals if you choose, and otherwise lets you 
tweak the settings.

>> Yes, reconfiguring remote sshd, firewall, or network interface is
>> risky operation. But it is risky by its very nature, not because you
>> edit config files. I strongly prefer to edit the file, being able to
>> see what I write and where and why, than to run some sequence of
>> questions which I can perfectly misunderstand or press Enter too
>> quickly.
>  
> How is that any more likely to happen with a config tool than when you're
> editing?

Probably because if you hit enter as randomly or impatiently as most 
users use "click and drool" interfaces wizards make it a lot simpler to 
screw up *when misdesigned*. It's an implementation question. The wizard 
could prevent that by just having clear explanations *available* (not 
filling the screen by default) and requiring you to input some setting 
before making "next" active, and having some way of giving feedback so 
you know a delay in your interface is a delay, not a lockup or your 
keystroke didn't register the first time.

Again, these things being picked at seem more a question of 
implementation than inherent problems with GUI vs. text editors.