Windows Vista and Mac OS X Leopard include widget (aka gadget) functionality that essentially lets you create a Web clipping from a Web page and park it in a dock. The built-in browser (Internet Explorer and Safari, respectively) works behind the scenes to display the clip. So at first glance, that seemed the way to go: Just tell users how to do this, and let them do it.

But that makes the user do the work, which is hardly ideal. And I wasn't happy with the Web-clip experience. It's just not as satisfying as a real desktop widget -- for example, you have to open the dock that displays the clip, so it's not convenient for all-the-time casual access. And in Mac OS X, when you close that widget dock, the Web clippings are removed, so they have to be created anew each session. That's silly.

More critical, 80 percent of our visitors use Windows XP, which doesn't support Web clippings.

So I had pretty much given up on doing desktop widgets.

But the weekend before I was due to deliver my working prototypes of the Windows Sentinel Web and mobile front ends, I saw that the Adobe AIR SDK and the companion plug-ins for Dreamweaver and Flash had just been released for download. I figured, "Let's see what AIR can do."

Less than two hours later, I was able to essentially export my mobile Web pages into desktop widgets. Better, Adobe AIR produces a single executable that runs on Windows XP, Windows Vista, and Mac OS X Leopard -- and, soon, Linux. (You do need the free Adobe AIR Reader, which is to AIR apps as Adobe Reader is to PDF files.)

A quick read of the documentation showed it was easy to add persistent object storage, such as saving your login information for these widgets. That was important for the Windows Sentinel desktop widgets because I had to have a user sign-in. Because the AIR apps are compiled, I couldn't embed a user ID into a URL or the equivalent on the fly for each user, as I could with the mobile widget's URL. There had to be a sign-in so that the widget would know what ID to send to Kennedy's servers to pull in the right performance data. But signing in each time would be a real user annoyance, which I knew but didn't want to admit as I hit a lazy point. As I was about to hand off the project to the Web developers, I knew I could no longer ignore the issue, so I did a quick search in the AIR SDK documentation. In a few minutes, the problem was solved. (Later on, Kennedy wrote a JavaScript that took care of this through a database query on his end, so we could keep all our code in JavaScript.)

Adobe has essentially taken the approach of extending JavaScript, so the programming is very familiar. And most of it can be done through what you develop in HMTL and in your scripts, with AIR taking care of the heavy lifting as you export from Dreamweaver or Flash. Of course, if you want to real app development, you get a full language as well. I'm not saying the AIR is perfect: Our Web developer Kwansah Madani had to create separate versions for Windows Vista, Windows XP and Mac OS X Leopard because the desktop widgets displayed slightly differently in each platform despite coming from the same Dreamweaver code -- the kind of infuriating display incompatibility issue we thought ha been related to Internet Explorer. And the AIR plug-in for Dreamweaver could use some refinements.

But I think most organizations will discover that Dreamweaver and Flash have magically become an easy lightweight development platform that a wider range of employees can put to good effect than could ever use a full-blown IDE.