jrg@Apple.COM (John R. Galloway) (05/22/88)
background:
I have been a Unix & X window user for about 2 years (unix under ISI's
window system for about 6 months before that). The system I use (at home as
a consultant) is an AT with a coprocessor on which I run Sys V.3 (from Opus
Systems) and has a 19" high res mono display. I can also run DOS and hence
MS-windows which also uses the high res display (from moniterm). Not being
able to get my hands on good word processing under the Opus Unix sysetm (like
interleaf, frame, etc.) I switched to MS-windows under dos for wp stuff.
** FLAME ON **
The overall experience of using MicroSoft Windows after Unix & X is
one of complete disgust. This is a toy system. I have heard people comment
on DOS that it seems like it was written by a few undergraduates for a not
so well taught OS-101 class. Well those that did not pass the class must have
decided to write MS-windows. Its user interface sucks, the environemt it
supplies sucks. the whole thing has left me with a great desire to vomit on
my keyboard.
** FLAME OFF **
Comments on Micro Soft Windows 2.1
POOR COMMAND INTERACE. Yes it is graphical, but only in that DOS like
commands can be "typed" with the mouse. i.e. to delete a file your
choices are:
via mouse
- click on the filename (optional)
- click on the FILE pulldown menu
- drag to the delete entry
- get a dialogue box which has either an empty filename or
if you have selected (by clicking on) the name of a file
before pulling down the FILE menu, then that name is in
the filename spot in the dialogue box.
- edit the filename with cursor keys, etc. if needed
- click on the OK (or perhpas it says YES) box
via keyboard
- type first letter of file until it is selected (optional)
- ALT
- F
- D, now same dialogue box apperas
- hit enter (enter is always the same has clicking on the highlited
button, in this case the OK or YES button).
Now correct me if I am wrong (as if you all need encourgement :-) but that
does NOT seem shorter, or easier, or anything then just typeing "rm file"
and is certainly not as easy or intuitive as grabbing the file with the mouse
and hauling it off to the trash can. i.e. putting the command line commands
into menus is not much of a graphical interface, its juts commands in menus.
POOR APPLICATION ENVIRONENT. I am not too familiar with the worms eye view
(from the application out) but the birds eye view (from the user in) is
very sparse. You can put itmes in your startup file to say which applications
you want started up and specify a few defaults like system wide border size
and color but that is about it. The biggest hit seems to be a lack of
position and size info (ala standard X geometry specs). So everytime you
start up an application it uses its default size wich is usually the whole
screen. The same holds true for all the rest of the resources/default values
that you can specify in X, nothing like it exists in MS-windows.
POOR WINDOW MANAGEMENT. One of the things I lke about the X uwm window
manager (although many feel otherwise) is the use of keyboard and
mouse combinations e.g. to move a window I need only be in the window and
hit (with my .uwmrc file) ALT + right button to drag the window, ALT + middle
to change its size, etc. All such items in MS-windows are based on being in
a particular spot on the window (in the border to change its size, in the
title to move it). Further there appears to be no way to move a window to
the bottom of the desktop, which is a big missing item especially given that
most applications seem to take have very large default windos that obscure
everything else on the desktop. To see other applications you have to always
resize or iconify.
POOR DIALOGUE BOXES. There are a million (ok maybe only 20 or 30) dialogue
boxes that keep poping up to ask "ARE YOU SURE?" and so on. This would not
be so much of a pain if the box was positioned correctly so that the default
button (the one highlited and clicked by hitting the enter key) was
positioned under the mouse. Since the various dialogue boxes all seem to
have fixed positions, this is never the case hence requireing much mouse
movement. Again it is more of a command line interface put into windows
then a window interface. I would suggest in the general area that any item
in a menu that has subsequent dialogue boxes should be equiped with a
command button off to one side of the menu button, but IN it. Then if I
select print but am not within prints inner command button, it just prints.
If I select print AND do so by being in the command button it goes through
all the questions. Thus 90% of the time I need not pay for the hassel of
going through options that I only need occaisionally.
MICRSOFT WRITE. Any supposedly WYSIWYG window oriented editor that does not
allow multiple rulers is a toy. enough said.
FILENAME EXTENSIONS. MS-windows keys off of filename extensions to chose
what application to run. Thus you can click on foo.wri which was written by
MS-write to run MS-wite with foo.wri opened. Well it sounds good but the
applications do not "see" files without their extensions. So for example if
importing a raw text file into MS-write, you must name it with a .wri extension
for MS-write to be able to open it. But the format is checked anyway and you
are asked if you would like to convet it (more dialogue boxes). It all seems
to be a very half baked idea, no maybe only a quarter baked.
PRINTERS AND FONTS. A very anoying item is that the printer state is not
maintained with documents. Hence if I setup for landscape mode under
Excel and forget to change back when I print a document from MS-write it
will come out in landscape mode. This is just silly. MicroSoft Excel by
the way is a WONDERFUL program (though I hear it is much faster on the Mac).
With regard to fonts, sigh, I could not afford a Apple Laserwriter II/NT so I
got a HP Laserjet II. Then I got a font maker program called Glyphix that
uses some sort of font definitions (same idea as adobe) and allows you to
make downloadable Laserjet fonts (specifing line thickness, slant, one of
four typefaces, point size, etc.). Then you take that down loadable font
and run it through a MS-windos program (PCLPFM) that allows it to be used
for printing by MS-windows programs. At this point editors are WYSIAWYG
(..Almost..) as the font sizes are known and sentences end at the right
word, but the screen fonts do not match the printer fonts. To get to this
last step you need yet another utility that converts HP downloadable fonts
into MS-windows screen fonts. Then you have a line for each font (note
that helv 10pt portrait, helv 10pt landscape, helv 10pt portrait bold, helv
10 pt landscape bold.. are each a seperate font) in your statup file. The
documentation on how all this works is very poor. MS-wirte does manyage to
corretly use the right font when I specify boldness, but I just guessed at
what I should call it and do not know what would happen if I had light,
medium, and bold fonts rather than just two. This isn't seamless, the pieces
are not even on the same table let alone stiched together. Perhaps a
postscript printer would have made it all work. It also might have worked
better if I just used HP font cartridges instead of soft fonts, but at
about $300 per cartridge that each contain about 8 fonts (not 8 typefaces
but 8 specific fonts (e.g. 10pt Roman bold), and $100 for the glyphix set
there was not much choice (I got the Laserjet for price after all).
Even if a good word processor was available (WinText from Palantir looks
interesting though I am not sure I am up for putting more money into this
project) the MS-windows environment and that of DOS has just done me
in. I will stick to Unix and X for everything but using the Excel spread
sheet and hope to later get a workstation that is supported by one of the
good word processing products. Perhaps novice users find MS-windows
appealing (I have been in computers for about 18 years now) but I VASTLY
prefer the open, customizable, lots of connectable tools, environment of
Unix and X (I think I would like some of the Mac and A/UX environments as
well, though my mimimal Mac experience seems to indicate that Mac/OS has
some of the same problems).
Perhaps it was asking to much to think that MS-windows might make DOS an OK
system, it does not. Some of the applications are very nice on the inside,
but the world they live in is a slum.
--
apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca
These are my views, not Apple's, I just get my mail here.wnp@dcs.UUCP (Wolf N. Paul) (05/23/88)
In article <10799@apple.Apple.Com> jrg@Apple.COM (John R. Galloway) writes: >Comments on Micro Soft Windows 2.1 >POOR COMMAND INTERACE. Yes it is graphical, but only in that DOS like >commands can be "typed" with the mouse. i.e. to delete a file your >choices are: > (long description deleted) >Now correct me if I am wrong (as if you all need encourgement :-) but that >does NOT seem shorter, or easier, or anything then just typeing "rm file" >and is certainly not as easy or intuitive as grabbing the file with the mouse >and hauling it off to the trash can. Yes, but if they did use a trash can, Apple would have one more reason to sue them :-) ... >POOR WINDOW MANAGEMENT. One of the things I lke about the X uwm window >manager (although many feel otherwise) is the use of keyboard and >mouse combinations e.g. to move a window I need only be in the window and >hit (with my .uwmrc file) ALT + right button to drag the window, ALT + middle >to change its size, etc. All such items in MS-windows are based on being in >a particular spot on the window (in the border to change its size, in the >title to move it). This is EXACTLY the way Apple invented it for the MAC, and presumably is one of the issues in the lawsuit :-) ... >POOR DIALOGUE BOXES. There are a million (ok maybe only 20 or 30) dialogue >boxes that keep poping up to ask "ARE YOU SURE?" and so on. This would not >be so much of a pain if the box was positioned correctly so that the default >button (the one highlited and clicked by hitting the enter key) was >positioned under the mouse. Of course, the MAC's "OK" button does not automatically pop up positioned under the mouse pointer either :-) ... >my mimimal Mac experience seems to indicate that Mac/OS has >some of the same problems). Bingo! -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: ihnp4!killer!dcs!wnp ESL: 62832882 INTERNET: wnp@DESEES.DAS.NET or wnp@dcs.UUCP TLX: 910-280-0585 EES PLANO UD
blair@pt1.Wichita.NCR.COM (Brian Lair) (05/23/88)
MS-Windows isn't THAT bad... In article <10799@apple.Apple.Com>, jrg@Apple.COM (John R. Galloway) writes: > the whole thing has left me with a great desire to vomit on > my keyboard. Really, now, let's not be melodramatic! > Comments on Micro Soft Windows 2.1 > POOR COMMAND INTERACE. Yes it is graphical, but only in that DOS like > commands can be "typed" with the mouse. i.e. to delete a file your > choices are: > via mouse > - click on the filename (optional) > - click on the FILE pulldown menu > - drag to the delete entry > - get a dialogue box which has either an empty filename or > if you have selected (by clicking on) the name of a file > before pulling down the FILE menu, then that name is in > the filename spot in the dialogue box. > - edit the filename with cursor keys, etc. if needed > - click on the OK (or perhpas it says YES) box You make this sound worse than it is... In most cases, this involves only four mouse clicks: Filename, File Menu, Delete menu item (you don't have to drag to it, just click on it), and OK button. I think that's fairly efficient (but maybe not like the trash can concept on the Macintosh). > via keyboard No arguments here... Windows with a keyboard is unruly. The main advantage of the MS-DOS Executive Window is that it puts all the filenames on the screen for you to choose from. "rm filename" is only more efficient if you already know exactly how "filename" is spelled. > > POOR APPLICATION ENVIRONENT. > The biggest hit seems to be a lack of [ability of the user to specify] > position and size info (ala standard X geometry specs). I agree -- this is annoying. I think applications CAN provide such a feature, but most don't. > POOR WINDOW MANAGEMENT. > To see other applications you have to always resize or iconify. Also annoying. However, you can press ALT-ESC or ALT-TAB to hop from one window to another without moving or resizing. > MICRSOFT WRITE. Any supposedly WYSIWYG window oriented editor that does not > allow multiple rulers is a toy. enough said. OK, enough said. > FILENAME EXTENSIONS. MS-windows keys off of filename extensions to chose > what application to run. Thus you can click on foo.wri which was written by > MS-write to run MS-wite with foo.wri opened. Well it sounds good but the > applications do not "see" files without their extensions. So for example if > importing a raw text file into MS-write, you must give it a .wri extension You can specify other "default" extensions to Windows by changing the [extensions] section of the WIN.INI file. For instance, I added the line "c=notepad.exe ^.c" so that I can just double-click on JUNK.C and the file is brought up automatically under NOTEPAD. > Even if a good word processor was available (WinText from Palantir looks > interesting ...) By the way, has anyone else used WinText? Any comments? > Perhaps novice users find MS-windows > appealing (I have been in computers for about 18 years now) ... Only 9 years for me :-( I don't think I'm a novice, but I find Windows to be a very good productivity tool. Sure, it has plently of problems (consider the clunker it's built on top of), but the advantages outweight the drawbacks. I get a lot of use out of the MS-DOS Executive, cutting&pasting, multiple windows, not to mention the pretty colors on my VGA (Although Windows doesn't use all available colors *sniff*). > Some of the applications are very nice on the inside, > but the world they live in is a slum. I don't agree, but that's kind of a clever analogy. -- Brian R. Lair NCR Corporation, E&M Wichita, Advanced Development Brian.Lair@Wichita.NCR.COM {ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!Brian.Lair {sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!ncrwic!Brian.Lair
dorourke@polyslo.UUCP (David O'Rourke) (05/24/88)
In article <91@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: >In article <10799@apple.Apple.Com> jrg@Apple.COM (John R. Galloway) writes: > >POOR DIALOGUE BOXES. There are a million (ok maybe only 20 or 30) dialogue > >boxes that keep poping up to ask "ARE YOU SURE?" and so on. This would not > >be so much of a pain if the box was positioned correctly so that the default > >button (the one highlited and clicked by hitting the enter key) was > >positioned under the mouse. > > Of course, the MAC's "OK" button does not automatically pop up > positioned under the mouse pointer either :-) ... No but it does allow you to press the return key so you don't have to use the mouse at all. > >my mimimal Mac experience seems to indicate that Mac/OS has > >some of the same problems). > > Bingo! It depends on what you're used to. What the above articles express as problems I happen to like. After using X-Windows for a while I feel I could make the same statment about X-Windows. So lets compromise. We'll not call them problems, but we'll call them differences that the user may or may not like. -- David M. O'Rourke Disclaimer: I don't represent the school. All opinions are mine!
wtm@neoucom.UUCP (Bill Mayhew) (05/24/88)
I agree whole heatedly with John Galloway at Apple that one glaringly absent feature of Windows is a feature for pushing a window to the bottom of the desktop stack. I've used several systems that do have a depth arranger, and it is extremely handy. On a screen that has limited resolution such as the PS/2 VGA screen (compared to a Sun 3, for instance), the windows necessarily stack up, and some means of managing them is a must. The ugliness of Windows' fonts in not totally the fault of Windows. Using the HP Laser Jet's downloadable fonts is laborious. Those LJ fonts also suck up a lot of memory. I do wish that Windows came with a good utility like Bitstream Fontware for making fonts. I guess there is a reason that the Apple PS Laserwriter, QMS, etc are as expensive as they are. Windows has still has some way to go to be mature product, but it is a heck of a lot better than it was a year ago. Makes you appreciate how much work has gone into the Macintosh. --Bill wtm@neoucom.UUCP
nowlin@ihuxy.ATT.COM (Jerry Nowlin) (05/24/88)
Before people start knocking something they should make sure they know enough about it to avoid chewing on their feet at the same time. In article <91@dcs.UUCP>, wnp@dcs.UUCP (Wolf N. Paul) writes: > In article <10799@apple.Apple.Com> jrg@Apple.COM (John R. Galloway) writes: > >POOR WINDOW MANAGEMENT. One of the things I lke about the X uwm window > >manager (although many feel otherwise) is the use of keyboard and > >mouse combinations e.g. to move a window I need only be in the window and > >hit (with my .uwmrc file) ALT + right button to drag the window, ALT + middle > >to change its size, etc. All such items in MS-windows are based on being in > >a particular spot on the window (in the border to change its size, in the > >title to move it). > > This is EXACTLY the way Apple invented it for the MAC, and presumably > is one of the issues in the lawsuit :-) ... There IS a keyboard interface for manipulating the active window in MS-windows. An active window can be moved, sized, iconized, restored and toggled back and forth between full screen size and its previous size all from the keyboard by use of ALT-function key combinations. An active window can also be closed with an ALT-function key combination. MS-windows provides a facility for "accelerators" to be defined for menu items that allow items to be selected from the keyboard without even displaying the menu. It looks like that's how the window manipulation commands above are implemented. > >POOR DIALOGUE BOXES. There are a million (ok maybe only 20 or 30) dialogue > >boxes that keep poping up to ask "ARE YOU SURE?" and so on. This would not > >be so much of a pain if the box was positioned correctly so that the default > >button (the one highlited and clicked by hitting the enter key) was > >positioned under the mouse. > > Of course, the MAC's "OK" button does not automatically pop up > positioned under the mouse pointer either :-) ... The OK and CANCEL buttons that normally appear in MS-windows dialog boxes (for instance when you try to close the last window during a windows session) can also be triggered from the keyboard. This depends on the application, but the MS-windows recommended design calls for the return key to activate the OK button and the escape key to activate the CANCEL button. Most applications work this way. If ones you use don't it's not the fault of MS. They make the facilities available to applications programmers but they can't stand behind them with a ruler and crack them on the knuckles if they don't use everything that's available. I've used the MAC, the Atari ST, MS-windows and a variety of different AT&T windowing systems. There are things about each that I like better then the others. Ideally I'd take the best of each and design my own interface. MS-windows is certainly as good as the others that are available in many ways and documented MUCH better than some (sorry Atari). Jerry Nowlin (...!ihnp4!ihuxy!nowlin)
diamant@hpfclp.SDE.HP.COM (John Diamant) (05/27/88)
> The idea of positioning the dialog box under the present position of the > mouse is worth a try. Yes, it sounds like a good idea, but what do you do if the mouse is over on the edge of the screen, such that the dialog box would be mostly off-screen if positioned that way. If you then just make the dialog box appear on the edge of the screen instead of mostly off-screen, then the mouse won't be on the right button any more. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
jrg@Apple.COM (John R. Galloway) (05/29/88)
In article <10700005@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >> The idea of positioning the dialog box under the present position of the >> mouse is worth a try. > >Yes, it sounds like a good idea, but what do you do if the mouse is over on >the edge of the screen, such that the dialog box would be mostly off-screen > Certainly the window manager would have to check to be sure the dialog box would be positioned off screen. Yet this is unlikely since the entire string of events was started by a menu, as long as it is positioned so that it leaves enough room, and the dialog boxes are well designed (perhaps with the OK button on the left, or right) this should be a rare occurence. -- apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
diamant@hpfclp.SDE.HP.COM (John Diamant) (05/30/88)
jrg@Apple.COM (John R. Galloway) writes: > Certainly the window manager would have to check to be sure the dialog box > would be positioned off screen. Yet this is unlikely since the entire > string of events was started by a menu, as long as it is positioned so > that it leaves enough room, and the dialog boxes are well designed (perhaps > with the OK button on the left, or right) this should be a rare occurence. In the case you were talking about, the events were keyed by a user action on the mouse, so you are correct. I am trying to consider the general case of popup dialog boxes. There are certainly cases where the dialog box pops up by itself due to system errors (disk full, etc) where the mouse sprite may be over in a corner because it is not being used at the moment. Maybe the answer is to do as you suggest and pop the dialog box up under the sprite for user initiated actions, but for modal dialog boxes caused by system errors, pop them up central to the application or screen. Or, alternately, simply always attempt to pop the dialog box up under the sprite, and if it would be paritally off screen, then move it fully onscreen. What I don't like about these approaches is that it is easy to learn a response that you can just always click no matter where you are to get the box to go away (because normally you're in the right place), but it wouldn't be consistently true. Also, moving the mouse sprite over the dialog box is generally considered to have poor human factors. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
gelphman@adobe.COM (David Gelphman) (05/31/88)
In article <11222@apple.Apple.Com> jrg@apple.UUCP (John R. Galloway) writes: >In article <10700005@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >>> The idea of positioning the dialog box under the present position of the >>> mouse is worth a try. >> >>Yes, it sounds like a good idea, but what do you do if the mouse is over on >>the edge of the screen, such that the dialog box would be mostly off-screen >> There is a very nice INIT/CDEV for the Macintosh called Front & Center which was written by Pete Helme. It centers dialogs around the current mouse position. When the mouse is near the edge of the screen it places the dialog as close to the edge as possible but with the whole dialog showing. It works very well, especially with very large screens. The only down side I've seen is that if you use two screens only the main screen is used. The whole effect does surprise guest users of my machines...they don't expect common dialogs to appear where they sometimes do. David Gelphman Adobe Systems, Inc.
jqj@uoregon.uoregon.edu (JQ Johnson) (05/31/88)
In article <10700005@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >> The idea of positioning the dialog box under the present position of the >> mouse is worth a try. > >Yes, it sounds like a good idea, but what do you do if the mouse is over on >the edge of the screen One standard technique in such cases is to push the current mouse position on the stack, relocate the mouse cursor to near the middle of the screen, and pop up the dialog box under the mouse. After the user has selected an item from the dialog box, remove the box and pop the mouse cursor location back to where you stole it from. Note that this approach works well for a mouse since the mouse reports delta-position rather than active position. It does not work for absolute positioning devices such as a touch screen or a tablet. If you have a touch screen, having the default be in your "current" location isn't too critical but if your pointing device is a tablet or light pen it's a real problem. Note that the idea of having the dialog box pop up with the default at the mouse cursor generalizes nicely to popup menus: in many window systems the popup menus can come up under the mouse such that the default selection is what you'll get if you just release the mouse button.
diamant@hpfclp.SDE.HP.COM (John Diamant) (06/03/88)
> > > >Yes, it sounds like a good idea, but what do you do if the mouse is over on > >the edge of the screen > One standard technique in such cases is to push the current mouse position > on the stack, relocate the mouse cursor to near the middle of the screen, > and pop up the dialog box under the mouse. After the user has selected > an item from the dialog box, remove the box and pop the mouse cursor location > back to where you stole it from. This is a reasonable solution (I mentioned it in an earlier response except for the return of the mouse to the previous location), except that it is very disconcerting to have your mouse sprite jump around the screen. In X, this operations is generally called warping the mouse, and it is frowned upon because people don't like their mouse bopping around all by itself. > in many window systems > the popup menus can come up under the mouse such that the default selection > is what you'll get if you just release the mouse button. Yes, I've used this myself. It is very valuable for popup menus. Actually, your mentioning the analogy reminds me of how I've seen the problem handled for menus that would be partially clipped. Usually, they are just moved as little as possible to put them fully on-screen, and the mouse is warped as little as possible to put it in the default location. Maybe that's the answer for dialog boxes too. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
roper@june.cs.washington.edu (Michael Roper) (06/03/88)
John Diamant writes: > > Also, moving the mouse sprite over the dialog box is generally considered > to have poor human factors. Could you elaborate? Seems to me to be a pretty good way of doing things. Especially if the dialog box is modal. -- Mike Roper * "I think I'm going to sneeze." ARPA: roper@june.cs.washington.edu * "A Klingon?" "Sneeze?" UUCP: ihnp4!uw-beaver!uw-june!roper * "It's the only kind I know."
don@brillig.umd.edu (Don Hopkins) (06/05/88)
In article <5034@june.cs.washington.edu> roper@june.cs.washington.edu (Michael Roper) writes: >John Diamant writes: >> >> Also, moving the mouse sprite over the dialog box is generally considered >> to have poor human factors. > >Could you elaborate? Seems to me to be a pretty good way of doing things. >Especially if the dialog box is modal. > I don't think you can make sweeping statements about what techniques are or are not good human factors, without taking into account the application. I think that there are situations in which moving the cursor on the screen, with no corresponding movement of the mouse, is very appropriate. For example: Idealy, a pie menu should pop up centered on the point where it was invoked, so that the cursor starts out in the inactive menu center, with all the selections around it in a circle. However, if the pie menu is invoked near the edge of the screen, the menu window must be moved so that it fits entirely on the screen, so the user can see and select every slice. The cursor must also be moved by the same distance that the menu was moved from its ideal position, so that the cursor is not left behind in an unexpected slice. Note that once the menu has popped up, the cursor may have traveled some distance from where it was when the menu was invoked. It's important to move the cursor to its CURRENT position plus the distance the menu was moved, as opposed to moving it from the menu invocation point plus the distance the menu was moved. If this is implemented right, it feels quite natural, and pie menus are reliable near the screen edge. If it's implemented wrong, or the cursor is not moved at all, it's very annoying -- and THAT's poor human factors! Another example is the way the OPEN LOOK scroll bar works: With Macintosh style scroll bars, clicking in the bar above or below the elevator brings the elevator towards the cursor by a certian ammount. If it's already near enough to the cursor, the elevator can move to the other side of the cursor, so the next click in the same place will make the elevator move in the other direction back over the cursor. In this state, multiple clicks will cause the elevator to oscilate back and forth around the cursor. The OPEN LOOK scroll bars are different, in that they have arrow buttons on the top and the bottom of the elevator, instead of at the top and the bottom of the scroll bar. That means that if you're clicking the arrow buttons to move up or down by lines, you don't have to move the cursor all the way to the other end of the scroll bar to press the other button, if you overshoot. What happens when you press one of the buttons on an OPEN LOOK scroll bar elevator is that the elevator moves up or down a little bit, and the cursor moves up or down by the same ammount, so that it's still over the same button! You can keep clicking the button, without moving the mouse, and your cursor moves along with the elevator! I consider that good human factors -- it's how a real elevator works! Who would use an elevator that you have to run up the stairs to catch, after pressing the up button??! -Don
diamant@hpfclp.SDE.HP.COM (John Diamant) (06/07/88)
> >Could you elaborate? Seems to me to be a pretty good way of doing things. > >Especially if the dialog box is modal. > > I don't think you can make sweeping statements about what techniques > are or are not good human factors, without taking into account the > application. This is true. General rules make sense, but there may be extenuating circumstances that take priority over the general rule (they still have to have a good reason!). > I think that there are situations in which moving the cursor on the > screen, with no corresponding movement of the mouse, is very > appropriate. [discussion of a pie menu partially off screen omitted] I agree. This makes sense in menus and is probably O.K. for dialog boxes that come up as a result of direct user action as opposed to one that pops up because of some background process. I see now that I didn't actually correctly specify the condition under which warping the mouse is bad. It is not a universal, certainly. The rule is that the system should not take control of the input focus away from the user. It should not take control, in general (this is partly what causes novice computer users to be scared by computers). If the user's input focus was already on the menu or some action which caused a dialog box to pop up immediately, then there is no problem in correcting the location of the mouse. This is because the user is the one who decided to perform the action. On the other hand, in a multi-tasking system where a dialog box pops up because of some background processing, it would be extremely bad human factors to grab the input focus by taking his mouse sprite away while he may be in the middle of something else. That was the point I was really getting at, though I didn't specify it sufficiently. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
sierch@well.UUCP (Michael Sierchio) (06/10/88)
I think I could get used to an editor occasionally adjusting the cursor
position, but it darn well bettter leave my mouse alone!
--
Michael Sierchio @ SMALL SYSTEMS SOLUTIONS
2733 Fulton St / Berkeley / CA / 94705 (415) 845-1755
sierch@well.UUCP {..ucbvax, etc...}!lll-crg!well!sierchtvillan@hpccc.HP.COM (Tim Villanueva) (06/10/88)
/ hpccc:comp.windows.misc / mcdonald@uxe.cso.uiuc.edu / 4:45 pm Jun 6, 1988 / >To continue on the theme of MS Windows bashing, I just today discovered >another gotcha. There is no way, given the tools provided when you >buy Windows, to write equations or Greek letters. The required symbols, >which are present in the normal IBM character set, are deleted in You can use GDI graphics, which are device-independent. It's not the "right" way to do it, but it's not that difficult either. Tim V tvillan%hpccc@hplabs.hp.com Hewlett-Packard (Personal Software Division)