Ajax Design Patterns

Chapter 8. Extended Technologies

Paradoxically, we round out the foundational Ajax technologies with a pattern that’s all about “non-Ajax” technologies. The term “Ajax” usually relates to the technologies provided by standard web browsers—those covered in the previous chapters. However, it’s pragmatic to bend that definition when there are useful “bonus” features that require extra capabilities; hence, the Richer Plugin pattern.

Richer Plugin

○ ActiveX, Applet, Extension, Flash, Greasemonkey, Hack, Java, Mashup, Plugin, ProgressiveEnhancement, Remix

Figure 8-1. Richer Plugin

Goal Story

Sasha is using an online photo-sharing web site. Since she’s become a big fan, she’s taking the time to install some optional plugins from the site: an in-browser photo editor, a screen capture tool, and a browser toolbar.

Problem

How can you make an Ajax App even richer?

Forces

Ajax makes web interaction much more like a desktop application, but there are limits. Many applications require functionality not available to Ajax Apps.
If you develop a desktop application, even if it connects to the Internet, you forego many advantages of an Ajax App.

Solution

Make your application “more Ajax than Ajax” with a Richer Plugin. Ajax is certainly a step up in richness, but sometimes you need more than Ajax can offer. That’s when you release a Richer Plugin that users install to get even more out of your application. The concept here is “progressive enhancement”—the application works fine in standard web browsers, but by installing the Richer Plugin, users can take the interaction to the next level.

What are the things that a Richer Plugin can achieve that an Ajax App can’t? Here’s a summary:

Browser morphing: Adding buttons, toolbars, bookmarks, icons; changing browser behavior.
Local file access: Reading and writing files on the user’s hard drive; unlike cookies, we sometimes want very large storage capacity and the ability to keep the data locally, without ever transferring to the server.
Sound: Playing music and sound effects.
Rich graphics: Providing rich graphics, changing dynamically; although this is changing with the gradual introduction of technologies like scalable vector graphics (SVG), even these can’t come close to utilizing the power of a modern display.
Hardware access: Providing input from devices such as microphones, webcams, and gamepads; output to devices like printers and portable gadgets.
Extended communication: Providing communication from the client machine to locations beyond just the base server, and in protocols other than plain old HTTP.
Operating system interaction: Catching events such as shutdown initiation, changing preferences, popping up alerts, and reading hardware information.
Keyboard shortcuts: Providing a full range of keyboard shortcuts, including those that are platform-specific, while avoiding conflicts with the browser’s own keyboard shortcuts.

The browser security model imposes these restrictions on web sites because it lets users freely surf the Web with no risk of being compromised (well, low risk). In its absence, users’ systems would be in constant danger from malicious web site owners, complacent web site programmers, and devious users. By releasing a Richer Plugin, you allow users to say, “I trust this site to do certain things with my computer or browser,” while keeping all other web sites tied down as before.

This pattern uses a loose definition of Richer Plugin to mean anything outside standard web technologies, which can take several forms:

