Examination of a Linux Gui, w/color commentary

[Derek Martin]

On Fri, Feb 27, 2004 at 09:15:32AM -0500, brian wrote:
> On Thu, 2004-02-26 at 21:34, Jeff Kinz wrote:
> > ESR's point is that the folsk designing the GUI's need ot think at the
> > problem from a perspective much closer the user's point of view.
> 
> Yes, programmers should all cater to the fact that for some reason
> people think that they can be blissfully ignorant about their PC
> hardware.  

Of course they should...  That's pretty obvious.  Well maybe not all,
but certainly a great many.  It depends on what they're writing, and
who the target audience is, of course.

> The expectation that the software/hardware vendor, kid down the
> street, or IT department should just make everything work FOR them
> is very prevalent.

Naturally, as it should be...

Oh, I see, you were being sarcastic.  For a moment, I thought you
actually got it.

> The computer is a tool.  Just like any other.  You can learn to use it,
> or you can learn to use a different tool to do the same job (although
> doing so may prove more costly, less efficient, more cumbersome, or any
> combination thereof.)

PRECISELY.  The computer IS a tool, and the job of the software
programmer is to make that tool useful.  In many, many cases, the
programmer is being paid specifically to make that tool useful to
people who are not programmers, by writing (at least in theory)
user-friendly software.  The system administrator's job is
specifically to configure and maintain computing resources for the
non-technical users who can't do it, or who simply have more important
things to do.  Believe it or not, there's a lot more to life than
tinkering with your computer...

Until extremely recently, I made my living supporting, and to a lesser
extent programming, computers (and I almost certainly will again in
the not too distant future).  I have been actively using and studying
computers since about 1983, long before I even had a thought about
entering the workforce.  And frankly, many of my colleagues consider
me fairly talented, despite the fact that there's a ton of crap I still
don't know about how to configure and maintain computers, and there
always will be.

So, then, if this is my career, and /I/ can't keep up, how can some
non-techie who's much more concerned about counting beans than
figuring out how to configure his printer?

The fact is, as has been reiterated here time and time again on this
list, most people who use computers aren't interested in the gory
details, and they shouldn't need to be.  They are (mostly) paying
customers (or at least their employers are), who demand software that
will do all the hard bits for them.  This is, actually, perfectly
reasonable.

The computer is a fantastically powerful tool, which is exceptional at
automating tasks that are repetetive, tedious and mundane, or
otherwise just electrically automatable...  But it is also an
extremely complex tool, and extremely picky about how you tell it what
to do.  To the average person, it is simply beyond them.  This is not
necessarily because they are stupid, or because they simply can't
understand computers; many of them COULD do it, if they chose to spend
the time to learn.  But their expertise and interests lie elsewhere,
and their time is better spent on those endeavors.  Not everyone can
be a computer expert; nor should everyone try.

So then, in order for the computer to be useful as a tool, it needs to
be running useful software.  In order for it to be useful as a tool to
most normal people, it needs to be running software that's easy to use
and configure.  And there's absolutely no reason that it can't be
that, other than programmer laziness, or perhaps lack of time
resources...  Neither of these problems are insurmountable.  I
guess a third reason is a general lack of interface design skill,
which is what ESR is complaining about.

The tool which ESR is blasting is called printconf-gui, a tool
provided by Red Hat specifically to meet the needs of the
non-technical user in setting up printers in a networked environment.
Given that this is its express purpose, ESR is right; it is a failure.
Few tools you will use are ever perfect, but this particular one could
be a lot better...

> I am not saying that the whole printer config thing doesn't leave
> something to be desired... However his "idea" that the whole thing
> should just discover your network and list for you only the available
> options is tad bit off as well.  

So then what, it should additionally list options which don't exist?
Or not list /any/ options  which are available, even though it
perfectly well could?

> How would it know that you had permissions to actually print to each
> printer?  

Irrelevant.  First of all, ESR never suggested that the tool provide
you with a list of all printers which are available and which you have
permissions.

But, since you brought the discussion around to that direction, it's
not at all unreasonable that the tool should list all possible
printers available on your network, though you may not actually have
permission to print to them.  It may well be that the person
configuring the system should eventually have access to the given
printer, but hasn't had the proper privileges bestowed yet.  The
printer should still be available for selection...  But as I said,
this was not ESR's point at all.

