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