222CHAPTER 6

The user experience

between the client and web tiers, and adding a pluggable update handler function. Eventually we come full circle to the issue of informing the user of changes and asynchronous updates as they take place. In the next section, we look at our options for presenting this information to the user in a more workable fashion, and we’ll factor out that pesky alert() function.

6.3 Designing a notification system for Ajax

The alert() function that we’ve been relying on up to now is a primitive throwback to the earlier, much simpler days of JavaScript, when web pages were largely static and the amount of background activity was minimal. We can’t control its appearance in any way through CSS, and for production-grade notification, we’re much better off developing our own notification mechanisms using the techniques employed to build the rest of our Ajax user interface. This also provides a much greater degree of flexibility.

If we look across the full spectrum of computer systems, we see that notifications come in many shapes and sizes, varying considerably in their impact on the user. At the low end of the scale regarding obtrusiveness are changes to the mouse cursor (such as the Windows hourglass or the Mac “spinning beach ball”) or the addition of secondary icons or emblems to an image denoting the status of the files or other items in a folder. These simple indicators offer relatively little information. A status bar can provide a bit more detail on background events, and finally the full-blown dialog can show a greater degree of detail than either. Figure 6.1 illustrates a range of notification conventions being used in the KDE desktop for UNIX.

The folder called lost+found is not accessible to the current user, so a secondary image of a padlock has been superimposed over that folder. The status bar at the bottom of the main window gives further information on the contents of the folder being viewed, without interrupting the user. Finally, the error window that is presented when the user tries to open the locked folder presents a stronger notification requiring immediate action by the user.

Compared to these notifications, the use of alert() is essentially ad hoc, as well as being simplistic and ugly. In our quest for robustness, consistency, and simplicity, it makes sense to develop a framework for presenting notifications to the user that we can reuse throughout our application. In the following sections we’ll do just that.

Designing a notification system for Ajax	223

Figure 6.1 Various conventions for providing status information in a user interface: modifying the icons to reflect particular characteristics (here access permissions), a status bar providing summary information, and a modal dialog. The interface shown here is the KDE desktop for UNIX workstations, but similar conventions are found in most popular graphical interfaces.

6.3.1Modeling notifications

As a first step, let’s define what a notification message looks like. It contains a text description for the user and optionally an icon to display alongside the message.

When we notify the user of background activity, some messages are going to be more urgent than others. Rather than working out each time whether or not to show a particular message, let’s define some generic priority levels, which we can then assign to each message.

In general, we want to tell the user something, which they can acknowledge and dismiss. Some messages might be important enough to stay around indefinitely until the user does dismiss them, whereas others will be relevant only for a limited time. Where a message does remove itself without user intervention, it may be in response to a callback, if it is telling the user that some background process such as a network download is under way and the process finishes before the user dismisses the notification. In other cases, such as a news feed, we may simply wish to assign a given lifetime to a message, after which it will tidy itself away.

With these requirements in mind, listing 6.3 presents a Message object, which provides a generic behind-the-scenes representation of a notification that is to be presented to the user. Once we’ve established this model of notification messages, we can dress them up in various ways, as we will see later.

224CHAPTER 6

The user experience

Listing 6.3 Message object

var msg=new Object();

msg.PRIORITY_LOW=	{ id:1, lifetime:30, icon:"img/msg_lo.png"				};
msg.PRIORITY_DEFAULT={		id:2,	lifetime:60,	icon:"img/msg_def.png" };
msg.PRIORITY_HIGH=	{	id:3,	lifetime:-1,	icon:"img/msg_hi.png"	};

msg.messages=new Array();

msg.Message=function(id,message,priority,lifetime,icon){

this.id=id;

msg.messages[id]=this;

this.message=message;

this.priority=(priority) ? priority : msg.PRIORITY_DEFAULT.id; this.lifetime=(lifetime) ? lifetime : this.defaultLifetime(); this.icon=(icon) ? icon : this.defaultIcon();

if (this.lifetime>0){ this.fader=setTimeout(

"msg.messages['"+this.id+"'].clear()",

this.lifetime*1000

);

}

}

msg.Message.prototype.clear=function(){

msg.messages[this.id]=null;

}

msg.Message.prototype.defaultLifetime=function(){ if (this.priority<=msg.PRIORITY_LOW.id){

return	msg.PRIORITY_LOW.lifetime;
}else if	(this.priority==msg.PRIORITY_DEFAULT.id){
return	msg.PRIORITY_DEFAULT.lifetime;
}else if	(this.priority>=msg.PRIORITY_HIGH.id){
return	msg.PRIORITY_HIGH.lifetime;
}
}

msg.Message.prototype.defaultIcon=function(){ if (this.priority<=msg.PRIORITY_LOW.id){

return	msg.PRIORITY_LOW.icon;
}else if	(this.priority==msg.PRIORITY_DEFAULT.id){
return	msg.PRIORITY_DEFAULT.icon;
}else if	(this.priority>=msg.PRIORITY_HIGH.id){
return	msg.PRIORITY_HIGH.icon;
}
}

Designing a notification system for Ajax	225

We define a global namespace object msg for our notification system, and within that an associative array from which any message can be looked up by a unique ID. The ID generation scheme will depend on the application using the framework.

We define three constants defining the three priority levels—low, default, and high—to which a message can be assigned. Each priority defines a default icon and lifetime (in seconds), both of which may be overridden by optional arguments in the constructor function. A lifetime value of -1, assigned to high-priority messages, indicates that the message will not expire automatically but will need to be dismissed explicitly, either by the user or by a callback function.

6.3.2Defining user interface requirements

In MVC terms, we have provided a Model for our notification system here. To make it useful, we need to define a View. There are many possible ways of visually representing notifications. For this example, we have chosen to provide a status bar of sorts, upon which notifications are represented as icons, as illustrated in figure 6.2.

Figure 6.2 Status bar user interface for our notification system. Individual messages are represented by their icons.

The red X icon is a standard icon provided for low-level notifications by our system. The third message object on the status bar has provided its own icon, a blue, shaded sphere, which overrides the default X. Each notification that is added to this status bar can be inspected as a tooltip device, as shown in figure 6.3.

Figure 6.3 Messages on the status bar can be inspected by rolling the mouse over the icon, causing a tooltip to appear.

This mechanism is designed to be unobtrusive. The status bar occupies relatively little screen space, but it is apparent to the user when a new notification has arrived by the presence of an additional icon. For more urgent messages, we may