Re: [Sheflug] GUI vs. text ;))

[Alex Hudson <nospam [at] york.ac.uk>]

On Mon, 12 Jun 2000, Stephen J. Turnbull wrote:

>  >> Show me a 3D, color-coded graph, along with a set of relevant
>  >> buttons, that helps a user whose kppp refuses to connect to his
>  >> ISP get it right.
>Al> I don't need to ;) I would lay money on more people new to
>Al> linux having success with kppp rather than configuring the
>Al> text files...
> So would I.
> 
> The issue is if kppp _doesn't_ work.  There is no graceful failure
> mode; the automatic response seems to be "post to ShefLUG."  :-(

I don't see why a user has to become fully conversant with the ins and
outs of ppp config on linux just to set up a dial-in line? Okay, if kppp
doesn't work, you're stuck. Most users don't care to work out how ppp
works, in exactly the same way that people don't learn how to fix their
car. Cars should just work ... ?

But what if the car breaks down? There is no graceful failure mode; the
automatic response seems to be "take it to a garage." 

I think the same argument holds for microwaves, vcrs, ovens, hoovers,
sound systems, televisions, telephones, faxes, etc.. I can fix
televisions. Most people can't. I don't expect people to learn how find
parts out of a catalogue when the l.o.t. goes bang; similarly, I don't
expect people to be able to configure all the software on their system
when the software doesn't work as the author intended. 

> Al> I think we've found an extreme case here; my comments about
> Al> multi-dimensional data structures don't count for *every*
> Al> application, obviously ;)
> 
> Um, name one sys admin task where it does?

I wasn't particularly thinking of sys adminning, I was thinking of
advantages of GUI displays for applications in general...

>  >> But just trolling the Sheflug archives will give me examples of
>  >> a dozen bad ones, I'll bet.  That's not a good ratio....
>Al> I would imagine the ratio is roughly the same as bad text
>Al> interfaces..
> Probably not.  I've yet to see a bad config file format that is
> written by a good GUI, but there are lots of reasonable config files
> not supported by _any_ GUI.

I can think of numerous bad config files, bad text mode programs, bad
command line switches, etc. It's not just a disease of the GUI was the
point I was making. Given most text-mode programs for synadmining are
approx. 10yrs older than the GUI equivilents, it may be that the ratio is
slightly different, but that's not because of a limitation of the GUI
paradigm.

>  Al> To be able to see dynamic results to a configuration change
>  Al> requires the use of a GUI.
>  >> Say what?
>Al> Constraint satisfation. I.e., radio buttons.
> In C, that's called an enum.

No it's not. Radio buttons can be 'one from a list', as can a picker box,
etc. However, one can specify greater relations than that: 'one from list
a if item 5 from list b is not selected', etc. The mailbox configuration
in NS is an example: selecting POP3 or IMAP automatically ghosts out
options that are not available for the user (although NS is *not* an
example of a good GUI IMO ;). Ghosting out menu items is also common. This
is functionality not possible in a configuration file. 

> The advantage of the radio buttons is to take up a lot of space
> displaying rarely used options.  (Yes, that's an advantage.
> Educational.  A good GUI would allow you to switch between radio
> buttons and other presentations of the select-one-from-many choice; I
> don't know any that do, though.  Although I'm writing one with that in
> the specs; main problem is figuring out how to present the choice of
> presentations to the user).

There are GUIs that do that; their names escape me for the moment. IIRC,
the specification for the dialog (for example) is specified in terms of
the constraints, the pre conditions and the post conditions. It is then up
to the GUI to present those constraints in the most appropriate way, which
is the way it should be done (IMO, of course ;). It also allows you to
update the GUI to take advantage of new controls (such as a pie menu),
which can be advantagous in many situations).

>  Al> To be able to group configuration options logically requires
>  Al> more than a command line.
>  >> Yeah; that's why environment variables, config files, and text
>  >> editors were invented.
>Al> . and why they were superceded by the GUI ;)) Where would you
> That's why /etc/hosts.deny is deprecated.  I note that change didn't
> require a GUI.  (Is there a GUI for TCP wrappers?)

I didn't realise hosts.deny was deprecated... I also note, though, that
although the configuration file hosts.allow is there, the format is
described in hosts_allow(5). So, the information is still disparate. There
is just no linking of this data. 

