Dynamic resource loading is one of the keys to have a performance happy web application. There are generally three different criteria we must address when making a request: cross domain security policies, asynchronous/synchronous (will it block the host page while loading), and whether or not events are triggered when the request completes.

If the resource and host page are on the same domain, obviously XMLHttpRequest works the best. We can control whether or not the resource is loaded asynchronously or synchronously, and we know exactly when it gets done.

If the resource and host page are on different domains (increasingly more common with CDN’s), our options narrow. Loading the JavaScript is a solved problem, just use the onload event on the <script> tag and you’re good to go (onreadystatechange for IE). But CSS is more complicated.

Existing Solutions

In all of the library source code I evaluated, Internet Explorer didn’t cause any issues. It fires both the onload and onreadystatechange events for <link> nodes. Obviously this is ideal behavior, and IE got it right. But what about Firefox and Safari/Chrome?

YUI 2.8.1 and 3.1.1

Original Source

// FireFox does not support the onload event for link nodes, so there is
// no way to make the css requests synchronous. This means that the css 
// rules in multiple files could be applied out of order in this browser
// if a later request returns before an earlier one.  Safari too.
if ((ua.webkit || ua.gecko) && q.type === "css") {
    _next(id, url);
}

I wouldn’t be surprised if the commit log there was from Bon Jovi; that code is living on a prayer.

LazyLoad

Original Source

// Gecko and WebKit don't support the onload event on link nodes. In
// WebKit, we can poll for changes to document.styleSheets to figure out
// when stylesheets have loaded, but in Gecko we just have to finish
// after a brief delay and hope for the best.
if (ua.webkit) {
    p.urls[i] = node.href; // resolve relative URLs (or polling won't work)
    poll();
} else {
    setTimeout(_finish, 50 * len);
}

Better, closer, warmer. This includes a nice method for working with webkit browsers. The poll method compares document.styleSheets, since Webkit has the nice option of only appending to the styleSheets object when the styleSheet has successfully loaded.

So we have working solutions for IE and Safari/Chrome. The only unsolved piece of the puzzle here is Firefox.

This post from the same author as LazyLoad also describes another solution which involves modifying the source CSS and polling against it. But that’s not really ideal. Can we do better?

Solution

Here’s what I came up with (using jQuery for brevity, note that this solution only fixes Firefox, and does not incorporate the above already solved solutions):

var url = 'css.php';
    id = 'dynamicCss' + (new Date).getTime();
 
$('<style/>').attr({
    id: id,
    type: 'text/css'
}).html('@import url(' + url + ')').appendTo(document.getElementsByTagName('head')[0]);
 
function poll()
{
    try {
        var sheets = document.styleSheets;
        for(var j=0, k=sheets.length; j<k; j++) {
            if(sheets[j].ownerNode.id == id) {
                sheets[j].cssRules;
            }
        }
        // If you made it here, success!
        alert('success!');
    } catch(e) {
        // Keep polling
        window.setTimeout(poll, 50);
    }
}
 
window.setTimeout(poll, 50);

See this demo in action. (Firefox only)

Update: After much joy and celebration, I have discovered that an approach similar to the above was written by Oleg Slobodskoi in his xLazyLoader plugin for jQuery. It shouldn’t be surprising that two independent developers might reach the same solution, and is just more proof that software patents are stupid. :)

Feel free to fork/contribute at your leisure.
http://github.com/zachleat/ALARMd

If you’re new, you can check out ALARMd.com to see what I’m talking about.

As many of you may already know, my day job includes managing a large and complex enterprise jQuery-based user interface component library. It’s used by all new web applications at the company, which boasts over an IT department of approximately 1500 people and hundreds of web applications. Needless to say, I get a fair volume of interesting support tickets that come my way. A few weeks ago, I had the pleasure of receiving one such ticket.

The support ticket’s symptoms included a oft-heard complaint: poor performance. On the web, poor performance can be attributed to a great many things, but most often can be boiled down to a bottleneck in JavaScript code using the DOM API. This time, strangely enough, the culprit was something else entirely.

One of the first things I check when an application complains of poor performance is the total size of the document, or how many nodes it has. One of the best ways to ensure good performance is to keep your document small, especially on projects using heavy dynamic element selection and filtering (think jQuery, Mootools, Prototype, Dojo, or any code using a selector engine like Sizzle). Any JavaScript library emulating CSS selectors executing over a very large document is going to take quite a bit longer than querying a small document, especially when the user’s browser doesn’t support native querySelector or getElementsByClassName.

To get an idea of what the size of a large document is, I usually go to a site with some fairly advanced JavaScript and query their size.

// Returns the total number of nodes in the document
document.getElementsByTagName('*').length;
// note: this number will not include any child nodes inside of iframes.

