Handling Feedback, Errors, and Warnings

In Chapter 12, "Client-Side Validation," we created quite a powerful process of managing custom server-side errors based on database information with the ErrorManager and UserValidator objects. In this chapter, we will take what we learned about displaying these errors to the user and go a step further by focusing on all forms of messages that need to be presented to a user in an application. We will take a look at a few figures that show different ways of displaying messages to a user and how to keep them consistent across an Ajax application. We will also learn how to create a very simple dialog object in the section, "Designing with Code," that will have a display method for custom messages of all kinds. This object will be focused on creating visual elements with the DOM and cascading style sheets (CSS). Let's first start with a very obvious and detrimental issue that occurs with all JavaScript applications.

One of the most obvious issues with Ajax applications is the fact that they use JavaScript and, although not often, some users may actually have JavaScript disabled. If we are developing an Ajax application, we really should add a quick line of code that informs non-JavaScript users how to enable it if they would like to use the application, just in case they do not know how. It is very easy to do this with the noscript HTML tag. Listing 19.1 is a quick example of how we could inform non-JavaScript users of the issue.

Listing 19.1. Displaying a Message for Non-JavaScript Users

<noscript>This application requires that your browser has JavaScript enabled.</noscript>

This message can be anything you decideit can explain how to enable JavaScript, what benefits it will provide, and so on. The choice is yours, so be creative.

Originally, I was going to separate feedback and errors into two different sections of this chapter, but as I thought more about it, I realized the best responses are the ones that are handled the same way throughout an application with very subtle but obvious design differences. When I say design differences, I mean colors, font decorations, and other display differences, not the interaction model. For example, errors could have a red background or font color, whereas successful feedback messages could use green. Keeping interaction models the same is the key to obtaining consistency in an application and ultimately the user experience. Each time we introduce a new interaction, users have to take the time to learn a new concept and are taken out of their current workflow, whicheven if for only a secondchanges the course of their experience. This means that if we are going to make users take the time to learn a new interaction, it should be up front and extremely obvious to the point that they may not even be aware that the interaction is something creative that we customized. Also, if we keep the interaction model consistent, we allow the workflow to progress without interruption. This allows users to solve the problem that they are using our application for in the first place, in a timelier manner. Interaction models could include fading messages, highlighting form fields, and so on. Again, this is your choice, so be creative.

Figure 19.1 has a combination of quite a few forms of error handling that I have mentioned so far in this chapter. Combining error-handling methods can really help users understand exactly what it is that they need to fix in order to move forward with their workflow. How many forms of error handling are there in this one figure? Obviously, it is not as easy to know without a working sample, but this figure actually features five forms of error handling. The first two are the most obvious: The first is the actual message at the top of the page that explains the errors, and the second is the highlighted fields in the form that correspond to the errors presented in the message. Again, it is a bit hard to notice without a working example, but the other error handlers include the cursor that appears in the first form field that has created an error, and hyperlinks on each actual error in the message at the top of the page, which when selected bring you to the form element to which it corresponds and adds the cursor to that field.

Figure 19.1. Handling errors with multiple combinations.

As Figure 19.2 shows, after the field has been updated, the strikethrough appears for the error that has been updated, and the hyperlink becomes disabled and disappears.

Figure 19.2. Adding feedback based on user error corrections.

Figure 19.3 shows an additional form of error handling that is a unique and unobtrusive way to help display errors to users. After the form has been submitted and errors occur, the form will not only highlight the incorrect form fields as our last solution did, but it will also display a "bubble" message above the first form field that caused an error and disappear along with the highlight color on the field after the error has been corrected. At this point, if there are more errors, the bubble will appear above the next error in the form and the cursor will move to that form element. To make it even more apparent, if the next form field happens not to be within visibility due to a scrollbar, the page will scroll to the location of the incorrect form field and bring it into focus.

Figure 19.3. Displaying feedback directly above form elements.

Designing with Code

As I mentioned at the beginning of this chapter, this section will explain how to create custom messages with an object called Dialog. This object will display a message based on CSS classes that we connect to it and will render itself based on the properties we define in these classes. Listing 19.2 shows the Dialog object in full, which is simply the instantiation of the object and a method called display. We know what the instantiation declaration looks like at this point, so we will focus on covering the display method, which is the meat of this object. The display method takes three parameters. The first is a unique id that will represent the actual id of the div that is created as the dialog in the front end. The second parameter is the class name that we will use to connect the div to a custom CSS class that will define the properties we define. The last parameter is the message that we would like to display to the user to provide feedback, errors, or warnings.

