- From: Marjolein Katsma <access@javawoman.com>
- Date: Tue, 25 Apr 2000 12:28:52 +0200
- To: w3c-wai-au@w3.org
It seems I understand the terms "Alert" and "Prompt" very differently from the rest of the group. I also found this actually very hard to explain on the phone. I'm not sure where this difference comes from (my background as a software developer?), but of course I also missed the start of the definition process in this group. So I'll attempt to write down my definition of these terms here: First, I see a very fundamental difference between an alert and a prompt. The basic difference is in the direction of the information stream. I'll start with some defionitions, and then give a few examples to illustrate. 1. Alert An alert is what happens when a process needs to *inform* the user of a situation that has occurred, of a status. The user never asks for an alert, and the information stream is always from the process to the user. It can take several forms, for example a red error message on a status line, or a popup window. 2. Prompt A prompt is a means for a process to *request* information from the user, to be used as data in that process. Prompts can occur in a linear process (question, answer, next question, next answer), or as input controls in a dialog. (A dialog itself is not a prompt.) The initiative can come either from the process, or from the user (the user can ask for a dialog to be displayed, or it can be popped up because the process cannot continue without new data). The actual information stream is from the user to the process, reagrdless which party took the initiative to display the prompt(s). 3. Required is a property that can be on or off. Neither an alert, nor a prompt, by itself actually *requires* a reaction or data from the user. Whether or not reaction or data is required is a *property* of the alert or prompt. For instance, the same prompt for the same piece of information can be required on one, but optional on another dialog, depending on context. A few examples: Alert - example 1. While the user is coding or testing some code, the status line may alert the user to some error; the user may choose to ignore this, and just continue coding, for instance because the error is a result of some missing code that will be added the next day. Alert - example 2. The user has instructed the system to print a document; the system attempts to do this, but then pops up a window with the message: "Error writing to LPT1: for Document [document name]: the printer is out of paper. Do you wish to retry or cancel the job?" Two buttons: Retry and Cancel Of course, the user may decide to cancel, and choose the Cancel button. Or, the user may choose the Retry button, because someone else is already filling the paper tray. Or the user may not choose either of the buttons, but knowing the printer is off-line flip a switch to bring the printer on-line again, whereupon the window will automatically disappear and printing will start: the process is contuously checking the actual situation even while the alert is displayed. This is an alert where the *situation* the user is alerted to requires some response, a reaction - but the alert itself does not. No *information* is needed, just something to be done by the user. Alert - example 3. The user picks a folder to go to from a previously stored list. An alert pops up with the message: "The selected folder is unavailable. Either it has been deleted or it is on a drive that is no longer connected." One button: OK. This can happen for instance with removable drives, or with a connection to a remote system that has gone down (or not been established yet). Cancel is not appropriate here, since there is nothing *to* cancel. But the process is informing the user it cannot continue. This window will not go away until the user has acknowledged the message by activating the OK button. Since there is no background process available to make a connection (it would require a separate action from the user), the message window is modal, it will not go away by itself. So here, the alert itself *requires* a reaction from the user. Prompt - example 1. User wants to print a document and chooses File -> Print from the menu rather than pressing on the "Print" toolbutton. A dialog pops up, allowing the user to accept or change parameters for the printing process. Now, assuming the system conforms to standards and the user knows how this works <grin> going through this dialog is the user's choice (the print toolbutton would just start printing with the *current* parameters). The dialog doesn't actually require the user to enter or change anything, it merely *allows* the user to inspect and / or change the current settings. Still, some of the prompts on the dialog can themselves require information from the user; in fact, they can be designed to automatically always provide some information, such as a dropdown list of printers to choose from. The prompt for printer has "required" as an attribute implicitly, because the control itself makes it impossible to leave it empty. Prompt - example 2. A dialog to enter or update all the data for an IMG tag in an HTML document; the dialog contains a prompt for each of the possible attributes. So the dialog contains an input field for an ALT attribute and can inform the user that the *attribute* is required; still, the user has the option not to provide any information for that prompt (maybe because an empty ALT attribute is the best option for this specific image, or because the information will have to be provided later). The dialog itself maybe popped up by the program as part of the process of inserting an image, or the user may choose to display the dialog as an easy way to enter all the information and write out the code in a consistent order. The prompt for ALT does not have the "required" property. Prompt - example 3. A wizard which guides the user through a complicated series of steps to accomplish an action. The user chooses the process, or chooses to accomplish the process with the Wizard rather than by another means. Some of the pages may have prompts for required information: when the intended process cannot be run without this information (the Finish button will be disabled), or the Wizard cannot decide which page to display next without this information (the Next button will be disabled). By disabling either or both of the Next and Finish buttons, the Wizard makes sure all information required for the process is provided. (The user can still cancel out of the Wizard, though.) Well, I hope this clarifies how I understand Alerts and Prompts. Fundamentally different (direction of information stream), and neither necessarily *requiring* anything from the user. "Required" reaction (alert) or information (prompt) can be a property, but this property does not always have to be "on". Cheers, Marjolein Katsma HomeSite Help - http://hshelp.com/ Bookstore for Webmasters - http://hshelp.com/bookstore/bookstore.html
Received on Tuesday, 25 April 2000 06:30:06 UTC