exodus@uop.UUCP (Freddy Kreuger) (10/09/87)
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 2 (of 4)."
# Contents: gem6.asc gem8.asc
# Wrapped by exodus@uop on Thu Oct 8 16:43:03 1987
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f gem6.asc -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"gem6.asc\"
else
echo shar: Extracting \"gem6.asc\" \(20501 characters\)
sed "s/^X//" >gem6.asc <<'END_OF_gem6.asc'
X *PROFESSIONAL GEM*
X by Tim Oren
X Column #6 - Raster operations
X
X SEASONS GREETINGS!
X
X This is the Yuletide installment of ST PRO GEM, devoted to
Xexplaining the raster, or "bit-blit" portion of the Atari ST's VDI
Xfunctions.
X
X Please note that this is NOT an attempt to show how to write
Xdirectly to the video memory, although you will be able to deduce a
Xgreat deal from the discussion.
X
X As usual, there is a download with this column. You will find
Xit in ATARI16 (PCS-58) in DL3 under the name of GEMCL6.C.
X
X DEFINING TERMS
X
X To understand VDI raster operations, you need to understand the
Xjargon used to describe them. (Many programmers will be tempted to
Xskip this section and go directly to the code. Please don't do it
Xthis time: Learning the jargon is the larger half of understanding
Xthe raster operations!)
X
X In VDI terms a raster area is simply a chunk of contiguous words
Xof memory, defining a bit image. This chunk is called a "form". A
Xform may reside in the ST's video map area or it may be in the data
Xarea of your application. Forms are roughly analogous to "blits" or
X"sprites" on other systems. (Note, however, that there is no sprite
Xhardware on the ST.)
X
X Unlike other systems, there is NO predefined organization of the
Xraster form. Instead, you determine the internal layout of the form
Xwith an auxiliary data structure called the MFDB, or Memory Form
XDefinition Block. Before going into the details of the MFDB, we need
Xto look at the various format options. Their distinguishing features
Xare monochrome vs. color, standard vs. device-specific and even-word
Xvs. fringed.
X
X MONOCHROME VS. COLOR
X
X Although these terms are standard, it might be better to say
X"single-color vs. multi-color". What we are actually defining is the
Xnumber of bits which correspond to each dot, or pixel, on the screen.
XIn the ST, there are three possible answers. The high-resolution mode
Xhas one bit per pixel, because there is only one "color": white.
X
X In the medium resolution color mode, there are four possible
Xcolors for each pixel. Therefore, it takes two bits to represent
Xeach dot on the screen. (The actual colors which appear are
Xdetermined by the settings of the ST's pallette registers.)
X
X In the low resolution color mode, sixteen colors are generated,
Xrequiring four bits per pixel. Notice that as the number of bits per
Xpixel has been doubled for each mode, so the number of pixels on the
Xscreen has been halved: 640 by 400 for monochrome, 640 by 200 for
Xmedium-res, and 320 by 200 by low-res. In this way the ST always
Xuses the same amount of video RAM: 32K.
X
X Now we have determined how many bits are needed for each pixel,
Xbut not how they are laid out within the form. To find this out, we
Xhave to see whether the form is device-dependent or not.
X
X STANDARD VS. DEVICE-SPECIFIC FORMAT
X
X The standard raster form format is a constant layout which is
Xthe same for all GEM systems. A device-specific form is one which is
Xstored in the internal format of a particular GEM system. Just as
Xthe ST has three different screen modes, so it has three different
Xdevice-specific form formats. We will look at standard form first,
Xthen the ST-specific forms.
X
X First, it's reasonable to ask why a standard format is used. Its
Xmain function is to establish a portability method between various
XGEM systems. For instance, an icon created in standard format on an
XIBM PC GEM setup can be moved to the ST, or a GEM Paint picture from
Xan AT&T 6300 could be loaded into the ST version of Paint.
X
X The standard format has some uses even if you only work with the
XST, because it gives a method of moving your application's icons and
Ximages amongst the three different screen modes. To be sure, there
Xare limits to this. Since there are different numbers of pixels in
Xthe different modes, an icon built in the high-resolution mode will
Xappear twice as large in low-res mode, and would appear oblong in
Xmedium-res. (You can see this effect in the ST Desktop's icons.)
XAlso, colors defined in the lower resolutions will be useless in
Xmonochrome.
X
X The standard monochrome format uses a one-bit to represent
Xblack, and uses a zero for white. It is assumed that the form begins
Xat the upper left of the raster area, and is written a word at a
Xtime left to right on each row, with the rows being output top to
Xbottom. Within each word, the most significant bit is the left-most
Xon the screen.
X
X The standard color form uses a storage method called "color
Xplanes". The high-order bits for all of the pixels are stored just as
Xfor monochrome, followed by the next-lowest bit in another contiguous
Xblock, and so on until all of the necessary color bits have been
Xstored.
X
X For example, on a 16-color system, there would be four different
Xplanes. The color of the upper-leftmost bit in the form would be
Xdetermined by concatenating the high-order bit in the first word of
Xeach plane of the form.
X
X The system dependent form for the ST's monochrome mode is very
Xsimple: it is identical to the standard form! This occurs because
Xthe ST uses a "reverse-video" setup in monochrome mode, with the
Xbackground set to white.
X
X The video organization of the ST's color modes is more
Xcomplicated. It uses an "interleaved plane" system to store the bits
Xwhich make up a pixel. In the low-resolution mode, every four words
Xdefine the values of 16 pixels. The high-order bits of the four
Xwords are merged to form the left-most pixel, followed by the next
Xlower bit of each word, and so on. This method is called
Xinterleaving because the usually separate color planes described
Xabove have been shuffled together in memory.
X
X The organization of the ST's medium-resolution mode is similar
Xto low-res, except the only two words are taken at a time. These are
Xmerged to create the two bits needed to address four colors.
X
X You should note that the actual color produced by a particular
Xpixel value is NOT fixed. The ST uses a color remapping system
Xcalled a palette. The pixel value in memory is used to address a
Xhardware register in the palette which contains the actual RGB
Xlevels to be sent to the display. Programs may set the palette
Xregisters with BIOS calls, or the user may alter its settings with
Xthe Control Panel desk accessory. Generally, palette zero
X(background) is left as white, and the highest numbered palette is
Xblack.
X
X EVEN-WORD VS. FRINGES
X
X A form always begins on a word boundary, and is always stored
Xwith an integral number of words per row. However, it is possible
Xto use only a portion of the final word. This partial word is called
Xa "fringe". If, for instance, you had a form 40 pixels wide, it
Xwould be stored with four words per row: three whole words, and one
Xword with the eight pixel fringe in its upper byte.
X
X MFDBs
X
X Now we can intelligently define the elements of the MFDB. Its
Xexact C structure definition will be found in the download. The
Xfd_nplanes entry determines the color scheme: a value of one is
Xmonochrome, more than one denotes a color form. If fd_stand is zero,
Xthen the form is device-specific, otherwise it is in standard format.
X
X The fd_w and fd_h fields contain the pixel width and height of
Xthe form respectively. Fd_wdwidth is the width of a row in words.
XIf fd_w is not exactly equal to sixteen times fd_wdwidth, then the
Xform has a fringe.
X
X Finally, fd_addr is the 32-bit memory address of the form
Xitself. Zero is a special value for fd_addr. It denotes that this
XMFDB is for the video memory itself. In this case, the VDI
Xsubstitutes the actual address of the screen, and it ignores ALL of
Xthe other parameters. They are replaced with the size of the whole
Xscreen and number of planes in the current mode, and the form is (of
Xcourse) in device-specific format.
X
X This implies that any MFDB which points at the screen can only
Xaddress the entire screen. This is not a problem, however, since the
Xthe VDI raster calls allow you to select a rectangular region within
Xthe form. (A note to advanced programmers: If this situation is
Xannoying, you can retrieve the address of the ST's video area from
Xlow memory, add an appropriate offset, and substitute it into the
XMFDB yourself to address a portion of the screen.)
X
X LET'S OPERATE
X
X Now we can look at the VDI raster operations themselves. There
Xare actually three: transform form, copy raster opaque, and copy
Xraster transparent. Both copy raster functions can perform a variety
Xof logic operatoins during the copy.
X
X TRANSFORM FORM
X
X The purpose of this operation is to change the format of a form:
Xfrom standard to device-specific, or vice-versa. The calling
Xsequence is:
X
X vr_trnfm(vdi_handle, source, dest);
X
Xwhere source and dest are each pointers to MFDBs. They ARE allowed
Xto be the same. Transform form checks the fd_stand flag in the
Xsource MFDB, toggles it and writes it into the destination MFDB after
Xrewriting the form itself. Note that transform form CANNOT change
Xthe number of color planes in a form: fd_nplanes must be identical in
Xthe two MFDBs.
X
X If you are writing an application to run on the ST only, you
Xwill probably be able to avoid transform form entirely. Images and
Xicons are stored within resources as standard forms, but since they
Xare monochrome, they will work "as is" with the ST.
X
X If you may want to move your program or picture files to another
XGEM system, then you will need transform form. Screen images can be
Xtransformed to standard format and stored to disk. Another system
Xwith the same number of color planes could the read the files, and
Xtransform the image to ITS internal format with transform form.
X
X A GEM application which will be moved to other systems needs to
Xcontain code to transform the images and icons within its resource,
Xsince standard and device-specific formats will not always coincide.
X
X If you are in this situation, you will find several utilities in
Xthe download which you can use to transform G_ICON and G_IMAGE
Xobjects. There is also a routine which may be used with map_tree()
Xfrom the last column in order to transform all of the images and
Xicons in a resource tree at once.
X
X COPY RASTER OPAQUE
X
X This operation copies all or part of the source form into the
Xdestination form. Both the source and destination forms must be in
Xdevice-specific form. Copy raster opaque is for moving information
Xbetween "like" forms, that is, it can copy from monochrome to
Xmonochrome, or between color forms with the same number of planes.
XThe calling format is:
X
X vro_cpyfm(vdi_handle, mode, pxy, source, dest);
X
X As above, the source and dest parameters are pointers to MFDBs
X(which in turn point to the actual forms). The two MFDBs may point
Xto memory areas which overlap. In this case, the VDI will perform
Xthe move in a non-destructive order. Mode determines how the pixel
Xvalues in the source and destination areas will be combined. I will
Xdiscuss it separately later on.
X
X The pxy parameter is a pointer to an eight-word integer array.
XThis array defines the area within each form which will be affected.
XPxy[0] and pxy[1] contain, respectively, the X and Y coordinates of
Xthe upper left corner of the source rectangle. These are given as
Xpositive pixel displacements from the upper left of the form.
XPxy[2] and pxy[3] contain the X and Y displacements for the lower
Xright of the source rectangle.
X
X Pxy[4] through pxy[7] contain the destination rectangle in the
Xsame format. Normally, the destination and source should be the same
Xsize. If not, the size given for the source rules, and the whole are
Xis transferred beginning at the upper left given for the destination.
X
X This all sounds complex, but is quite simple in many cases.
XConsider an example where you want to move a 32 by 32 pixel area
Xfrom one part of the display to another. You would need to allocate
Xonly one MFDB, with a zero in the fd_addr field. The VDI will take
Xcare of counting color planes and so on. The upper left raster
Xcoordinates of the source and destination rectangles go into pxy[0],
Xpxy[1] and pxy[4], pxy[5] respectively. You add 32 to each of these
Xvalues and insert the results in the corresponding lower right
Xentries, then make the copy call using the same MFDB for both source
Xand destination. The VDI takes care of any overlaps.
X
X COPY RASTER TRANSPARENT
X
X This operation is used for copying from a monochrome form to a
Xcolor form. It is called transparent because it "writes through" to
Xall of the color planes. Again, the forms need to be in
Xdevice-specific form. The calling format is:
X
X vrt_cpyfm(vdi_handle, mode, pxy, source, dest, color);
X
X All of the parameters are the same as copy opaque, except that
Xcolor has been added. Color is a pointer to a two word integer
Xarray. Color[0] contains the color index which will be used when a
Xone appears in the source form, and color[1] contains the index for
Xuse when a zero occurs.
X
X Incidentally, copy transparent is used by the AES to draw
XG_ICONs and G_IMAGEs onto the screen. This explains why you do not
Xneed to convert them to color forms yourself.
X
X (A note for advanced VDI programmers: The pxy parameter in both
Xcopy opaque and transparent may be given in normalized device
Xcoordinates (NDC) if the workstation associated with vdi_handle was
Xopened for NDC work.)
X
X THE MODE PARAMETER
X
X The mode variable used in both of the copy functions is an
Xinteger with a value between zero and fifteen. It is used to select
Xhow the copy function will merge the pixel values of the source and
Xdestination forms. The complete table of functions is given in the
Xdownload. Since a number of these are of obscure or questionable
Xusefulness, I will only discuss the most commonly used modes.
X
X REPLACE MODE
X
X A mode of 3 results in a straight-forward copy: every
Xdestination pixel is replaced with the corresponding source form
Xvalue.
X
X ERASE MODE
X
X A mode value of 4 will erase every destination pixel which
Xcorresponds to a one in the source form. (This mode corresponds to
Xthe "eraser" in a Paint program.) A mode value of 1 will erase every
Xdestination pixel which DOES NOT correspond to a one in the source.
X
X XOR MODE
X
X A mode value of 6 will cause the destination pixel to be toggled
Xif the corresponding source bit is a one. This operation is
Xinvertable, that is, executing it again will reverse the effects.
XFor this reason it is often used for "software sprites" which must be
Xshown and then removed from the screens. There are some problems
Xwith this in color operations, though - see below.
X
X TRANSPARENT MODE
X
X Don't confuse this term with the copy transparent function
Xitself. In this case it simply means that ONLY those destination
Xpixels corresponding with ones in the source form will be modified
Xby the operation. If a copy transparent is being performed, the
Xvalue of color[0] is substituted for each one bit in the source form.
XA mode value of 7 selects transparent mode.
X
X REVERSE TRANSPARENT MODE
X
X This is like transparent mode except that only those destination
Xpixels corresponding to source ZEROS are modified. In a copy
Xtransparent, the value of color[1] is substituted for each zero bit.
XMode 13 selects reverse transparent.
X
X THE PROBLEM OF COLOR
X
X I have discussed the various modes as if they deal with one and
Xzero pixel values only. This is exactly true when both forms are
Xmonochrome, but is more complex when one or both are color forms.
X
X When both forms are color, indicating that a copy opaque is
Xbeing performed, then the color planes are combined bit-by-bit using
Xthe rule for that mode. That is, for each corresponding source and
Xdestination pixel, the VDI extracts the top order bits and processes
Xthem, then operates on the next lower bit, and so on, stuffing each
Xbit back into the destination form as the copy progresses. For
Xexample, an XOR operation on pixels valued 7 and 10 would result in a
Xpixel value of 13.
X
X In the case of a copy transparent, the situation is more
Xcomplex. The source form consists of one plane, and the destination
Xform has two or more. In order to match these up, the color[] array
Xis used. Whenever a one pixel is found, the value of color[0] is
Xextracted and used in the bit-by-bit merge process described in the
Xlast paragraph. When a zero is found, the value of color[1] is
Xmerged into the destination form.
X
X As you can probably see, a raster copy using a mode which
Xcombines the source and destination can be quite complex when color
Xplanes are used! The situation is compounded on the ST, since the
Xactual color values may be remapped by the palette at any time. In
Xmany cases, just using black and white in color[] may achieve the
Xeffects you desire. If need to use full color, experimentation is
Xthe best guide to what looks good on the screen and what is garish
Xor illegible.
X
X OPTIMIZING RASTER OPERATIONS
X
X Because the VDI raster functions are extremely generalized, they
Xare also slower than hand-coded screen drivers which you might write
Xfor your own special cases. If you want to speed up your
Xapplication's raster operations without writing assembl language
Xdrivers, the following hints will help you increase the VDI's
Xperformance.
X
X AVOID MERGED COPIES
X
X These are copy modes, such as XOR, which require that words be
Xread from the destination form. This extra memory access increases
Xthe running time by up to fifty percent.
X
X MOVE TO CORRESPONDING PIXELS
X
X The bit position within a word of the destination rectangle
Xshould correspond with the bit position of the source rectangle's
Xleft edge. For instance, if the source's left edge is one pixel in,
Xthen the destination's edge could be at one, seventeen, thirty-three,
Xand so. Copies which do not obey this rule force the VDI to shift
Xeach word of the form as it is moved.
X
X AVOID FRINGES
X
X Put the left edge of the source and destination rectangles on
Xan even word boundary, and make their widths even multiples of
Xsixteen. The VDI then does not have to load and modify partial words
Xwithin the destination forms.
X
X USE ANOTHER METHOD
X
X Sometimes a raster operation is not the fastest way to
Xaccomplish your task. For instance, filling a rectangle with zeros
Xor ones may be accomplished by using raster copy modes zero and
Xfifteen, but it is faster to use the VDI v_bar function instead.
XLikewise, inverting an area on the screen may be done more quickly
Xwith v_bar by using BLACK in XOR mode. Unfortunately, v_bar cannot
Xaffect memory which is not in the video map, so these alternatives
Xdo not always work.
X
X FEEDBACK RESULTS
X
X The results of the poll on keeping or dropping the use of
Xportability macros are in. By a slim margin, you have voted to keep
Xthem. The vote was close enough that in future columns I will try to
Xinclude ST-only versions of routines which make heavy use of the
Xmacros. C purists and dedicated Atarians may then use the alternate
Xcode.
X
X THE NEXT QUESTION
X
X This time I'd like to ask you to drop by the Feedback Section
Xand tell me whether the technical level of the columns has been:
X
X A) Too hard! Who do you think we are, anyway?
X B) Too easy! Don't underestimate Atarians.
X C) About right, on the average.
X
X If you have the time, it would also help to know a little about
Xyour background, for instance, whether you are a professional
Xprogrammer, how long you have been computing, if you owned an 8-bit
XAtari, and so on.
X
X COMING UP SOON
X
X The next column will deal with GEM menus: How they are
Xconstructed, how to decipher menu messages, and how to change menu
Xentries at run-time. The following issue will contain more feedback
Xresponse, and a discussion on designing user interfaces for GEM
Xprograms.
END_OF_gem6.asc
if test 20501 -ne `wc -c <gem6.asc`; then
echo shar: \"gem6.asc\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f gem8.asc -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"gem8.asc\"
else
echo shar: Extracting \"gem8.asc\" \(24791 characters\)
sed "s/^X//" >gem8.asc <<'END_OF_gem8.asc'
X *PROFESSIONAL GEM*
X By Tim Oren
X Column #8: USER INTERFACES
X HOMILY #1
X
X AND NOW FOR SOMETHING COMPLETELY DIFFERENT! In response to a
Xnumber of requests, this installment of ST PRO GEM will be devoted
Xto examining a few of the principles of computer/human interface
Xdesign, or "religion" as some would have it. I'm going to start
Xwith basic ergonomic laws, and try to draw some conclusions which
Xare fairly specific to designing for the ST. If this article
Xmeets with general approval, further "homilies" may appear at
Xirregular intervals as part of the ST PRO GEM series.
X
X For those who did NOT ask for this topic, it seems fair to
Xexplain why your diet of hard-core technical information has been
Xinterrupted by a sermon! As a motivater, we might consider why
Xsome programs are said by reviewers to have a "hot" feel (and
Xhence sell well!) while others are "confusing" or "boring".
X
X Alan Kay has said that "user interface is theatre". I think
Xwe may be able to take it further, and suggest that a successful
Xprogram works a bit of magic, persuading the user to suspend his
Xdisbelief and enter an imaginary world behind the screen, whether
Xit is the mathematical world of a spreadsheet, or the land of Pacman
Xpursued by ghosts.
X
X A reader of a novel or science fiction story also suspends
Xdisbelief to participate in the work. Bad grammar and clumsy plotting
Xby the author are jarring, and break down the illusion. Similarly,
Xa programmer who fails to pay attention to making his interface
Xfast and consistent will annoy the user, and distract him from
Xwhatever care has been lavished on the functional core of the program.
X
X CREDIT WHERE IT'S DUE. Before launching into the discussion
Xof user interface, I should mention that the general treatment and
Xmany of the specific research results are drawn from Card, Newell,
Xand Moran's landmark book on the topic, which is cited at the end
Xof the article. Any errors in interpretation and application to
XGEM and the ST are entirely my own, however.
X
X FINGERTIPS. We'll start right at the user's fingers with the
Xbasic equation governing positioning of the mouse, Fitt's Law,
Xwhich is given as
X
X T = I * LOG2( D / S + .5)
X
X where T is the amount of time to move to a target, D is the distance
Xof the target from the current position, and S is the size of the
Xtarget, stated in equivalent units. LOG2 is the base 2 (binary)
Xlogarithm function, and I is a proportionality constant, about
X100 milliseconds per bit, which corresponds to the human's "clock
Xrate" for making incremental movements.
X
X We can squeeze an amazing amount of information out of this
Xformula when attempting to speed up an interface. Since motion time
Xgoes up with distance, we should arrange the screen with the
Xusual working area near the center, so the mouse will have to move
Xa smaller distance on average from a selected object to a menu or
Xpanel. Likewise, any items which are usually used together should
Xbe placed together.
X
X The most common operations will have the greater impact on
Xspeed, so they should be closest to the working area and perhaps
Xlarger than other icons or menu entries. If you want to have
Xall other operations take about the same time, then the targets
Xfarthest from the working area should be larger, and those closer
Xmay be proportionately smaller.
X
X Consider also the implications for dialogs. Small check boxes
Xare out. Large buttons which are easy to hit are in. There should
Xbe ample space between selectable items to allow for positioning
Xerror. Dangerous options should be widely separated from common
Xselections.
X
X MUSCLES. Anyone who has used the ST Desktop for any period
Xof time has probably noticed that his fingers now know where to find
Xthe File menu. This phenomenon is sometimes called "muscle memory",
Xand its rate of onset is given by the Power Law of Practice:
X
X T(n) = T(1) * n ** (-a)
X
Xwhere T(n) is the time on the nth trial, T(1) is the time on the
Xfirst trial, and a is approximately 0.4. (I have appropriated
X** from Fortran as an exponentiation operator, since C lacks one.)
X
X This first thing to note about the Power Law is that it only
Xworks if a target stays in the same place! This should be a potent
Xargument against rearranging icons, menus, or dialogs without some
Xexplicit request by the user. The time to hit a target which moves
Xaround arbitrarily will always be T(1)!
X
X In many cases, the Power Law will also work for sequences of
Xoperations to even greater effect. If you are a touch typist, you
Xcan observe this effect by comparing how fast you can enter "the"
Xin comparison to three random letters. We'll come back shortly
Xto consider what we can do to encourage this phenomenon.
X
X EYES. Just as fingers are the way the user sends data to the
Xcomputer, so the eyes are his channel from the machine. The rate
Xat which information may be passed to the user is determined by
Xthe "cycle time" of his visual processor. Experimental results
Xshow that this time ranges between 50 and 200 milliseconds.
X
X Events separated by 50 milliseconds or less are always
Xperceived as a single event. Those separated by more than 200
Xmilliseconds are always seen as separate. We can use these
Xfacts in optimizing user of the computer's power when driving the
Xinterface.
X
X Suppose your application's interface contains an icon which
Xshould be inverted when the mouse passes over it. We now know
Xthat flipping it within one twentieth of a second is necessary
Xand sufficient. Therefore, if a "first cut" at the program achieves
Xthis performance, there is no need for further optimization, unless
Xyou want to interleave other operations. If it falls short, it will
Xbe necessary to do some assembly coding to achieve a smooth feel.
X
X On the other hand, two actions which you want to appear distinct
Xor convey two different pieces of information must be separated
Xby an absolute minimum of a fifth of a second, even assuming that
Xthey occur in an identical location on which the user's attention
Xis already focused.
X
X We are able to influence the visual processing rate within the
X50 to 200 millisecond range by changing the intensity of the stimulus
Xpresented. This can be done with color, by flashing a target, or
Xby more subtle enhancements such as bold face type. For instance,
Xmost people using GEM soon become accustomed to the "paper white"
Xbackground of most windows and dialogs. A dialog which uses a
Xreverse color scheme, white letters on black, is visually shocking
Xin its starkness, and will immediately draw the user's eyes.
X
X It should be quickly added that stimulus enhancement will only
Xwork when it unambiguously draws attention to the target. Three or
Xfour blinking objects scattered around the screen are confusing, and
Xworse than no enhancement at all!
X
X SHORT-TERM MEMORY. Both the information gathered by the eyes
Xand movement commands on their way to the hand pass through short-term
Xmemory (also called working memory). The amount of information which
Xcan be held in short-term memory at any one time is limited. You can
Xdemonstrate this limit on yourself by attempting to type a sheet of
Xrandom numbers by looking back and forth from the numbers to the
Xscreen. If you are like most people, you will be able to remember
Xbetween five and nine numbers at a time. So universal is this
Xfinding that it is sometimes called "the magic number seven, plus
Xor minus two".
X
X This short-term capacity sets a limit on the number of choices
Xwhich the user can be expected to grasp at once. It suggests that
Xthe number of independent choices in a menu, for instance, should
Xbe around seven, and never exceed nine. If this limit is violated,
Xthen the user will have to take several glances, with pauses to
Xthink, in order to make a choice.
X
X CHUNKING. The effective capacity of short-term memory can be
Xincreased when several related items are mentally grouped as a "chunk".
XHumans automatically adopt this strategy to save themselves time.
XFor instance, random numbers had to be used instead of text in the
Xexample above, because people do not type their native language as
Xindividual characters. Instead, they combine the letters into words
Xand remember these chunks instead. Put another way, the characters
Xare no longer considered as individual choices.
X
X A well designed interface should promote the use of chunking
Xas a strategy by the user. One easy way is to gather together
Xrelated options in a single place. This is one reason that like
Xcommands are grouped into a single menu which is hidden except for
Xits title. If all of the menu options were "in the open", the user
Xwould be overwhelmed with dozens of alternatives at once. Instead, a
X"Show Info" command, for instance, becomes two chunks: pick File
Xmenu, then pick Show.
X
X Sometimes the interface can accomplish the chunking for the user.
XConsider the difference between a slider bar in a GEM program, and
Xa three digit entry field in a text mode application. Obviously,
Xthe GEM user has fewer decisions to make in order to set the associated
Xvariable.
X
X THINK! While we are puttering around trying to speed up
Xthe keyboard, the mouse, and the screen, the user is actually
Xtrying to get some work done. We need to back off now, and
Xlook at the ways of thinking, or cognitive processes, that go into
Xaccomplishing the job.
X
X The user's goal may be to enter and edit a letter, to retrieve
Xinformation from a database, or simply draw a picture, but it
Xprobably has very little to do with programming. In fact, the
XProblem Space Principle says that the task can be described as
Xa set of states of knowledge, a set of operators and associated
Xconstraints for changing the states, and the knowledge to
Xchoose the appropriate operator, which resides in the user's head.
X
X Those with a background in systems theory can consider this
Xas a somewhat abstract, but straightforward, statement in terms of
Xstate variables and operators. A programmer might compare the
Xknowledge states to the values of variables, the operators to
Xarithmetic and logic operations, the constraints to the rules of
Xsyntax, and the user's knowledge to the algorithm embodied by a
Xprogram.
X
X ARE WE NOT MEN? A rational person will try to attain his
Xgoals (get the job done) by changing the state of his problem space
Xfrom its initial state to the goal state. The initial state,
Xfor instance, might be a blank word processor screen. The desired
Xfinal state is to have a completed business letter on the screen.
X
X The Rationality Principle says that the user's behavior in
Xtyping, mousing, and so on, can be explained by considering the
Xtasks required to achieve the goal, the operators available to
Xcarry out the tasks, and the limitations on the user's knowledge,
Xobservations, and processing capacity. This sounds like the
Xtypical user of a computer program must spend a good deal of time
Xscratching his head and wondering what to do next. In fact, one
Xof Card and Moran's key results is that this is NOT what takes place.
X
X What happens, in fact, is that the trained user strikes a sort
Xof "modus vivendi" with his tool and adopts a set of repetitive,
Xtrained behavior patterns as the best way to get the job done.
XHe may go so far as to ignore some functions of the program in
Xorder to set up a reliable pattern. What we are looking for is a
Xway of measuring and predicting the "quality" of this trained
Xbehavior. Since using computers is a human endeavor, we should
Xconsider not only the speed with which the task is completed, but
Xthe degree of annoyance or pleasure associated with the process.
X
X Card and Moran constructed a series of behavioral models which
Xthey called GOMS models, for Goals-Operators-Methods-Selection.
XThese models suggested that in the training process the user
Xlearned to combine the basic operators in sequences (chunks!)
Xwhich then became methods for reaching the goals. Then these
Xfirst level methods might be combined again into second level
Xmethods, and so forth, as the learning progressed.
X
X The GOMS models were tested in a lengthy series of trials
Xat Xerox PARC using a variety of word processing software. (Among
Xthe subjects of these experiments were the inventors of
Xthe windowing methods used in GEM!) The results were again
Xsurprising: the level of detail in the models was really unimportant!
X
X It turned out to be sufficient to merely count up the number
Xof keystrokes, mouse movements, and thought intervals required
Xby each task. After summing up all of the tasks, any extra time
Xfor the computer to respond, or the user to move his hands from
Xkeyboard to mouse, or eyes from screen to printed page is added in.
XThis simplified version is called the Keystroke-Level Model.
X
X As an example of the Keystroke Model, consider the task of
Xchanging a mistyped letter on the screen of a GEM word processor.
XThis might be broken down as follows: 1) find the letter on the screen;
X2) move hand to mouse; 3) point to letter; 4) click mouse button;
X5) move hand to keyboard; 6) strike "Delete" key; 7) strike key
Xfor new character.
X
X The sufficiency of the Keystroke Model is great news for our
Xattempt to design faster interfaces. It says we can concentrate
Xour efforts on minimizing the number of total actions to be taken,
Xand making sure that each action is as fast as possible. We have
Xalready discussed some ways to speed up the mouse and keyboard
Xactions, so let's now consider how to speed up the thought intervals,
Xand cut the number of actions.
X
X One way to cut down "think time" is to make sure that the
Xcapacity of short-term memory is not exceeded during the course of
Xa task. For example, the fix-a-letter task described above required
Xthe user to remember 1) his place in the overall job of typing the
Xdocument; 2) the task he is about to perform; 3) where the bad
Xcharacter appeared, and 4) what the new character was. When this
Xtotal of items creeps toward seven, the user often loses his place
Xand commits errors.
X
X You can appreciate the ubiquity of this problem by considering
Xhow many times you have made mistakes nesting parentheses,
Xor had to go back to count them, because too many things happened
Xwhile typing the line to remember the nesting levels. The moral is that
Xoperations with long strings of operands should be avoided when
Xdesigning an interface.
X
X The single most important factor in making an interface
Xcomfortable to use is increasing its predictability, and
Xdecreasing the amount of indecision present at each step during
Xa task. There is (inevitably) an Uncertainty Principle which
Xrelates the number of choices at each step to the associated
Xtime for thought:
X
X T = I * LOG2 ( N + 1)
X
X where LOG2 is the binary logarithm function, N is the number of
Xequally probable choices, and I is a constant of approximately
X140 msec/bit. When the alternates are not equally probable, the
Xfunction is more complex:
X
X T = I * SUM-FOR-i-FROM-1-TO-N (P(i) * LOG2( 1 / P(i) + 1) )
X
X where the P(i) are the probabilities of each of the choices (which
Xmust sum to one). (SUM-FOR-i... is the best I can do for a sigma
Xoperator on-line!) Those of you with some information theory
Xbackground will recognize this formula as the entropy of
Xthe decision; we'll come back to that later.
X
X So what can we learn from this hash? It turns out, as we might
Xexpect, that we can decrease the decision time by making some
Xof the user's choices more probable than others. We do that by
Xmeans of feedback cues from the interface.
X
X The important of reliable, continuous meaningful feedback
Xcannot be emphasized enough. It helps the beginner learn the system,
Xand its predictability makes the program comfortable for the expert.
XPrograms with no feedback, or unreliable cues, produce confusion,
Xdissonance, and frustration in the user.
X
X This principle is so important that I going to give several
Xexamples from common GEM practice. The Desktop provides several
Xinstances. When an object is selected and a menu drops down, only
Xthose choices which are legal for the object are in black. The
Xothers are dimmed to grey, and are therefore removed from the
Xdecision. When a pick is made from the menu, the bar entry remains
Xblack until the operation is complete, reassuring the user that
Xthe correct choice was made. In both the Desktop and the RCS,
Xitems which are double-clicked open up with a "zoom box" from
Xthe object, again showing that the right object was picked.
X
X Other techniques are useful when operator icons are exposed on
Xthe screen. When an object is picked, the legal operations might
Xbe outlined, or the bad choices might be dimmed. If the screen
Xflashing produced by this is objectionable, the legal icons can
Xbe made mouse sensitive, so they will "light up" when the cursor
Xpasses over - again showing the user which choices are legal.
X
X The desire for feedback is so strong that it should be provided
Xeven while the computer is doing an operation on its own. The hour
Xglass mouse form is a primitive example of this. More sophisticated
Xare "progress indicators" such as animated thermometer bars,
Xclocks, or text displays of the processing steps. The ST Desktop
Xprovides examples in the Format and Disk Copy functions. The purpose
Xof all of these is to reassure the user that the operation is
Xprogressing normally. Their lack can lead to amusing spectacles
Xsuch as secretaries leaning over to hear if their disk drives are
Xworking!
X
X Another commonly overlooked feature is error prevention and
Xcorrection. Card and Moran's results showed that in order to go
Xfaster, people will tolerate error rates of up to 30% in their
Xwork. Any program which does not give a fast way to fix mistakes
Xwill be frustrating indeed!
X
X The best way to cope with an error is to "make it didn't happen",
Xto quote a common child's phrase. The same feedback methods
Xdiscussed above are also effective in preventing the user from
Xpicking inappropriate combinations of objects and operations.
XReplacement of numeric type-ins with sliders or other visual
Xcontrols eliminates the common "Range Error". The use of radio
Xbuttons prevents the user from picking incompatible options.
XWhen such techniques are used consistently, the beginner also
Xgains confidence that he may explore the program without blundering
Xinto errors.
X
X Once an error has occured, the best solution is to have an
X"inverse operation" immediately available. For instance, the way
Xto fix a bad character is to hit the backspace key. If a line is
Xinadvertantly deleted, there should be a way to restore it.
X
X Sometimes the mechanics of providing true inverses are
Ximpractical, or end up cluttering the interface themselves. In
Xthese cases, a global "Undo" command should be provided to
Xreverse the effect of the last operation, no matter what it was.
X
X OF MODES AND BANDWIDTH. Now I am going to depart from
Xthe Card, Newell and Moran thread of discussion to consider
Xhow we can minimize the number of operations in a task by
Xaltering the modes of the interface. Although "no modes" has
Xbeen a watchword of Macintosh developers, the term may need
Xdefinition for Atarians.
X
X Simply stated, a mode exists any time you cannot get to
Xall of the capabilities of the program without taking some
Xintermediate step. Familiar examples are old-style "menu-driven"
Xprograms, in which user must make selections from a number of
Xnested menus in order to perform any operation. The options
Xof any one menu are unavailable from the others.
X
X Recall that the user is trying to accomplish work in his
Xown problem space, by altering its states. A mode in the
Xprogram adds additional states to the problem space, which he is
Xforced to consider in order to get the job done. We might call
Xan interface which is completely modeless "transparent", because it
Xadds no states between the user and his work. One of the best
Xexamples of a transparent program is the 15-puzzle in the Macintosh
Xdesk accessory set. The problem space of rearranging the tiles
Xis identical between the program and a physical puzzle.
X
X Unfortunately, most programmers find themselves forced to
Xput modes of some sort into their programs. These often arise
Xdue to technological limitations, such as memory space, screen
X"real estate", or performance limitations of peripherals. The
Xquestion is how the modes can be made least offensive.
X
X I will make the general claim that the frustration which a
Xmode produces is directly proportional to the amount of the user's
Xbandwidth which it consumes. In other words, we need to consider
Xhow many keystrokes, mouse clicks, eye movements, and so on, are
Xgoing into manipulating the true problem states, and how many
Xare being absorbed by the modes of the program. If the interface
Xis wasting a large amount of the user's effort, it will be perceived
Xas slow and annoying.
X
X Here we can consider again the hierarchy of goals and methods
Xwhich the user employs. When the mode is low in the hierarchy,
Xand close to the user's "fingertips", it is encountered the most
Xfrequently. For instance, consider how frustrating it would be
Xto have to hit a function key before typing in each character!
X
X The "menu-driven" style of programs mentioned above are
Xalmost as bad, since usually only one piece of information is
Xcollected at each menu. Such a program becomes a labyrinth of
Xstates better suited to an adventure game!
X
X The least offensive modes are found at the higher, goal
Xrelated levels of the hierarchy. The better they align with
Xchanges in the state of the original problem, the more they
Xare tolerated. For example, a word processing program might
Xhave one screen layout for program editing, another for writing
Xletters, and yet another while printing the documents. A
Xmulti-function business package might have one set of menus for
Xthe spreadsheet, another for a graphing module, and a third
Xfor a database.
X
X In some cases the problem solved by the program has convenient
X"fracture lines" which can be used to define the modes. An
Xexample in my own past is the RCS, where the editing of each
Xtype of resource tree forms its own mode, with each of the modes
Xnested within the overall mode and problem of composing the
Xentire resource tree.
X
X TO DO IS TO BE! Any narrative description of user interface
Xis bound to be lacking. There is no way text can convey the vibrancy
Xand tactile pleasure of a good interface, or the sullen boredom
Xof a bad one. Therefore, I encourage you to experiment. Get out
Xyour favorite arcade game and see if you can spot some of the
Xelements I have described. Dig into your slush pile for the most
Xannoying program you have ever seen, run it and see if you can see
Xmistakes. How would you fix them? Then... go do it to your own
Xprogram!
X
X AMEN... This concludes the sermon. I'd like some Feedback
Xas to whether you found this Boring Beyond Belief or Really Hot
XStuff. If enough people are interested, homily number two will
Xappear a few episodes from now. The very next installment of ST
XPRO GEM will go back to basics to explore VDI drawing primitives.
XIn the meantime, you might investigate some of the Good Books on
Xinterface design referenced below.
X
X REFERENCES. Stuart K. Card, Thomas P. Moran, and Allen
XNewell, THE PSYCHOLOGY OF HUMAN-COMPUTER INTERACTION, Lawrence
XErlbaum Associates, Hillsdale, New Jersey, 1983. (Fundamental
Xand indispensible. The volume of experimental results make it
Xweighty. The Good Parts are at the beginning and end.)
X
X "Macintosh User Interface Guidelines", in INSIDE MACINTOSH,
XApple Computer, Inc., 1984. (Yes, Atarians, we have something to
Xlearn here. Though not everything "translates", this is a fine
Xpiece of principled design work. Read and appreciate.)
X
X James D. Foley, Victor L. Wallace, and Peggy Chan, "The
XHuman Factors of Computer Graphics Interaction Techniques",
XIEEE Computer Graphics (CG & A), November 1984, pp. 13-48.
X(A good overview, including higher level topics which I have
Xpostponed to a later article. Excellent bibliography.)
X
X J. D. Foley and A. Van Dam, FUNDAMENTALS OF INTERACTIVE
XCOMPUTER GRAPHICS, Addison Wesley, 1984, Chapters 5 and 6. (If
Xyou can't get the article above, read this. If you are designing
Xgraphics apps, buy the whole book! Staggering bibliography.)
X
X Ben Schneidermann, "Direct Manipulation: A Step Beyond
XProgramming Languages", IEEE Computer, August 1983, pp. 57-69.
X(What do Pacman and Visicalc have in common? Schneidermann's
Xanalysis is vital to creating hot interfaces.)
END_OF_gem8.asc
if test 24791 -ne `wc -c <gem8.asc`; then
echo shar: \"gem8.asc\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of archive 2 \(of 4\).
cp /dev/null ark2isdone
MISSING=""
for I in 1 2 3 4 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have unpacked all 4 archives.
rm -f ark[1-9]isdone
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0