Rob Wilkerson

I keep trying to leave Firefox behind.  And trying.  And trying.  Not behind, behind like feathered hair or roadkill, but behind as in dropping it as my primary browser.  I haven't had much luck so far and it's pissing me off just a little bit.  This I tell you this now because I just installed 3.0 b2 on my Mac hoping it would be better than 2.x and my bitterness is a bit more acute at the moment.  Needless to say, it's not better.  Not really, anyway.  It doesn't even look that much better.  I may even prefer the look of 2.x with one of Aronnax's outstanding grApple themes applied, to be honest.

I adopted Firefox as my primary browser somewhere around the 0.8 release.  It was fresh, clean and snappy and it was just a pleasure to drive.  I don't know when the transition occurred, but somewhere in the last year or so it's begun to feel clumsy, cumbersome, bloated and generally heavy.  Memory leaks, crashes, sluggishness when simply opening a new tab (which I have set to load about:blank) and seemingly random beach ball appearances have all taken their toll on my patience.  And before you ask, no, I don't have an endless parade of extensions loaded.  I've long since gone through the effort of identifying those that are really useful to me and those that are merely convenient or even whimsical and weeding them out.  Nothing has helped.  Certainly not enough to make me truly enjoy the experience of browsing with Firefox.

I've tried Safari.  I like it.  It's fast.  Unfortunately, it's not even remotely extensible.  Yeah, I know you can pimp Safari, but those aren't extensions.  Safari doesn't offer an official extension architecture, as far as I know.  The very fact that any extended functionality exists at all is owed entirely to the talented developers who wanted more and cared enough to dig deep and find a way.  Apple could slam that door any day, if they chose to do so.  I don't want to become dependent on something that could disappear tomorrow.

I've tried Flock.  Nice, but too much social butterfly bloat for my tastes.  Full disclosure: I didn't spend enough time with it to even determine whether extensions are available.  I may go back and give it another shot if I hear of any reason to think it's better than I give it credit for.

I had hoped that "Site-Specific Browsers" like Fluid (Mac only) and Prism (née WebRunner) might fill the void.  I love the concept.  The ability to run web applications as independent desktop applications solves a lot of problems for me - real and imagined.  On the "real" side, I love that I have some measure of protection if/when my browser crashes.  My apps are running independently and are unaffected by whatever fit of irritability strikes my browser.  On the "imagined" side I have better control over my desktop clutter.  Throughout the day, I spend a lot of time in Gmail and Google Reader.  I also spend a fair amount of time in Basecamp, several different Trac projects, Google Docs and few others.  That's a lot of tabs in a browser window so I typically leave only Gmail and Google Reader open.  Two permanent tabs are somewhat manageable.  More, well, aren't.

Site-specific browsers spare me from having to make that choice.  I can create a separate desktop application for each web app and have each window open all day long without affecting my browsing experience.  On the Mac, I have the added capability of hiding windows (via Cmd+H) to keep them open, but further reduce desktop clutter.  Those I don't explicitly hide away are hidden away for me by SpiritedAway (a very handy utility for clutter freaks like me).

Alas, none of these are extensible either.

I tried Camino, but to be honest, I did so when I was still pretty enamored with Firefox.  I may not have given it a fair shake.  I think I'll venture back in that direction for a little while.

Maybe I just need an intervention.  Maybe I'm hopelessly addicted to the extensibility that Firefox offers and its sluggishness and unresponsiveness are the price I pay.  Between extensions and Greasemonkey scripts, maybe my life has become too productive within the browsing experience for me to sacrifice it in favor external issues.  Maybe Meatloaf was right and objects in the rear view mirror really are closer than they appear.  Firefox 3 is still in beta.  Maybe there's still hope...

I write less code than I used to (particularly during the daylight hours), but I inherit a lot of code and I review a lot of code in addition to that which I still write. Today I read something that reminded me to write about a trend - or maybe it's an oversight - I've noticed in the last few years. It seems that a lot of developers are afraid of errors. Somewhere, somehow, it seems like it became the norm to create "bug-free" software by masking bugs and failing silently. Why? Or, more assertively...stop that.

