Richer Plugin

Time your website with WebWait - from the creator of AjaxPatterns.org

From Ajax Patterns

Archived Version
There's an archived version of this pattern available, taken from the Ajax Pattern book draft, showing roughly how it appeared before the page became publicly editable.

Evidence: 0/3

Tags: Extension Greasemonkey Hack Mashup Plugin ProgressiveEnhancement Remix

[edit]

In A Blink

Browser search toolbar

[edit]

Goal Story

Dave's developing an online photo-sharing website. He uses Ajax to push the application as far as possible, but quickly hits the wall when it comes to some more advanced features. The Ajax application remains, but some advanced plugins are developed for users who are willing to install them. These include: a photo editor, a screen capture tool, a printing tool, and a browser hack that displays random images in the toolbar.

[edit]

Problem

How can you make an Ajaxian application even richer?

[edit]

Forces

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

[edit]

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.

The browser security model places many restrictions on websites, which is a good thing because it lets users freely visit any website with minimal risk of being violated. In its absence, users' systems would be in constant danger from malicious website operators, complacent website programmers, and devious peers. The default security model treats all websites with the same degree of suspicion, but in reality, a user places different degrees of trust in each website. The upshot is that you can use all the Ajax you like, but there are some things you simply can't do in a browser script. That's where Richer Plugin comes in. You can create a Richer Plugin that users can download and install for their browser. A user can tell their browser, "I trust this site to access extra features on my computer", while keeping all other websites tied down as before.

What are the things that a Richer Plugin can achieve, that an Ajaxian application can't? Here's a summary:

Browser morphing: Adding buttons, toolbars, bookmarks, icons; changing browser behaviour.
Local file access: Reading and writing files on the user's hard drive.
Sound: Playing music and sound effects.
Rich graphics: Providing rich graphics, changing dynamically.
Keyboard shortcuts: Providing a full range of keyboard shortcuts, many of which are normally overridden by the browser's own keyboard shortcuts.
Hardware access: Printing; joystick control; specialised hardware interaction.
Operating system interaction: Catching events such as shutdown initiation; changing preferences; reading hardware information.

There are four ways to build a Richer Plugin. One of the decisions below weighs up the choices.

Rely on browser-specific functionality, such as the scaleable vector graphics (SVG) capability introduced in Firefox 1.5.
Hook into an existing browser plugin framework, like Flash or Java or Real. These are third-party plugins which 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.
Build your own browser-specific plugin. Users will then have to explicitly install it.
Improve standards and implement them, eg adding multi-screen window support to the Frame standard, and then implementing that in Firefox, or just implementing/fixing an existing standard, eg adding SVG 1.1 support to Firefox.

The main browsers all have a standard "plugin" mechanism, often used for standard third-party platforms lie Java and Flash. There are simpler ways to extend behaviour if building your own plugin. In IE, you can include ActiveX Controls. Mozilla and Firefox have their own comprehensive extension framework.

(Incidentally, I'm not discussing the popular Greasemonkey framework here (itself a Firefox extension) because it's really intended to let the user community tweak an existing website, rather than let a website developer extend their own site.)

A Richer Plugin should be implemented with caution. It breaks browser portability, one of the great advantages of Ajaxian applications. It creates a layer of complexity to the website, which must target users who do and don't have the plugin installed. It also demands a different skill set from standard web development.

[edit]

Decisions

[edit]

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 is usually portable across browser versions. If you write a program in Java, it will run the same no matter which browser and operating system it's used on.
It's often already installed on the user's browser. Often, browsers come with Java and other plugins pre-installed. And if not, there's a good chance the user's previously installed them.
The user might trust it more than your own system. Users generally trust names like Flash and Java, so they may be more likely to install those plugins than your own plugin, even if it's your website they need it for.
The plugin might save you a lot of work as the API is higher-level than the basic browser plugin mechanism.

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

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 browser's toolbar.
You can target browser versions not supported by a plugin platform.

[edit]

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 was 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.

[edit]

Real-World Examples

[edit]

Google Toolbar and Google Suggest for Firefox

Google makes available a [1] for both IE and Firefox. The toolbar augments standard browser behaviour 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 which many people assume is used to help fine-tune their search algorithms.

Google also offers a "Google Suggest for Firefox" extension. This is a toolbar version of the Ajax Google Suggest website.

[edit]

Bloglines Plugins

Bloglines is an RSS aggregator, albeit not (yet) Ajaxian. The site offers a wide range of browser plugins and desktop applets. The browser plugins provide are icons providing notification that new blog entries are available. In addition, they add features to browser context menus that let users subscribe to the page being viewed.

[edit]

Amazon Mini-Shop

Amazon Mini-Shop is a Firefox extension that lets users search within the sidebar, and summarises the rsults.

[edit]

TiddlyWiki

Jeremy Ruston's Tiddlywiki is a SPA application (defined in Alternative Patterns below), 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. What's similar to Richer Plugin is that Tiddlywiki overcomes the local storage barrier by requiring users to save the wiki page locally and point the browser to that file.

[edit]

Code Examples

[edit]

Amazon Mini-Shop

It's beyond scope to cover plugins in detail, but this example gives an insight into the components of a Firefox extension. It's based on Paul Millar's Amazon Mini-Shop Firefox extension. 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, in curly braces is the extension ID, and you need to go into a directory by that name. That's where the extension code is.

The extension contains several components: chrome/amazoncomsearch.jar: is a jar file which can be opened with a standard unzipping utility. It contains the main resources for the extension. Of particular note here is the code. In Firefox, user-interfaces are set up with the XML User Language (XUL), a format which 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;

chrome.manifest is just 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 which are stored as standard Firefox preferences. In this case, only one preference: the Amazon site being search (US, UK, etc.) (You can see the settings in prefs.js.)

[edit]

Alternatives

[edit]

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 to 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.

[edit]

Related Patterns

[edit]

Fat Client

Fat Clients 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.

[edit]

Single Page Application (SPA)

Single Page Application is a newer-than-Ajax term to describe an application whose entire logic and data are embedded in a single HTML file. You point the browser to the HTML file on a local drive and editing the data will update the file accordingly. In the extended case of Single Page Application and Development Environment (SPADE), you can even update the code via the page itself! SPA is useful for certain specialised local applications where you want a web interface and local storage.

[edit]

Browser-Side Cache

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

[edit]