> What if it "recommends" the wrong or sub-optimal printer?  

The recommendation of which you speak was not for a specific printer,
but for a class of queues in which the new print queue should be
placed.  This entire line of your argument is a red herring.  You
clearly didn't understand what ESR was saying.  

  New form. "Queue type", it says. There's a drop-down menu. The
  default is "Locally connected", which is reasonable. Clicking on the
  menu, I am presented with the following alternatives:

  [SNIP LIST OF QUEUE TYPES]

  Here is our first intimation of trouble. If I were Aunt Tillie the
  archetypal nontechnical user, I am at this point thinking "What in
  the holy fleeping frack does that mean? And just as importantly, why
  do I have to answer this question?" I do not, after all, have any
  Windows machines on my network. Nor any Netware boxes. And I
  certainly don't have a "Networked JetDirect", whatever that might
  be.

  [MORE UNNEEDED STUFF SNIPPED]

  I am not ignorant, but I have my own equivalent of Aunt Tillie's
  problem. I know I want one of the top two methods [THAT'S METHODS,
  NOT PRINTERS -- EITHER UNIX OR CUPS IN THIS CASE], but I don't know
  which one. And I don't want to know or care about the difference
  either; I have better things to do with my brain than clutter it
  with sysadminning details. If the tool can detect that both methods
  are available on the local net (and that shouldn't be hard, they're
  both well-known ports) it should put "(recommended)" next to one so
  I can click and keep going.

It is not at all difficult for the client to send out a broadcast to
identify whether thare are any lpd (Unix print) servers running, CUPS
servers running, or JetDirect printers running on the local subnet.
Assuming the appropriate tools are installed (printconf-gui depends on
them, so they should be), it is also easy to subsequently query those
servers to identify the available print queues on them.  This is a
technical problem for which there is a simple solution, and therefore
there is no good reason not to at least provide the option to do so.
There is an argument about network traffic to be made, but
realistically we're talking about a simple one-time three-port port
scan here.  The traffic is pretty negligible.  

> Anyway... I use linux for a number of reasons.  One of which is that it
> is much cheaper than some of the alternatives, yet still does everything
> I want it to.  The offsetting factor is that I have to actually *know* a
> little more about my environment than I might have to if I were using,
> say, Windows.  This is fine for me, although maybe not for Aunt Millie. 
> If Aunt Millie don't want to learn, she can pay the Windows ignorance
> tax I suppose.

It's fine for me too; but if there were GUI tools available which
greatly simplified my job, and reliably produced the necessary
results, I'd use them...  The computer /is/ a tool, there's no reason
it can't do a lot of this stuff for me.  So, it should.  Plain and
simple.

> Maybe linux on the desktop *isn't* for everyone.  Maybe that isn't a Bad
> Thing?

No, it /IS/ a bad thing.  Because so long as Linux is difficult for
the average user to use, the demand for it will be less than it could
be otherwise.  As I argued in the other thread, we NEED those users,
in order to improve the selection and quality of software alternatives
available to us as Linux users.

On Fri, Feb 27, 2004 at 10:06:15AM -0500, brian wrote:
> I know a lot of these may seem to be silly arguments, 

Then please stop making them.

> it's just the other end of ESR's rant about how all this should be
> so simple to implement.  

What ESR actually suggested IS simple to implement, though your
misinterpretation of what he said isn't, admittedly.

> In real life, it's not so simple because there are far too many
> variables you (you being the programmer, not you being you) simply
> cannot know.  Trying to code for every possible iteration becomes
> far too much overhead...

So you're suggesting that software should not try to make things
easier for the user, just because someone somewhere might misconfigure
something?  You're asking the rest of the world to do a lot more
tedious and unnecessary work because some of the less
technically-minded users, who would DEFINITELY have got it wrong
anyway without the GUI, might make a mistake.  Give me a break.

Besides which, ESR's point was (if I may be allowed to interpret)
that if you design the interface properly, techies and non-techies
alike are a lot less likely to a) get it wrong and b) have to spend 18
hours sifting through documentation to figure it out.

And he's right.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.
Replying to it will result in undeliverable mail.
Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20040228/69901563/attachment.bin