Getting back to the support ticket in question. After querying the document, I quickly found that the page contained over 50000 nodes. Wow. So, we’ve caught a big one. You’re going to be telling your grandkids about this some day. But, now what?

I decided it would be beneficial to find out where and what all of those nodes were. After clicking around the live document in the Firebug’s HTML tab for awhile, looking at View Source, and Ajax requests in the Console, I successfully determined the culprit. This particular application was using Wicket, a popular Java library for web applications, which includes its own Ajax Logger component (similar to my favorite log4javascript; or something like the YUI Logger), used to keep track of an application’s Ajax calls and JavaScript page manipulations with an inline GUI embedded in the parent document. On one page load, this application’s Ajax logger component had created 40000 nodes of log content.

It’s important to realize that embedding unnecessary content of that magnitude on the page can be very detrimental to performance. JavaScript loggers should log to a new child window, rather than be embedded in the parent document. This way they won’t bloat the document, but still provide you with much needed logging information.

But, in the future, how might this type of problem be more easily diagnosed and prevented? Ideally, when confronted with large documents, we want to see where in the document the majority of those nodes are located. But there isn’t an easy way to see which portion of the document is using the largest number of nodes, especially if the culprit is deep into the document tree. We can go through the source code manually, but that isn’t very efficient.

So in the spirit of exploratory development to help troubleshoot real-world problems, I decided to make a Firebug Lite plugin. This would give me an easy cross-browser tool to diagnose my problem in a familiar interface. Load up Firebug Lite, load the DOM Sailbloat JavaScript file, and easily spot the HTML love handles.

Here’s what it looks like in action:

Go Forth

1. See the demo
2. Download the source
3. Fork the Sailbloat on GitHub

Note: there is currently an undiagnosed issue with the Sailbloat and it fails to load intermittently. If you know why, I’d be happy to put your name in the source code credits.

Date Pickers are helpful components that are useful for a couple of reasons:

1. They allow you to easily map an existing real-world mental model (the Calendar) to form input (a text field). This provides additional context beyond what the simple string value of a date represents: days of the week, Calendar month labels, leap year information.
2. They allow for more usable and actionable data restrictions and error feedback. Want the user to select a weekday? Just show them on the calendar which days are available.
3. Visual cue as to what the form field’s data format should be. If a calendar icon is next to the form field, it becomes very obvious what kind of data the user should put into the field.

Now, the last two reasons are all well and good, but carry no intrinsic incentive for the user to actually click on and use the Date Picker component. The first reason is what actually motivates a user to bring up the Date Picker and select a date on it.

Now, consider the following Time Picker component, popularized by a John Resig blog post:

Comparing to the Date Picker component above, one could easily make the argument that it offers little to no incentive over simple keyboard input. It offers no additional context, extra data, or an existing physical mental model for the user to associate with. The only advantage it might offer is an easy calculator for those unfamiliar with 24-hour (military) time. I would argue that placing the AM/PM selection at the beginning of the selection creates a reversal of the closest established mental model a person typically uses to represent a time: the digital clock (hours, minutes, seconds, and AM/PM at the end).

These implementation examples speak to a larger trend of front end engineers that concentrate too much on code optimization and cross browser compatibility, and not enough on usability and user driven design. It’s an easy trap to fall prey to, but one we must be wary of. A Time Picker might offer benefit in terms of data restriction (e.g.: select an hour in the range of a normal workday), but it does very little for the efficiency and usability of data entry. So, before you start putting Time Pickers on all of your forms, make sure the Time Picker you add represents something like this:

and not this:

Image Sources:
1. tesora.com.au
2. codeproject.com

When you see issues with Character Encoding, it’s traditionally in the form of text on your page that looks like this: in Firefox or in IE.

Usually, those characters mean that the character encoding used on the page is either ambiguous (not specified), or incorrect. We can use Firefox to determine that Character Encoding of a web page (Right Click and go to View Page Info; or use the “Character Encoding” entry in the View menu). Check to make sure that the encoding reported by Firefox is the same encoding used in your IDE. For example, Eclipse 3.5 has a “Set Encoding” option in the Edit menu.

The reason most English alphabetic and numeric characters are consistent independent of character encoding is due to consistency in the lower characters in each encoding. The characters making up the ASCII character set (0-127) are the same as the lowest 128 characters of ISO-8859-1, UTF-8, and others.

Managing your character encodings gets trickier as you add more architectural layers to your application. For example, character encodings may differ in your database, the properties files used to configure your application (java.util.Properties uses ISO-8859-1 by default), or maybe the XML or JSON file you’re loading from an external API.

Ever heard of HTML character entities? That’s the primary reason they exist — as a sort of encoding independent reference to a particular character. So, for example, the Œ character does not exist in the ISO-8859-1 character set. To display this character in a document with ISO-8859-1 encoding, use the equivalent HTML character entity: Œ. For an easier reference, check out this full table of HTML character entities. If using ISO-8859-1 for your HTML document, any entity above Unicode index 255 will need to be escaped. If you’re using UTF-8 encoding, HTML character entities shouldn’t be required.

