Rob Wilkerson

In spite of my previous rant, I'm not prepared to give up Firefox just yet - even in the face of blazing speed increases from the Safari camp.  Now the Firefox team has given me one less reason to switch (albeit a superficial one). The new beta3 release is gorgeous, borrowing heavily (it's homage, right?) from the Safari UI, it seems to me.

I've only had it installed for a few minutes so I can't speak to any other improvements, but I like the look (a lot) and they appear to have fixed a bug that prevented me from editing blog posts in the beta2 version.

I've been looking forward to this for a long time now. SuperDuper, of course, is the outstanding backup software for Macs and this release offers compatibility with OS X Leopard. It's not free, sadly, but it's one of those apps that is far enough ahead of its free counterparts that I believe it's worth paying for. Yeah, I know Leopard ships with TimeMachine. Wonderful. Fantastic. Not good enough. Doesn't work for me.

I don't mean that it literally doesn't work for me. It probably functions just fine. My problem with it is that TimeMachine forces me to park a big ol' external hard drive on my desk and hard-wire it to my machine. One of the reasons I transitioned to laptops all these years ago is because I really like the small footprint. My workspace doesn't feel as cluttered as it did when it was dotted with a monitor (or two) and all of the other accoutrements. I actually have room to, you know, work. My mission is minimalism - even at the expense of a proper backup, apparently. Why TimeMachine can't natively support backups to a network server, preferably over wireless, I don't know. The cynic in me is inclined to wonder whether it was a deliberate ploy to create a market for Time Capsule, though the fanboy in me keeps the cynic from getting too belligerent. The point is, TimeMachine doesn't backup to a network server. Nor is a TimeMachine copy bootable. A SuperDuper copy is, though. Another check in favor of the latter, as far as I'm concerned.

I upgraded to Leopard about a week after its release (when was that? October? November?) and hadn't done a backup until two nights ago after installing the SuperDuper upgrade. I was fortunate that nothing catastrophic happened in the interim, to be sure. I waited to write this until I had performed two backup operations - one kicked off manually and the other scheduled - and I'm happy to report that the upgrade was every bit as seamless as I could have dreamed it to be. Not only was the upgrade itself easy, but even after several months worth of file system changes, both backups ran without issue.

Comparatively speaking, I'm feeling very safe these days thanks to the guy(s) at ShirtPocket Software.

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.