After the method has been called and we have passed all the parameters, the first thing our method does is create a div element that will become the dialog in the front end and, ultimately, display the message to the user. After we have created the element with the Utilities object from Chapter 9, "Extending the Engine," we define the elements id and className properties by making them equal to the parameters we passed to the method when we fired it. In order to get the correct message to display to the user, we will use the innerHTML property of the div element to display our custom message to the user. Last, we must have a way to add the completed dialog to the page the user is currently using. We will do this by appending the element to the document body, once again with our handy Utilities object.

Listing 19.2. The Dialog Object (Dialog.js)

Dialog = {}; Dialog.display = function(id, c, message) {     var d = Utilities.createElement("div");     d.id = id;     d.className = c;     d.innerHTML = message;     Utilities.appendChild(document.body, d); }

In order to use this method, we must have an HTML page to import the appropriate objects. The following code shows how to import the Dialog and Utilities objects along with a corresponding CSS file that we will create shortly, and a method call to display an error at the top of the page.

<html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <title>Ajax Message Dialogs</title> <link href="css/dialog.css" rel="stylesheet" type="text/css" /> <script type="text/javascript" src="/books/1/87/1/html/2/javascript/Utilities.js"></script> <script type="text/javascript" src="/books/1/87/1/html/2/javascript/utils/Dialog.js"></script> </head> <body onload="Dialog.display('dialog', 'error', 'Please correct the following errors.');"> </body> </html>

You probably noticed we are only creating an error message in this page and that it does not even correspond to anything. Well, you are rightthis is simply an example of how to display a custom dialog, but I will also show you how to display the other two types with the following code. This code shows how to create a warning and a success feedback message.

Dialog.display('dialog', 'warning', ' Your form submission was successful, but you did not enter a web site URL, click here in order to update this record.'); Dialog.display('dialog', 'success', 'Your form submission was successful!');

The success message works very similarly to the error message because it is straightforward, but the warning works a bit differently and takes a bit more thinking on our part. If we display a warning to users, we must provide them with a way to ignore it or act on it by updating the data based on the issue. In the sample code, I have a message that says click here. As an example, this could be a hyperlink that links users to a form that allows them to update the information that produced the warning, or they could choose to ignore it and move on to another area of the application.

Now that we have the method that creates the dialog and we are calling it from the application, we will have a simple message that will display to users. However, there will still not be any style to the element until we create the CSS that corresponds to the id and class name we defined. In order to define the classes that correspond with different types of messages, the application may need to display to the user that we will create a CSS file called dialog.css. This file will contain four custom classes. The first will be a class that all the messages will share by corresponding to the dialog id that we passed as the first parameter to the Dialog object's display method. This class will contain the font weight and the padding for the messages, and will ensure that all our messages are consistent in this way. The code in Listing 19.3 shows this class as it is defined in the dialog.css file.

Listing 19.3. The Dialog CSS Class (dialog.css)

#dialog {     font-weight: bold;     padding: 5px; }

After we have this shared class defined, we can focus on defining the individual classes that correspond to each of the different types of messages that an application can have. Again, the different types we will be focusing on are the error, warning, and success feedback messages. In this example, we will simply change the color of the background based on the message type, but we could use many different CSS properties to make these messages distinctively different from one another. Errors will have a red background color, warnings will be orange, and success messages will be green. It doesn't get much more apparent than this, but there is always room for improvement. Listing 19.4 shows all of these classes as they are defined in the dialog.css file.

Listing 19.4. Specific Classes for Each Corresponding Message Type (dialog.css)

#dialog.error {     background-color: #ff0000; } #dialog.warning {     background-color: #ff9900; } #dialog.success {     background-color: #00cc33; }

These classes extend the dialog id element class by specifically specifying the dialog div as the base class and then appending each message type as the class name for each message. These also happen to be the names that we pass to the display method to connect the correct class to the message. With all of this code in place, we can very easily provide feedback for any form of message with which we need to inform the user. Creating all of this code up front will actually save you a lot of grief in the long run, especially if you work on a team with members who are responsible for displaying their own feedback to the user. This way, we as the design-oriented developers do not need to be concerned with inconsistencies between each team member's messages, and I am sure they will be happy that they do not need to define their own messages as well.