Yahoo! User Interface Blog

Firebug 1.0 hit the wires at Mozilla on Wednesday night and Firebug’s author Joe Hewitt of Parakey Inc. stopped by Yahoo! Thursday to debut the new features. Joe was kind enough to let us record his talk, and we’re pleased to share that with you in the YUI Theater. Although I use Firebug on a daily basis, this was an eye-opening talk for me — I had no idea how much Firebug was capable of until I saw Joe give the power-user tour.

If you’re reading this in a flash-capable viewer, you can check out Joe’s talk in the embedded player below:

Update 1/29: Yahoo!’s Lauren Garcia has a nice recap/summary of the talk on her blog.

More Video

The YUI Theater section of the YUI Website contains links to videos from JSON inventor Douglas Crockford, Oddpost cofounder Iain Lamb, YUI engineer Matt Sweeney, and much more.

Frontend engineering rocks right now. The era of boring web sites is over and we’re all into pushing the envelope, erasing boundaries and getting beyond whatever prevents us from building the next killer web application. New companies building quick-turnaround web products spring up like mushrooms and many an old convention of web design is cast aside to make way for quick prototyping and agile development.

The real confusing part of it — at least to me — is that we don’t try out new ways to approach web application development. Instead, there seem to be two separate schools of development approach:

• You either use a framework (like Ruby on Rails, Spring or Microsoft .NET) to build your web-app or
• You build your web app with best-practices ideas coming from more traditional web design and/or application design.

The framework approach relies heavily on the quality of the generated code and the accessibility and usability of the out-of-the-box page widgets and components. The pure web design approach relies on what HTML allows you to do and most of the time doesn’t take scripting-enhanced widgets into consideration.

As there are not many developers that follow both approaches there is a big divide in skill sets. People tend to become experts in one or another and stay within this comfort zone when talking to other developers. This is a real big waste as both factions could learn a lot from each other. All we need to overcome are the competing notions that (a) web standards and accessibility are show-stoppers for rapid framework-driven development and that (b) frameworks are a source of bad and invalid code. Both approaches are flexible: Frameworks can be extended to produce cleaner code and web standards can be seen as an agreed way of working with one another rather than as immutable laws that are never to be broken.

A Problem of Approach

The sad truth now is that both approaches often lead to hard-to-maintain products that don’t scale gracefully and are a pain to make accessible, localise to different languages or customise to different needs and channels. This is caused by false assumptions made by practitioners of both approaches:

• The framework approach relies on a silver bullet and approaches web development with fat-client application ideals from higher programming languages like Java or C++. This does not take into consideration the fact that web development is a discipline that operates with great uncertainties regarding the nature of client-side hardware and software. Optimization has to be for the user and not for the developer (although these don’t necessarily have to be mutually exclusive).
• The web standards approach would not be a problem at all if people would follow standards with the goal of making things easier by following an agreed approach and not see following the words of the W3C to the last detail as the only way to do things. Web standards are there to take the randomness out of web development and not to act as a policing tool.

The crux of the matter is that we don’t really yet understand how to build a real web application. We take tried and true methodologies that cover other development scenarios and try to shoe-horn them into something that helps us to achieve what we want on-time and within budget (and when was the last time that happened?).

The other problem is that we approach web application design with browser limitations in mind and plan only for what browsers can do rather than what the application should offer the user.

When it boils down to it, the main differentiator of a web application and a web site is that an app has much more interaction and is process-focused rather than content-driven. Users come in to achieve a goal: They provide data to the application, they use the application to enhance that data, and then they expect data to come out. They interact with components of the application and expect them to do something that brings them closer to their goal. It is of utmost importance that we plan for how users interact with the product and react accordingly.

When trying to accomplish this in the browser, there is one core technique at our disposal: Event handling.

Periodically, we sit down with developers in the community who are implementing YUI for projects outside of Yahoo. Recently, we sat down with a team from SmugMug — including CEO Don MacAskill and Web Superhero Jimmy Thompson — and talked about their company and how YUI fits in to their overall strategy.