>  >> Haven't seen a GUI yet that allows, let alone encourages,
>  >> keeping that kind of notes.
>Al> Strange, I have ;)
> In your dreams?  Or is it available in RPM format?

Even Windows has capability like that. Click on '?'. Click on tool. See
information. Possibly links to other help files / web pages. Okay, you
can't edit them, but I would imagine that it isn't hard to implement ;)

> Al> You can dynamically link GUI options to other sections of the
> Al> program, or help files. You can invoke the browser to bring up
> Al> the full RFC. There's no limit to the amount of information a
> Al> GUI can relate to you.
> Sure, you _can_.  I'm not blind to the possibilities.

Not only _can_ people, people _do_. 

> But this leaves the newbie without the expert's expertise, and without
> the habit of reading man pages that makes acquisition of expertise so
> much faster.

I'm sure people also learn expertise from reading Haynes', it doesn't mean
that they want to / should / could.

>     Al> Not quite ;) As an example, it is *much* easier to screw SAMBA
>     Al> by altering the conf files directly than using the web tool -
>     Al> it guarantees syntactic correctness, so all you're left with
>     Al> is the plain ole human logic errors.
> This is a huge advantage to the wizard.  Not so much so for the
> newbie.  You learn a lot (by osmosis) studying the man page to figure
> out the syntax.  Certainly, it's a tradeoff.  If the GUI gets it right
> the first time, and you never have to revisit your decisions, it's
> great.  If not, you post to ShefLUG.  Nothing lost by using the GUI;
> Al will be happy to help you....

Obviously, this is one of the main points where we differ. I believe
strongly that the user has no interest in learning how the system works,
nor should they be expected to. I believe computers should set themselves
up, and configure themselves correctly. I believe that any configuration
you do should be one-time only. I believe it should be as simple as
possible, and hide as much from the user as possible. 

>Al> However, in the general case it's not true, because the
>Al> fundamental usability of a GUI is far and away better than
>Al> that of a text-mode interface.
> What do you mean by "fundamental usability"?

A GUI has fewer fundamental axioms that text-mode interfaces; it is
quicker for a user to pick up, and they are more productive using GUI than
TMUI. There is a reason why GUIs have taken off..

>  Emacs + AUC-TeX + LaTeX
> is capable of producing nicer, far more maintainable print documents
> than any GUI I know of.

LyX? I haven't used the Emacs solution, but for me, LyX works incredibly
well. It may be that it hasn't caught up with the text stuff for many
features, but that's a time limitation rather than a 'can't do it'
limitation.

> doesn't provide buttons and stuff.  However you class it, there are
> very few dedicated GUIs that provide a similar functionality of
> exposing fundamental structures in a document; most GUIs proceed on
> the assumption that WYSIWYG is good, and thus hide the underlying
> structure.

Not true. All professional web designers I know use Dreamweaver /
Fireworks, and while they do provide a WYSIWYG interface, they also
provide a window onto the HTML document. The quickest interface is then
used (ie. removing the border from a table would probably be done in the
HTML window: highlight border="1", press delete, done. Creating a table in
the first place would be done in the WYSIWYG window, cos it's quicker than
typing out <table border=.. id=.. name=..> .. etc. etc.).

> For some people, such text descriptions provide far more "fundamental
> usability" than GUIs yet do.

Yes, and I'm sure a car mechanic would rather have a monkey wrench than a
tow-truck, but it's not for the 90%+ of computer users who don't have such
in-depth knowledge.

> And we know, as yet, very little about
> how to design GUIs to take advantage of the potential usability,
> nowhere near as much as we know about using things like enums and
> structs in linear text representations.

Granted, but this a field that's only thirty-or-so years old : text mode
has an extra ten/twenty years advantage, enums and structs hundreds more.

> I will grant that most users don't give a shit about maintainability,
> they just want to minimize the time between getting the assignment and
> the time they can make their break for the pub.  But I don't see
> anything particularly fundamental about that.

I'm not sure maintainability is necessarily a goal for most users, hence
it's probably not something well-developed within the GUI world.
Certainly, though, in apps where maintainability is a goal, it is far
easier than using a couple of xterms or something. See Dreamweaver.

Cheers,

Alex.


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.