Last month, the Software Usability Research Laboratory (SURL) at Wichita State University put out a new eye-tracking study, focused on differences in eye-movement patterns between single- and two-column web pages.

For some reason, I always read these, and inevitably end up frustrated. Not just because of the standard objections to eye-tracking as a useful methodology, but because out of the 20 of them I've read, it feels like numbers 2-20 haven't added anything substantive – or, more importantly, generalizable – to the information I got in the first one, which taught me about the "F"-shaped eye pattern (later popularized as the "golden triangle").

So this time, I was determined to review some of the secondary literature on these studies (in the form of scanning the first page of Google's search results [note to self: touché]), and see if I could generalize the lessons of eye-tracking studies for myself and people like me.

And when I say generalize, I don't mean come up with a Smashing magazine list of "The Top 276 Things Designers Can Learn from Eye-Tracking Studies" that basically recapitulates the bullet points of all the harvested literature verbatim. I'm talking about getting this down to a set of rules of thumb you can write on the back of a business card.

Now, if the post title didn't scare you away, here's your explicit warning: I am a web designer. I make sites that don't tend to be advertising-supported. My problems are very different than the problems of people who have to figure out how to increase click-through at Google, or who sell their expertise at ad-placement. I am honestly concerned with usability here, not revenue. If you want that, here are about 89,400 references for you.

Mutatis mutandis, and without further ado:

1. Use the top left corner.

As indicated back in April of 2006 by the Nielsen group, readers focus hard at the top left corner, and progressively less to the right and down the page. This means that you've got a relatively small piece of your total real-estate to both get your readers hooked on your content and to teach them how to use your site.

This gets exploded into a lot of facts, but the rule here is simple: Don't get creative about where you put your site hooks. If they're not in the top left corner, users are going to leave before they ever find them.

This is, of course, only true for countries and alphabets that read from top left to bottom right, and particularly in languages that allow people to effectively create useful semantic maps by scanning (as opposed to more ideographic alphabets).

Additionally, all of the standard corollaries about short paragraphs, big headlines, preference for single-column layouts, etc. are established by this rule. Assume that your reader is already not paying attention. "This seems consistent with 'Information Foraging Theory' where users are said to hunt for information by 'scent' or navigation and content of the highest value to them." (Spillers, 12-2004)

2. Type size & attention have an inverse relationship.

The data seems to indicate that people read smaller type more carefully.

That said, you're going to need to strike a balance, as left to run amok, this can operate contra to all that good advice about not fatiguing our readers eyes, and about bigger text being "friendlier", etc.

In fact, bigger text is presumably thought friendlier precisely because it invites you (the reader) to scan it easily, and doesn't force you to pay particularly close attention. So, understanding that screen type-design is a negotiation between being better liked (using bigger fonts) and being better read (with smaller fonts), it's clear that you can't just make all your text minute with the hope that it will force your readers into a trance-like focus on your every word.

You can't, that is, unless you have a 250px-wide readable column.

3. Pretty bird!

Finally, there is apparently some evidence that people will look more carefully at images if they are (a) big, and if (b) they contain a person's face.

You talkin' to me? Pretty bird!

We're calling this "Pretty bird!", because I am pretty sure this is an Amygdala-level reaction that operates similarly to a parakeet staring at itself in the mirror. We like to look at big, clear pictures of people. We can sympathize.

Mission Accomplished!

Some time ago, we were working on a website that required a contact form with the ability to attach a file. This sounds like, at this point in web design, it should be incredibly simple. Imagine my chagrin as I learned that, in fact, styling the FileUpload Object had a smack of Holy Grail-ness to it. Well, at least as far as HTML form objects are concerned.

A lot of people have had similar ideas on how to handle this. I suppose it all started with Michael McGrady's solution, which was followed closely by an improvement on McGrady's technique from Peter-Paul Koch over at Quirksmode. The closest thing I found to a satisfactory solution, though, came from Shaun Inman. His solution was definitely the right idea, but it wasn't exactly full-featured, and I wanted it built in my favorite Javascript framework.

Like Shaun, I don't think that the text-box is an appropriate UI element for a file upload in 2008 (who wants to type c:\Documents and Settings\Paul\My Documents\My Photos\2008-06-02-Me.jpg into a field that only shows 25 characters?!). Further, every implementation I've ever seen that makes use of a text-box is wonky. So I wanted to do a Safari-style upload.

I appreciate the cleanliness of Safari's implementation. It's the best default browser implementation out there...but it's still not good enough!

Shaun's really clever idea involves setting the input's opacity to zero and then using a little javascript function to keep the button under your mouse while you're hovering inside the input's parent container. With the hardest part figured out, I had two additional goals:

1. First, I needed it to display the file name of the uploaded file. One problem with Shaun's is that I couldn't even verify if I'd successfully attached a file.
2. Second, I agree with Peter on the importance of being able to clear the file from the form. No implementation I've seen allows you to do that, so I added the feature.

To see how it's done, you can either read the walkthrough or else download a working example.

I spent a good part of this morning watching John Berger's 1972 television series Ways of Seeing (nod to Click Opera).

Ways of Seeing follows from a line of thought set forth in Walter Benjamin's canonical 1936 essay, The Work of Art in the Age of Mechanical Reproduction. Summarily, with the advent of art's mechanical reproducibility, and the development of forms of art (such as film) in which there is no original, the experience of art is freed from place and ritual and instead brought under the gaze and control of a mass audience, leading to a shattering of the object d'art's "aura" - its ability to produce awe and reverence in a viewer.

You must hurry to see this incredible show at YouTube while it is still available.

Read More...

Now more than ever, our clients want cool AJAX components for their sites. It seems like more often than not, we find ourselves creating whiz-bang image galleries, file upload forms, and a variety of other interactive components. These components can be tasteful and add much-needed fun to an otherwise run-of-the-mill interaction experience, so we like doing it.

One of the things we don't like about it, however, is the ease with which web standards can be thrown out the window in the "getting it working" part of the component development. One of the most frustrating culprits is often the family of tags that are required to generate CSS-based opacity effects for interaction elements.

Now, I am generally against using Javascript to apply unsupported CSS definitions as a salvo against the mean red screen of the CSS validator. This is usually a bad idea because, among other reasons, it can fail to degrade gracefully if the user doesn't have Javascript, and it provides a strategy to allow invalid CSS validate in cases where it really shouldn't, it's a little bit clunky when compared to other available methods, and frankly, introducing Javascript into the equation just to validate CSS rarely seems worth the trade-off. That said, in this situation, I think it's legit because:

1. The opacity definition(s), while being supported by all current major browsers and darn useful, isn't included in the CSS 2.1 spec, despite apparently being part of the jetpack-esque CSS 3 spec (::someday::), and doesn't validate.
2. In the case of an AJAX component, you're already requiring that your users have Javascript enabled, and hopefully you have a graceful exit strategy already in play if they don't.
3. Your only other choice to achieve the effect you want is to use something like Flash, which is certainly worse even than invalid CSS.

So let's take a look at how to save your opacity effects and your valid CSS using some handy DOM scripting.

Example: SmoothGallery

I like Mootools. I like its speed, and its clever implementations, and of course, its tiny size. From now until something better comes out, when I write example AJAX, it's going to use Mootools. It rules. End of plug.

Along with the Mootools framework, I have (several times) used customized versions of JonDesign SmoothGallery, a free Mootools-based AJAX image gallery. It is a very nice little component in many respects, but, being one of these it doesn't validate, which makes it untenable as a final client solution, at least out of the box.

By brilliant deduction, you will have already gathered that the reason it doesn't validate is because CSS 2.1 doesn't support a handful of opacity-related tags that SmoothGallery uses. It is full of CSS definitions that look like this:

filter: alpha(opacity=n);
-moz-opacity: n;
-khtml-opacity: n;
opacity: n;

Which lead to something like this:

Opacity: Does not compute!

To fix this up nicely, I always go in and delete these CSS definitions, and then write a little Javascript function, using the good old Mootools selectors, to apply these events at runtime:

function applyOpacity()
{
    if ($E('a.right'))
    {
        $E('a.right').setStyle("filter:","alpha(opacity=20)");
        $E('a.right').setStyle("-moz-opacity","0.2");
        $E('a.right').setStyle("-khtml-opacity", "0.2");
        $E('a.right').setStyle("opacity", "0.2");
        $E('a.right').addEvent('mouseover', function(e) {
            $E('a.right').setStyle("filter:","alpha(opacity=100)");
            $E('a.right').setStyle("-moz-opacity","1.0");
            $E('a.right').setStyle("-khtml-opacity", "1.0");
            $E('a.right').setStyle("opacity", "1.0");
        });
        $E('a.right').addEvent('mouseout', function(e) {
            $E('a.right').setStyle("filter:","alpha(opacity=20)");
            $E('a.right').setStyle("-moz-opacity","0.2");
            $E('a.right').setStyle("-khtml-opacity", "0.2");
            $E('a.right').setStyle("opacity", "0.2");
        });
    }
}

You'll note that in addition to setting the default opacity, we have to add some events to mouseover and mouseout. This is because Mootools (currently) doesn't support CSS pseudoselectors, so we have to replace the .n:hover definitions in the CSS with Javascript events.

Now all we have to do is call this method on domready (or on window load in more old-skool cases):

	window.addEvent('domready',applyOpacity);

Here are the final opacity effects in action, at one of our client sites, Angel Guardians, Inc:

Runtime-applied CSS opacity in an image slideshow. Look at the top left and top right corners.

And here's the gin in your martini:

Opacity, computing!

Hopefully you can see how this abstracts to any situation in which CSS opacity is being used on elements in an AJAX component, and also to any Javascript framework. You can always use document.getElementsByClassName('right'), or any other selector you
prefer, as well as window.onload = applyOpacity or your choice of any method of attaching a Javascript event.

Update (2008-05-24)

Due to some confusion regarding the application of this technique, I've created an example, which you can view online or download (12kb, zip).