mo@maximo.UUCP (05/16/87)
From: <seismo!maximo!mo@mimsy.umd.edu> Subject: NeWS and X Date: Fri, 15 May 87 08:16:27 -0400 X is fast???? Give me a break. I just saw News and X running side by side, News on a 160 and X on a 260. News was just as fast if not faster. In particular, try to do the rubber-band-line tracking trick with X. Putting the interaction smarts next to the display has much to say for it - mostly all correct. This has been proven time and again in other situations. Why is it some people insist on reinventing square wheels?? MOREOVER - the Sun mouse already has 2 too many buttons,(*) but can X do anything with just the mouse? NOOOOOOOOO!!!!! You gotta drive the damn thing with BOTH HANDS!! One playing the mouse, and the other playin chords on the damn control-shift-meta-cokebottle keys!! Jeeeeeezzzz!! What a complete crock of flaming feces!! I have never seen anything as user fiendly as that. It simply sucks molten lava. Why is it that anyone who thinks they understand TECO and/or EMACS can build a user interface??? I got big news for them. If X becomes the defacto window standard for window systems you can completely kiss-off the real commercial marketplace. It completely fulfills everyone's worst fears and nightmares about UNIX. The simple fact is that designing REALLY GOOD user interfaces is astonishingly hard, probably as hard as designing fonts, and simply being able to hack your favorite programming language is neither necessary nor sufficient. Anyone anywhere attempting to write "window-based software" who doesn't spend a long time studying the Apple Macintosh User Interface Guidelines before even thinking about their design is simply wasting their time. I am not claiming the Mac interface is perfect, but before you make any claims about knowing anything about what is going on with user interfaces, you better well deeply understand all the issues, tradeoffs, and decisions that when into formulating those guidelines, otherwise you are fooling yourself. I have never yet seen any really window-based software on any UNIX window system, possibly excepting the BLIT, but even then, only barely. I have seen lots of glass-ttys with options and widgets that make TECO and EMACS look like smooth-surfaced spheres. Only when the UNIX folks realize that, in fact, they really don't know crap about what windows are good for and will take a look at a system with tons of extremely consistant, truly window-based software will we ever see UNIX window systems that are worthy of the name. I guess we have to wait for A/UX on the MacII. Flamin' away, as usual, -Mike O'Dell (*) O'Dell's observation on mouse design - An N button mouse has N-1 too many buttons. PS - Thought for the day: "X does for UNIX what Berkeley did for ls(1)."
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (05/17/87)
Date: Sat, 16 May 87 11:08 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: NeWS and X
To: seismo!maximo!mo@mimsy.umd.edu, NeWS-makers@brillig.umd.edu
X is fast???? Give me a break. I just saw News and X
running side by side, News on a 160 and X on a 260.
News was just as fast if not faster.
It is amazing how silly people can be. Trying to make blanket
statements about X or NeWS is stupid to begin with, but comparing an
unsupported non-product with a supported product is less than sensible.
In particular,
try to do the rubber-band-line tracking trick with X.
The effect was virtually instantaneous on and between GPXes, last time I
tried it. Of course, the Sun port is less than adequate in this area
(due to a mismatch between what the vanilla X10 server would like to see
for a kernel interface and what the Sun kernel provides), but we
wouldn't want a reality like that to affect our unbiased opinion, would
we?
Why is it that anyone who thinks they understand
TECO and/or EMACS can build a user interface???
I got big news for them. If X becomes the
defacto window standard for window systems
you can completely kiss-off the real
commercial marketplace. It completely
fulfills everyone's worst fears and nightmares
about UNIX.
It is easy to lump lots of different things into the collective "X" and
then dump on it, just as so many do with "Unix", "AI", etc. At the
lowest level, X Version 11 has very little to say about "user
interface". And if you ask various vendors who have "endorsed X"
exactly what they mean, you will get very different answers. To most it
appears to mean standardizing on a lowest level (non-UI) C programming
interface and a network protocol. Others only care about the
programming interface, or only the network protocol. Others want to
standardize on a C toolkit. Off-hand, I don't know of ANY company
endorsing existing V10 (or V11) user interfaces as standards, and
certainly there are companies that are off doing their own thing here.
That is one reason WHY vendors are backing the X protocol: it doesn't
unduly restrict them in terms of user interface. [All of this is
probably just as applicable to NeWS.]
I am not claiming the Mac interface is perfect,
but before you make any claims about knowing
anything about what is going on with user
interfaces, you better well deeply understand
all the issues, tradeoffs, and decisions that
when into formulating those guidelines, otherwise
you are fooling yourself.
The same, of course, applies to claims about network-based virtual
console protocols, like X and NeWS.
Only when the UNIX
folks realize that, in fact, they really don't know
crap about what windows are good for and will take a
look at a system with tons of extremely consistant,
truly window-based software will we ever see
UNIX window systems that are worthy of the name.
The fact that you seem to view "X" as somehow synonymous with "Unix
window system" is just another indication that you are confused.putnam@thuban.steinmetz (putnam) (05/18/87)
In article <870516110816.9.RWS@KILLINGTON.LCS.MIT.EDU> RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) writes: > X is fast???? Give me a break. I just saw News and X > running side by side, News on a 160 and X on a 260. > News was just as fast if not faster. > >It is amazing how silly people can be. Trying to make blanket >statements about X or NeWS is stupid to begin with, but comparing an >unsupported non-product with a supported product is less than sensible. Enough already! XV11 isnt really out there yet, and NeWS is just getting out. For months in various places we have been listening to the NeWS vs X bashing and flaming and yelling and screaming and .... There is much to be said for both systems, but we cant decide which is better yet - we just dont have enough experience. Furthermore this kind of emotional battle line setting is only clouding our ability to make reasonable technical judgements. I think the thing to do now is for all of us to try playing with both systems and building some large applications in them. Then maybe we can get together and talk about whats good and whats bad in a year or so. Is it unreasonable to suggest that there might be a better system that builds on the strengths of both NeWS and X that might succeed them? Then lets find out what the good and bad points are of both systems and think about what we might want next. (Interestingly, i would note that i have heard from at least two sources the rumour that Sun might be building their next version of sunview on X rather than on NeWS. Can anybody confirm this?) Well, shall we go? -- jefu (jeff putnam) Yes, lets go. -- UUCP: steinmetz!putnam (They do not move.) -- ARPA: putnam@ge-crd.com
steven@pearl.berkeley.edu (Stephen the Greatest) (05/18/87)
This reminds me of an article I read somewhere (DECPRO? UNIX-WORLD? ???) which compares X with NeWS. X is like vi while NeWS is like EMACS, which I think is a pretty neat analogy. Personally, I like vi and X, but there are people who want flexibility and functionality. - Stephen
chan@hpfcmp.HP.COM (Chan Benson) (05/20/87)
> but can X do anything with just the mouse? > > NOOOOOOOOO!!!!! You gotta drive the damn thing with > BOTH HANDS!! One playing the mouse, and the other > playin chords on the damn control-shift-meta-cokebottle > keys!! Jeeeeeezzzz!! What a complete crock of flaming > feces!! I have never seen anything as user fiendly > as that. It simply sucks molten lava. You obviously know not that which you flame so vehemently. X itself does not dictate any particular human interface (window manager in the X parlance). Users are free to write their own. If you're so hot on the Mac interface, you can write a similar one that will work on an X system. Someone's probably writing one right now. Most X distributions include several window managers, one of which is uwm, probably the one you are flaming. And believe it or not, you *can* easily set up your .uwmrc file to let you manipulate windows without having to use keyboard shift keys. Why don't you take some time to learn about things before you splash your ignorant ravings on the net. -- Chan Benson Hewlett-Packard Fort Collins, CO {hplabs|ihnp4}!hpfcla!chan
greg@CITI.UMICH.EDU.UUCP (05/20/87)
From: greg@citi.umich.edu Date: 18 May 1987 02:36 EDT Subject: NeWS and X > A friend of mine said that AI group at MIT is never going to be running > NeWS on many workstations. One of the reasons he gave was that X will > always be at least a factor of 3 faster than NeWS. > > I started thinking about all of the atoi() that news always has to do, > and the fact that it is interperted, and am beginning to think that he > might be right. Is there any truth to this? REGARDING atoi(): ----------------- PostScript programs are simply an ascii datastream. NeWS gains performance improvements by checking the high bit of the its incoming datastream. If its just straight PostScript, no problem NeWS parses it. If the datastream happened to be generated from a smart NeWS client, the high bit will be set on a byte. The remaining 7 bits will clue the NeWS server as to what token this byte should represent, or what to expect within the next few bytes. ie. get ready for a character string server, here is how long it is. A C function called pprintf is provided with NeWS. This provides the equivalent of printf in the C library, but implements the format described above for sending data to the NeWS server. If you really have a performance critical client, pprintf can be replaced with a few macros which implement the NeWS compression format. I did this for a terminal emulator, because after profiling I found that pprintf was taking as much time as my code which interpreted the terminals escape code sequences. REGARDING interpretation overhead. ---------------------------------- I think the overhead will be much less noticeable on machines with no graphics assist. In this case the cycles spent on rasterization will become more important. NeWS versus X ------------- I have done both a mono and color NeWS port to Apollo workstations, and am In the middle of a port of a port of X10 for a Parallax videographics card. Which doesn't mean anything besides the fact that I've looked at the source and have examined a few ports. I agree completly with the comments of Guy Harris: > If the claim is made that X is now at least a factor or 3 faster than > NeWS, the only way to ascertain whether this claim is true or false > would be to test it with a given application or set of applications. > Does anybody have this sort of data? With the added stipulation that not only are multiple applications tested, but that they should be tested on multiple server ports. Personal Prejudices ------------------- From what I've seen of X11 source, I believe it will outperform NeWS by a wide margin on machines with graphics assist. But, I've been bitten by the NeWS bug, and no amount of performance data is going to change my mind. PostScript is nice to work with when developing user interfaces. I only hope that SUN will release the combined X-NeWS server into the public domain once it is completed. -greg
derek@nbires.UUCP.UUCP (05/20/87)
Date: Tue, 19 May 87 08:10:38 mdt From: umcp-cs!seismo!hao!nbires!derek (Derek Fluker) The Mac does have a very good user interface but if you have used and/or programed under MS/Windows you will not that they did an equally fine job if not better. They provide facilities and standards that allow for driving the system with the keyboard OR mouse OR both on an equal and consistent basis. The Mac does lack this ability. Yes, there are people in this world who perfer a key based interface and task that are done more efficiently with one; so supporting both equally is the proper route, especially in the commercial marketplace. When driving certain types of mouse based interfaces, it is often less efficient to only have one mouse button. This is often requires more motor actions from the user to perform actions needed to switch between context. As an example of this look at the many Mac programs that put glyphs on the screen to denote which mode the user is in (MacPaint and MacDraw have glyphs on the left hand side that denote what operation the user is allowed to perform; what mode he is in. This requires constant moving over an pressing the glyphs to change allowable operations.) If the number of number of descrete mode need is three or less, is it not better to asign them to specific mouse buttons allowing the user to change context with a minimal amount of motor action?
gilbert@aimmi.UUCP (05/21/87)
In article <8705151216.AA00774@maximo.uucp> version B 2.10.2 9/18/84; site aimmi.UUCP aimmi!hwcs!its63b!ukc!mcvax!seismo!rutgers!ames!ucbcad!ucbvax!maximo.UUCP!mo mo@maximo.UUCP writes: >Why is it that anyone who thinks they understand >TECO and/or EMACS can build a user interface??? >I got big news for them. If X becomes the >defacto window standard for window systems >you can completely kiss-off the real >commercial marketplace. It completely >fulfills everyone's worst fears and nightmares >about UNIX. > >The simple fact is that designing REALLY GOOD >user interfaces is astonishingly hard ... and simply being >able to hack your favorite programming language >is neither necessary nor sufficient. Hear, hear - I go along with much of your flaming, but from past experience of the USENET milieu, I think your comments will fall on stoney ground. Despair not, most commercial users don't get UNIX systems. Those who do are increasingly getting a cleaned up proprietry shell thrown in by the suppliers. Cleaning up hackers' user interfaces is a profitable sideline for some firms, so don't make too much noise about the ergonomic incompetence of the average unwashed UNIX guru - you could wipe out a tidy little market if they got wise :-) -- 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
paul@osu-eddie.UUCP (05/21/87)
In article <8705151216.AA00774@maximo.uucp> mo@maximo.UUCP writes: >From: <seismo!maximo!mo@mimsy.umd.edu> >Subject: NeWS and X >Date: Fri, 15 May 87 08:16:27 -0400 > >MOREOVER - the Sun mouse already has 2 too many buttons,(*) >but can X do anything with just the mouse? See below... >NOOOOOOOOO!!!!! You gotta drive the damn thing with >BOTH HANDS!! One playing the mouse, and the other >playin chords on the damn control-shift-meta-cokebottle >keys!! Jeeeeeezzzz!! What a complete crock of flaming >feces!! I have never seen anything as user fiendly >as that. It simply sucks molten lava. Actually, this is not true. I have re-configured my X setup for just-plain-left button (in root) to give me menus. On the other hand, I would **LIKE** to have my window system be able to tell the difference between a window title bar, the window, an icon, etc. A beginning user, however, dosn't know this. 8-( Also, I believe (and have good reason) that the window system should impose a set of standard window types that a programmer can get around only with a LOT of work. The idea being that the standard window types are just that: STANDARD and UNIFORM. Also no one, not even Richard Stallman, should write things with non-standard windows just because they don't like the way the standard ones work. If this person isn't God, they won't know all of the reasons why that standard window was set up that way!!! If a programmer can change the STANDARD for her environment, however... 8-) >Why is it that anyone who thinks they understand >TECO and/or EMACS can build a user interface??? They don't!!! Look at GnuEmacs. I use it, but only because (1) it is far better than vi, and (2) I learned it before I knew anything about writing my own. >The simple fact is that designing REALLY GOOD >user interfaces is astonishingly hard, probably >as hard as designing fonts, and simply being >able to hack your favorite programming language >is neither necessary nor sufficient. Anyone >anywhere attempting to write "window-based >software" who doesn't spend a long time >studying the Apple Macintosh User Interface >Guidelines before even thinking about their >design is simply wasting their time. >I am not claiming the Mac interface is perfect, >but before you make any claims about knowing >anything about what is going on with user >interfaces, you better well deeply understand >all the issues, tradeoffs, and decisions that >when into formulating those guidelines, otherwise >you are fooling yourself. YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES !!!! In some cases, before a PROGRAMMER writes a user-interface, they should talk to a PSYCHOLOGIST about learning, ease of use, contexts, etc. Look at _Fundamentals_of_Human-Computer_Interaction, ed. Andrew Monk Academic Press 1985, ISBN 0-12-504580-8 (hardcover), 0-12-504582-4 (pbk.) >I have never yet seen any really window-based software >on any UNIX window system, possibly excepting the BLIT, >but even then, only barely. Look at Xtrek, SDI, and other games. It's funny how the games lead other programs for nice (or at least good attempts at) user interfaces. 8-( > Flamin' away, as usual, > -Mike O'Dell And in turn... -- Paul Placeway Department of Computer and Information Science SNail: The Ohio State University 2036 Neil Ave. Columbus OH USA 43210-1277 ARPA: paul@ohio-state.{arpa,csnet} UUCP: ...!cb{osgd,att}!osu-eddie!paul >(*) O'Dell's observation on mouse design - > An N button mouse has N-1 too many buttons. Placeway's observation (based on my experience, and other peoples' experience, including psychological experiments): The correct number of buttons for a mouse is a small finite number, GREATER THAN ONE, but less than four. This is because an _exper- ienced_ user wants to have more control then just a single click (ie. Apples (1) click, (2) double-click, (3) shift-click, etc. which corrispond to (1) Left, (2) Middle, and (3) Right buttons), but not so many that she has to use one finger for more than one button. Since humans generally have 5 fingers, 3 is a practical limit. -=- -- Paul Placeway Department of Computer and Information Science SNail: The Ohio State University 2036 Neil Ave. Columbus OH USA 43210-1277 ARPA: paul@ohio-state.{arpa,csnet} UUCP: ...!cb{osgd,att}!osu-eddie!paul
bobr@zeus.TEK.COM (Robert Reed) (05/21/87)
In article <8705191410.AA00489@milo.NBI.COM> derek@nbires.UUCP (Derek Fluker) writes:
... many Mac programs ... put glyphs on the screen to denote which
mode the user is in (MacPaint and MacDraw have glyphs on the left hand
side that denote what operation the user is allowed to perform; what
mode he is in. This requires constant moving over [and] pressing the
glyphs to change allowable operations.) If the number of [discrete
modes needed] is three or less, is it not better to [assign] them to
specific mouse buttons allowing the user to change context with a
minimal amount of motor action?
A set of applications running on a windowed system is rarely limited to
three distinct operating states. If there were only three that you ever had
to deal with, then such an approach might be reasonable. However, as soon
as you go over three, you are stuck in the same situation as the Mac with
one button--you must be able to reassign the function of a mouse button (or
buttons) on user demand. If button functions change, then you must still
represent the current state in some way, such as the way the Mac does it.
There is a little more subtlety to be considered here. The Mac mouse button
is actually at least bi-functional in that it is sensitive to certain
regions of the display, and when invoked in those areas operates at a higher
level to effect a change of function. Outside these areas, button events go
to the function currently invoked. On three button mice, even if there were
only three distinct functions required, the mental exercise of remembering
which button does what is too much to expect of the casual user. Such a
system would still require some display (even if it is labels on the keys)
to act as a reminder for the functionality of the application.
A more conventional solution with mouse buttons is to assign some generic
operation to each which does not vary despite the number of available
functions. The smallTalk example of left = select, middle = local popup,
right = window manager popup, is typical of the assignment choices made.
The usefulness of an interaction scheme where the selection of a menu symbol
then causes the symbol to be highlighted, is not limited to environments
where you have access to only a single mouse button. In particular, use of
a three button mouse does not nullify the value of this technique.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKshs@vanhalen.rutgers.edu (Steven H. Schwartz) (05/22/87)
> Anyone >anywhere attempting to write "window-based >software" who doesn't spend a long time >studying the Apple Macintosh User Interface >Guidelines before even thinking about their >design is simply wasting their time. Are these guidelines available on the net, say by ftp? -- If G-d had wanted man to eat shellfish, He would have created self-opening clams with pop-tops. Steven H. Schwartz (201) 846-9185 ARPA: shs@paul.rutgers.edu (201) 932-4714 UUCP: ...seismo!rutgers!paul!shs
langdon@lll-lcc.aRpA (Bruce Langdon) (05/23/87)
In article <8705180645.AA08543@brillig.umd.edu>, greg@CITI.UMICH.EDU writes: > > ... NeWS gains performance > improvements by checking the high bit of the its incoming datastream. > If the > datastream happened to be generated from a smart NeWS client, the high > bit will be set on a byte. The remaining 7 bits .... Hey, looky here! Information about NeWS innards in comp.windows.news! ---------------------------------------------------------------------- Bruce Langdon L-472 langdon@lll-lcc.ARPA Physics Department "langdon#bruce%d@lll-mfe.ARPA" Lawrence Livermore National Laboratory Livermore, CA 94550 (415) 422-5444 UUCP: ..{ihnp4,qantel,ucdavis,pyramid,styx,topaz}!lll-lcc!langdon ..{gymble,ll-xn,seismo}!lll-crg!lll-lcc!langdon