At 01:50 PM 10/1/00, Roger B.A. Klorese wrote:
>Developers tend to write GUIs that are really config file editors,
>providing a point-and-click interface which requires you to understand the
>underlying config variables, instead of the actions they control.
Yep. That's so ANYTHING can be controlled, not just the things
the GUI writer thought of.
>going all the way to the task orientation, why not a check box for
>"Users should be able to send mail to LISTNAME-subscribe to be added
>to the list and to LISTNAME-unsubscribe" to be removed"?
Listserv has something like this, which handles 90% of list admin
for inexperienced list owners. As a more experienced owner, I find
myself always escaping to their, which is basically the "configedit"
command in Mj2.
I ran into this with commercial software I wrote and sold: The config
file had 80+ options (Mj2 has 110+) and they interacted with each other
in complex ways (just like Mj2). Users would ask for a simple interface
to do complex things, but would then spend page after page of email
trying to define what they wanted to do before realizing they really
DID need to understand all the options to set them intelligently.
List configs interact with each other, and most of those interactions
are captured in the help files. Trying to explain them on a web GUI
might wind up looking like HTML help instead of a list config form.
After all that ranting, if you've got time to study the configs and
write down some sort of spec for how the GUI can simplify the common
admin tasks, I'll see if that would allow me to configure my 30 lists
as they are now. You'll also get further with the guy who's writing
the web interface if you say "please do these specific things" instead
of saying "please do this sort of thing".
>serve as a focus for a simplified and task-oriented end-user and
>administrative usage model. I know we won't get there in a single
>release, but since it's what I do for a day-job, it's an area I can add
You bet! Good specs make coding SOOO much easier!