[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sheflug] https
>>>>> "Al" == Alex Hudson <eah106 [at] york.ac.uk> writes:
Al> 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." :-(
>> It must be necessary to use all three dimensions, and the color
>> coding, of course; if it can be done in text it doesn't count.
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?
>> 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.
Al> fundamental n-dimensional relationships between data /
Al> functions much better than the command line ever will.
>> Which has squat to do with the problem of administering a
>> computer system. And the command line is a straw man.
Al> Not necessarily, no. Graph drawing[1] is fundamental to most
Al> network analysis tools I know of, for example...
And which ShefLUG newbie is doing network analysis at that level?
Name me a Linux GUI _config_ tool that uses such graphs? I think
Karpski or one of those tools will produce connectivity graphs for
you, but I don't think that's relevant to any of the problems most of
us face.
I can see where it would be useful. Eg, to display relations like
INSIDE the firewall vs OUTSIDE; it would be very cool to be able to
type a hostname to your IPchains[1] GUI, have it automatically
tracerouted and appear (along with any gateways) in the appropriate
place. Then to change your firewall setup you just drag it across the
line. But what tool does that?
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.
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).
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
Al> like all the pertinent information - in various variables,
Al> files and command-line switches all over the system, or in one
Al> box on the screen which takes care of it all for 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?)
>> 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?
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.
One point is, I've rarely[2] seen it done. The other point is that
the strong temptation with a GUI is to do as much as possible of the
stuff that is boring routine to the expert "behind the newbie's back."
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.
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....
"What does it profit a man to compile correctly on the first try, if
by so doing he loses his soul to SIGSEGV?"
It's true that many man pages are pretty terrible. My question is, is
it really sensible to spend large amounts of energy writing a GUI that
can cope with a small fraction of the cases that revising the man page
would prevent in the first place?
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"? Emacs + AUC-TeX + LaTeX
is capable of producing nicer, far more maintainable print documents
than any GUI I know of. I guess you could call font-lock/syntax
coloring a form of GUI, but it works on any color-capable TTY, and
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.
This is typically true even of GUIs that use radio buttons properly to
represent the exactly-one-of-many constraint.
For some people, such text descriptions provide far more "fundamental
usability" than GUIs yet do. 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.
Al> Computers as we know them would
Al> not have taken off if it were not for the GUI.
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.
Footnotes:
[1] I'm limited to Linux 2.2 technology for now.
[2] Custom files in Emacs; I haven't seen it in anything else. The
Lynx 2.8.4 config files are interesting, they support *roff-like tags
to allow you to browse the config file. XML will definitely make this
easier.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
---------------------------------------------------------------------
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.