Take, for example, the Travelocity site. Its creators recognize that when you’re looking for accommodation, there are normally one or two variables that you want to use to narrow down your options. To let you get feedback quickly on the effect that your choices have made, they implemented the variables as JavaScript sliders, as shown in Figure 9.1. These sliders allow you very easily to specify your accepted range for the variables, and immediately see how many hotels meet your criteria.

If you wanted to implement this sort of feature using nothing but server-side calculation, obtaining the correct data would take an impractical number of form submissions. The site’s users would probably either give up before discovering exactly what they wanted, or settle for accommodation that wasn’t really what they wanted.

By having this easy-to-use interface element, the site actually encourages users to explore all of the options, making them much happier throughout the experience, and giving them a greater chance of finding ideal accommodation matches.

Among all of the Ajax voodoo used on Flickr, one of my favorite pieces of functionality is the inline editing capability shown in Figure 9.2. This type of interaction tool serves two purposes. Firstly, the use of an Ajax call to update information means that users’ changes are applied to pages very quickly. Helping this impression of speed, only small amounts of data are being sent (which is important on Flickr’s sometimes slow-loading pages), and the Gallery view makes it easy to make bulk changes to multiple photos.

The other great thing about inline editing is that you can be browsing your photo gallery pages, spot something that you want to change (like the typo in Figure 9.3), and change it right there and then. You get to see the data exactly as it appears to users, rather than in a form that’s not at all connected with the way the data will be finally presented. Thus the usual disconnect between administration and presentation vanishes.

You can perform a million and one usability tweaks with JavaScript, but they still essentially function like static HTML—with a bit less waiting. By far the most forward-thinking—and, let’s face it, sexier—examples are those that use the interactive capabilities of JavaScript to create something that’s not possible using traditional client-server techniques.

One of my favorite examples of this is Meebo, which is shown in Figure 9.4. It (and its web-based IM brethren) take the originally desktop-based instant messaging applications and move them onto a freely available web-based platform, thereby multiplying their usefulness by a factor of approximately 15.^[30]

With IM available through your browser, maintaining contact with your friends becomes as easy as blinking. Having an entirely browser-based chat client means you don’t have to install any software (an impossibility on many corporate systems), and you can switch workstations and still use the service—without having to transfer your IM account details. These services are also pretty good at beating firewalls that are set up to block IM ports. (I’m not sure whether this is counted as a good thing for employers, though!) Without JavaScript, this type of complex interface would be impossible—it would simply take too long using a normal page request architecture.

If you want to take a bigger step into the future, it’s possible to combine JavaScript with emerging vector-rendering standards that allow you to create you own really customized interfaces. Brand new at the time this book was written was the Yahoo! Pipes service shown in Figure 9.5. It uses the canvas element (which is available in quite a few browsers) to create a unique interface that’s best suited to its own particular functionality: wiring together an unlimited number of data modules.

canvas and its cousin SVG give designers the ability to create lightweight, highly adaptable vector graphics for use in web interfaces. Combined with the interactivity of JavaScript, these technologies are finally giving web applications the power that their desktop cousins have enjoyed for so many years, thereby removing one of the biggest barriers to the proliferation of a totally web-based application system.

And of course it’s not all business suits and briefcases on the side of JavaScript; there’s the potential to let your mind wander and produce some frivolous but fun entertainment of the kind for which Flash has earned a reputation—my Bunny Hunt game is a case in point. The sky’s the limit!

A number of common themes run through the design of a lot of applications. On the desktop, these functional commonalities include tasks like file handling and window control, and tools such as dialog boxes, toolbars, and menus. You can use a range of these standard components to build desktop applications, so you don’t have to reinvent the wheel every time you create a new application. By using these components, you take advantage of established conventions that aid usability—users already know what a menu looks like, how a dialog box works, and what they should do with a button.

Parallels are starting to be drawn in application design on the Web. A few interactions are now becoming sufficiently common to warrant the creation of reusable components, or widgets, that, when dropped into a page, just work. Whereas previously these widgets might have been offered piecemeal across a dozen sites spread over the Web, now they’re beginning to be aggregated in large libraries, to become what you might call component frameworks.

These frameworks don’t provide just a bit of abstracting code that addresses specific browser differences; they offer an entirely new mode of development. Instead of writing all the HTML, all the styles, and all the JavaScript for a particular piece of functionality, you can just include a widget—maybe just one line of code—and your application will automatically boast the functionality that you once had to write hundreds of lines of code to achieve.

Frameworks don’t just make coding easier, however; they also have an effect upon the language itself. If you start substituting one line of Dojo for a hundred lines of JavaScript, are you writing JavaScript, or are you writing Dojo?

We’ve taken a decent look at Dojo throughout this book, but only as a library, not a framework. Dojo offers more than just helper functions to shortcut common scripting actions—it actually provides an entire system for developing interfaces using common widgets.

