[Skip Navigation] [CSUSB] / [CNS] / [Comp Sci & Eng Dept] / [R J Botting] >> [papers] >> rjb84a.FRED
[Index] [Contents] [Source] [Notation] [Copyright] [Comment] [Search ]
Sat Jan 24 12:34:27 PST 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 ( Sat Jan 24 12:34:27 PST 2009 ). Permission is granted to quote and use this document as long as the source is acknowledged.


Contents


    FRED - A FRIENDLY EDITOR

      Richard J. Botting, Ph.D., B. Tech., Chairman, Department of Computer Science California State College San Bernardino, California

      Abstract

      A simple editor is described. The designer analysis four problems and presents his solutions. He gives the good and bad features of each solution. A key theme in the project was tailoring the program to fit the user: The program keeps a special memory of each user and so adapts as they grow more knowledgeable. It also allows an edit to be stopped and restarted later. The editor is simple and most users go on to other editors after their first two quarters. Unexpectedly some users who are not naive do use it because they don't have time to spare to learn a complex word-processor.

      1 INTRODUCTION

      In September 1983 I decided to use Pascal in our Computer Science BS at California State College, San Bernardino. The existing editors were not easy to learn and incompatible with each other. It seemed feasible to produce an editor especially for undergraduates to write their first programs. I decided to make this an experiment on 'user friendliness'.

      2. LIMITED RESOURCES (PROBLEM 1)

      The first problem to be faced was the lack of hardware, people, and time. With less than one man-month of time available and with the majority of visual display units having no complex functions; the power of the editor would have to be limited. I decided to have the simplest possible line oriented design. It allows only simple "cut and paste" operations. Beginning students write small programs so I limited file size to 250 lines and kept a working copy of the file in an array.

      The first version was ready for use by the end of December. Few bugs have been reported. Experts dislike the lack of power and do not use it. The size limit encourages modular programming and has never been extended in any student version.

      3. REDUCING NEED FOR TRAINING (PROBLEM 2)

      The objective was an editor which could be used after a 30 minute demonstration plus an average of 5 minutes help per user. In the first quarter with the new editor the computer center people noticed a drop in the number of questions.

      To do this it had to fit the user's expectations and skills. I had observed that beginning students could:

      On the other hand they had no experience of:

      So the original version had none of these features and used the familiar ones instead. The final version has a single menu and this only appears with a sophisticated user. The student follows the normal pencil and paper cycle of:

    1. Find line; Cut; Paste;.

      Similarly, the file is displayed with line numbers (1,2,3,4, . . . ) and only 11 lines are shown at one time. The line to be changed has a'>' in front of it. I have found that the above explanation gets most students started.

      This simplicity has an unexpected consequence:

      Busy people (a biologist, the author, the department's secretary, . . . ) use it for word processing rather than learn more powerful editors.

      4. REWARDING CORRECT INPUT (PROBLEM 3)

      Programs often output "rewarding" statements like "OK" "Well done", etc. But users are rewarded by seeing their work approach completion. They are discouraged by actions which delay their progress. Artificial reinforcement is not required: Just showing the results of their actions would provide the exact reinforcement needed. Past experience [R1] had shown that giving a window of 11 lines surrounding the line being worked on was about right on most VDUs.

      A later improvement was to quickly print the new line after it changed. This provided immediate corrective feedback.

      This conversation is typical:

       LNo? 34
       34>        if x < 3 then
       Cut? 3
       -----------------|3|
       New? 0
       34>        if x < 0 then

      5. ADAPTING WITH THE USER (PROBLEM 4)

      A system designed to fit a user must change as the user changes [R5] or be outgrown. Jackson System Development [R4] is based on dynamic models of the user's world. Jackson's ideas were used to make the program more useful.

      The program has a special memory of each user. The program memorizes the student's name and can automatically insert identification at the head of new programs. It also store"s the name of the last used file and presents the option of going back to the old file." If 'chosen the editor recalls the line last selected. So at any time the"user can quit out leaving an updated file and later continue the interrupted edit; Thus; if the user wants advice he or she can stop and restart with minimal hassle (3).

      Some interesting consequences of this design technique are as follows: (1) New users are noticed and given more information. (2) When a user feels he or she doesn't need the extra information the program expects the user to get familiar with the system; ten edits later it shortens the prompts. (3) A new version recognizes each user who has only used the old one and adjust its behavior. (4) A user who hasn't used the system for a month or so is given the opportunity to review the beginner's information in case he or she has forgotten something.

      There is a cost: A file with one record is kept in the user's account. This takes space but keeps personal data private.

      6. CONCLUSIONS

      It is possible to quickly produce an editor which is easy to learn by cutting back the functionality to the limit and taking time to design accurate feedback to the user. Another paper[R2] describes how this editor was developed further by interpreting erroneous inputs as if they were commands. The result is not as powerful as an expert desires. They move on to other editors but the simple editor was used by the author to prepare this article because he did not have time to learn a more complex editor.

      7. REFERENCES


      (R1): Botting, Richard J. & J. P. A. Race, "Homebrew Word Processing on the Wang 2200B" , IUCC Conference Lancaster University, 1978.


      (R2): Botting, Richard J., "Generalization - An Alternative to Error Messages", Eight Annual Western Educational Computing Conference, California Educational Computing Consortium, 1984. [ rjb84b.Generalization.html ] [Botting84b]


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


      (R4): Jackson, Michael A., System Development, Prentice Hall International 1983.


      (R5): Quirk, William G., "Designing for Novice and Expert", Computer World., In depth, P4-1,0', Oct 31, 1983.

      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 Brunel University and taught computer programming and various theoretical topics. From 1979 to 1982 he taught structured methodology at 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 FRED - A FRIENDLY EDITOR) <<Contents | End>>

End