Exhibit 1015 – Part 3
`
`Exhibit 1015 — Part 3
`
`

`
`120
`
`Designing the User Interface
`
`the RETURN key was
`was then highlighted by reverse video until
`pressed. Each subject worked for three minutes with each form. The
`results were:
`
`Item-RETURN
`
`Mean tasks
`
`completed
`14.8
`
`Immediate response
`Highlight—RETURN
`
`15.5
`15.3
`
`4
`
`7
`3
`
`Preferred
`
`form
`0 subjects
`
`7 subjects
`29 subjects
`
`Subjects worked slightly faster with the immediate response form, but the
`error rate was highest. The subjective preference strongly favored the
`highlighting, whichlooks very impressive to novice users.
`
`3.8 EMBEDDED MENUS
`
`the menus discussed thus far might be characterized as explicit
`All
`menus in that
`there is an orderly enumeration of the menu items with
`little extraneous information. However,
`in many situations the menu
`items might be embedded in text or graphics and still be selectable.
`
`In designing a textual database about people, events, and places for a
`museum application,
`it seemed natural to allow users to retrieve detailed
`information by selecting a name in context. Selectable names were
`highlighted and the user could move a reverse video bar among
`highlighted names by pressing the four arrow keys
`(Figure 3.10).
`Selection was made by pressing ENTER and the user obtained a new
`article plus the option of returning to the previous article. The names,
`places, phrases, or foreign language words were menu items embedded in
`meaningful text that informed the user and helped clarify the meaning of
`the
`items.
`Subsequent
`implementations used mouse
`selection _or
`touchscreens, leading to the generic term touchtext for this application of
`embedded menus.
`'
`
`Touchtext was also used in an implementation of online maintenance
`manuals that provided diagnostic information in textual form on one
`
`

`
`Ch. 3 Menu Selection Systems
`
`121
`
`lNTRODUCTl0N: STAMP UNION
`
`not 1 of 2 '
`
`The Adele H. Stamp Union, formerly known as the Student Union, is the
`
`cultural and social center for the University. The Union provides a variety of
`
`services to the faculty, staff, and students. A plethora of restaurants are
`
`available providing 5' wide choice of atmosphere and a variety of menus. The Union
`
`is also center for entertainment. Several shops and many special services
`
`are available, too. Union programs include concerts, exhibitions, and craft
`
`classes. The Union is open all week from 7 M1. to 1 M1. Monday through Friday,
`and until 2 /t.|"l. on weekends.
`
`p
`EXT PAGE
`
`[ Select option then press RETURN]
`
`Figure 3.10: Display from the database on the Adcle H. Stamp Student Union at
`the University of Maryland showing the embedded menu style of TIES. A
`reverse video selector box initially covers the NEXT PAGE command. Users
`move the selector box over highlighted references or commands and then select
`by pressing RETURN. A touch screen version allows selection by merely
`touching the highlighted reference or command.
`
`and graphics
`monitor
`Shneiderman, 1986).
`
`assistance
`
`on‘
`
`a
`
`second monitor
`
`(Koved &
`
`traffic
`Embedded menus have emerged in other applications. Air
`control systems allow selection of airplanes in the spatial layout of flight
`paths to provide more detailed information for controllers. Geographic
`display systems allow selection of cities or zooming in on specific regions
`to obtain more information (Herot, 1984).
`In these applications,
`the
`items are icons, text, or regions in a two-dimensional layout.
`
`Languagc—dirccted editors permit users to select programming language
`constructs
`for
`expansion during the program composition process
`(Teitelbaum & Reps, 1981).
`In a program browser at the University of
`Maryland, Phil Shafer offered programmers the capability of moving the
`
`

`
`Designing the User Interface
`
`cursor onto a variable name or procedure invocation, pressing a function
`key, and receiving the data declaration or procedure definition in a
`separate window. The variable and procedure names were menu items
`embedded in the context of a Pascal program.
`concept by
`Many
`spelling
`checkers
`use
`the
`embedded menu
`highlighting the possibly misspelled words in the context of their use.
`The author of the text can move a cursor to a highlighted word and
`request possible words or type in the correctly spelled word.
`Embedded menus permit
`items togbe viewed in context and they
`eliminate the need for a distracting and screen-wasting enumeration of
`items. Contextual display helps keep the users focused on their tasks and
`the objects of interest.
`Items rewritten in list form may require longer
`descriptions (of the items) and increase the difficulty of making selections
`because of confusion arising from cross—referencing between the menu
`and the context.
`
`3.9 FORM FILL-‘IN
`
`Menu selection is effective in choosing an item from a list, but some
`tasks are cumbersome with menus.
`If data entry of personal names or
`numeric values
`is
`required,
`then keyboard typing becomes more
`attractive. The keyboard may be viewed as a continuous single menu
`from which multiple selections are made rapidly. When many fields of
`data are necessary,
`the’ appropriate interaction style might be called form
`fill-in. For example, the user might be ‘presented with a purchase order
`form for ordering from a catalog, as in Figure 3.11. Another example of
`a form using color coding is in Color Plate 1.
`The form fill~in approach is attractive because the full complement of
`information is visible, giving the users a feeling of being in control of the
`dialog. Few instructions are necessary since this approach resembles
`familiar paper forms. On the other hand, users must be familiar with
`keyboards, use of the TAB key to move the cursor, error correction by
`backspacing, field label meanings, permissible field contents, and use of
`the ENTER key. Form fill-in must be done on displays, not hardcopy
`devices, and the display device must support cursor movement.
`
`

