So when InfoWorld decided to create a lightweight front end for the Windows Sentinel performance-monitoring agents developed by our Enterprise Desktop blogger Randall C. Kennedy, I probably wasn't the safe choice to do the development work. But if you believe in the Web 2.0 promise that business analysts can do lightweight development, then I was the perfect test.
Well, the proof is in the pudding. You can see the results of my work (though vetted and tightened by our Web development team) at our beta Windows Sentinel page. The page is nothing special; it does what Web pages have done for years. But what is new is the creation of mobile and desktop widget components. Here's how they came to be.
Building for mobile Web 2.0
But I had recently bought an iPod Touch and was enamored with its ability to deliver much of the real Web in a handheld form factor. No less-than-Web technologies like WML there -- call it mobile Web 2.0.
I believe the era of a crippled mobile browser is coming to an end very soon (sorry, BlackBerry and all the cellular companies), thanks to the iPhone and the iPod Touch. Yes, Palm has been there too with its Blazer browser, but it was the iPhone that made the idea of the mobile Web real to the world at large. Given the crippled-Web strategies of most mobile devices today, our mobile widget won't work on many. But it will work on the most popular mobile devices: the iPhone/iPod Touch and Symbian 12-based Nokia devices; these two devices account for about 0.23 percent each of Web traffic, versus 0.06% for all Windows Mobile versions combined and nearly 0 percent for Palm OS devices, according to March 2008 data from both Net Applications and StatCounter. Users have quickly migrated to the mobile Web 2.0 devices, and that's where InfoWorld will play.
The Windows Sentinel mobile widget should also work with the Blazer browser on Palm OS-based Treos and the Opera Mini browser available for a variety of mobile devices, though given the wide number of variants, we're not prepared to guarantee that.
When Microsoft releases its Windows Mobile 6.1 platform and its promised truly Web-compatible mobile Internet Explorer, we hope our widget will become available to that community. If you use Windows Mobile 6 or earlier, all bets are off. The RIM BlackBerry is not compatible, even if you fiddle with its settings to simulate a Web browser.
Focusing on mobile Web 2.0 devices also simplified a difficult question: what screen sizes to support. When you take in all the mobile devices that have some graphical capability and Internet connectivity, you discover dozens of variations, using different standards to boot. It's nuts to try to support them all, even if you use a tool such as Adobe Device Central that tracks the dozens of display profiles for you.
By sticking with mobile Web 2.0 devices, that universe got a lot smaller. That range of sizes is still bigger than it should be, but I'm confident that the iPhone's 320-by-480-pixel screen will set the bar for the rest of the market, in a year or two, we'll see most devices either at that size or at a 240-pixel width, as many Palm, Symbian and Windows Mobile devices still use.
Fortunately, Kennedy had designed his monitors to be compact, so it was trivial for him to adjust their size to fit the 240-pixel width I decided would be our minimum. That left precious little space for the "skin" that wraps his monitors, presenting a real challenge to our designer. Ultimately, I asked him to design it to look good at 320-pixel width but to work in a collapsed form at 240 pixels. My bet is simple: The world will coalesce at the 320-pixel width in the next two years, so the 240-pixel devices are soon to be our legacy and should not overly confine where we want to be.
The designer had to make sure the UI fit in the small space, something I tried to anticipate in the prototype stage with a very simple interface that would reside in that skin. We did not want to repeat the mistakes of many early Windows Mobile apps, which tried to shrink full screens into postage-stamp-sized spaces. So the interface is minimalist: a simple pull-down menu lets you move from one widget to another (it also saves users from having to move among four separate bookmarks on their mobile device to see the different monitor views). We took another page from the iPhone experience and aimed for a simple interface.
And pure elegance is the only way to describe the simple extension that Apple provides to HTML CSS to let users easily add a Web page as an app to their iPhone's home screen -- it's an easy way to get viral distribution. Yes, I know it's essentially the same concept as an ICO file for a Web page to put an icon in the Web address in a browser. That's elegant too -- and Apple doesn't make you use a weird file format.
Desktop widgets: AIR to the rescue
So mobile was easy, once we decided on a minimum standard based on the popular leading-edge devices. But the other type of widget -- the desktop widget -- was a bit trickier.
I wanted to offer a desktop widget, something you could leave running on your computer even if you weren't in your browser. After all, an admin is going to be doing lots of stuff on his compute, and keeping a browser window open all day for these performance monitors wasn't a realistic goal. But leaving a small widget running on the desktop -- that's already been proven effective in the BI world.
But how to do this in a lightweight way?
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.)
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.