SmugMug is a four-year-old service that provides online photosharing to high-end, high-touch customers — professional and avocational photographers who care deeply about the presentation of their photographic assets. Headquartered in Mountain View, SmugMug has gotten a lot of press for its incorporation of Amazon’s S3 storage service, but its model is creative on a number of levels. As a small company, its 17 employees are distributed around the US and around the world. Many of SmugMug’s employees have been hired from the talent pool discovered within its own loyal customer base. And they’ve built a site that now supports more than 100 million photographs, all with a very small engineering team. In part, they’ve done this by leveraging inexpensive pieces of infrastructure (like S3) and open-source software — like YUI.

SmugMug started using YUI shortly after it was released, after it was discovered independently by MacAskill and Thompson. Says MacAskill: "When I first became aware of YUI in March or February, I said look, this is the JS Library to use. I looked at all kinds of different things. It seemed to be lean and designed in a way that made sense." The à la carte approach with its small file footprint was a big factor for MacAskill. "I’m the optimization guy. I did not want a heavy footprint for a client-side library."

Looking beyond the architecture and the code quality, SmugMug’s engineers saw some other elements that were appealing. "The documentation was really good," says Jimmy. "We didn’t want to dig through sparse documentation trying to figure things out. I looked at the YUI examples and I could picture immediately how this fit in the work I was doing."

One of the singular qualities of SmugMug’s YUI implementation is that YUI is exposed directly to SmugMug customers. "We let customers control every pixel on the screen," MacAskill told us. "We give them all the tools they need to get exactly the result they want, including using YUI as part of their customization. That’s another reason why documentation was such a high priority for us."

In the past 9 months, the team has incorporated into numerous facets of SmugMug’s product:

• Accordion menus based on Animation;
• Panel-based flyouts for displaying EXIF information and phototools;
• Drag & Drop rearrangements of galleries;
• Lightbox functionality based on the Panel Control
• Rendering and adding new comments based on Connection Manager
• In-context notifications using Panels and Animation;
• Animation Utility and Dom Collection are used to manage opacity and other transitions, giving the interface a more fluid, polished feel;
• Dom Collection used throughout to manage dynamic DOM updates;
• Rich interactions underpinned by the Event Utility, including performance techniques like the use of purgeElement to stay skinny on memory;
• Use of a modified version of the Slider Control’s Color Picker example in customization screens.

Pain points for SmugMuggers using YUI? "We’d like to see more DOM insertion and creation functionality, the kinds of things we saw in looking quickly at TabView in the past few days with its Element object," Thompson told us.

We’re big fans of SmugMug — they joined us at Yahoo! for Hack Day late last year and their passion for geeking out, building cool stuff, and taking care of their customers is evident in everything they do. If you want to get a sense of the love they bestow on their product, go to any gallery (here’s a pretty one with waterfalls) and click on the slideshow link. When the slideshow begins to play, zoom your browser window — note that the pictures scale up to fill your screen from high-resolution source. They never forget, even in the details, that this is a site for photographers and image lovers and that it’s all about maximizing the experience of beautiful images.

Do you have a YUI implementation that would be of interest to the YUI community? If so, please share your link and post a message to the community forum at YDN-JavaScript, or leave us a message in the comments section below.

I love Greasemonkey. I like how much power it gives me when it comes to bending other peoples’ websites to my will, how I can add features to or or ditch them from a website, how I can use Greasemonkey scripts to pull data from all over the net to spice up the very page I am looking at. It makes my daily life as Yahoo! engineer easier.

Also, I love the Yahoo! UI library. YUI contains JavaScript and CSS components that allow anyone to quickly build some pretty amazing things.

Wouldn’t it be great if we could bring Greasemonkey and YUI together? How nice would it be to use YUI components anywhere, to have Greasemonkey dynamically load the libraries when needed and to attach YUI-powered thingamajigs to any page we like? For example to add autocompletion to form fields, or to make use of the advanced event management in your Greasemonkey scripts! The mind boggles.

In this brief article, I’ll share with you my own effort to reach that goal — a Greasemonkey script that adds calls to external JavaScript libraries and CSS files to a given page and, once they are loaded, passes the YAHOO global object to the code inside the Greasemonkey script. (All YUI components reside within this single single global variable, YAHOO — so, for example, you access the YUI Event Utility by referencing YAHOO.util.Event.) I’m sure that this approach is neither the perfect nor the only solution to achieving YUI/Greasemonkey integration, so suggestions and ideas are welcome! Please sound off in the comments and let me know what approaches you’ve taken to this problem in your own projects.

