Adventures in lightweight Internet app development

Follow InfoWorld's first steps in lightweight app development for emerging mobile devices and desktop widgets

I should be clear up front: I am no programmer. I dabble in JavaScript, and I learned Fortran and Basic (not the visual kind) in 1978 and haven't used either since 1986. My programming style (such as it is) is declarative, not object-oriented. But I'm handy with Dreamweaver.

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.

[ Monitor your Windows desktop and server performance with the new Windows Sentinel toolsfrom InfoWorld. Share your questions and experiences in the companion blog. ]

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.

Originally, Editor in Chief Eric Knorr's project mandate was to make Kennedy's performance monitors accessible through our site, so readers would have a personal landing page for viewing their data. That was easy enough: iframe the monitors generated by Kennedy's application on his server and add a simple JavaScript line to insert the individual's unique ID, so Kennedy's app would know whose data to stream. To get that ID, our registration server simply included it in the URL, so all I had to do was read it and pull the ID into a JavaScript variable, which would then pass it to the iframe.

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.

Because Kennedy's monitors produced graphical charts from what the software agents recorded and because those monitors offered user configurability, it was clear right off the bat that we needed to focus on mobile devices that support "real" browsers, meaning those that could support the kind of HTML, JavaScript, PHP, and so on that you'd use on the desktop. The iPod Touch and iPhone showed me these devices now existed -- and that people were actually buying them.

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.

Because the mobile "app" is really a miniature Web page, I could also avoid having to add a sign-in area in the skin. Instead, the e-mail that generates the link for you to bookmark on your mobile device simply appends your unique ID using a simple JavaScript snippet, so the sign-in is embedded into the URL. Because neither the ID nor the displayed data identifies whose systems' performance data is being displayed, we were all confident that this approach would not cause privacy concerns.

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.)

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.

Copyright © 2008 IDG Communications, Inc.