Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!mcvax!ukc!its63b!hwcs!aimmi!gilbert From: gilbert@aimmi.UUCP Newsgroups: comp.windows.news Subject: Re: Confusing Confusion with Technical Issues Message-ID: <29@aimmi.UUCP> Date: Fri, 22-May-87 14:04:54 EDT Article-I.D.: aimmi.29 Posted: Fri May 22 14:04:54 1987 Date-Received: Fri, 29-May-87 00:40:25 EDT References: <8705181811.AA05417@maximo.uucp> Reply-To: gilbert@aimmi.UUCP (Gilbert Cockton) Distribution: world Organization: Heriot-Watt/Strathclyde Alvey MMI Unit, Scotland Lines: 105 In article <8705181811.AA05417@maximo.uucp> mo@maximo.UUCP writes: >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. 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 >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. .......... 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 purport >it to do, .................... I cannot for the life of me understand >what X does that I'm remotely interested in, EXCEPT run across >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 >suggested that X was indeed salvation for my complaint about >not liking chording, etc., because you could CHANGE IT ALL!! 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 >from the implementation. 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 <27924@rochester.ARPA> ken@rochester.UUCP (Ken Yap) writes: >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. 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 :-) >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". 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: gilbert@uk.ac.hw.aimmi ARPA: gilbert%aimmi.hw.ac.uk@cs.ucl.ac.uk UUCP: ..!{backbone}!aimmi.hw.ac.uk!gilbert