No abstract

No abstract

This paper discusses the problem of recognizing and responding to plan-oriented misconceptions in advice-seeking dialogs, concentrating on the problems of novice computer users. A cooperative response is one that not only corrects the user's mistaken belief, but also addresses the missing or mistaken user beliefs that led to it. Responding appropriately to a potentially incorrect user belief is presented as a process of 1. checking whether the advisor holds the user's belief; 2. confirming the belief as a misconception by finding an explanation for why the advisor does not hold this belief; 3. detecting the mistaken beliefs underlying the misconception by trying to explain why the user holds the incorrect belief, and 4. providing these explanations to the user. An explanation is shown to correspond to a set of advisor beliefs, and searching for an explanation to proving whether various abstract configurations of advisor beliefs hold. A taxonomy of domain-independent explanations for potential user misconceptions involving plan applicability conditions, preconditions, and effects is presented. INTRODUCTIONA novice computer user having trouble performing a task often describes his problem to an expert, who is then expected to explain its cause and provide its solution. Consider, for example, the following adviceseeking dialog between a novice UNIX user and his more experienced counterpart.User: I tried to remove a file with the "rm" command. But the file was not removed and the error message was permission denied. I checked and I own the file. What's wrong? Advisor: To remove a file, you need to be able to write into the directory containing it. You do not need to own the file. User: How do I make that directory writeable? Advisor: To make a directory writeable, use the "chmod +w" command. User: Wait a second while I try it. No, "chmod +w" prints the error message "permission denied". Advisor: To make a directory writeable, you need to own it. User: So to remove a file, I have to own the directory that contains it.Advisor: No, to remove a file, you need to have write permission on the directory that contains it. You do not need to own the directory that contains it. You need to own that directory when you do not already have write permission on it. User: So how do I remove the file? Advisor: Send mail to whomever has write permission on the directory, asking him to remove the file for you. Participating as the advisor in such a dialog requires the ability to recognize and respond to missing or mistaken user beliefs about plan applicability conditions, preconditions, and effects. The advisor above recognizes two user misconceptions. The user first incorrectly believes that owning a file is a precondition to removing it, and then incorrectly believes that the precondition is owning the directory containing it. This advisor also notices several gaps in the user's knowledge. The user has no plan for making a directory writeable, does not know why the advisor's plan for doing so failed, and has no plan for removing a fi...

Visual programming research has largely focused on the issues of visual programming-in-the-small. However, entirely different concerns arise when one is programmingin-the-large. We present a visual software engineering environment that allows users to construct visually programs consisting of hierarchically organized networks of components that process streams of arbitrary objects. We discuss the problems that occur when trying to construct systems consisting of thousands of interconnected components, examine how this environment deals with some of the problems specific to visual programming-in-the-large, and show why our initial solutions failed to scale successfully. Finally, we argue that a single visual mechanism called "zooming" addresses these scaling problems and, when suitably augmented, can also support automatic component discovery and intelligent error correction.

No abstract