[Skip Navigation] [CSUSB] / [CNS] / [Comp Sci & Eng Dept] / [R J Botting] >> [papers] >> rjb84b.Generalization
[Index] [Contents] [Source] [Notation] [Copyright] [Comment] [Search ]
Thu Aug 27 21:34:21 PDT 2009

This part of my site contains partly baked ideas (PBI). It has drafts for publications, essays, plus illustrations and visual aids for presentations and seminars.

Disclaimer. CSUSB and the CS Dept have no responsibility for the content of this page.

Copyright. Richard J. Botting ( Thu Aug 27 21:34:21 PDT 2009 ). Permission is granted to quote and use this document as long as the source is acknowledged.


Contents


    GENERALIZATION - AN ALTERNATIVE TO ERROR MESSAGES

      Richard J. Botting, Ph.D., B. Tech.

      Chairman, Department of Computer Science California State College

      San Bernardino, California

      Abstract

      The author proposes a novel solution to the problem of errors by describing how what would normally be treated as errors can be converted into features. He shows how a simple editor can be useful without conventional commands, errors, or HELP files. The process of making the system more helpful and useful is named "generalization". Several examples are given.

      1. INTRODUCTION

      Error handling has received some attention in the literature recently. [R2,R5,R6] It is a problem area with few friendly solutions. If the user makes a mistake and notices it he or she should be able to backtrack. Most other 'errors' occur when the user does something unexpected. While working on a new editor [R1], I decided that if the program can't handle something then the user doesn't want an error message. I analyzed such 'errors' and turned them into 'features'. This was like a step in Jackson Structured Programming (JSP) [R4] where the designer deliberately elaborates the good structures to allow for diagnosable errors and then other possible inputs. This paper outlines a variation on this elaboration process called "generalization".

      2. TYPING ERRORS

      As a first example: A common 'error' happens because the user ignores upper and lower case when specifying a piece of a line to cut. The editor looks for a perfect match first but if there isn't one will accept one with incorrect cases. Also the users are typists and use the Backspace (BS) key to delete things. For historical reasons the hardware and software stores the BS character and makes the DEL key do the backspace function.

      Similarly, the TAB key is stored but looks like a string of spaces. On the advice from a colleague at Dominguez Hills the editor replaces all BS and TAB characters so that what the user sees is what the user gets.

      3. BAD FILE NAMES

      Another 'error' message is "file not found". The editor assumes that no file means new file. Thus the user does not have to learn a command to create a new file. Usually the users will want a Pascal program [R1] and so the editor can automatically create a generic program for the user like this:

       file name? TEST
       Do you want a Pascal Program [Y/N/Q]? Y
       File TEST.PAS has 5 lines
       TEST.PAS at 5:40pm on 23-Feb-84
       1> Program TEST; {by Dick Botting on 23-Feb-84}
       2: <declarations>
       3: begin
       4: <statements>
       5: end.
       Lno?

      4. MODE MISTAKES

      Another class of 'errors' occurs because the user loses track of what the program expects to be done next[R5]. These mode mistakes mean that the program can sometimes be redesigned to enter the right mode. The program originally [R1] ran thru a cycle with three prompts (LNo? Cut? New?). What follows is an analysis of the input to LNo? showing how each 'error' can be interpreted as a command.

      The most obvious mistake is a number which is not a line number. An input of nothing or a zero can not be a line number but might indicate a desire to edit nothing more: so the program wraps up the edit if and as the user desires. Similarly, a number which is too big probably means a desire for a bigger file, so the program asks for input to extend the file. Finally, a negative number is interpreted as a desire to see part of the file and not edit it. This is an arbitrary feature that starts by confusing people but becomes indispensable. This feature needs rethinking.

      It is possible for the user to input a string and not a number. This is often because the user wants to cut the string out of the current line. So if the input matches part of the current line the program invites the user to replace it.

      Sometimes the user doesn't type in a text on the current line: the program assumes that the user has seen the input recently. The program searches the last displayed screen for the input string (First forward and then backward from the current line). It assumes that the match is what the user wants but can not be certain. The output is unique (I believe) in the history of systems programs:

       	I guess you want this line:

      If the input string doesn't fit in the previous display the program searches the entire file (first forward and then from the top down) for a matching string. It takes the first one as a line the user might be interested in and displays it (with 10 surrounding lines).

      Finally the user may type a text which the editor has never seen before. Conventionally this must be an error but users can do this on purpose. The program explains that it needs a line number or a text to search for. Thus a paradox: FRED has no HELP files or features and yet if the user inputs HELP it is provided[R3].

      5. CONCLUSIONS

      This project shows how a system can be fitted to a live user by repeatedly redesigning erroneous input as if it was a command. The design was based on the theory that the user is always right. The program becomes more useful and easier to learn as a result. The bad news is that redesign takes time and the resulting program is inefficient.

      6 REFERENCES


      (R1): Botting, Richard J. , "FRED - The Friendly Editor", Eighth Annual Western Educational Computing Conference, California Educational Computing Consortium, 1984. [ rjb84a.FRED.html ] [Botting84a]


      (R2): Brown P. J., "Error Messages: the neglected area of the man/machine interface?", Comm ACM, Vol 26, No 4, April 83.


      (R3): Houghton Jr., Raymond C., "Online Help systems: a conspectus", Comm ACM, Vol 27, No 4, Feb. 84.


      (R4): Jackson, Michael A., Principles of Program Design, Academic Press, A.P.I.C. Studies in Data Processing, No 12, 1975.


      (R5): Norman, Donald A., "Design Rules Based on Analysis of Human Error", Comm ACM, Vol 26, No4, April 83.


      (R6): Schneiderman, Ben, "Designing Computer System Messages", Comm ACM, Sep 82 Vol 25, No9, pp 610-611.

      Author

      Dr. Richard J. Botting has a Bachelors degree in Mathematics and a Ph.D. in Computer Science from Brunel University in England. His Ph.D. work produced a low cost portable graphics system. From 1970 to 1978 he was with the Computer Science Department at Briney University and taught computer programming and various theoretical topics. From 1979 to 1982 he taught structured methodology at the Civil Service College, London. He now teaches at California State College, San Bernardino and has been Department Chairman since 1983. His research interest is in the technology and methodology of software engineering.

      History

      This paper was originally presented at the Western Educational Computer Conference, San Diego November 1984, California Educational Computing Consortium. This is a transcription from an OCR scan of the published paper.

    . . . . . . . . . ( end of section GENERALIZATION - AN ALTERNATIVE TO ERROR MESSAGES) <<Contents | End>>

End