`
`Ch. 3 Menu Selection Systems
`
`123
`
`Type in the information below,
`pressing TAB to move the cursor, and
`press ENTER when done.
`
`Name:
`
`Address:
`
`City:
`
`Charge Number:
`
`Catalog
`Number
`
`Quantity
`
`Catalog
`Number
`
`Quantity
`
`Figure 3.11: A form fill-in design for a department store.
`
`An experimental comparison of database update by form fill-in and a
`command language strategy demonstrated a significant speed advantage
`for the form fi11—in style (Ogden & Boyle, 1982). Eleven of the twelve
`subjects expressed a preference for the form fil1—in approach.
`
`3.9.1 Form fill-in design guidelines
`
`There is a paucity of empirical work on form fi1l—in, but a number of
`design guidelines have emerged from practitioners (Galitz, 1980; Pakin &
`Wray, 1982; Brown, 1986). Many companies offer form fi11—in creation
`
`

`
`Designing the User Interface
`
`FORM FILL-IN GUIDELINES
`_
`
`° Meaningful title
`~
`Comprehensible instructions
`
`-
`
`Logical grouping and sequencing of fields
`Visually appealing layout
`Familiar field labels
`
`Consistent terminology and abbreviations
`Error correction for characters and fields
`
`Visual templates for common fields
`Help facilities
`-
` j___j—
`
`Table 3.3: Form fill-in guidelines based on practical experience, but in need of
`validation and clarification.
`
`ISPF, Digital
`IBM’s
`such as Hewlett—Packard’s Forms 3000,
`tools,
`Equipment Corporation’s FORM, Ashton-Tate’s dBASE and Lotus
`Development Corporation's Symphony. Software tools simplify design,
`help ensure consistency, ease maintenance, and speed implementation.
`But even with excellent tools, the designer must still make many complex
`decisions (Table 3.3).
`
`The elements of form fill-in design include:
`
`0 Meaningful
`terminology
`
`title:
`
`Identify the topic and avoid computer
`»
`
`Comprehensible instructions: Describe the user’s tasks in
`familiar
`terminology.
`Try to be brief;
`but
`if more
`information is needed, make a set of help screens available
`to the novice user.
`In support of brevity, just decribe the
`necessary action (“Type the address” or simply “address:")
`and avoid pronouns (“You should type the address”) or
`references to the user “The user of the form should type the
`address.” Another useful rule is to use the word type for
`entering information and press for special keys such as the
`. TAB, ENTER, cursor movement, or Programmed Function
`(PFK, PF, or F) keys. Since ENTER often refers to the
`special key, avoid using it in the instructions (for example,
`
`

`
`Ch. 3 Menu Selection Systems
`
`125
`
`do not use “Enter the address,” but stick to “Type the
`address”) Once a grammatic
`style for
`instructions
`is
`developed, be careful to apply that style consistently.
`
`Logical grouping and sequencing of fields: Related fields
`should be adjacent and aligned with blank space for
`separation between groups. The sequencing should reflect
`common patterns;
`for example, city followed by state
`followed by zip code.
`
`the form: A uniform
`layout of
`appealing
`Visually
`distribution of fields is preferable to crowding one part of
`the screen and leaving other parts blank. Alignment creates
`a feeling of order and comprehensibility. For example, the
`field labels, Name, Address, and City, were right justified
`so that the data entry fields would be vertically aligned.
`This allows the frequent user to concentrate on the entry
`fields and ignore the labels.
`If working from hard copy,
`the screen should match the paper form.
`
`If
`Familiar field labels: Common terms should be used.
`Address were replaced by Domicile, many users would
`be uncertain or anxious about what to do.
`'
`
`Consistent terminology and abbreviations: Prepare a list of
`terms and acceptable abbreviations and diligently use the
`list, making additions only after careful consideration.
`Instead of varying such terms as Address, Employee
`Address, ADDR., and Addr ., stick to one term, such as
`Address.
`
`entry fields:
`and boundaries for data
`space
`Visible
`Underscores or other markers
`indicate the number of
`
`characters available, so users will know when abbreviations
`or other trimming strategies are needed.
`
`visible
`and
`cursor movement: A simple
`Convenient
`mechanism is needed for moving the cursor, such as a TAB
`key or cursor movement arrows.
`
`

`
`Designing the User Interface
`
`Error correction for individual characters and entire fields:
`A backspace key and overtyping should be allowed to
`enable easy repairs or changes to entire fields.
`
`Error messages for unacceptable values: If users enter an
`unacceptable value,
`the error message should appear on
`completion of the field. The message should indicate
`permissible values of the field, for example, if the zip code‘
`is entered as 28K2l or 2380,
`the message might indicate
`that “Zip codes should have 5 digits.”
`
`Optional fields should be marked: The word optional or
`other indicators should be visible. Optional fields should
`follow required fields, whenever possible.
`
`Explanatory messages for fields: If possible, explanatory
`information about a field or its values should appear in a
`standard position,
`such as in a window on the bottom,
`whenever the cursor is in the field.
`
`Completion signal: It should be’ clear to the users what to
`
`do when they are finished filling in the fields. Generally,
`designers should avoid automatic completion when the last
`field is
`filled, because users may wish to go back and
`review or alter field entries.
`
`These considerations may seem obvious, but often forms designers
`omit the title or have unnecessary computer file names, strange codes,
`unintelligible
`instructions, unintuitive groupings of
`fields,
`cluttered
`layouts, obscure field labels,
`inconsistent abbreviations or field formats,
`awkward cursor movement, confusing error correction procedures, hostile
`error messages, and no obvious way to signal completion.
`and
`Detailed
`design
`rules
`should
`reflect
`local
`terminology
`abbreviations; field sequences familiar to the users; the width and height
`of
`the display device; highlighting features
`such as
`reverse video,
`underscoring,
`intensity levels, color, and fonts;
`the cursor movement
`keys; and coding of fields.
`
`

`
`Ch. 3 Menu Selection Systems
`
`3.9.2 Coded fields
`
`Columns of information require special treatment for data entry and for
`display-. Alphabetic fields are customarily left justified on entry and on
`display. Numeric fields may be left justified on entry but then become
`right justified on display. When possible, avoid entry and display of
`leftmost zeroes in numeric fields. Numeric fields with decimal points
`should line up on the decimal points.
`,
`Special attention should be paid to such common fields as:
`
`'
`
`Telephone numbers: Offer a form to indicate the subfields:
`
`Phone:
`
`L
`
`Be alert to such special cases as addition of extensions or the need for
`nonstandard formats for foreign numbers.
`
`°
`
`'l‘he pattern for Social Security
`Social Security numbersi
`numbers should appear on the screen as:
`
`Social Security Number:
`
`When the user has typed the first three digits,
`to the leftmost position of the two-digit field.
`
`the cursor should jump
`
`'
`
`is
`‘clock
`twe'nty—four hour
`the
`Times: Even though
`convenient, ‘many people find it confusing and prefer A.M.
`or P.M. designations. The form might appear as:
`
`(9:45
`
`AM or PM)
`
`Seconds may or ‘may not be included, adding to the
`variety of necessary formats.
`
`Ddtes: This is one of the nastiest problems for which no
`good solution exists. Different
`formats
`for dates
`are
`
`

`
`Designing the User Interface
`
`tasks, and European rules differ
`appropriate for different
`from American rules.
`It may take a generation until an
`acceptable standard emerges.
`
`the instructions might
`When presenting coded fields,
`show an example of correct entry, for example:
`
`Date: _ _/_ _/_ _
`
`(O4/22/86 indicates April 22, 1986)
`
`For many people, examples are more comprehensible than
`an abstract description, such as MM/DD/YY.
`
`Dollar amounts (‘or other currency): The dollar sign should
`appear on the screen, and users then type only the amount.
`If a large volume of whole dollar amounts are to be
`entered, the user might be presented with a field such as:
`
`Deposit amount: $
`
`with the cursor to the left of the. decimal point. As the user
`types numbers, they shift left. To enter an occasional cents
`amount,
`the user must type the decimal point to reach the
`00 field for overtyping.
`
`in form fill-in design include dealing with
`_Other considerations
`multiscreen forms, mixing menus with forms,
`the role of graphics,
`relationship to paper
`forms, use of pointing devices, use of color,
`handling of special cases, and integration of a word processor to allow
`remarks.
`
`3.10 PRACTITIONER’S SUMMARY
`
`Begin by understanding the semantic structure of your application
`within the vast
`range of menu selection situations. Concentrate on
`organizing the sequence of menus to match the user’s tasks, ensure that
`
`

`
`Ch. 3 Menu Selection Systems
`
`129
`
`each menu is a meaningful semantic unit, and create items that are
`distinctive and comprehensible.
`If some users make frequent use of the
`system, then typeahead, shortcut, or macro strategies should be allowed.
`Permit simple traversals to the previously displayed menu and to the main
`menu. Finally, be sure to conduct human factors tests and involve
`human factors specialists in the design process (Savage et al., 1982).
`When the system is implemented, collect usage data, error statistics, and
`subjective reactions to guide refinement.
`
`Whenever possible, use a menu builder/driver system to produce and
`display the menus. Commercial menu creation systems are available and
`should be used to reduce implementation time, ensure consistent layout
`and instructions, and simplify maintenance.
`
`3.11 RESEARCHER’S AGENDA
`
`the design guidelines
`refine
`research could help
`Experimental
`concerning semantic organization and sequencing in single and‘ linear
`sequences of menus. How can differing communities of users be
`satisfied with a common semantic organization when their information
`needs are very different? Should users be allowed to tailor the structure
`of the menus or is the advantage greater in compelling everyone to use
`the same structure and terminology?
`
`Should a tree structure be preserved even if some redundancy is
`introduced? How can networks be made safe?
`
`Research opportunities abound. Depth versus breadth tradeoffs under
`differing conditions need to be studied to provide guidance for designers.
`Layout strategies, wording of instructions, phrasing of menu items, use of
`color, response time, and display rate are all excellent candidates for
`experimentation. Exciting possibilities are becoming available with larger
`screens, multiple displays, and novel selection devices.
`
`Implementers would benefit fromthe development of software tools to
`support menu system creation, management, usage statistics gathering,
`
`

`
`130
`
`Designing the User Interface
`
`Portability of “rrienu-ware” could be
`and evolutionary refinement.
`enhanced to facilitate transfer across systems.
`
`REFERENCES
`
`Billingsley, P. A., Navigation through hierarchical menu structures: Does
`it help to have a map‘? Proc. Human Factors Society, 26th Annual
`Meeting, (1982), 103-107.
`I
`Brown, C. Marlin, Human-Computer Interface Design Guidelines, Ablex
`Publishing Company, Norwood, NJ, (1986).
`Brown,
`James W., Controlling the complexity ‘of menu networks,
`Communications of the ACM 25, 7, (July 1982), 412-418
`
`Card, Stuart K., User, perceptual mechanisms in the search of computer
`command menus, Proc. Human Factors in Computer Systems, (March
`1982), 190-196.
`Clauer, Calvin Kingsley, An experimental evaluation of hierarchical
`decision-making for information retrieval, IBM Research Report RJ
`1093, (September 15, 1972), 83 pages.
`Doughty, Roger K., and Kelso, John, An evaluation of menu width and
`depth on user_perfoi'rnance, Unpublished project paper done with Prof.
`James Foley, George Washington University, Washington, DC (i984).
`Dray, S. M., Ogden, W. G.,
`and Vestewig, R. E., Measuring
`perfdrrnance with a meriu—selection huinan-computer interface, Proc.
`Human Factors Society, 25th Annual Meeting, (1981), 746-748.
`Galitz, Wilbert 0., Human Factors in Ofiice Automation, Life Office
`Managment Assn., Atlanta, GA, (1980).
`in Vassiliou, Y.
`interfaces,
`Herot, Christopher F., Graphical user
`(Editor), Human Factors and Interactive Computer Systems, Ablex
`Publishers, Norwood, NJ, (1984), 83-103.
`Hiltz, Starr Roxanne, and Turoff, Murray, The evolution of user behavior
`in a computerized conferencing system, Communications of the ACM
`24, 11, (November 1981), 739-751.
`
`

`
`Ch. 3 Menu Selection Systems
`
`131
`
`Kiger, John 1., The depth/breadth trade—off in the design of menu-driven
`user
`interfaces,
`International Journal of Man-Machine Studies 20,
`(1984), 201-213.
`Koved, Lawrence, and Shneiderman, Ben, Embedded menus: Menu
`selection in context, Communications of the ACM 29,
`(1986) ,
`312-318.
`
`Landauer, T. K., and Nachbar, D. W., Selection from alphabetic and
`numeric menu trees using a touch screen: Breadth, depth, and width,
`Proc. Human Factors in Computing Systems
`(April 1985), ACM
`SIGCHI, New York, 73—78.
`Laverson, Alan, Norman, Kent, and Shneiderman, Ben, An evaluation of
`jump—ahead
`techniques
`for
`frequent menu users, University of
`Maryland Computer Science Technical Report 1591, (December 1985).
`Lee, E., and Latremouille, S., Evaluation of tree structured organization
`of information on Telidon, Telidon Behavioral Research I, Department
`of Communications, Ottawa, Canada, (1980).
`S
`Liebelt, Linda S., McDonald, James E., Stone, Jim D., and Karat, John,
`The effect of organization on learning menu access, Proc. Human
`Factors Society, 26th Annual Meeting, (1982), 546-550.
`McDonald, James E., Stone, Jim D., and Liebelt, Linda S., Searching
`for items in menus: The effects of organization and type of target,
`Proc. Human Factors Society, 27th Annual Meeting, (1983), 834-837.
`McEwen, S. A., An investigation of user search performance on a
`Telidon information retrieval system, Telidon Behavioral Research 2,
`Ottawa, Canada, (May 1981).
`Mantei, Marilyn, Disorientation behavior in person—computer interaction,
`Ph. D. Dissertation, University of Southern California (August 1982).
`Martin, James, Viewdata and the Information Society, Prentice-Hall, Inc.,
`Englewood Cliffs, NJ, (1982), 293 pages.
`Miller, Dwight, P., The depth/breadth tradeoff in hierarchical computer
`menus, Proc. Human Factors Society, 25th Annual Meeting, (1981),
`296-300.
`Murray, Robert P., and Abrahamson, David S., The effect of system
`response delay and delay variability on inexperienced videotex users,
`Behaviour and Information Technology 2, 3, (1983), 237-251.
`
`

`
`132
`
`Designing the User Interface
`
`Ogden, William C., and Boyle, James M., Evaluating human—computer
`dialog styles: Command vs. forrn/fill-in for report modification, Proc.
`Human Factors Society, 26th Annual Meeting, Human Factors Society,
`Santa Monica, CA, (1982), 542-545.
`
`Pakin, Sherwin E., and Wray, Paul, Designing screens for people to use
`easily, Data Management, (July 1982), 36-41.
`
`Parton, Diana, Huffman, Keith, Pridgen, Patty, Norman, Kent, and
`Shneiderman, Ben, Learning a menu selection tree: Training methods
`compared, Behaviour and Information Technology 4, 2, (1985), 81-91.
`
`Perlman, Gary, Making the right choices with menus, INTERACT '84,
`First IFIP International Conference on Human—Computer Interaction,
`North—Holland, Amsterdam (September 1984), 291-295.
`
`Price, Lynne A., Design of command menus for CAD systems, Proc.
`ACM—IEEE I9tlz Design Automation Conference,
`(June
`1982),
`453-459.
`
`Robertson, G., McCracken, D., and Newell, A., The ZOG approach to
`man—machine communication, International Journal of Man—Machine
`Studies 14, (1981), 461-488.
`
`Savage, Ricky E., Habinek, James K., and Bamhatt, Thomas W., The
`design, simulation, and evaluation of a menu driven user interface,
`Proc. Human Factors in Computer Systems, (1982), 36-40.
`
`Shneiderman, Ben, Direct manipulation: A step beyond programming
`languages, IEEE Computer 16, 8, (August 1983).
`
`information
`and Picardi, Maria C., Locus of
`Somberg, Benjamin,
`in the search of computer menus, Proc. Human
`familiarity effect
`Factors Society, 27th Annual Meeting, (1983), 826-830.
`
`Teitelbaum, Richard C., and Granda, Richard, The effects of positional
`constancy on searching menus for information, Proc. CHI ’83, Human
`Factors in Computing Systems, Available from ACM, Baltimore, MD
`(1983), 150-153.
`
`Teitelbaum, T., and Reps, T., The Cornell program synthesizer: A
`syntax—directed programming environment, Communications of the
`ACM 24, 9, (September 1981), 563-573.
`
`two
`and McEwen, Scott A., Comparison of
`Jo W.,
`Tombaugh,
`information retrieval methods on Videotex: Tree—structure versus
`
`

`
`Ch. 3 Menu Selection Systems
`
`133
`
`alphabetic directory, Proc. Human Factors in Computer Systems,
`(1982), 106-110.
`Young, R. M., and Hull, A., Cognitive aspects of the selection of
`Viewdata options by casual users, Pathways to the Information Society,
`Proc. 6th International Conference on Computer Communication,
`London, (September 1982), 571-576.
`
`

`
`CHAPTER 4
`
`COMMAND LANGUAGES
`
`I soon felt that the forms of ordinary language were far too diffuse....I
`was not
`long in deciding that the most favorable path to pursue was to
`have recourse to the language of signs.
`lt
`then became necessary to
`contrive a notation which ought.
`if possible,
`to be at once simple and
`expressive, easily understood at the commencement, and capable of being
`readily retained in the memory.
`
`Charles Babbage, “On a method of expressing by signs the action of
`machinery,” 1826
`
`

`
`1363
`
`Designing the User Interface
`
`4. 1 TNTRODUCTION
`
`The history of written language is rich and varied. Early tally marks
`and pictographs on ' cave walls existed for millenia "before precise
`notations
`for numbers or other concepts appeared.
`The Egyptian
`hieroglyphs of 5,000 years ago were a tremendous advance because
`standard notations
`facilitated communication across
`space and time.
`Eventually,
`languages with a small alphabet and rules of word and
`sentence formation dominated because of the relative ease of learning,
`writing, and reading.
`In addition to these natural
`languages, special
`languages for mathematics, music, and chemistry emerged because they
`facilitated communication and problem ‘solving.
`In the twentieth century,
`novel notations were created for such diverse domains as dance, knitting,
`higher forms of mathematics, logic, and DNA molecules.
`
`The basic goals of language design are:
`
`precision
`
`compactness
`
`ease in writing‘ and reading
`speed in learning
`
`simplicity to reduce errors
`ease of retention over time.
`
`Higher level goals include:
`
`a close correspondence between reality and the notation
`convenience in carrying out manipulations relevant to the
`users’ tasks
`
`compatibility with existing notations
`flexibility to accommodate novice and expert users
`expressiveness to encourage creativity
`visual appeal.
`
`Constraints on a language include:
`
`

`
`Ch. 4 Command Languages
`
`137
`
`the capacity for human beings to record the notation
`a good match with the recording and the display media
`(e. g., clay tablets, paper, printing presses)
`the convenience in speaking (vocalizing).
`
`Successful languages evolve to serve the goals within the constraints.
`The printing press was a remarkable stimulus to language development
`because it made widespread dissemination of written work possible. The
`computer is another remarkable stimulus to language development, not
`only because widespread dissemination through networks is possible, but
`also because the computer is a tool to manipulate languages and because
`languages are a tool for manipulating computers.
`'
`The computer has had only a modest
`influence on spoken natural
`languages, compared to its enormous
`impact as
`a
`stimulus
`to the
`development of numerous
`new formal written
`languages.
`Early
`computers were meant
`to do mathematical computations,
`so the first
`programming languages‘ had a strong mathematical flavor. But computers
`were quickly found to be effective manipulators of logical expressions,
`business data, graphics, and text.
`Increasingly, computers are used to
`operate on the ‘real world: directing robots,
`issuing dollar bills at bank
`terminals, controlling manufacturing,
`‘and guiding spacecraft. These
`newer applications encourage language designers to find convenient
`notations to direct the computer while preserving the needs of people to
`use the language for communication and problem solving.
`Therefore, effective computer languages must not only represent the
`users’ tasks and satisfy the human needs for communication but must also
`be
`in harmony with mechanisms
`for
`recording, manipulating,
`and
`displaying these languages in a computer.
`Computer programming languages that were developed in the 19605
`and early 1970s_, suchyas FORTRAN, COBOL, ALGOL, PL/I, or Pascal,
`were designed for use
`in a noninteractive
`computer environment.
`Programmers would compose hundreds or thousands of lines of code,
`carefully check them over, and then compile or interpret by computer to
`produce a desired result.
`Incremental programming was one of the
`design considerations in BASIC and such advanced languages as LISP,
`
`

`
`Designing the User Interface
`
`APL, or PROLOG. Programmers in these languages were expected to
`build smaller pieces online and interactively execute and test them. Still
`the common goal was to create a large program that was preserved,
`studied, extended, and modified.
`Database query languages developed in the mid to late 1970s, such as
`SQL or QUEL, emphasized shorter segments of code (three to twenty
`lines) that could be written at a terminal and immediately executed. The
`goal of the user was more to create _a result than a program.
`systems
`Command
`languages, which
`originated with
`operating
`commands, are distinguished by their immediacy and by their impact on
`devices or information; Users issue a command and watch what happens.
`If the result is correct,
`the next command is issued; if not, some other
`strategy is adopted. The commands are brief and their existence is
`transitory. Of course, command histories are sometimes kept and macros
`are created in some command languages, but the essence of command
`languages is their ephemeral nature and the fact
`that
`they produce an
`immediate result on some object of interest.
`
`Command languages are distinguished from menu selection systems by
`the fact that the users of command languages must recall notation and
`initiate action." Menu selection users receive instructions and must only
`
`they
`recognize andchoose among a limited set of visible alternatives;
`respond more than initiate. Command language users are often called on
`to accomplish remarkable
`feats of memorization and typing.
`For
`example, does it make sense to type the UNIX command:
`
`GREP ~V “S13, FILEA > FILEB
`
`to get printout on
`in order to delete blank lines from a file? Similarly,
`unlined paper with the IBM 3800 laser printer, a user at one installation
`was instructed to type‘
`
`CP TAG DEV E VTSO LOCAL 2 OPTCD=J F'=387l X=GBl2
`
`The puzzled user was greeted with a shrug of the shoulders and the
`equally cryptic comment that “sometimes logic doesn’t come into play,
`it’s just getting the job done.” This style of work may have been
`acceptable in the past, but user communities and their expectations are
`
`

`
`Ch. 4 Command Languages
`
`139
`
`changing. The empirical studies described in this chapter are beginning
`to clarify guidelines for many command language design issues.
`
`Command languages may consist of single commands or have complex
`syntax (Section 4.2). The language may have only a few operations or
`thousands. Commands may have a hierarchical
`structure or permit
`concatentation to form variations (Section 4.3). A typical form is a verb
`followed by a noun object with qualifiers or arguments for the verb or
`noun. Abbreviations may be permitted (Section 4.5). Feedback may be
`generated for acceptable commands and error messages (see Section 8.1)
`may result
`from unacceptable forms or
`typos. Command language
`systems may offer the user brief prompts or they may be close to menu
`selection systems (Section 4.6). Finally, natural language interaction can
`be considered as a complex form of command language (Section 4.7).
`
`4.2 FUNCTIONALITY TO SUPPORT USERS’ TASKS
`
`People use computers and command language systems to accomplish
`tasks. The most common application of command languages is for text
`editing;
`other
`applications
`include
`operating systems
`control,
`bibliographic retrieval, database manipulation, electronic mail, financial
`management,
`airline or hotel
`reservations,
`inventory, manufacturing
`process control, and adventure games.
`
`The critical determinant of success is the functionality of the system.
`People will use a computer system if it gives them powers not otherwise
`available.
`If the power is attractive enough, people will use a system
`despite its poor user interface. Therefore, the first step for the designer is
`to determine the functionality of the system by assessing the user task
`domain.
`
`In a misguided effort
`A common design error is excess functionality.
`to add features, options, and commands, the designer can overwhelm the
`user. Excess functionality means more code to maintain, potentially
`more bugs, possibly slower execution, and more help screens, error
`messages, and user manuals
`(see Chapter 9).
`For
`the user, excess
`functionality slows learning, increases the chance of error, and adds the
`confusion of longer manuals, more help screens, and less specific error
`
`

`
`140
`
`Designing the User Interface
`
`insufficient functionality leaves the user
`messages. On the other hand,
`frustrated because an apparent function is not supported. For instance,
`the system might require the user to copy the contents of the screen by
`hand because there is no simple print command or to reorder the output
`because there is no sort command.
`
`from a study of 17
`Evidence of excessive functionality comes
`secretaries at a scientific research center who used IBM’s XEDIT editor
`for a median of 18 months for 50 to 360 minutes per day (Rosson, 1983).
`Their usage of XEDIT commands was monitored for five days. The
`average number of commands used was 26 per user with a maximum of
`34;
`the number of commands was correlated with experience (r=.49).
`XEDIT has 141 commands, so even the most experienced user dealt with
`less than a quarter of the commands. Users did not appear to employ
`idiosyncratic subsets of the language but added commands to their
`repertoire in an orderly and similar pattern.
`Careful task analysis might result in a table of user communities and
`tasks with each entry indicating expected frequency of use. The high
`volume tasks should be made easy to carry out, and then the designer
`must decide which communities of users are the prime audience for the
`system.
`‘Users may differ in their position in an organization,
`their
`knowledge of computers, or their
`frequency of system usage. One
`difficulty in carrying out such a task anal