Setting the Character Encoding

To specify the character encoding for any file, you can set a Content-Type header by configuring your web server or application. Apache lets you easily set different default character encodings for each individual file extension (.js for example). Using the Content-Type header is the most full proof and efficient ¹ method to serve content.

But without access to the Apache configuration, how do we specify the character encoding?

For external JavaScript Files

In the HTML File

Just add the charset attribute. If not specified, the HTML document’s character encoding is used by default (specified in the Content-Type header or the appropriate meta tag, for example: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>).

<script type="text/javascript" src="script.js" charset="utf-8"></script>

In the JavaScript File

To my knowledge, there is no way for a JavaScript file to report its own character encoding. To me, this seems like an omission. Each individual document should be able to report its own character encoding without a header. CSS files can do it (@charset at-rule). HTML files can do it (<meta> tag). Why not JavaScript files?

For Dynamically Created Script Tags

var s = document.createElement('script');
s.src = 'script.js';
s.type = 'text/javascript';
s.charset = 'utf-8';

If you’re using jQuery’s Ajax functions to load external JavaScript files, perhaps you might be inclined to use the script dataType. jQuery even provides a scriptCharset option for wrapping the above method for changing the charset on a dynamic script tag. Be warned, the jQuery Ajax function uses two different methods to load external script files (as of version 1.4.2). If a same-domain request, it uses an XMLHttpRequest. If a cross-domain request, it uses a dynamic script tag. So the scriptCharset jQuery option only applies to cross-domain requests. We’ll need some other method to mitigate our character encoding issues (or just use dynamic script tags).

For XMLHttpRequest Objects

Our saving grace would be the overrideMimeType method, if it weren’t poetically unavailable in Internet Explorer. Using this method, we can override the mime type and character encoding.

var xhr = new XMLHttpRequest();
// Not available in Internet Explorer (up to version 8 at time of writing)
if (xhr.overrideMimeType) {
    xhr.overrideMimeType('application/x-javascript; charset=utf-8');
}

Portable non-ASCII JavaScript

The best way to make non-ASCII characters in JavaScript files portable is to escape the characters properly. If the character is destined for HTML, use an HTML character entity (if available, not all Unicode or ISO-8559-1 characters have entities). Or, escape the characters using the proper Latin or Unicode escape sequence.

// Raw characters
var string = "ñó";

// HTML character entities
var string = "ñó";

// Escaped to Latin
var string = "\xf1\xf3";

// Escaped to Unicode
var string = "\u00f1\u00f3";

If you use the Google Closure Compiler, you’ll get the Unicode escape sequences for free (see issues 24 and 68). Make sure to read the tickets for more benefits of serving your JavaScript files using Unicode escape sequences to output only ASCII characters.

Summary

The easiest way to preemptively solve a lot of character encoding issues is to use UTF-8 for everything, and configure your web server/application to serve the UTF-8 Content-Type header. If you’re writing JavaScript code that you’re going to distribute to the masses, convert any non-ASCII characters using the proper escape sequences. Your JavaScript will be more portable, and will work out of the box on more server configurations.

Sources

1. Performance Implications of Charset, an article by Kyle Scholz

// Create a medium size array, at least 100 items
var obj = [];
for(var j=0, k=150; j<k; j++) {
    // the value here doesn't matter.
    obj.push('ABCD'+j);
}
 
