Sean Coates: PHP, Web (+Beer)

I have a love-hate relationship with Adobe AIR.

On the positive side, AIR allows developers who are primarily experienced in web technologies (such as myself) to apply existing skills to the creation of GUI applications with a minimum of additional deployment-specific competence, and to release those apps on several platforms, in parallel.

This shallow learning curve has facilitated the creation of GUI apps that would never have otherwise graduated beyond a passing thought by their creators.

A good example of this is Spaz, my currently-preferred interface to the Twitter. Ed, its author, and my friend, is well-skilled in web technologies and I suspect that both the application of HTML and JavaScript to GUI deployment, and platform independence, were key factors in choosing AIR as Spaz's platform.

Is platform independence and portability really a good thing? I do think so, but I also think that special care must be taken to conform to the target platform's established conventions. This is where AIR fails (but where other similar—but not the same—platforms such as RealBasic, XUL and (dare I say it?) yes, even Java do a better job).

I've been sitting on this rant for a long time, and it's come up with several people in the past few weeks, so once again, I'm blogging about it as time allows. Sorry if these thoughts seem incomplete. Truth is that some of them are, but I want to get something written down.

Widgets, Controls and Placement

One of the first things you'll notice if you run several AIR apps concurrently is that they all look different. Take a peek at this article on "8 AIR apps that don't suck", for screen shots. All eight of these apps are visually appealing in their own way (this is subjective, of course), but that's the key: in their own way.

A lot of care and money has been spent on research and development of the major GUI interfaces, especially by Microsoft and Apple. With few exceptions where the AIR author has opted to adopt the system's native GUI, at least for the basic window chrome, these applications have reinvented the wheel.

I've read that AIR makes it very hard to emulate the system look and feel for standardized UI widgets. It is especially difficult in HTML-based apps, because the version of webkit they ship will not allow you to modify the look and feel of some form widgets (selects, radio buttons) or the scroll bars. You have to roll your own widgets entirely if you want to change the look of these. Adobe allegedly does this is on purpose. They want apps to look the same on their platform—the Adobe Flash platform—and to look and behave identically on all OSes.

As a user, this is confusing. Not confusing to the point where I don't know how to use the 7 different types of scrollbars displayed in these 8 applications (hint: WebDrive's screenshot doesn't display a scrollbar), but the lack of established convention is visually distracting at the very least.

Buttons, menus (I didn't know that the "Spaz >>" button was actually a button for the first few months I used the app; maybe I'm just an idiot), scroll bars, handles, "grippies", toolbars: these controls have been well-defined by our window managers and operating systems. Is it really worth the inconsistency just so you can be more visually appealing (and often fail at this)? I don't think it is.

(I wrote a short piece on this a while back, and many of the same assertions apply.)

Inter-application Consistency, Established Conventions

The previous point leads directly into this one: AIR apps are generally terribly inconsistent, not only between each other but also with the native toolkit.

Here are some conventions that apply to (almost) every application I currently have open on my Mac, but rarely apply to AIR apps:

• Window close button is at the top left corner of the window
• Toolbar at top of window (if applicable); button at top right of window hides this toolbar
• Scroll bars are clickable outside of the control bar, buttons to increase/decrease scroll are both at the bottom of the scroll bar
• Pressing cmd-, opens the application's preferences dialog
• Double-clicking the application's title bar "minimizes" the application to my dock (I actually dislike this, but at least it's consistent in native apps)
• Pressing cmd-z causes the "undo" event to be fired; this is built in to the toolkit for controls like text boxes

With the exception of cmd-, (which the author has explicitly definied in the code), Spaz does not conform to any of these conventions. Do I think this is Ed Finkler's fault? No, I don't. At least not entirely his fault...

Adobe seems to have adopted a different consistency regime than what I believe to be the right solution. It appears that they're more concerned about AIR apps looking exactly the same on each platform, than for those apps to conform to their platform.

Operating System Conventions

Admittedly, the convention I'm about to mention is only a de facto standard; not officially endorsed by Apple.

I love Growl. It works well, and adds much needed consistency to application notifications. I even use it to tell me the caller ID when my home phone rings. With the possible exception of a recent AS3 Growl library, AIR apps have been painfully unable to easily generate Growl notifications (due to improper application sandboxing, in my opinion), and I know this has been a major point of contention for Spaz's author (we've discussed it several times, and I think I was even tasked with solving it, last summer, but no time... no time).

Worse yet, Adobe has "conveniently" built Notification support into the AIR platform. This sounds good, until one discovers that the notification support has been created from the ground up, and doesn't hook existing conventions. I suppose this was necessary on platforms that don't have a widespread system like Growl, but for us Mac users, it's outright annoying.

Applescript and Accessibility

On to the final point of my rant...

Last weekend, I attempted (and failed for several reasons) to write some AppleScript that would allow automated repsositioning of most of my applications when I change display configurations from laptop to desktop.

I was not surprised to find that Spaz didn't have an AppleScript dictionary (is AppleScript dying? I'm starting to think so...), but worse, it didn't respond to a standard request: tell application "Spaz" to get the bounds of the first window (results in an error). I found a workaround (sort of), but this just illustrates AIR's neglect when it comes to abiding by system conventions.

I can only imagine how badly these things must play with accessibility software. Are visually impaired users able to use screen reading software with AIR apps? Spaz certainly doesn't play well with VoiceOver. Perhaps my colleague and friend Jon Gibbins can shed some light on the accessibility issue.

All this to say: I'm quite fed up with AIR apps. The lack of convention with my regular workflow has gone from annoying to downright disruptive, and I'm on the verge of abandoning them entirely, if something isn't done to promote platform conformance... and I suspect I'm not the only one.

Thanks to Ed Finkler for giving me some feedback on this rant. I greatly respect his opinion in this area, and he gave me some excellent additional points that I need to think about, especially why I think it's OK for web sites to have a more freeform canvas than desktop apps (though I do think that it's even more evil for web sites to reinvent their toolkits). Some thoughts published, yet more filling my head...