Hooking into an existing browser plugin framework, like Flash, Java, or Real. These are third-party plugins that are very common in many browsers. They’re often packaged with the browser, and even if not, there’s a good chance the user will have previously installed them for another application. Your application should work automatically as long as the plugin’s installed.
Building a browser-specific plugin. Users will then have to explicitly install it.
Building a companion desktop application. This is not a replacement, because the user primarily interacts through the web site, but a means for better desktop integration, with features like pop-up alerts or quick entries. Many plugins of this nature integrate with frameworks such as Konfabulator (http://konfabulator.com) and Growl (http://growl.info/).
Exploiting browser-specific functionality, such as the scalable vector graphics (SVG) capability introduced in Firefox 1.5 or IE’s ActiveX components.

The main browsers all have a standard “plugin” mechanism, often used for standard third-party platforms like Java and Flash. There are simpler ways to extend behavior if you are building your own plugin. In IE, you can include ActiveX Controls, and Firefox has its own extension framework^[*] (http://developer.mozilla.org/en/docs/Extensions).

A Richer Plugin should be implemented with caution. It breaks browser portability, one of the great advantages of Ajax Apps. It creates a layer of complexity to the web site, which must target users who do and don’t have the plugin installed. It also demands a different skill set from standard web development. As a rule of thumb, use Richer Plugins only when there’s no standard way to implement the same functionality.

Decisions

Will you reuse a third-party plugin or develop your own?

Having decided that you need extra functionality, the biggest decision is whether or not you’ll to build a browser-specific plugin or to build on a standard plugin platform like Java or Flash.

A standard plugin platform has the following advantages:

The plugin will likely save a lot of development if there’s already a specialized API.
The plugin is usually portable across browser versions. If you write a program in Java, for example, it should run the same no matter which browser and operating system it’s used on.
The plugin might already be installed on the user’s browser. Often, browsers come with Java and other plugins preinstalled. And if not, there’s a good chance the user’s previously installed them.
The user—or his employer—might trust it more than your own system. People generally trust brands like Flash and Java, so they might install those plugins and nothing else.

However, there are also advantages of writing your own plugin:

You’re not locked in to a relationship with the plugin provider. You’re therefore in control of issues such as licensing and management of user data, and not at the mercy of another company’s future plans for the plugin—or lack thereof.
You can implement more functionality. Plugin platforms impose their own security model because it’s expected different applications will run on them. So while Flash, for example, lets you extend the browser’s multimedia capabilities, you can’t use it to morph the Firefox toolbar.
You can target browser versions not supported by a particular plugin platform.
You can control the plugin installation process, as opposed to sending the user over to a third-party site.

What will happen if the plugin’s not installed?

You’ll need to consider the user experience when the plugin’s not installed. How will you treat content—and links to content—that requires the plugin? For example, you could hide it altogether, explain what would be present if the plugin is installed, or perhaps provide an alternative representation. You also need to consider what to say if the plugin’s not available on the user’s platform.

In extreme cases, you could make the plugin mandatory. This might be plausible in an intranet setting and is really quite similar to a standard desktop application. However, it might be preferred to a desktop application if users are more comfortable in a web environment.

Real-World Examples

Amazon Mini Shop

Amazon Mini Shop (http://extensionroom.mozdev.org/more-info/amazonsearch) is a Firefox extension that lets users search within the sidebar and summarizes the results (Figure 8-2).

Figure 8-2. Amazon Mini Shop

Google Toolbar and Google Suggest for Firefox

Google makes available a toolbar (http://toolbar.google.com) for both IE and Firefox. The toolbar augments standard browser behavior with a convenient search entry as well as several other features, including Google’s page rank metric for the page. Google openly notes that they may collect information about web pages being viewed, data that many people assume is used to help fine-tune their search algorithms.

Google also offers a “Google Suggest for Firefox” extension (http://toolbar.google.com/firefox/extensions/suggest/install.html). This is a toolbar version of the Ajax Google Suggest web site (http://www.google.com/webhp?complete=1&hl=en).

Odeo

Odeo (http://odeo.com) is a podcast manager (Figure 8-3). The main web site interaction—functionality like subscribing and tagging—uses standard web technologies, with many Ajax techniques. In addition, Odeo offers a number of Richer Plugins. Flash is used to play and record podcasts in the browser. For pulling down podcasts to a local machine, there’s an Odeo “Syncr” desktop tool and also a more specialized Apple Dashboard widget.

Figure 8-3. Odeo

TiddlyWiki

Jeremy Ruston’s TiddlyWiki (http://tiddlywiki.com) is a SPA application (defined in the section "Alternatives,” later in this chapter), an interesting variant of Richer Plugin. It’s an entire wiki within a single HTML file, including the wiki script and the wiki content itself. Tiddlywiki is similar to Richer Plugin because it overcomes the local storage barrier by requiring users to save the wiki page locally and point the browser to that file.

Code Example: Amazon Mini Shop

It’s beyond the scope of this book to cover plugins in detail, but this example gives an insight into the components of a Firefox extension, Paul Millar’s Amazon Mini Shop Firefox extension (http://extensionroom.mozdev.org/more-info/amazonsearch). If you want to grab the code, visit the link with Firefox and install the extension. Then, look at Extensions.rdf in your firefox profile directory (e.g., under ~/.mozilla/firefox/ in Unix or under c:\Windows\Profiles\%USER%/Mozilla/Firefox). Search for “amazoncomsearch” and you should see a nearby tag beginning with RDF:Description. Within that tag, the extension ID is in curly braces, and you need to go into a directory by that name, which is where the extension code is.

The extension contains several components. To start with, chrome/amazoncomsearch.jar is a jar file that can be opened with a standard unzipping utility. It contains the main resources for the extension. In Firefox, user-interfaces are set up with the XML User Language (XUL) (http://xulplanet.com/tutorials/xultu/intro.html), a format that looks similar to HTML. The sidebar UI is captured in one XUL file:

  <?xml version="1.0"?>
  <?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

  <page id="pageAmazonPanel" style="background-color: #ffffff;" title=
"Amazon Search"
          xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
xmlns:html=
"http://www.w3.org/1999/xhtml" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
onload=
"disable();javascript:document.getElementById('txtAmazonSearch').focus( )">

    <script type="application/x-javascript"
src="chrome://amazoncomsearch/content/amazonsearch.js"/>
    <hbox pack="center">
      <menulist flex="1" id="menuAmazonSearch" label="Search Category" onChange=
"change( )">
        <menupopup id="popupAmazonSearch" onpopupshowing="popamazon( )"/>
      </menulist>
    </hbox>
    ...
  </page>

There is also JavaScript code, which populates the UI and handles user-interface interaction similarly to a normal browser script. For example, an XMLHttpRequest Call is used to gather data from Amazon’s web service:

  aURL = "http://xml-"+value+".amznxslt.com/onca/xml?Service=AWSECommerceService&..."
  ...
  httpReq.open("GET", aURL, true);
  httpReq.send(null);
  httpReq.onload = httpLoaded;

Among the remaining components, chrome.manifest is a meta-information file that points to the resources above. install.rdf provides meta-information about the application, such as its ID and creator. install.js is a script to handle initial installation of the extension. defaults/preferences/ams.jar provides defaults that are stored as standard Firefox preferences. In this case, there is only one preference: the Amazon site being searched (U.S., U.K., etc.). (You can see the settings in prefs.js.)

Alternatives

Desktop Client

The desktop client runs as a standard application in the user’s operating system and connects to one or more servers using HTTP or any other protocol. It would make sense to use a Desktop Client if the required user interface is very different than a standard browser interface, or if it’s difficult to extend the browser as desired. While the plugin frameworks provide more control than regular web applications have, the developer is still restricted relative to a standalone desktop client.

A variant is a “Richer Desktop Client.” That is, an Ajax App to do most basic things, and a richer desktop client with extra features and improved usability. This is the strategy Microsoft might follow with Office Live.

Related Patterns

Fat Client

Fat Clients (Chapter 13) are sometimes replacements for desktop applications, used frequently and for long sessions. A Richer Plugin will enhance their experience, and the effort to set it up will eventually provide users with ample payback.

Single Page Application

Single Page Application (SPA) is a newer-than-Ajax term that describes an application whose entire logic and data are embedded in a single HTML file. Point the browser to the HTML file on a local drive; editing the data will update the file accordingly. In the extended case of Single Page Application and Development Environment (SPADE) (http://trimpath.com/project/wiki/SinglePageApplicationAndDevelopmentEnvironment), you can even update the code via the page itself! SPA is useful for certain specialized local applications where you want a web interface and local storage. A nice way to use it is to load it onto a USB key along with a web browser, which allows you to maintain the content anywhere, even in the absence of a Net connection.

Bookmarklet

A bookmarklet (or “favelet”) is a link that references JavaScript instead of a web location. For example, you can create a link like this: <a href="javascript:alert('You are at' + document.location.href + '.');">Bookmark Me!</a>. The user will be able to drag it to their toolbar, and when they click on it later on, it will run the script, which pops up the current location in this example. With a bookmarklet, you can build a custom Ajax App inside other web sites. Display Manipulation (Chapter 5) patterns and Dynamic Behavior (Chapter 7) patterns work as on a local site, so you can, for example, tweak any web site whenever the user clicks on the bookmarklet. One thing you can’t do is issue XMLHttpRequest Calls (Chapter 6), due to the same-origin policy, but you can work around that with On-Demand JavaScript (Chapter 6). WizLite (http://wizlite.com), a collaborative annotation tool, is a great example of how powerful bookmarklets can be.

Browser-Side Cache

A Richer Plugin, with access to the local filesystem—or at least more sophisticated browser-based storage than normal cookies—can be a useful data repository for a Browser-Side Cache (Chapter 13).

Metaphor

Consider a regular web app as a black-and-white movie. Ajax adds color; Richer Plugin adds 3-D (or Smell-O-Rama if you wish).

Want to Know More?

Firefox Extension Tutorial (http://extensions.roachfiend.com/howto_bug.html)
Building ActiveX Controls for Internet Explorer (http://msdn.microsoft.com/workshop/components/activex/buildax.asp)
Tutorial: Creating a Mozilla Extension (http://www.mozilla.org/docs/tutorials/tinderstatus/)

^[*]This pattern doesn’t discuss the Greasemonkey Firefox extension because, although a great tool, its primary purpose is to let users re-purpose an existing web site, and just about anything that can be performed with Greasemonkey could also be performed by the web site owner.

Get Ajax Design Patterns now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Ajax Design Patterns by Michael Mahemoff