bobr@zeus.UUCP (Robert Reed) (09/24/86)
Bill Idsardi writes in article 1897@utecfa.UUCP > > I don't really know whether modelessness is a myth or not, (though I suspect > it is a myth). > > For example, the dialog boxes and file selection boxes and pull-down menus > and click-drag mouse functions are ALL modes. > > The idea is, however, to keep the modes simple and small, so that a user's > options and how to get at them are obvious. > > So, MacWrite has lots of little modes, and vi has two big modes. Proving the myth of modelessness by picking at nits seems to be a waste of time. Larry Tesler gave a reasonable definition of the "modes" of which people speak when they talk about modeless programming: A useful definition of mode is a state of a user interface that affects the interpretation of subsequent inputs without obvious indication. The operant words here are "WITHOUT OBVIOUS INDICATION." We can argue all month about whether holding down the shift key or pushing the mouse button while looking at a pull-down menu constitutes a mode in the strictest definition, but all of this would be beside the point. The idea behind modeless programming is to eliminate surprises. If I click-drag an object or pull down a menu, or hold down the shift key, it is a conscious act for which I am getting direct feedback from the system. As a novice user of vi, I was constantly surprised by trying to enter text, only to find that I was in command mode (with no obvious indication). That is the point. One additional attribute of systems which are objectionably modal is their way of navigating through the modes. If holding the shift key is considered a mode, it is not very objectionable because I can get out of it by just letting go. The same goes for pulldown menus. If I don't like the choices, I can intuitively avoid them by moving the cursor away before letting go. Getting out of insert mode in vi, is not quite as easy, but can be easily acquired through the learned behavior of hitting the ESC key. The lesson here is NOT that systems should have no global states (i.e., modes) but that: o Users should be able to know, without having to query, those states of the system that will affect what they are about to do. o If in a state that the user no longer desires, they should be able to correctly guess how to get out of it (e.g., letting go of the shift key). Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
mark@cbosgd.ATT.COM (Mark Horton) (09/29/86)
In article <585@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes: > A useful definition of mode is a state of a user interface that affects > the interpretation of subsequent inputs without obvious indication. > >The operant words here are "WITHOUT OBVIOUS INDICATION." We can argue all >month about whether holding down the shift key or pushing the mouse button >while looking at a pull-down menu constitutes a mode in the strictest >definition, but all of this would be beside the point. The idea behind >modeless programming is to eliminate surprises. > >If I click-drag an object or pull down a menu, or hold down the shift key, >it is a conscious act for which I am getting direct feedback from the >system. As a novice user of vi, I was constantly surprised by trying to >enter text, only to find that I was in command mode (with no obvious >indication). That is the point. Sorry, Bob, I disagree. Your version of vi (3.7) doesn't show you when you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI clone. (It says "INPUT MODE" right there on the bottom line, or "I" if you have terse set. There are similar messages for r and R modes.) In System V release 2, you can get this by putting "set showmode" in your EXINIT, in release 3 it's on by default. In spite of this, I still consider vi a moded editor, and I think most others do too. As an extreme example, ex command mode is certainly a mode, with a very obvious visual indication (the : prompt and cursor at the bottom of the screen.) There's nothing wrong with being moded, it's just a personal preference. I've taught vi to many novices, such as secretaries; I stick to a 10 command subset and they seem quite happy. Mice and other pointing devices are handy for lots of things, but with only two hands, you can't keep one hand on the mouse all the time. A really good mouse interface never has your hands on the keyboard, you do everything with the mouse. (MacPaint is a good example of this.) But for a text editor, you can't reasonably input new text with a mouse, and there's the problem. There are so many things you want to do in a complex text editor that you can't really put them all on a menu without having zillions of menus and never being able to find anything. This goes for shell commands too. A person who has learned a keyboard oriented editor like vi or emacs becomes very familiar with that editor. Commands become reflexive habits, and switching to another editor is very painful; this is why there are so many flames about editors. I personally have the vi command set hardwired in my fingers, so I'm not anxious to learn another text editor or word processor. It took a quantum leap in editor quality to get people to switch from line editors to screen editors, and there are still plenty of line editor users out there. (My office mate hunts and pecks at ed.) It will take a similar quantum leap, plus near universality of mice as standard input devices, plus a mousecap or similar notion, to make people jump from screen editors to mouse editors. So far I haven't seen the quantum leap, at best things seem about even. (Cursor motion is easier but commands like "delete 2 sentences" or "find the matching parenthesis", or even a simple search, are harder.) Mark Horton
dubois@uwmacc.UUCP (Paul DuBois) (09/30/86)
> [Mark Horton] > There's nothing wrong with being moded, it's just a personal preference. > I've taught vi to many novices, such as secretaries; I stick to a 10 > command subset and they seem quite happy. I face the problem of teaching vi to novices, also, and would be interested to know what 10 commands you chose (and in hearing how others handle this problem). -- Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois | ARPA: dubois@easter --+-- dubois@rhesus (no kidding) | | "If it works, I didn't write it." "That's for sure!"
bobr@zeus.UUCP (Robert Reed) (10/01/86)
In article <2637@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes: > >Sorry, Bob, I disagree. Your version of vi (3.7) doesn't show you when >you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI >clone. (It says "INPUT MODE" right there on the bottom line,... This change sounds like a definite improvement and one that I wouldn't criticize without having a chance to see it, but an immediate concern of mine would be how visible this indicator is for someone whose focus of attention is the cursor, not the bottom of the screen. I still might not consider this indication as "obvious." >There's nothing wrong with being moded, it's just a personal preference. I agree that modes are useful and far be it from me to presume that either vi or emacs be considered modeless. My argument was not for the elimination of modes, but for the elimination of modes which demonstrate the two following features: o Their presence is not obvious to the user (whatever this means in terms of visual or mechanical feedback). o The mechanism for exiting them is not obvious. There are features of both vi and emacs that arguably fall within these dictates. The criterion for "obviousness" is necessarily vague, because level of expertise will affect the user's perceptions of natural behavior. Knowing to hit ESC in vi is a learned behavior, just as is knowing to hit ^G in emacs to abort multi-keystroke commands. Neither is particularly obvious if you don't know about them in advance. >Mice and other pointing devices are handy for lots of things, but with >only two hands, you can't keep one hand on the mouse all the time. > >...for a text editor, you can't reasonably input new text with a mouse, >and there's the problem. Agreed. Despite the attractiveness of the "cut and paste" style text editing paradigm, the actual mechanics of using such a system for text editing are cumbersome. That is not the same as saying that keyboard driven editing and cut-and-paste editing cannot be used in concert. Cut-and-paste grafted onto emacs would be a definite wart, but a useful one. Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
barmar@mit-eddie.MIT.EDU (Barry Margolin) (10/02/86)
In article <2637@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes: >In article <585@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes: >> A useful definition of mode is a state of a user interface that affects >> the interpretation of subsequent inputs without obvious indication. >> >>The operant words here are "WITHOUT OBVIOUS INDICATION." ... >>As a novice user of vi, I was constantly surprised by trying to >>enter text, only to find that I was in command mode (with no obvious >>indication). That is the point. > >Sorry, Bob, I disagree. Your version of vi (3.7) doesn't show you when >you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI >clone. (It says "INPUT MODE" right there on the bottom line, or "I" >if you have terse set. There are similar messages for r and R modes.) ... >In spite of this, I still consider vi a moded editor, and I think most >others do too. As an extreme example, ex command mode is certainly a >mode, with a very obvious visual indication (the : prompt and cursor >at the bottom of the screen.) > >There's nothing wrong with being moded, I think that we need to decide how "obvious" the indications must be before one is willing to call something "modeless". I don't consider a word or two somewhere else on the screen, or a change in shape of the cursor (as is common in many PC applications) obvious enough. However, moving the cursor out of the window, as is done for Emacs ESC-X commands or Macintosh dialogs, is about as obvious as you can get without grabbing the user by the collar and screaming "What extended command do you want?" in his ear. Emacs and MacWrite, however, are only modeless to a slightly greater extent than vi. Emacs has major (C, Lisp, Fundamental) and minor (Auto Fill, Overwrite, Macro Learn) modes. MacWrite has modes that specify the justification, font, and style of the text to be typed in. I think that the difference between these and vi is the extent to which use of the editor depends on the modes; a novice Emacs user might hardly ever change modes, but a vi can't be used without going between insert, overwrite, and edit modes relatively frequently. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
werner@ut-ngp.UUCP (Werner Uhrig) (10/03/86)
once you master an editor-interface well, you shouldn't have to waste your time to learn another one - which isn't likely going to be a cost-effective move anyway. I am convinced that the same is true for learning natural languages and consider the years I spent on Latin, Greek, French, etc. time that was not spent in a very productive manner. I approve of it for cultural and humanistic reasons though and wished I could find the time to polish my French again .....
tim@ism780c.UUCP (Tim Smith) (10/03/86)
In article <308@uwmacc.UUCP> dubois@uwmacc.UUCP (Paul DuBois) writes: >> There's nothing wrong with being moded, it's just a personal preference. >> I've taught vi to many novices, such as secretaries; I stick to a 10 >> command subset and they seem quite happy. > >I face the problem of teaching vi to novices, also, and would be >interested to know what 10 commands you chose (and in hearing how >others handle this problem). Ok, here are the 10 commands I would teach someone :-) 1. rm /bin/vi # adjust for local config. 2. ln /bin/qed /bin/vi 3. w 4. q 5. p 6. a 7. i 8. x 9. d 10. s :-) :-) :-) :-) :-) -- member, all HASA divisions POELOD ECBOMB -------------- ^-- Secret Satanic Message Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 Delphi or GEnie: mnementh
tuba@ur-tut.UUCP (Jon Krueger) (10/13/86)
In article <585@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes: > A useful definition of mode is a state of a user interface that affects > the interpretation of subsequent inputs without obvious indication. I'll rewrite this: A mode is a system state. The same user inputs in different modes get different system responses. Or: Users input to systems. Systems respond to users. A mode is a set of pairs of user inputs and their corresponding system responses. User inputs in the same mode get the same responses. User inputs in different modes may get different responses. I'm aiming toward a definition that's sufficiently general to apply to a variety of systems, devices, interfaces, and applications. Whether and how obviously a system indicates its mode is a testable matter. If the user behaves differently when the system indicates its mode, we can call the indication obvious. If the user behaves the same in the presence of an mode indication as in its absence, then the indication wasn't obvious. In fact, as far as I'm concerned, in that case the system didn't indicate a mode. I hope this kind of discussion is boring and dry enough to calm down the vi versus mouse flames. We're getting more heat than light. It's more useful to gain consensus on matters as basic as how to apply terms to objects. Hence I offer my use of the term "mode". But actually I have little interest in it, I'd rather see a useful definition of the terms: "sucessful user behavior" "effective use" "productive use" and so on. My definitions lack precision and vigor. I'd have to say something like "needs little reference to printed documentation or human consultants" or "minimal time to first satisfactory result" or "user jumps up and down and says he likes it" or "user rushes out and buys ten more of it". These are pretty imprecise, although demonstrably better than "I like it and I think everyone should like it" or "it's just obviously better than its competitors" or "what's wrong with it? Everyone uses it here all the time". -- jon -- --> Jon Krueger uucp: {seismo, bullwinkle, allegra, decvax, harvard}!rochester!ur-tut!tuba Phone: (716) 275-2811 work, 235-1495 home BITNET: TUBA@UORDBV Drop in next time you're in the tri-planet area!
maslak@sri-unix.ARPA (Valerie Maslak) (10/24/86)
When I learned vi, and when I have to show someone how to use it, I teach things in four segments: -Logging on and off, enough shell to create and delete files and directories, entering and exiting from vi. -Entering draft text, a and i; a few basic macros; Basic correction commands, moving in the file -Colon mode, strings -Printing to screen with formatter, copying and moving files and parts of files, hard copy output and calling macropackages. Seems to work pretty well for most folks, because they can hold on to things that are related in function, then move on to a new part of the process.