Subject: Confusing Confusion with Technical Issues

From: <[email-masked]>
Date: Wed, 20 May 87 05:50:33 EDT

From: <[email-masked]>
Date: Mon, 18 May 87 14:11:07 -0400

In Mr. Scheifler's rejoinder to my note criticizing X, he accuses
me of being badly confused as to what X really is.  Maybe that
is so, probably because I can't figure out what it is - it doesn't
seem to do anything I want to do, so I admit having trouble
understanding it.  Oh I understand what various groups pruport
it to do, but being an active user of a true window-based
platform of a different type, I cannot for the life of me understand
what X does that I'm remotely interested in, EXCEPT run across
networks.  As a  person interested in building programs with
good interfaces, it doesn't seem to supply a toolkit, instead
it provides several, all incompatible.  It doesn't seem to supply
any particular model for building such interfaces, instead, it
provides support for unbounded excess creativity.  In remote,
isolated "research environments," and places which must support
epistemologically incompatible window paradigms, this universality
is probably useful.  For building anything approaching a "product,"
i.e., something you can get paid for writing and someone else
being willing to use, it is inappropriate.  One other person
suggested that X was indeed salvation for my complaint about
not liking chording, etc., because you could CHANGE IT ALL!!

What this will produce is a "portable" "environment" which
is equally unusable no matter where you find it.  This is what
I call "the EMACS effect."  Eveyone can use it on THEIR machine,
with THEIR customization file, but nowhere else (do YOU
understand hyperbole?).

As for Mr. Scheifler's comments about everyone adopting X for
different reasons, the real reason is that none of the other
vendors wanted SUN's name on TWO Unix standards, so when X
came along and it seemed competent, ZAP!!  Everyone and their
dog announced support for X.  By Mr. Scheifler's own comments,
noone really knows what that means, and everyone wants to improve it,
but everyone is supporting this "Industry Standard." At Uniforum in
Washington in January, 11 companies "announced support" for X.
I know a fait accompli when I see it.

So, as technologists are wont to do, it would seem that
Mr. Scheifler is confusing technical issues with the real
forces that shape the world (read marketplace).  These
are not decisions based on reason.  If so, people would
be spending time writing user interface guidelines so
random programmers won't inflict their utter lack of
taste and aesthetics on Users (ie, the paying customers),
instead of running off and building all this stuff bottom-up
from the implementation.

Besides, if technical issues mattered a whit, noone would
be running System V. (grin...)

	"Quick Sherman, the asbestos!!"

	-Mike O'Dell
	abort-and-stay-resident sage and curmudgeon

---

From: [email-masked] (Ken Yap)
Date: Wed, 20 May 87 18:14:26 EDT

Date: 20 May 87 14:35:21 GMT
From: [email-masked]  (Ken Yap)

I don't know Mike. Would you say that something like Unix is doomed to
fail because it doesn't support many high level user oriented
constructs? DR himself said Unix (V7 at least) was a glorified I/O
multiplexer, and that was as it should be.  No, I didn't think you
would.

I think you're confusing the X that you can ftp with the X that vendors
are working on. There is no reason a vendor couldn't throw out the
entire set of X toys and write their own. The Sun X that we run has so
many annoying problems that I wouldn't dare call it a product. But it
is free, which is all us poor educational institutions can afford.

Summary: X supplies mechanism, you can program your own style of user
interface. I don't think Athena wants to get involved with the
religious issues of the sort "one button vs three".

	Ken

---

From: [email-masked] (Jim Fulton)
Date: Thu, 21 May 87 23:59:38 EDT

Date: 21 May 87 20:50:53 GMT
From: [email-masked]  (Jim Fulton)

>            As a  person interested in building programs with
> provides support for unbounded excess creativity.

Probably one of the main reasons why X is (and NeWS will hopefully become) so
popular in the industry is that it DOESN'T inflict any particular UI model.
The canon that a window system should provide "mechanism, not policy" isn't
just a cliche.  Toolkits are a powerful and necessary mechanism that X needs
(and will have) for building USER INTERFACES, but they by no means should
define the way in which one writes applications that use the window system.