The widgets currently available in Dojo number well over a hundred and include such items as accordion menus, combo boxes, date pickers, fish-eye lists, progress bars, sliders, and tree menus. The framework also has its own layout system, which allows you to create panes with related dimensions (such as equal heights) and adjustable dimensions—something that’s quite common in desktop application design.

We can implement widgets in Dojo in two ways: structurally and programmatically. If you use the structural method, you must modify the HTML structure of your page in order to include the Dojo widgets you want to use. To achieve this, you tack non-standard attributes onto particular HTML elements—a big no-no if web standards are an important consideration to you.

The programmatic creation of Dojo widgets is most useful when you want to create new interface elements on the fly, or you don’t want to dirty your HTML with attributes that aren’t meant to be there. You create the new widget inside your JavaScript, then include it on the page via the DOM.

Following the tenets of progressive enhancement, a lot of Dojo widgets try to use HTML elements that provide the same functionality, then transform them into more complex objects. For example, a select box can be turned into a combo box (a box that allows you to type and receive suggestions) with the addition of some extra attributes:

<select dojoType="ComboBox" dataUrl="example.php" name="state">
</select>

Next, include that element on an HTML page along with the Dojo library and ComboBox module:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
  <head>
    <title>ComboBox</title>
    <meta http-equiv="Content-Type"
        content="text/html; charset=utf-8" />
    <script type="text/javascript" src="dojo.js"></script>
    <script type="text/javascript">
      dojo.require("dojo.widget.ComboBox");
    </script>
    …

The result is a custom form element that provides users with suggestions as they type, like the one shown in Figure 9.9.

When the page is parsed by Dojo, the dojoType attribute is used to determine which elements are to be transformed into widgets. Then, the Dojo engine will go about changing the page to include the specified widgets.

If you wanted to include the ComboBox programmatically, you could write a script that creates a ComboBox widget, then adds it to the page:

var comboBox = dojo.widget.createWidget("ComboBox",
    {
      dataUrl: "../../tests/widget/comboBoxData.js"
    });
document.getElementsByTagName("body")[0].appendChild(
    comboBox.domNode);

New widgets are created using the dojo.widget.createWidget method, which takes the name of the widget, followed by a set of options expressed as an object literal. In this case, the only option we’re supplying to the ComboBox widget is the dataUrl location.

Once that widget has been created, we’ll have a reference to the widget as a JavaScript object, but in order to include it on the page, we’ll have to use its domNode property, which acts as the HTML interface for the actual object. And once that’s done, we’ll have a working ComboBox widget in our interface.

In the example above, the ComboBox is actually Ajax-driven—it will use the URL specified by the dataUrl property to retrieve listings that match what the user types. However, this explanation highlights a flaw in the way that this widget uses progressive enhancement.

When using a select box, users without JavaScript would expect to click on the box, and receive a number of options from which they can choose. The only way that this can be done is if all the options are included in the HTML. One of the aims of the ComboBox is to reduce the amount of data transferred between client and server by only retrieving the data that matches what the user is typing. However, leaving the select box empty initially renders it useless to users who don’t have JavaScript enabled. This is not progressive enhancement. Then again, if we included all the options for the select box in the HTML, we’d be removing one of the main advantages of the ComboBox.

Maybe a ComboBox could be thought of more like a plain text field (although Dojo’s ComboBox widget doesn’t work with text fields, so this is a purely academic argument). Non-JavaScript users would be able to type whatever value they wanted into the field, but they wouldn’t get a list of possible values.

These questions highlight some of the problems that are being caused by Rich Internet Applications. JavaScript and HTML give us a great deal of flexibility to create whatever we want, but sometimes that flexibility comes at the cost of accessibility. Is there a better answer? Only time will tell.

The Google Web Toolkit (GWT) uses Java as the basis for its engine. You never have to write JavaScript, HTML, or CSS if you don’t want to. Using GWT’s API, you can create entire applications in Java. The GWT compiler translates all of the Java into browser code (HTML, CSS, and JavaScript) for inclusion in your web site.

This style of framework makes web application development similar to traditional application development—all the code is written by the developer, then compiled for execution. In GWT’s case, compilation includes the creation of HTML and JavaScript files that will help run your application in a browser.

This framework is radically different from anything we’ve looked at in this book, but as an example, this Java class is used to create a page with a button that launches an alert box saying, “Hello, JavaScript:”

public class Hello implements EntryPoint {

  public void onModuleLoad() {
    Button b = new Button("Click me", new ClickListener() {
      public void onClick(Widget sender) {
        Window.alert("Hello, JavaScript");
      }
    });

    RootPanel.get().add(b);
  }

}

As well as being a very quick way for Java developers to create web applications, GWT is also extremely inaccessible. No static HTML is provided as the structure for the application, and every interface element is created via JavaScript. Therefore, there is essentially no document for the browser to fall back on if JavaScript is not available. The unlucky user gets zip, nada, nothing. If this isn’t a worry for you, you might want to give GWT a try. But, personally, it scares the pants off me.