// Sort the array alphabetically.
obj.sort(function(m,p){
    m=(''+m).toLowerCase();
    p=(''+p).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

The obj Array should now be sorted, in alphabetical order based on value. BUT, in our best friend Internet Explorer, a Number Expected error may be the result. Don’t be fooled if your test array behaves correctly, it only happens intermittently for arrays of varying size!

So, I whipped up a quick test to check the damage. Iterating over array sizes from 1 to 150, running the Array sort algorithm. The following failures resulted:

* Failures may vary to the specifications of the test machine.

Of course, the Number Expected error is going to result whenever your code doesn’t return a number inside of the function callback. But the problem here is something deeper than simple application code failure. The problem is in JScript itself. Any modification to the sort arguments may result in the Number Expected error.

    m=(''+m).toLowerCase(); // modifies the argument m and is unreliable.

This problem will manifest itself more frequently if you use the Google Closure Compiler, which restructures JavaScript to reuse argument variables if possible, probably to save the 4 character penalty of a “var ” declaration.

Normally, reusing argument variables is a safe practice for primitives, since they are passed by value and not by reference, as is the case in this Array sort example ¹. So, what exactly is going on here? One commenter at the Google Closure Compiler bug seems to think that the actual array values are being passed by reference instead of by value. I’m not completely convinced that’s the case.

The Fix

Don’t reuse the argument variables inside of an Array sort function.

// Changing the above example
obj.sort(function(m1,p1){
    var m=(''+m1).toLowerCase(),
        p=(''+p1).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

Check the source code of the demo file to see the different methods of modifying the arguments that I attempted.

1. If you want to learn more about passing by value or reference, Jonathan Snook has a nice explanation.

Internet Explorer can’t make you do anything, it can only make you wish you hadn’t.

Now, upon discovering myself a newly minted Mac OS convert from the hugely popular World of Windows, I quickly discovered that the application menus (File, Edit, etc) were one of the glaring differences I’d have to adjust to. Mac OS had all menus separated from the application window, all the way at the top of the screen. Coming from the Windows environment, this seemed unintuitive. But after reading more about Fitts’s Law, I discovered the reasoning: the edges of the screen are treated as an infinite height or width! Which is just a way of modifying the Fitts’s Law to say: the easiest things to click on are at the edges of the screen. That’s why the close icon or the Start Menu is so easy to access on Windows, and why the Application Menu is at the top of the screen in Mac OS.

We know about Fitts’s Law, but why aren’t we applying it to our web applications? Why aren’t we using the power of infinite height/width to help out on our designs? It seems like this crucial usability law has been overlooked on the web, and without good reason. Let’s look at a few applications that get it wrong (of course, in my humble opinion).

All of these screenshots were taken from 100% width designs, with no real reason not to incorporate the ideas behind Fitts’s Law into the menuing system. At first glance when I brought up Google Reader, I was excited. The hover behavior appeared when the mouse cursor was positioned at the very far left of the screen, but was disappointed to discover that the although the hover background color had changed, the entire hover target was not clickable.

Naturally, I decided to make a test of my own, to test which web browsers allowed Fitts’s Law Menus. The test case encompassed both left and bottom aligned menus, for completeness. A top menu was excluded, given that the top of the screen is reserved for browser chrome or application menuing. A right menu was also excluded as the right portion of the screen is reserved for the page scrollbar (which is the easiest scrollbar to manipulate with your mouse, per the same rules).

Also, on the Mac OS 10.6 and Windows XP operating systems, a Fitts’s Law Menu at the bottom of the screen is not possible, given that the Dock and Taskbar in these operating systems occupy at least a 4 pixel trough of the bottom-most space on the monitor, even as a hover target in “auto-hide” mode. Everyone is fighting over these crucial and very useful edge pixels.

To test whether or not this behavior is working correctly, maximize your browser window and move the cursor as far left on the screen as possible, but still over the menu. If the links are still clickable, congratulations, your browser works!

View the Demo / Test Page for the Fitts’s Law Menu

Compatibility Table

The full screen mode of each individual browser was considered outside the scope of this study.

Conclusion

We should stand on the shoulders of giants and reuse the usability studies already completed on software that has gone before us. The left side of the browser window is the best place to utilize Fitts’s Law, and we should move our left-aligned menus on fluid width designs to occupy the space flush with the window’s edge to increase the speed at which those menus will be accessible by users. Having an infinite width menu is a big click target to hit.

Generally when exploring a development opportunity, I tend to prioritize my adventures towards things that are supported in Internet Explorer first. This often has the biggest cross-browser payoff, since the other browser vendors tend to have a quicker draw than the Microsoft Team. However, surprisingly enough, this writing-mode study proved the opposite to be true. It seems very interesting that Microsoft has decided to implement a portion of the CSS 3 specification, given its general stance of moving slower than an iceberg to avoid “breaking the web.” But I, for one, welcome our new choose-your-own-adventure standards loving overlords.

As far as my tests go, the only browser to support the writing-mode property at all is Internet Explorer, which was very surprising. At it’s heart, though, writing-mode is just shorthand for two other properties: direction and block-progression. Luckily, Firefox, Safari, Chrome and IE back through at least version 6 support the direction property and have proprietary options for rotation, which allows for emulation of a few of the unsupported writing-mode‘s, but not all of them. The missing piece of writing-mode emulation belongs to the block-progression property, which isn’t supported by anyone, and would allow elements to flow reverse vertically (start at the bottom of a block and flow upwards).

It’s important to note that while IE8 has really set the bar for implementation here and has chosen to support writing-mode: lr-bt and writing-mode: rl-bt, they aren’t used to display any known language text. They’re just included for completeness, and aren’t a part of the W3C CSS 3 Text Module specification.

View the Demo / Test Page

Compatibility Table

CSS Code for Emulation

// Default

direction: rtl;

// Not possible using W3C spec

// Not possible using W3C spec

// Not possible using W3C spec

-webkit-transform: rotate(90deg);
-moz-transform: rotate(90deg);
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

// Not possible using W3C spec

direction: rtl;
-webkit-transform: rotate(90deg);
-moz-transform: rotate(90deg);
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

Conclusion

Given that 4 of the 6 known writing modes are available or available through CSS emulation means we’re in pretty good shape on the internationalization front. Consulting the Microsoft provided table for common use cases, we’re only in trouble when trying to use the “Mongolian script writing system” and an “Arabic script block quote embedded in Mongolian script document.”

In some far fetched fantasy-world legacy application where a page may use tables for layout, I could see an application team possibly using the direction property to redistribute the tables for a print stylesheet. But that certainly wouldn’t be a common use case, since using CSS for layouts is going to give you much more flexibility in that regard. If you can think of any other off the wall uses for writing-mode or direction, I’d love to hear them!

Related

• Very complete article on CSS 3 writing-mode, including some direction properties that don’t exist in the specification (like ttb, ltr-ttb, and ltr-btt)
• Bugzilla Bug for writing-mode in Firefox
• As of the time of this writing, I was unable to find any results for writing-mode on the Webkit bug tracker.

It would seem that perfection is attained not when no more can be added, but when no more can be removed.

While most would argue that the principles espoused in the above quote might also be applied to the quote itself, it would serve us better to consider how we can attempt perfection in our User Interface designs instead.

The most complete litany of reasons why you should spend your page weight on more useful bytes has been compiled by Jukka Korpela, although he seems to both confirm that they are harmful and still use them on his site.

The rules of engagement I find useful when dealing with the ill-fated “Back to Top” or its ugly stepsister “Top of Page” link are as follows:

1. Delete the link.

Really, you don’t need the link. It’s a sacred cow remnant of a time when people believed that all content needed to be positioned above the page fold.

Guess what? People know how to scroll! They know how to scroll down, they know how to scroll up. Considering this prerequisite has been met, it becomes very apparent that the “Back to Top” link shares an unnecessary overlap in functionality with the scrollbar and is thus, unnecessary itself.

If you have an incredibly long page with a full set of “Table of Contents” links, it would be better to position your table of contents fixed to the viewport, so as to make it always available to the user. If the Table of Contents is always available, the user will never have to click a link as a shortcut to find it.

While not a usability epidemic, the “Back to Top” link is still widely used. Instant Shift and Smashing Magazine both have articles with hundreds of examples of sites with these links.

Don’t agree? If you’re stubborn as hell and hate simplicity, you’re going to keep the link on your page no matter what reasons are presented. In that case, at the very least follow these two guidelines:

1. Use progressive enhancement:

   <a href="#" id="back-to-top">Back to Top</a>

   // jQuery Prerequisite
   $('#back-to-top').click(function() {
       window.scrollTo(0,0);
    
       // don't change the hash if not needed
       return false;
   });

2. Hide the link if the page doesn’t have a scrollbar. If no scrollbar exists, the user will always be “at the top.”

   // Continuing with Previous Example
   $(function() {
       $('#back-to-top').hide();
   });
    
   // If the page scrolls, we know there is a scrollbar.
   $(window).scroll(function() {
       $('#back-to-top').show();
   });
    
   // For completeness, you may also want to
   //   add logic to the "resize" event.

Really though, just delete the link.

Take a look at the Dingbats section on fontsquirrel to get your brain going in the same direction.

Webdings is a symbol font designed in 1997 as a response to the need of Web designers for a fast and easy method of incorporating graphics in their pages.
…

Webdings is ideal for enriching the appearance of a Web page. Because it’s a font, it can be installed on the user’s system, (or embedded in the document itself) is fully scaleable [sic] and quick to render. It’s a perfect way of including graphics on your site without making users wait for lots of graphic files to download.

– Source Microsoft Typography

Microsoft was onto something here, and there is a nice parallel that can be drawn between the font and a CSS sprite: namely that multiple images are stored under the guise of a single HTTP request. So, why not create our own font and use it as a CSS sprite? Each character in the font (glyph) will be a single image in the sprite.

Why is this awesome?

• We can change the color of our font using nothing but CSS color. This is a big one. We don’t have to have separate images for hover states! And if we want to change the color scheme, there are no new images to generate and we don’t have to make any changes to the font to do so.
• Don’t have to monkey around with difficult to maintain CSS positioning code.
• Fonts scale, graphics don’t. Zooming in on a graphic will result in a pixelated image, but fonts will be smooth like a 6 blade razor shave. Try zooming on the demo file below.

Why is this not awesome?

• Font glyphs can only contain one color.
• May experience the Flash of unstyled text (FOUT) while the font is loading.
• Extra markup required for IE6 and IE7. While @font-face is supported in all non-extinct versions of IE, each @font-face sprite requires a corresponding text character on the screen. For instance, <span style="font-family: MyCustomFont;">A</span>, the A is required to display the @font-face Sprite stored under the A glyph.
  
  Luckily, in most browsers we can inject a character using CSS :after/:before and the content property. Unfortunately, this is not supported in IE6 or IE7. I haven’t investigated whether or not this might be solved using other means (CSS expressions) yet.
• Safari asks for permission to use the font with a scary popup box, which I assume is a security precaution gleaned from the Windows Vista playbook.

Demo

The following jQuery UI Icons are currently used in jQuery UI and are stored in one big CSS sprite.

It was pretty trivial to create a font with a subset of the jQuery UI icons (only the first 20, just a proof of concept here) using the wonderful FontStruct utility. Then, I took the TTF generated by FontStruct and plugged it into the completely lovely FontSquirrel @font-face Kit Generator. That gave me everything I needed for a fully cross-browser test.

• View the Demo

Let me know what you think!

Read more about @font-face support from Paul Irish.

We must be resilient to resist the transformation from development pragmatism to user abandonment, especially considering a developer’s trend of being insulated with the latest equipment. We use the newest hardware and download the most sophisticated browser software because we want the best experiences. We stack the cards in our favor. The difficulty lies with the populace that want a good experience (they can tell a fast site from a slow site), but they don’t want to buy new equipment or install a better browser. So the question has become: Where do you place your chips on the spectrum balancing modern hardware/software and the user experience?

As web developers, it has become increasingly easy to become disenfranchised with the lay majority’s computing environment. I’ve witnessed this personally after purchasing my first Apple computer, a device curiously immune to the plague of IE 6/7 (8 as well, but I would hesitate to label it as a plague, more like a normal run of the mill flesh eating virus). It’s an interesting phenomenon, being cutoff from the Windows environment (save virtualization) during development. It’s delightfully tempting to declare damnation upon the plague ridden Internet Explorer Zombies, and develop your web presence to standards alone, allowing less focus on the harshest development environment imaginable and more on actual problem solving.

When developers engage in quasi-web development, perhaps in the form of an iPhone specific web application or an Adobe AIR desktop application, it fosters similar feelings. The work shares many languages and technologies with real (wide-open) web development, but is targeted towards a single web browser. This benefits of this sort of tunnel vision device targeting must be carefully weighed against the penalties you’re paying in narrowed default-install client compatibility. At that point, it’s just friends with benefits.

Google Wave, in fact, requires the use of Safari, Firefox, Chrome, or the Google Chrome Frame plugin (which doesn’t count as actual browser support). As of the time this article was written, as many as 64% of all users (source) are met with the above screen when trying to access Google Wave. Let’s be clear: Ease of development is not an excuse to abandon users. Whatever happened to Device Independence?

Not surprisingly, Google Wave’s stand against Internet Explorer has not started a trend. Instead of all out war, the community at large has decided that subtlety is what’s needed to win this fight. Let’s hold back the sexual healing of rounded corners, even though perhaps users will call our design harsh or cold. Let’s give them plain buttons instead of nice three dimensional buttons with text and box shadows, even though they may be less actionable.

Let’s make it easier on ourselves at the expense of the user experience of The Zombie Majority. We make this sacrifice because we assume that Zombies won’t be able to tell the difference between eating a big juicy Einstein brain and a smaller but nonetheless still tasty brush clearing George W. And you know what, I think we’re right.

Updated to include a few more thoughts on Adobe AIR and the iPhone.

Big Enterprise is traditionally known for creating development environments that foster a “get it done” mentality, often rewarding results over correctness (mileage, of course, may vary).

My company uses IE6, and the application works in IE6, so it’s done!

This little quagmire is amplified by the fact that when using Open Web technology, there are many ways to get things done, and most of them are incorrect. But those mistakes don’t manifest themselves until the project is in the hands of the end user, whom we often punish for our oversight.

But there is hope. Using the power of web standards and Open Web best practices, we can achieve something panoramically, not microscopically, beautiful.

The secret sauce of building for the Web isn’t its distribution model, in which updates are managed on the web server without the need to update software on the client (although the Anti-IE6 vigilantes would tell you differently). It most certainly isn’t development efficiency, as most people new to the game will so readily inform you of. Cross browser quirks due to non-standard browser implementations of CSS and JavaScript, or vague standards specifications have seen to that.

When I was writing Visual Basic, I got my job done so much quicker and easier!

The power of the Open Web is Device Independence.

Visitors to our sites shouldn’t be met with warnings about what device they’ve chosen to use.

This site viewable only in IE7+, Firefox, Chrome, or Safari, and at minimum 1024×768 resolution.

This site requires Flash or Silverlight

I realize that this is a controversial stance, especially given that most sites are dropping support for IE6, and more are relying on Flash and Silverlight plugins. Architect applications to your client device usage statistics, and don’t let your tools shape the statistics for you. Using techniques like progressive enhancement, we can ensure that our sites degrade gracefully to the capabilities of the client device. At it’s truest form, this is basic accessibility. But, Device Independence might be a more accurate term, since accessibility is unfortunately an overloaded term scoped solely with devices tied to disabilities (screen readers, for example). While screen readers are a very important piece, there is a bigger picture.

When the iPhone came out, there was an uproar because it didn’t support Flash, for battery life and other reasons. But the uproar was from developers who had designed applications specifically for Flash! Would you say that those Flash applications were designed with device independence in mind? YouTube got around this by encoding their videos in MP4 format, which arguably has a higher device independence rating than the Flash format.

Keep in mind that we’re not attempting to handle every permutation of end user browser settings, since most don’t change the defaults. Instead we are trying to scoop up the largest base of supported devices with the least amount of effort! Who cares if an end user disabled JavaScript in their preferences? I’m more worried about the mobile browser that doesn’t even support JavaScript at all. But when you use Open Web properly, you get support for both!

Output Device Independence

• Full Web Browsers: Does your site work in Opera? Don’t worry about pixel perfection, that’s something completely different — does it work?
• Web Browsers on Mobiles
• Search Engine Spiders and other Screen Scrapers
• Screen Readers
• Printers: Ever had to make an entirely separate page for print-friendly version of your application? Flash/Silverlight do not print well
• Televisions: Xbox 360, Wii, and Other Media Center Devices
• Projectors
• and more…

Take a look at the CSS specification for media types. The standards are there! Support for CSS media types isn’t fool proof by any means, but the end goal is clearly visible.

Input Device Independence

But I’m not just talking about output device independence either. User interfaces should be adaptable to different input devices as well.

• Mouse
• Keyboard (often overlooked in web applications)
• Touch Screens (Single and Multi-touch)
• Voice, Motion Capture, and Facial Recognition (the standards and technology aren’t quite there yet, but progress is being made)
• and more…

The world is developing the Open Web, and it isn’t limited by a single company’s goals and timelines. At times, Open Web may seem like it’s a very slow moving glacier headed our way, but what else can you do but laugh when companies try to power their Titanic right through it?

Article originally inspired by Yahoo’s Graded Browser Support.

As of jQuery 1.3.2, adding multiple HTML classes to an element using jQuery’s addClass method will add them one at a time, modifying the className property of an element for each class.

$('#myElement').addClass('myFirstClass mySecondClass');

Here’s the original code inside of jQuery 1.3.2. Note how the classNames string is split, and elem.className is changed for each split entry.

add: function( elem, classNames ) {
    jQuery.each((classNames || "").split(/\s+/), function(i, className){
        if ( elem.nodeType == 1 && !jQuery.className.has( elem.className, className ) )
            elem.className += (elem.className ? " " : "") + className;
        });
    },
// ...

This may cause longer than needed delays, as reflow may occur after every class is added individually. If absolutely necessary, you can always fall back to modifying the className yourself, like so:

$('#myElement').each(function()
{
   this.className += ' myFirstClass mySecondClass';
});

Most likely, this isn’t a tip that will be needed, but it is useful to be aware of.

This morning I went back to the same URL to find a site that was no longer using the full page Flex application I had been expecting. Instead it was now using native Open Web technology.

Naturally, my first assumption was that I had hallucinated the original research. But as it turns out, I wasn’t the only one that noticed the Flex application. This blogger complained about the accessibility of a full page Flash/Flex store. Another blogger had a similar complaint.

I have no idea how long the Flash/Flex Adobe store experiment went on before they changed it back. I’m just glad I’m not crazy.

Update: Turns out they are using a whitelist/blacklist of user agents to decide whether or not to show the Flex store. The original entry point above is incorrect, and shouldn’t have the html subdirectory. If you go to the site in Chrome, it will redirect you to the HTML version. My apologies, Adobe, although I do think the HTML version is much more accessible.

When developing on the front end, it’s easy to prioritize correctness over performance. Performance is the step child that gets lost while you’re pulling your hair out worrying about cross browser compatibility. It’s very important to regularly benchmark your JavaScript code, using a profiler or some form of benchmarking code paired with a cross browser logging utility (see Firebug Lite, YUI Logger, or log4javascript).

Event delegation is a great way to program for performance. The live jQuery method was a great addition to the jQuery core, it makes event delegation really easy (see also the closest method). Unfortunately, it isn’t quite what I expected.

For example, say you have a page containing approximately 500 custom tooltip components on it (not typical, but stick with me, this is to prove a point). How might one go about adding a simple live event to activate each tooltip when the user hovers over it?

$('span.myTooltip').live('mouseover', function(event) {
    // activate tooltip
});

See the problem? jQuery will actually run the selector on the document, resulting in unnecessary overhead. jQuery is only assigning a single event handler to top level of the document, why does it need to know what nodes it will be binding to before assigning the callback?

What can we do? Let’s create a jQuery function, instead of a method, so it won’t query the document. Try this on for size:

$.live = function(selector, type, fn)
{
    var r = $([]);
    r.selector = selector;
    if(type && fn) {
        r.live(type, fn);
    }
    return r;
};

Usage

// Single event type
$.live('span.myTooltip', 'mouseover', function(event) {
    // activate tooltip
});
 
// Multiple event types (you can call the jQuery live method on the return value from the function)
$.live('span.myTooltip')
    .live('mouseover', function(event) {
        // activate tooltip
    })
    .live('mouseout', function(event) {
        // deactivate tooltip
    });

Also, as a side note, keep in mind that jQuery live doesn’t support space separated events, like bind does.

// Will not work.
$('span.myTooltip').live('mouseover mouseout', function() {});

Have fun!

Hit Options, then the Clock Format tab to change to Unix Time. Enjoy!

So, some sites have gone two ways, allowing OpenID, but also a proprietary registration system. This too, is problematic. It would seem that given a choice, the John Doe the Plumber style user will choose a proprietary account over the confusing user experience presented to them through OpenID.

But the annoyance doesn’t just lie with account registration for web applications. Typing your personal information on every blog you comment at is also repetitive and unnecessary. Some sites even require account registration for something so minor and transient as a blog comment.

Unfortunately, for the time being, it looks like registration forms are here to stay. So, what can we do to make those registration forms more usable, more efficient, and ultimately downright friendly? I know that you’re ahead of me on this one: Let’s auto-complete information for the user.

Please keep in mind that this power can be used for both good and evil. Essentially what we’re discussing here is data mining available information from various social networking sites on the internet, trying to glean personal information about an end user that has volunteered a piece of their data already. What can we get from what we already have?

Once a user has typed in their e-mail address, we can:

• Retrieve Twitter profile information (example shown on Chris Heilmann’s blog):
  • Full Name
  • Short Personal Description
  • Location
  • Web site URL
  • Time Zone
  • Favorite Colors (used on their profile)
• Retrieve an avatar if they’ve registered for the Gravatar web service (See my earlier post discussing this).
• Get their upcoming calendar events from a public Google Calendar. (Perhaps not as useful for autocompleting forms, but interesting)
• Find their UID on Flickr, which gives you a source for:
  • Full Name
  • Location
  • Flickr Avatar

If you know any of their social networking usernames, you can:

• find their MyBlogLog profile, if they’ve linked the service to their account (Sample query, I added my twitter). Now we have:
  • MyBlogLog Screen Name and ID, from which you get their MyBlogLog profile:
    • Nickname
    • Picture
    • Age
    • Sex
    • Location
    • A list of tags they use to describe themselves.
  • MyBlogLog Avatar

Those are only some of the proof of concept API’s that I’ve listed here. The interesting piece of this, is that once you have a small piece of information, it opens up the door to other searches.

One can only imagine how many leaves are in this tree. For example:

• Facebook’s Users.getInfo (in JavaScript)
• Yahoo’s Social Tools, get an end user’s GUID and go to town on their profile.
• Google Contacts, I didn’t even start to look through their API’s.

Before you start jumping the privacy fence to a self induced heart attack, remember that all this information has been volunteered by each individual participating in each of these services. Remember, with great power comes great responsibility.

What do you think? Scary or useful?

Download the Source Code

Here’s a use case. An unregistered visitor visits your blog, and decides that your content is so good that it merits a comment! Congratulations, you’ve fooled them! Now you can twply their account details for $1200 on Sitepoint! Just kidding. But generally, when you visit a blog’s commenting section (such as the Tournology Blog shown above), you’ll see a simple form to authenticate you’re not a spammer, generally including (among other things) an e-mail address field.

Well, since they’re typing their e-mail address, wouldn’t it be cool if we could show them their gravatar right there, inline with the blog comment form? Well, that’s now possible with my new JavaScript Gravatar Plugin! It doesn’t have any server side language dependencies.

Hell, gravatar.com could even use this to improve the user experience of registering your e-mail account. Right now it does a full page refresh and doesn’t even show you a preview!

See the Demo

Download the Source Code

Licensing

Licensed under the WTFPL, as highly recommended by Isaac Schleuter (see discussion).

JavaScript Dependencies:

• Requires jQuery (Feel free to port and post a link!)
• Requires md5.js

Example Usage:

Easiest form, onblur of email text input field:

$('#emailTextField').blur(function(event)
{
    $(this).after($.gravatar($(this).val()));
});

Showing all options, again onblur of email text input field.

$('#email').blur(function(event)
{
    $('body').append($.gravatar($(this).val(), {
        // integer size: between 1 and 512, default 80 (in pixels)
        size: 200,
        // maximum rating (in order of raunchiness, least to most): g (default), pg, r, x
        rating: 'pg',
        // url to define a default image (can also be one of: identicon, monsterid, wavatar)
        image: 'identicon'
    }));
});