Contrary to popular belief, errors are user-friendly (at least in the long run). Errors are certainly developer-friendly. In almost every case, the latter begets the former, I've found.

I've spent hours of my life on the phone with customers attempting to articulate some cryptic, unexpected behavior in their own vernacular expressed through their perception of events. It's irritating and frustrating for everyone involved, but it's not their fault. If the software I've created or inherited hasn't provided them with a more precise avenue by which to relay the problem - a clear, concise error message - then this is the only means I've allowed them. This will not end well. Not for anyone.

Users are using software for their own reasons and their reasons almost never include carefully monitoring action sequences in case they need to replay it later for support or development staff. Really. When they're forced to do so, the result is often wildly inaccurate and littered with assumptions. Likewise, support and development staff have their own assumptions and even their own vocabulary. Sync'ing so many variables across disparate actors is challenging at best.

Many of these challenges can be easily avoided with proper error messages. Errors should be written clearly and concisely, but with sufficient detail. If detail must be omitted from the message presented to the user for spatial or security reasons, at least log the necessary level of detail. More information translates directly into easier reproduction, quicker isolation, more precise adjustments and faster turnaround time. That translates nearly as directly into a happy user.

Here are my requirements for error messages:

1. Use complete sentences.  Sentence fragments can sound terse and "unfriendly".
2. Briefly, but clearly, state the nature of the error.
3. Provide additional detail about the error.  This might include where it occurred, when it occurred, the previous action, etc.
4. Offer a few common, known causes of the error (if applicable).
5. Provide the details of a workaround (if any).

The first two requirements are mandatory.  The third is highly recommended, but may be logged rather than displayed.  The last two are optional largely because they may not be applicable.  Adding this level of information, though, gives the user a sense of empowerment and is generally well received.

Most (reasonable) users I've encountered don't mind errors (to a point). When errors occur, most genuinely try to provide as much information as they can and are even willing to work with support and development staff to reach a level of comfort that the problem has been clearly expressed. Articulate error messages bring that process to a happy conclusion much faster by removing ambiguity.

Generally speaking, I do everything I can to avoid images in content. Simple text is easier, more maintainable, more accessible and, for added incentive, I'm a spectacularly inept designer. Predictably, though, there's always an exception. When an exception arises and I have to use an image, I still want the markup to be semantic and accessible.

The technique I use isn't revolutionary or even new, but I don't see it used very much where I work, so I thought I'd write it down. Who knows? Maybe it's less common than I've been assuming it is.

Let's pretend, for example, that I have a logo for robwilkerson.org that I want to use in lieu of the text that appears now (work with me here). Since it's the name of my site, it's also the most important text on any given page of the site - a perfect candidate for h1 status. Except I need to use an image to get the branding right. Hmmm...

Fortunately, it's not so hard to do both using semantic markup and a background image. Using this example, my markup would look like this:

<h1><a href="/"><span>robwilkerson.org</span></a></h1>

h1 because it's important text. a because I want to be able to click on the site name and get back to the site homepage. span because, well, you'll see. Now that I have my text, it's time to apply the logo image. I do this in my stylesheet:

h1 {
   background: url(/path/to/my/logo.png) top left no-repeat;
   height: 57px;
}
   h1 a {
      display: block;
      height: 100%;
   }
      h1 a span {
         visibility: hidden;
      }

My logo image is applied as a non-repeating background on the h1 element. To make this work, the element's height must be at least equal to the height of the logo. The nested anchor element is given a block display so that its height can be set. Given this styling, the entire logo will be clickable. Lastly, the inner span is hidden so that only the logo is visible. If I hid either the anchor or the heading then the logo wouldn't be clickable.

One important detail is the use of the visibility property rather than the display property to hide the text. Many, maybe all, screen readers will not read text whose display is set to none. Most, and again maybe all, will read text that is simply hidden.

Stylish, accessible and searchable.