An Example Greasemonkey Script Implementing a YUI Loader and Using YUI Components

What I am interested in sharing with you here, primarily, is the mechanism by which you can include and invoke YUI from within a Greasemonkey script while reusing (and not disturbing) existing YUI components already present in the document. I’ll do that by exploring a simple Greasemonkey sample script that translates selected text on YUIBlog.com, Yahoo! News, or my personal blog using Yahoo! Babelfish; with the script installed, you can highlight any passage of text on one of those sites and, if you hold down the shift key while releasing the mouse, a YUI Panel with a German Babelfish translation will pop up. (If you want to install and test the script, you can download it from http://carlo.zottmann.org/code/yuigm_example_yuiblog_babelfish.user.js; the script is configured to operate only on http://*yuiblog.com/*, http://news.yahoo.com/*, and http://carlo.zottmann.org/* URIs).

In case you’re not using Firefox, here’s a quick example of the script in action. Click the screencapture below to see a 10-second QuickTime movie of the interaction:

Key Objects in the Script

We have four key objects in the script: GM_YUILOADER, GM_YUILOADER_CONFIG, YBFLOOKUP, and of course the YAHOO global object.

1. GM_YUILOADER holds all the logic to inject the necessary JavaScript and CSS files, makes sure they are loaded and triggers execution of the main part of the script (the “payload”).
2. GM_YUILOADER_CONFIG contains the configuration parameters for our YUI usage, including the list of YUI JavaScript libraries and/or CSS files we want to load, the maximum time to wait for for said files to complete loading, the frequency with which to check for completion, and information about which callback function to fire once everything is loaded.
3. YBFLOOKUP is the “payload”, containing the code where we use YUI to achieve our goals. In our example this is the Babelfish YUI Panel (hence the name of the object) which will display a German translation for the English text on the page that was marked by the user.
4. YAHOO is what you would expect — the YAHOO global object. It is avaible once GM_YUILOADER has triggered execution of the main part of the script.

The Loader

The loader is the most critical component of the script, and it’s the part that you are most likely to want to adapt in creating your own YUI-based Greasemonkey implementations. Here is the general workflow of the GM_YUILOADER technique.

1. Greasemonkey triggers script execution.
2. GM_YUILOADER.loader() is called and…
   • adds a GM_YUILOADER_DOC property to Greasemonkey’s unsafeWindow.document which (among other things) holds a counter, a so-called trigger variable and a function (which increments aformentioned counter; if the counter reaches the number of included <script/> tags, the trigger variable is set to true)
   • adds new <script src="..."/> and/or <link rel="stylesheet" type="text/css" href="..."/> tags to the page (unless that YUI component is already included in the page, which is determined using object detection)
   • adds onLoad event handlers to above <script/> tags (which call the
     function inside unsafeWindow.document.GM_YUILOADER_DOC)
3. GM_YUILOADER.loaderCheck() is run periodically, checking the status of the trigger variable, until one of two things happens: either the variable is true, in which case the payload logic is invoked (i.e. YBFLOOKUP.run()) after making the YAHOO global object available to the Greasemonkey script, or the maximum loading time is reached, which will cause the script to abort.

Let’s take a look at some of the loader-specific code in the sample script. First, you specify the YUI components on which your Greasemonkey script will rely. You do so in an structured object — the assets member of the GM_YUILOADER_CONFIG object:

// Settings used by the loader "engine"
var GM_YUILOADER_CONFIG = {
    // List of JS libraries and CSS files to load. obj is used for the object
    // detection used in the loader. Basically, if the object already exists,
    // the script is not injected in the page.
    assets: [
        { type: 'css', url: 'http://developer.yahoo.com/yui/build/container/assets/container.css' },
        { type: 'js', obj: 'YAHOO', url: 'http://us.js2.yimg.com/us.js.yimg.com/lib/common/utils/2/yahoo_2.1.0.js' },
        { type: 'js', obj: 'YAHOO.util.Event', url: 'http://us.js2.yimg.com/us.js.yimg.com/lib/common/utils/2/event_2.1.0.js' },
        { type: 'js', obj: 'YAHOO.util.Dom', url: 'http://us.js2.yimg.com/us.js.yimg.com/lib/common/utils/2/dom_2.1.0.js' },
        { type: 'js', obj: 'YAHOO.util.Anim', url: 'http://us.js2.yimg.com/us.js.yimg.com/lib/common/utils/2/animation_2.1.0.js' },
        { type: 'js', obj: 'YAHOO.widget.Panel', url: 'http://us.js2.yimg.com/us.js.yimg.com/lib/common/widgets/2/container/container_2.1.0.js' }
    ],

By comparing this list with the YUI objects that may already be present in the YAHOO global object, the script creates a “to-do” list of needed-but-missing components. It can then loop through the needed assets and include them on the page. Here’s the underlying code for that part of the loader:

// Now let's add the extra tags to the page that'll load the libraries and
    // CSS files.

    var numAssets = GM_YUILOADER_CONFIG.assets.length;

    for (var a = 0; a < numAssets; a++) {
        var tag;
        var asset = GM_YUILOADER_CONFIG.assets[a];

	switch (asset.type) {
		// CSS file
		case 'css':
			tag = document.createElement('link');
			tag.href = asset.url;
			tag.type = 'text/css';
			tag.rel = 'stylesheet';
			break;

		// Javascript library.
		case 'js':
			var injectScript = true;

			// Object detection
			try {
				injectScript = eval('window.' + asset.obj + ' === undefined');
			}
			catch (e) {}

			if (injectScript) {
				tag = document.createElement('script');
				tag.src = asset.url;

				// The crucial part: triggering document.GM_YUILOADER.countLoaded()
				// means keeping track whether all scripts are loaded yet.

				tag.setAttribute('onload', 'document.GM_YUILOADER_DOC.countLoaded();');

				// How many JS libraries are we dealing with again? Let's keep
				// track.

				ud.GM_YUILOADER_DOC.numberTotal++;
			}
			break;
	}

	document.body.appendChild(tag);
}

There are other details taken care of in the loader portion of the script, but this is the heart of the logic & and the code above captures the essence of this approach to marrying YUI with Greasemonkey.

The Payload

The practical part of the script (a.k.a. the "payload") is pretty straightforward: a simple, invisible YUI Panel is built, a mouseup event handler is attached to the document body. Once triggered, it'll check if text was selected and if the shift key is still pressed; if so, it'll grab the German translation for the text from Babelfish, put it in the body of the Panel and invoke the Panel's show() method.

At the heart of the payload is an event listener listening for the mouseup event on the window object. Here's the beginning of that event handler:

// Event handler for mouseUp events
YBFLOOKUP.subscriberSelect = function(e) {
var selection = window.getSelection();
var selectionText = selection.toString();

// Shift key pressed? Anything selected?
if (!e.shiftKey || selectionText == '') { return; }
	YBFLOOKUP.panel.setBody('Loading Babelfish EN-DE translation, just a second...');
	YBFLOOKUP.panel.cfg.setProperty('x', e.clientX + 20);
	YBFLOOKUP.panel.cfg.setProperty('y', e.pageY + 20);
	YBFLOOKUP.panel.show();

From there, the script proceeds to make a call to Greasemonkey's built in facility for loading external pages (GM_xmlhttpRequest), loads the translation from Yahoo! Babelfish, and shows the result in the Panel.

Closing Words

The ability to use YUI in Greasemonkey scripts can be quite beneficial to Greasemonkey developers. I know from personal experience that YUI brings a lot of new options and tools to the Greasemonkey playing field that, without a library, you would have to build on your own. Also I like the idea of playing with new YUI-powered gimmicks on a live site; for instance, it is rather easy now for me to to inject autocompletion into a form field on a live Yahoo! page just to see what it would look and how it would behave — without running the risk of destroying things and without having to set up a dedicated development environment, do exhaustive QA testing, or ask anyone for permission. Greasemonkey captures the essence of hacking and it opens up wonderful creative opportunities.

For me personally, YUI and Greasemonkey are a perfect fit, and I'd like to use this opportunity to thank both the Greasemonkey developers and the YUI crew for their ingenuity and willingness to share the love with us.