> came along and it seemed competent, ZAP!!

I'll assume that this is refering to NeWS and that is meant to be taken
seriously.  Many companies had decided that The X Window System was valuable
well before Sun announced NeWS (I personally picked up our copy of the X.V6
tape two years ago, back when one actually had to sign a license agreement to
get X).  Regardless of the technical issues, the simple matters of

	o cost ($25000 vs. $100),
	o time (X has been available for development use longer),
	o proven portability, and
	o ownership (changes in X through V10 were done primarily by MIT; X11
		was designed in concert with a number of manufacturers and
		MIT has repeated stated its desire to get out of the window
		system business)

make it not very surprising that a lot of companies are supporting X11.  If Sun
does a good job on their NeWS/X11 port and addresses these issues I suspect
that NeWS will become a very popular path for upward-compatible growth within
the industry.

There are clearly more ill-designed user interfaces around than there are
well-designed ones.  But if part of your product's appeal is its UI then you
had better make sure you put more effort into it than just letting a couple of
random programmers hack up something that they feel is adequate.  Whether or
not you have complicated libraries of widgets you still need good artists and a
feel for the perspective of the intended user.

Excellent, commercial user interfaces can be and have been implemented on top
of X.  Under X11 it will be much easier, and under NeWS/X11 it may well be
easier still.

							Jim Fulton
							Cognition Inc.
                                                        900 Tech Park Drive
uucp:  ...!{mit-eddie,talcott,necntc}!ci-dandelion!jim  Billerica, MA  01821
arpa:  [email-masked], [email-masked]         (617) 667-4800

---

From: [email-masked] (Gilbert Cockton)
Date: Wed, 27 May 87 14:17:03 EDT

Date: 22 May 87 18:04:54 GMT
From: [email-masked]  (Gilbert Cockton)

In article <[email-masked]> [email-masked] writes:
>understanding it.

Poor old Mike, hit again by the technological tendency to go 'IS-ing'
all over the place. The one blessing which people from non-technical
backgrounds have is that they learn pretty quickly that

		THINGS AREN'T

Thus one cannot possibly misunderstand what X IS, as it is not a
monolithic entity with an uncontroversial god-given essence. One can
misunderstand how it works, but this is often a good indicator of
inelegant design. Mike and the MIT crowd just have different interpretations
of what a windowing system is about. The situation seems to be further
confused by mixing up what a window system SHOULD be (i.e. inter-subjective
expectations of functionality) with what the guys who were making X thought they
were doing. Start with prescriptions ---

>.........  As a  person interested in building programs with
>provides support for unbounded excess creativity.  ..........

Mike thinks that a windowing system should have design requirements
based on a proper analysis of user interfaces. So do I. I'd also lay a
few pounds that IF someone knows what windows are in a computing
environment, THEN they will see them as primarily something to do with
interaction. Not so the MIT respondents -- here's what they think X is --

>Oh I understand what various groups p
rport
>it to do, .................... I cannot for the life of me understand
>networks.

Now have we got that - the main design requirement for a windowing
system is that it runs on networks. Forget everything else :-)
Sure, we can fix the user interface bits later.

>..........................................  One other person

As someone with a strong interest in adaptable user interface
abstractions, I'll lay a few more pounds that you can't CHANGE IT ALL
via profiling or parameter files. There will be some things in X which
constrain ALL user interfaces which would like to team up with it.
If someone can mail out a formal spec, we can have a look for
hard-wired features which affect the user interface.

>instead of running off and building all this stuff bottom-up

This is the surest way to get user interface support software wrong.
Programmers who are ignorant of dialogue design guidelines will not
know when they are hard-wiring in interaction-style dependencies.
Profiling files which don't let you at every parameter are bound to
restrict you.

