hobbs@tove.umd.edu (James David Hobbs) (01/13/90)
I am pursuing effective command-line spelling correction for Unix. Such a system would ideally increase user-efficiency for two major reasons. The users would not be spending time and becoming frustrated correcting trivial slips. Also, they could preserve their train of thought on the task at hand instead of the computer details. I have already implemented two such systems, but neither have been very effective. The first system was tested on computer novices through the University of Maryland Psychology subject pool. The second was aimed at more Unix-knowledgeable users. There seem to have been two significant problems with both of these systems: 1) the user felt out of control and 2) the output was too verbose. The most difficult problem is the interplay of user control and preserving task train of thought. Ben Shneiderman brought up an analogy for this problem: In word procesors the spelling correction is not usually made immediately. We both assume this is largely so that the user stays in control. The second system that I implemented waited until a return was hit, then, if a slip was made, produced a corrected line and asked for confirmation. Here, the user can keep typing even when he or she knows a slip was made, simply assuming that the correction will be made. The problem is the user is not totally in control. Another extreme might be to check every blank-terminated word immediately, and just beep when the user seems to make a mistake. Here, the user will more easily break her or his train of thought. Any comments on command-line spelling correction in general? Any comments on how to balance user control/task train of thought? Would anyone be interested in using the next (Sun) system?
jhc@iris.brown.edu (James H. Coombs) (01/13/90)
If you are trying to help naive users, then you also need to address the problem of associating the proper keyword with the desired command. Spelling correction might help in this process, but errors will often not be a matter of spelling. Is there also a problem of generating "corrections" that do not map onto Unix commands at all? I can't tell from your posting. Anyway, you might want to take a look at this article: Dumais, Susan T., George W. Furnas, Thomas K. Landauer, Scott Deerwester, and Richard Harshman. Using Latent Semantic Analysis to Improve Access to Textual Information. Proceedings of CHI '88. 281-85. I hope I have grabbed the right reference. I associate the work with Landauer and Furnas, and that's the only citation I have in my bibliography for Furnas. It will get you on the track in any case. --Jim Dr. James H. Coombs Senior Software Engineer, Research Institute for Research in Information and Scholarship Box 1952, Brown University, Providence, RI 02912
chuck@melmac.harris-atd.com (Chuck Musciano) (01/15/90)
In article <21791@mimsy.umd.edu> hobbs@tove.umd.edu (James David Hobbs) writes: >I am pursuing effective command-line spelling correction for Unix. >Such a system would ideally increase user-efficiency for two major >reasons. The users would not be spending time and becoming frustrated >correcting trivial slips. Also, they could preserve their >train of thought on the task at hand instead of the computer details. Win Strickland did his master's thesis on this topic at Georgia Tech around 1982 or so. He produced a "backstop" which provided command name spelling correction based upon patterns of typographic errors committed on qwerty keyboards. I liked this tool a lot, and always used it. You could configure it to prompt you with a correction, or to automatically correct, or whatever. You might want to get a copy of his thesis from Ga Tech. Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} Gee, Beaver, everything that's fun can get you in trouble. Haven't you learned that yet? --Gilbert