Error-Checking, Default Values, and More

Error-proof handling of input is not necessarily part of the visible interface, but it's still part of the interface. You want to make sure that dialog boxes are ready to receive input, that they include default values when appropriate, and that they stay out of the user 's way but stop him from making disastrous coding mistakes. Macromedia suggests the following:

Focus and Selection

If the dialog box includes one or more text fields, the first of these should have keyboard focus so that the user can immediately start typing without having to click in the field first.

Also, if the dialog box comes up with default contents in the text field, contents should be selected so that the user doesn't have to select and delete them before typing.

Both of these functions are handled by the two lines of code you've been entering in the locally defined initializeUI() function:

 document.myForm.firstTextField.focus();  document.myForm.firstTextField.select(); 

By defining this function and calling it by using the onLoad event handler, you accomplish this interface requirement.

Error-Checking

What happens if the user supplies bad information or no information in a dialog box? An attribute requires a numeric value, but the user enters a filename by mistake. A required attribute for a certain tag is left blank. What should a good interface do?

Hands-Off Philosophy

The Macromedia philosophy is this: Do nothing unless the mistake will actually "break" the page in a browserin other words, if it will cause visitors ' browsers to crash or display the page disastrously wrong. If the error causes some page element to "fail gracefully," you shouldn't interfere with it.

Why such a hands-off approach? One of the reasons web designers love Dreamweaver is that it stays out of their way, not insisting that it knows coding better than the user does. Users might not be making mistakes; they may be applying newly evolving coding standards or creating effects the software authors could not expect as they're writing the software. Therefore, you must assume users know what they're doing until they absolutely prove otherwise .

Preventing Disasters

It's all about form validationusing event handlers to check user input as soon as it's entered and before it becomes part of the document. Luckily, you only have to interfere when certain input (or lack of input) will break the page, and, surprisingly, it's not that easy to truly break a Web page. A table formatted with width="fred" probably won't display quite as the user intended, but it probably won't ruin the display of the entire page. Therefore, in its Table object, Dreamweaver won't interfere if a user enters this value. However, just try adding a Swap Image behavior without specifying an image to use as the rollover state. Dreamweaver won't let that happen because rollover code without a source image specified will generate a JavaScript error in a browser.

What should you do if some user input will cause a disaster, and must be prevented? The appropriate response is to show an alert dialog box, explaining the reasons why the input is invalid and returning the values to their previous, or default, settings. Figure B.20 shows this happening with the Swap Image behavior.

Figure B.20. A dialog box showing the interface response to invalid user input.

Default Values

Dialog boxes should not only function with strange user input; they should also function with no user input. Creating this situation isn't always possible, but you should take advantage of those situations in which it is possible. This can be accomplished in various ways, depending on the circumstances.

If the input value is for an optional parameter, obviously omitting to fill in the value should remove the parameter from the code. In this case, field can default to empty every time the dialog box appears, or a value can appear by default. The document code won't actually suffer in either case. The operative question here is the following: In most cases, do you think users will want a value there or not? And if so, what is probably the most likely value they'll want?

If the input value is required, it makes sense to have a default value always appear. Remember, though, that by "required," you mean the following: Will the page be ruined without a value here? If a missing value will cause one page element to display improperly but won't affect the rest of the page, this could be considered to fall under the non-interference policy. Your judgment is required to determine how much damage a page can suffer without being "broken."