An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications

An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications

An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications J. F. KELLEY IBM Thomas J. Watson Research Center A six-step, iterative, empirical human factors design methodology was used to develop CAL, a natural language computer application to help computer-naive business professionals manage their personal calendars. Input language is processed by a simple, nonparsing algorithm with limited storage requirements and a quick response time. CAL allows unconstrained English inputs from users with no training (except for a five minute introduction to the keyboard and display) and no manual (except for a two-page overview of the system). In a controlled test of performance, CAL correctly responded to between 86 percent and 97 percent of the storage and retrieval requests it received, according to various criteria. This level of performance could never have been achieved with such a simple processing model were it not for the empirical approach used in the development of the program and its dictionaries. The tools of the engineering psychologist are clearly invaluable in the development of user-friendly software, if that software is to accommodate the unruly language of computer-naive, first-time users. The key is to elicit the cooperation of such users as partners in an iterative, empirical development process. Categories and Subject Descriptors: D.m [Software]: software psychology; H.1.2 [Models and Principles]: User/Machine Systems--human factors; 1.2.1 [Artificial Intelligence]: Applications and Expert Systems--natural language interfaces; 1.2.7 [Artificial Intelligence]: Natural Language Processing--language parsing and understanding; 1.6.3 [Simulation and Modeling]: Applications; K.6.3 [Management of Computing and Information Systems]: Software Management--software development General Terms: Experimentation, Human Factors Additional Key Words and Phrases: Natural language, limited context, naive user, discretionary user, iterative design, simulation, user-friendly, ease-of-use, empirical grammar, task analysis, engineering psychology. 1. INTRODUCTION Computerized office applications employ one of three modes of input: menus, command languages, or natural language. According to one view. the suitability of a particular mode of input depends on the "semantic" and "syntactic knowl- This work was mostly supported by a research agreement with the IBM Corporation Systems Products Division, under the supervision of Prof. A. Chapanis, Dept. of Psychology, The Johns Hopkins University. Portions of this material appeared in the Proceedings of the CHI '83 Conference on Human Factors in Computing Systems, Dec. 1983. Author's address: IBM, Thomas J. Watson Research Center, Room ST-K40, P.O. Box 218, Yorktown Heights, NY 10598. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. © 1984 ACM 0734-2047/84/0300-026. $00.75 ACM Transactions on Office Information Systems, Vol. 2, No. 1, March 1984, Pages 26-41. An Iterative Design Methodology 27 edge" of the user [11]. Menus might best serve a person who is not familiar with the computer's command structure (low syntactic knowledge) and who is uncer- tain how to proceed in solving his particular problem (low semantic knowledge); the menu tells the person which responses to make at any given time, leading him through the problem-solving process. Command languages are good for people who know what steps they want to undertake to solve a problem and are familiar with the computer's syntax for accomplishing each step. This view holds that a natural language interface might be appropriate for people who have a high level of semantic knowledge in a problem domain, but aren't familiar with any special computer syntax for achieving their goals. While experts are pessimistic about the general implementation of a program that can "understand" and respond meaningfully to unrestricted natural utter- ances on a range of topics from naive users, such a program would certainly entice "a large number of people who are potential computer users [but] are unwilling to learn and then use a formal machine language." ([9], p. 314). The principal purpose of the research reported here was to design and test a systematic, empirical methodology for developing context-dependent natural language computer applications. This paper describes that methodology and its successful use in the development of a natural language computer application: CAL, Calendar Access Language. The limited context or domain in which the application operates is the management of a personal calendar, or office appoint- ment database by computer-naive business professionals. Designers of natural language systems have, in the past, begun with a compre- hensive model of the language expected in a particular domain and have built up recognition systems from there (see, for example [10, 13, 14, 15]). Contrary to that "armchair" method of program development, this research involves an iterative empirical development approach (which has recently been aptly dis- cussed in [3]). 2. METHODOLOGY The development process for CAL comprised six steps [5]. Central to the methodology is an experimental simulation which I call the OZ paradigm, in which experimental participants are given the impression that they are interact- ing with a program that understands English as well as another human would. In fact, at least in the earlier stages of development, the program is limping along, only partly implemented. The experimenter surreptitiously intercepts communications between participant and program, supplying answers and new inputs as needed. The six steps of program development are follows: (1) Task analysis. Twenty-three business professionals were interviewed ex- tensively to discover how they keep their appointment calendars. That informa- tion provided a starting point for the functional specification of a computerized calendar [4]. For the majority of the persons interviewed, calendars are indis- pensable to the conduct of their business and, in some cases, their personal lives. The data from this step show an unexpectedly large amount of diversity in the kinds of calendars people use and in the ways they use them. Substantially more than half of the respondents have more than one calendar, with two persons using as many as six calendars at once. Portability and access from diverse ACM Transactions on Office Information Systems, Vol. 2, No. 1, March 1984. 28 • J.F. Kelley locations are important for many. Concerns about privacy vary widely: some keep their calendars closely guarded, others allow free access to them. Relevant time spans covered by calendars are enormous. Some few people are concerned only with the current day and the day following, others may plan appointments a year or more in advance. A substantial number of appointments are changed after they have been made and, once again, the range is large, from about 2 percent for some persons to about 80 percent for others. Archiving, query patterns, and the insertion of correlated information into calendars also vary greatly among users. (2) Deep structure development. In this second step of program development, the database manipulating functions were written in APL. (3) First run of OZ (simulation). Here, no language processing components were in place. The experimenter simulated the system in toto. This simulation is similar to the ones used in [2] and [12]. (4) First-approximation language processor. The corpus of inputs obtained in step three was used to develop a first approximation of the language processing subroutines (described in [6]). (5) Second run o[ OZ (intervention). This was the iterative design phase of program development. Fifteen participants used the program, and the experi- menter intervened as necessary to keep the dialog flowing. As this step progressed, and as the dictionaries and functions were augmented, the experimenter was phased out of the communications loop. (6) Cross-validation. The final program was tested with six additional partic- ipants to see how well it performed. In this step the program ran without any assistance from the experimenter. Various measures of program speed, "under- standing," and efficiency were combined with the results of postsession interviews to evaluate CAL's success. 2.1 Apparatus Participants and experimenter communicated via IBM 3277 displays and key- boards to an APLSV program residing in an IBM 370/168 host system. During the simulation and intervention steps of the development (first and second runs of OZ), all communications between the participant and the program were channeled via shared variables and appropriate software through the experimen- ter's workspace. Both participant and experimenter, working in separate rooms, communicated with the host system via a Bell System 4800 baud modem and an IBM 3271 controller. A two-way push-to-talk intercom was provided for voice communication between the participant and the experimenter. The keyboard used by the participants in the iterative design phase of OZ and in the cross- validation was modified by abbreviating the available editing functions to include only backspace, forward cursor motion,

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    16 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us