Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!topaz!ll-xn!nike!ucbcad!ucbvax!decvax!cwruecmp!bammi From: bammi@cwruecmp.UUCP (Jwahar R. Bammi) Newsgroups: net.micro.atari16 Subject: ProGem parts 13-14 (2 of 2) Message-ID: <1513@cwruecmp.UUCP> Date: Fri, 27-Jun-86 03:00:03 EDT Article-I.D.: cwruecmp.1513 Posted: Fri Jun 27 03:00:03 1986 Date-Received: Sat, 28-Jun-86 09:00:31 EDT Organization: CWRU Dept. Computer Eng., Cleveland, OH Lines: 647 #!/bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #!/bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # wind14.prf # tut.prf # macros.prf # This archive created: Fri Jun 27 02:53:58 1986 # By: Jwahar R. Bammi () export PATH; PATH=/bin:$PATH echo shar: extracting "'wind14.prf'" '(22068 characters)' if test -f 'wind14.prf' then echo shar: over-writing existing file "'wind14.prf'" fi sed 's/^X//' << \SHAR_EOF > 'wind14.prf' X.!**************************************************************************** X.! X.! ANTIC PUBLISHING INC., COPYRIGHT 1985. REPRINTED BY PERMISSION. X.! X.! ** Professional GEM ** by Tim Oren X.! X.! Proff File by ST enthusiasts at X.! Case Western Reserve University X.! Cleveland, Ohio X.! uucp : decvax!cwruecmp!bammi X.! csnet: bammi@case X.! arpa : bammi%case@csnet-relay X.! compuserve: 71515,155 X.! X.!**************************************************************************** X.! X.! X.!**************************************************************************** X.! X.! Begin Part XIV X.! X.!**************************************************************************** X.! X.PART XIV USER INTERFACES - Part 2 X.PP XThis issue of ST PRO GEM (#14) continues the discussion of Xuser interface design which began in episode eight. It begins Xwhere we left off, with a further treatment of the mode problem, Xand proceeds into topics such as visual grammar and layered Xinterfaces. X.PP X Note that there is no download for this column. The Xdownloads will return with the next issue, a discussion of using Xthe GEM DOS file system within a GEM application. Specifically, Xit will include sample code for using the file selector, the GEM Xform_error alerts, and some utilities for manipulating file and Xpath names. There will also be a feedback section. The following Xtwo columns will be devoted to "graphics potpourri", a collection Xof small but useful GEM utilities such as popup menus, string Xediting, and source code for drag and rubber box operations. X.SH MODES AGAIN XIf a program is modeless, it acts predictably, Xwhich turns out to be very important. On the other hand, a good Xdefinition for "modes" is hard to find. In column eight, I Xsuggested that a mode exists when you cannot use all of the Xcapabilities of the program without performing some intermediate Xstep. If this is less than clear, here are two alternate Xdefinitions offering different views of the problem. X.SH THE "TWO USER TEST" XConsider the following thought Xexperiment: Imagine that your ST (and GEM) had two mice, two Xcursors, and two users. Could they both effectively use the Xprogram at the same time? If so, the application is modeless. If Xthere are points where one user can be "locked out" by the actions Xof the other, then a mode exists at that point. Let's consider Xsome examples of this test. X.PP XIn any program which uses the GEM menu system, one user could Xstop the other by touching a menu hotspot and dropping a menu. XThis constitutes an inherent mode in the GEM architecture. X.PP XOn the GEM Desktop, two users could open windows and view Xfiles without interference. However, as soon as one person tries Xto delete a file (assuming the verify option is on), the other is Xbrought to a halt as a dialog appears. Thus, we have found a Xmodal dialog. X.PP XIn many "Paint-type" programs, such as MacPaint, PC Paint, Xand GEM Paint, two artists could co-exist quite well, utilizing Xthe on-screen palette and tool selection. Of course, these Xprograms also contain modal dialogs for such operations as file Xand brush shape selection. In contrast, consider the paint Xprogram DEGAS for the ST. Here, two artists could only work Xtogether as long as neither wanted to change tool or color. Then Xthe display would have to be flipped to the selection screen, Xstopping the other user. This is a mode in the DEGAS interface. X.PP X(By the way, this test is not just academic. The grand-daddy Xof all mouse based systems, NLS, demonstrated by Doug Englebart in X1968, had two mice and two users, one of whom was physically Xremote. Cooperative techniques such as this are still largely Xunexplored and unexploited.) X.SH ONE LINER XHere's a terse definition by Jef Raskin: A Xprogram is modeless if a given action has one and only one result. XAgain, let's run a few examples. X.PP XThe menu dropdowns are clearly modal by this definition. XBefore the menu was activated, window control points could be Xactivated with a click. However, when the dropdown is visible, a Xclick action is interpreted as a menu selection or a dismissal of Xthe dropdown. Similarly, dialogs are modal because the action of Xmoving the mouse into the menu bar no longer causes the dropdown Xto appear. X.PP XI am typing this using the First Word editor program. It has Xa nice desktop level box full of characters where I can click to Xget symbols which the ST keyboard won't produce. However, if I Xinvoke the find or replace string dialog, the click-in-the-box Xaction doesn't work anymore. This is a mode in the First Word Xinterface. X.PP XFinally, consider an "old style" menu program, the kind where Xyou type in the number of the desired action from a list. Since Xthe number "2" might mean "Insert the record" in one menu, and X"Purge the file" in another, such a program is clearly modal by XRaskin's definition. X.PP XThese three definitions say almost the same thing, but from Xdifferent viewpoints. Depending on the situation, one or the Xother may be more intuitive for you. The goal of this type of Xanalysis is to root out unnecessary modes, and to make sure that Xthose which remain only appear when requested by the user, offer Xsome visual cue such as a rubber line or standard dialog box, and Xare used consistently throughout the application. X.SH PREDICTABILITY FOREVER AND EVER AND EVER XAs Raskin's Xdefinition makes clear, when the modes go away, the interface Xbecomes predictable. Predictability leads to the formation of Xhabits of use. Habits reduce "think time" and become Xprogressively faster due to the Power Law of Practice discussed in Xcolumn eight. This is exactly what we want! X.PP XThere is another benefit of predictability. A habit learned Xin one part of a program with a consistent interface can be Xtransferred and used elsewhere in the application. If several Xprograms share the same style of interface, the same habits can be Xused across a complete set of products. Learning time for the new Xfunctions becomes shorter, and the user is more likely to use the Xnew feature. X.SH IS A BOGEYMAN! XMost casual users are scared silly of Xcomputers and programs. (If you have any doubt, eavesdrop on a Xsecretary with a new word processor, or the doctor's receptionist Xcoping with an insurance data entry program.) In most cases, they Xhave a right to be frightened. Even experienced programmers, Xprone to toss the manuals and hack away, know that moderate Xparanoia is the best way to deal with an unknown program. How Xmust this feel to someone whose ability to perform (or lose) their Xjob depends on an unpredictable (aha!) black box. X.PP XSo here's another way in which predictability works. But to Xproduce a truly fearless user, we need other qualities as well. XOne is robustness, meaning that the program will not crash given Xnormal or even bizarre actions by the user. Another is feedback, Xwhich shuts off invalid options, reinforces correct actions, and Xgives reassurance that an operation is proceeding normally. XFinally, we need forgiveness, in the form of inverse operations or XUndo options, when the inevitable mistake is made. X.PP XThe ultimate goal is make the program discoverable. This Xmeans the user should be able to safely "wing it" after a short Xsession with the application and its interface. This practice Xought to be considered the norm anyway, since the manual is always Xacross the office or missing when an esoteric and half-forgotten Xfeature is needed. If it is possible to muddle through such a Xsituation by trial and error, without causing damage, the Ximmediate problem will be solved, and the user will gain Xconfidence. X.SH GOOD GRAMMAR OR... XSo exactly what are these habits that are Xsupposed to be so helpful? One of the most useful patterns is a Xconsistent command grammar for the program. This may sound Xstrange, since we have supposedly abandoned command line Xinterfaces in the graphics world, but in fact, the same type of Xrules apply. For instance, in the world of A> we might issue the Xcommand: X.br X.sp X.ce Xcopy a:foobar.txt b: X.PP XBy analogy to Englist grammar, this command contains a verb, X"copy", a file as subject: "a:foobar.txt", and a location as Xan object: "b:". The equivalent GEM Desktop operation is: X.BO X- Move mouse to foobar.txt icon in a: window X.EO X.BO X- Press mouse button X.EO X.BO X- Move mouse to b: icon X.EO X.BO X- Release mouse button X.EO X.PP XThe operation can be described as a select-drag-drop sequence, Xwith the select designating the subject file, the drag denoting Xthe operation (copy), and the location of the drop showing the Xobject. A grammar still exists, but its "terminal symbols" are Xcomposed of mouse actions interpreted in the context of the Xcurrent screen display, rather than typed characters. X.PP XOne useful way to analyze simple grammars, including those Xused as command languages, is to separate them into prefix, Xpostfix, and infix forms. In a prefix grammer, the operation to Xbe performed precedes its operands, that is, its subject(s) and Xobject(s). The DOS copy command given above is an example of a Xprefix command. LISP is an example of a language which uses Xprefix specification for its commands. X.PP XPostfix grammars specify the action after all of the operands Xhave been given. This command pattern is familiar to many as the Xway in which Hewlett-Packard calculators work. FORTH is an Xexample of a language which uses a postfix grammar. X.PP XInfix notation places the verb, or operator, between its Xsubject and object. Conventional algebraic notation is infix, as Xare most computer languages such as C or PASCAL. The example GEM Xcommand given above is also infix, since the selection of a Xsubject file preceded the action, which was followed by the Xdesignation of an object. X.PP XThe "standard" GEM command grammar, as used in the products Xproduced by Digital Research, is in fact infix. This is not to Xsay that GEM enforces such a convention, or that it is rigorously Xfollowed. However, when there is no pressing reason for a change, Xadoption of an infix command grammar will make your application Xfeel most like others which users may have seen. X.PP XThe general problem of specifying a graphic command language Xcan be difficult, but much of the problem has already been handled Xon the ST. Part of the solution is by constraint: the input and Xoutput hardware of the ST are predefined, so most developers will Xnot need to worry about choosing a pointing device or screen Xresolution. The other part of the standard solution is the GEM Xconvention for mouse usage. I am going to review these rules, and Xthen describe of the situations in which they have been bent, and Xfinally some alternate approaches which may prove useful to some Xdevelopers. X.SH SPECIFYING A SUBJECT XThere are really two sets of methods Xfor designating what is to be affected by an operation. One set Xis used when distinct objects are to be affected. Examples are Xfile and disk icons in the Desktop and trees in the RCS. Another Xset of designation methods is used when continuous material, such Xas text or bit images, is being handled. X.PP XWhen dealing with objects, a single mouse click (down and up) Xover the object selects it. The application should show that the Xselection has occurred by changing the appearance of the object. XThe most common methods are inverting the object, or drawing X"handles" around it. X.PP XMany operations allow "plural", or multiple object, Xselections. The GEM convention is that a click on an object while Xthe shift key is held down extends the selection by adding that Xobject. If the shift-clicked object was already selected, it is Xdeleted from the selection list. X.PP XAnother way to select multiple objects is to use a "rubber Xbox" to enclose them. This operation begins with drag on a part Xof the view where no object is present. The application then Xanimates a rubber box on the screen as long as the mouse button is Xheld down. When the button is released, all objects within the Xcurrent extent of the box are selected. A shift-drag combination Xcould be used to add the objects to an existing selection list. X.PP XSelecting part of a text or bit plane display is also done Xwith a rubber box. Since there are no "objects" in the view, any Xmouse drag is interpreted as the beginning of a selection Xoperation. In the simplest case, a bit plane, the rectangle Xwithin the box when the button is released is the selected extent. X.PP XWhen the underlying data has structure, such as words and Xlines of text, the display should reflect this fact during the Xselection operation. Typically, text selection is indicated by Xinversion of the characters rather than a rubber box. The Xselection extends along the starting line so long as the mouse Xstays within the line. If the mouse move off the starting text Xline, the implied selection is all characters between the starting Xcharacter and the character currently under the mouse, which is Xnot necessarily a rectangular area. X.PP XAn extended "plural" selection may be supported in text Xediting. The use of the shift key is also conventional in this Xapplication. X.SH ACTION XWith the subject designated, the user can now choose Xan operation. In many cases, this will be picked from the menu, Xin which case the entire command is complete. Some menu Xselections will lead to dialogs, in which the interaction methods Xare regulated by the GEM form manager. When the command is Xcompleted, it is often helpful if the application leaves the Xobjects (or areas) selected and ready for another operation. A Xsingle click away from any object is interpreted as cancelling the Xselections. X.PP XMany operations are indicated by gestures on the screen. XUsually, this is some variant of a drag operation. The Xinterpretation of the gesture may depend on the type and location Xof the selected subject, which part of it is under the mouse, and Xin what location the drag terminates. X.PP X"Handles" are small boxes or dot displayed around an object Xwhen it is selected. A drag beginning with the mouse on a handle Xis usually interpreted as a resizing operation, if this is Xappropriate. The pointing finger mouse form is displayed to Xindicate the operation in progress, and a rubber version of the Xobject is animated on the screen to show the user the result if Xthe button were released. In some cases, where an underlying X"snap" grid exists, the animated object may change size in Xdiscrete steps. X.PP XDragging a non-handle area of a selected object is usually Xinterpreted as the beginning of a move function. In most Xapplications, a move of a single object may be started without Xpre-selection. Simply beginning the drag on the object is taken Xto imply selection. The spread hand, or "grabber", mouse form is Xtypically displayed during a drag operation. X.PP XDragging may denote copying or movement, or more complex Xfunctions such as instantiation or generalization. The operation Ximplied by movement on the screen will differ among applications, Xand often within the same application, depending on target Xlocation. This target is the recipient of the command's action, Xor its object, in an English grammar sense. X.PP XFor example, a drag from window to window in the Desktop Xdenotes a copy. On the other hand, dragging the same icon to the Xtrashcan deletes it completely. Dragging an object from the RCS Xpartbox to the editing view creates a new copy of that prototype Xobject. Dragging the same object within the edit view simply Xchanges its placement. X.PP XThere are some mouse actions which are conventional X"abbreviations". A double click on an object is interpreted as Xboth a selection and an action. Usually, the double click action Xis the same as the Open entry in the "File" menu. X.PP XWhen the usual interpretation of a drag is movement, then Xshift-drag may be used as an enhanced varient implying copying. XFor instance, shift-dragging an object within the RCS editing Xwindow makes a copy of the object and places it in the final Xlocation. X.PP XTo return to the beginning of this discussion, the reason for Xadopting these conventional usages is to build an interface that Xpromotes habits. Particularly, a standard grammar for giving Xcommands helps answer the question "What comes next?". It breaks Xthe user's actions into logical phrases, or chunks, which may be Xthought of a whole, rather than one action at a time. X.SH DIFFERENT FOLKS, DIFFERENT STROKES X.PP XThere are always Xexceptions to a rule, or so it seems. In this case, consistency Xof the interface grammar is sometimes traded off against Xconsistency of metaphor, preservation of screen space, and "fast Xpath" methods for experts. X.PP XOne example is the use of "tools" in Paint and Draw programs. XIn such programs, an initial click is made on a tool icon, Xdenoting the operation to be applied to all following selections. XThis is an prefix style of grammar, and stands in contrast to the Xusual method of selecting subject object(s) first. Because of Xthis contrast, it is sometimes called "moding the cursor". (Try Xapplying the tests above to be sure it really is a mode.) X.PP XIn these cases, there are two reasons for accepting the Xnonstandard method. The first is consistency of metaphor. The X"user model" portrayed in the programs is an artist's work table, Xwith tools, palette, and so on. The cursor moding action is Xequivalent to picking up a working tool. The second reason is Xspeed. In a Paint program, the "canvas" is often modified, and Xspeed in creating or changing the bits is important. In more Xobject oriented applications such as Desktop or RCS, the objects Xare more persistent. Speed is then more essential when adding or Xchanging properties of the objects. X.PP XWhen command styles are mixed in this fashion, you must Xdesign very carefully to avoid conflicts or apparent side-effects Xin the command language. For example, in GEM Draw picking an Xaction from the Edit menu cancels the current cursor mode without Xwarning. Confusion from such side-effects may cancel out the Xbenefits of the mixed grammar. X.PP XThe subject of command speed deserves further attention. XWhile the novice approaching a program needs full feedback, a Xperson who uses it day in and day out will learn the program, and Xwant faster ways to get the job done, even if they are more Xarcane. The gives rise to a "layered" style of interface. X.PP XA layered interface is designed so that the visual grammar is Xobvious, as we have discussed. However, there are one or more Xsets of "accelerators" built into the program, which may be harder Xto find but faster to use. One example is condensed mouse actions Xsuch as the double-click. For instance, attempting to select a Xblock of text which extends beyond a window is impossible using Xthe basic metaphor. The novice will simply do the operation in Xpieces. A layered interface might put a less obvious Mark Begin Xand Mark End option in the menus. Another way is to take a drag Xwhich extends outside the window as a request to begin scrolling Xin that direction, while extending the current selection. X.PP XOne of the most common and useful accelerator methods is Xfunction keys. Using this approach, single key equivalents to Xactions are listed in the menu. Striking this key when an object Xis selected will cause the action to occur. Note that this is Xmost useful if some keyboard driven method of object selection, Xsuch as tabbing, is also available. Otherwise, the time switching Xfrom the mouse, used to select the object, to the keyboard for Xcommand input, may well cancel any advantage. X.PP XFinally, radical departures from the GEM metaphor may be Xuseful when attempting to replicate the look of another system, or Xtrying to meet severe constraints, such as display space. One Xexample would be discarding the standard GEM menus in favor of X"popup" menus which appear next to the current mouse position in Xresponse to a click on the second button. This method has the Xadvantage of preserving the menu space at the top of the screen, Xand is potentially faster because the menu appears right next to Xthe current mouse position. The drawbacks are lack of a visual Xcue for naive users trying to find the commands, and the need for Xcustom coding to build the popups. X.SH MORE TO COME XWe have reached the end of the second sermon Xon user interface. In a future column, I will look at "higher Xlevel" topics relating to the design of the application's user Xmetaphor. These include issues of object orientation, direct Xmanipulation, and the construction of microworlds. In the Xmeantime, several of the more practical columns will present Ximplementions of techniques such as accelarator keys and popup Xmenus which I have discussed this time. X.PP XTHANKS AND APOLOGIES to the following people whose public and Xpublished remarks have formed part of the basis of this Xdiscussion: Jef Raskin, Bill Buxton, Adele Goldberg, James Foley, Xand Ben Schneidermann. As always, any errors are my own. X.! X.! X.!***************************************************************************** X.!* * X.!* End Part XIV * X.!* * X.!***************************************************************************** SHAR_EOF if test 22068 -ne "`wc -c 'wind14.prf'`" then echo shar: error transmitting "'wind14.prf'" '(should have been 22068 characters)' fi echo shar: extracting "'tut.prf'" '(1236 characters)' if test -f 'tut.prf' then echo shar: over-writing existing file "'tut.prf'" fi sed 's/^X//' << \SHAR_EOF > 'tut.prf' X.!**************************************************************************** X.! X.! ANTIC PUBLISHING INC., COPYRIGHT 1985. REPRINTED BY PERMISSION. X.! X.! ** Professional GEM ** by Tim Oren X.! X.! Proff File by ST enthusiasts at X.! Case Western Reserve University X.! Cleveland, Ohio X.! uucp : decvax!cwruecmp!bammi X.! csnet: bammi@case X.! arpa : bammi%case@csnet-relay X.! compuserve: 71515,155 X.! X.!**************************************************************************** X.! X.! Begin Tutorial X.! X.!*************************************************************************** X.! X.! X.so macros.prf X.so wind1.prf X.so wind2.prf X.so wind3.prf X.so wind4.prf X.so wind5.prf X.so wind6.prf X.so wind7.prf X.so wind8.prf X.so wind10.prf X.so wind11.prf X.so wind12.prf X.so wind13.prf X.so wind14.prf X.! X.! Add any further Parts Above X.! X.cl 0 APPENDICES X.so apndx1.prf X.so apndx2.prf X.so apndx3.prf X.so apndx4.prf X.so apndx5.prf X.so apndx6.prf X.so apndx7.prf X.so apndx8.prf X.so apndx9.prf X.so apndx10.prf X.! X.! Add any further Appendicies Above X.! X.so toc.prf X.! X.! X.!**************************************************************************** X.! X.! End Tutorial X.! X.!*************************************************************************** SHAR_EOF if test 1236 -ne "`wc -c 'tut.prf'`" then echo shar: error transmitting "'tut.prf'" '(should have been 1236 characters)' fi echo shar: extracting "'macros.prf'" '(1170 characters)' if test -f 'macros.prf' then echo shar: over-writing existing file "'macros.prf'" fi sed 's/^X//' << \SHAR_EOF > 'macros.prf' X.!**************************************************************************** X.! X.! Macros X.! X.!**************************************************************************** X.! X.! Begin New Part X.! X.define PART X.he /Professional GEM//#/ X.bp X.bold on X.ce 1 XPART - $1 X.br X.sp 1 X.ce 1 X$2 $3 $4 $5 $6 $7 $8 $9 X.bold off X.cl 0 PART - $1. $2 $3 $4 $5 $6 $7 $8 $9 X.he /Professional GEM/Part $1/#/ X.sp 1 X.en X.! X.! Section Heading X.! X.define SH X.cl 1 $1 $2 $3 $4 $5 $6 $7 $8 $9 X.ne 5 X.sp 2 X.bold 1 X$1 $2 $3 $4 $5 $6 $7 $8 $9 X.br X.sp 1 X.ti +5 X.en X.! X.! Figure Begin X.! X.define FB X.ne 3 X.br X.cl 2 $1 X.sp 1 X.ce on X.en X.! X.! Figure End X.! X.define FE X.br X.ce off X.sp 1 X.en X.! X.! Paragraph X.! X.define PP X.ne 3 X.sp 1 X.ti +5 X.en X.! X.! Begin Option X.! X.define BO X.sp 1 X.in +4 X.en X.! X.! End Option X.define EO X.in -4 X.en X.! X.! X.define AP X.fi X.he /Professional GEM/Appendix $1/#/ X.bp X.cl 1 Appendix - $1 $2 $3 $4 $5 $6 X.ce on X.bold on XAppendix - $1 X.br X$2 $3 $4 $5 $6 X.bold off X.ce off X.sp 3 X.nf X.en X.! X.! X.!**************************************************************************** X.! X.! End Macros X.! X.!**************************************************************************** SHAR_EOF if test 1170 -ne "`wc -c 'macros.prf'`" then echo shar: error transmitting "'macros.prf'" '(should have been 1170 characters)' fi # End of shell archive exit 0 -- Jwahar R. Bammi Usenet: .....!decvax!cwruecmp!bammi CSnet: bammi@case Arpa: bammi%case@csnet-relay CompuServe: 71515,155