In article <[email-masked]> [email-masked] (Ken Yap) writes:
>multiplexer, and that was as it should be.

Yes, V7 was an inadequate I/O multiplexer. It had blocking I/O and
that makes it hard (nay impossible?) to program certain interaction
styles. The old tty interface also makes a lot of 4.2 tricks
impossible. Even 4.2 could be improved - how about arbitrary binding
of input device events to arbitrary signals >32 (say) and <255?
Then Sun's SIGWINCH's and SIGMOUSE would have fitted into a std
kernel. These are NOT HIGH LEVEL constructs, so don't fall into the
trap of thinking that user interface design is so high level that the
OS doesn't affect it. There's one big firm that makes machines that
don't do character-level I/O. I bet they didn't see need for this very
high level user interface abstraction :-)

>religious issues of the sort "one button vs three".

Shame - the fact is that you cannot duck these style issues. Unless
the range of options in user interface design is understood by the
software designers, they'll not know when they're trading off ease of
future user interface programming for ease of hacking their user
interface toolkits. Ever seen a hammer designer who doesn't understand
nails, wood or the human arm? Software tools implementation is full of such
people.

P.S. the trivialisation of serious ergonomic issues to "religious"
bickering is another mark of the technical mentality - nothing like a
difficult, knowledge intensive, empirical, open-ended, concept-intensive
unresolved problem for sending the technophiles scurrying off to their
workbenches and pretending there's no BEST answer so ANY one (i.e.
theirs!) will do.  Could it be that the arch hacker has the lowest possible
closure threshold for intellectual debate and reasoned decision making
in a noisy environment? :-)
--
   Gilbert Cockton, Scottish HCI Centre, Ben Line Building, Edinburgh, EH1 1TN
   JANET:  [email-masked]    ARPA:   [email-masked]
		UUCP:	..!{backbone}!aimmi.hw.ac.uk!gilbert

---

From: [email-masked] (Ken Yap)
Date: Wed, 27 May 87 14:18:46 EDT

Date: 27 May 87 16:24:24 GMT
From: [email-masked]  (Ken Yap)

|Shame - the fact is that you cannot duck these style issues. Unless
|the range of options in user interface design is understood by the
|software designers, they'll not know when they're trading off ease of
|future user interface programming for ease of hacking their user
|interface toolkits. Ever seen a hammer designer who doesn't understand
|nails, wood or the human arm? Software tools implementation is full of such
|people.
|
|P.S. the trivialisation of serious ergonomic issues to "religious"
|bickering is another mark of the technical mentality - nothing like a
|difficult, knowledge intensive, empirical, open-ended, concept-intensive
|unresolved problem for sending the technophiles scurrying off to their
|workbenches and pretending there's no BEST answer so ANY one (i.e.
|theirs!) will do.  Could it be that the arch hacker has the lowest possible
|closure threshold for intellectual debate and reasoned decision making
|in a noisy environment? :-)

Tsk. You read far too much into a single word "religious". I am not
suggesting ducking the issues or trivializing them. I'm am certainly
not suggesting that X is the last word in windowing systems.

Your example of what V7 lacks is just the right point.  The
improvements came after experience had been accumulated and
shortcomings exposed.  If Ritchie and Thompson had argued about styles
of command interpreters instead of providing a basic mechanism and
leaving that decision to a different, *higher* level, Unix would not
have seen the light of day.

Unless one believes that it is impossible to have layered
implementations, that a single designer has to have every skill under
the sun rolled in to even begin to start on the problem, instead of
having people from various disciplines divide the problem into
manageable pieces and refine the overall design by discussing
problems.

In other words, if one believes <favourite window system> fails to
provide the *mechanism* for implementing <favourite interface style>,
then one should speak up so that future designers know what to work
on.

	Ken

PS: It always looks silly to make sweeping statements about the
characteristics of a class of people in a single paragraph, smiley face
notwithstanding.  It just degenerates to ad hominem mud slinging.