Path: utzoo!attcan!uunet!husc6!tut.cis.ohio-state.edu!allosaur.cis.ohio-state.edu!bob
From: bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
Newsgroups: comp.windows.news
Subject: Re: Bugs in NeWs documentation (really: terminology confusing to novices)
Summary: don't hide the truth behind imprecise terminology
Message-ID: <20102@tut.cis.ohio-state.edu>
Date: 16 Aug 88 19:11:04 GMT
References: <1327@ucsfcca.ucsf.edu>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University Dept of Computer & Information Science
Lines: 80

In article <1327@ucsfcca.ucsf.edu> dick@ucsfccb.UUCP (Dick Karpinski) writes:
>
>The NeWS and the Open Look documentation is said to refer to the
>local graphics device as a window server and the distant applications
>engine as a window client.  I am fully aware that this makes good
>sense when you understand the mechanism.  However, I am acutely aware
>that novices find this confusing.
>
>The local thing is client.  The distant thing is server.  Don't
>confuse me.  Don't confuse me with facts or opinions.  My workstation
>is me or my agent.  Distant hosts serve me and my agent.

When I need to explain the window server/client relationship, I
describe it in terms the user is already familiar with, and which keep
things rational and consistent.

In economic terms: A server allocates a scarce resource to clients who
want access to parts of it.

In the case of a supermarket, there are only a finite number of loaves
of bread on the shelf and the supermarket manages contention between
the customers (clients) who want that bread.  They do it by requiring
money in exchange, and throttle the demand by maintaining long lines
at the checkout counter, among other things.

In the case of a file server, the scarce resources are blocks on a
disk.  Only the server machine has direct access, every client must
request portions, and the server doles them out as it sees fit, and
scheduling demand between other requests as well as mine.  It
allocates it fairly by normal request queueing mechanisms at various
levels of the protocol stack.

In the case of a window server, the scarce resources are the acreage
on my screen, and my input devices.  There are a finite, countable
number of pixels, keys, mice, and mouse buttons available.  Screen
space and input events are apportioned fairly by algorithms relating
to geometry, overlap heirarchies, etc.  (Anyone who thinks they know
about time-sharing schedulers can handle this.)

Once they have this much down, I generalize it yet more and say that
the Cray across campus is the cycle server, but my Sun runs the window
server.  Each needs something the other has in order for the
application to run, so each provides the other some of the resources
it is uniquely best at providing.

When I have to explain what's going on in a server-based window
system, I find it much easier to first explain the architecture so
that the audience knows just a little bit about what's going on
"behind the curtains".  Then they have a much better understanding of
what they are really trying to do, and my phone doesn't ring with so
many questions about incomprehensible error messages, etc.  Explain
the mechanism to the novice, and {s}he will be happier in the long
run.

I find this true in most technical fields that I try to explain to
novices, not just with window systems.  For instance, my wife is a
brilliant elementary music teacher, but she never considered herself
too hot at "science stuff".  She now understands how our airplane
flies in terms of compressible flow of air molecules over the wings,
and therefore is beginning to understand how and why temperature
variations affect wing and engine performance.  Then she came
full-circle and connected that back to "warming up" an instrument.

Don't try to hide the details, if the audience really wants to know!
If they build an incorrect mental model too early, it could be very
hard to replace it with what's *really* happening later on.

>Change the terminology pronto.  Please.

The terminology has been arrived at through several years of work by
lots of folks in the field (not just the authors of the NeWS and Open
Look documentation), and is pretty well entrenched.  It is even
appropriate to describe what's happening.  Don't bother trying to
change it now.

Sorry, I've really strayed from the subject here.  Oh well...
-=-
 Bob Sutterfield, Department of Computer and Information Science
 The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob