eBay has an AIR app for managing your eBay activity. Launched during MAX 2007, even though it has been around since last year’s MAX. They learned things from it.

First, recognize that desktop apps have much more power than a web app. Why doesn’t everyone do them then? Desktop apps are a lot more expensive to build! Web apps have been getting more expensive as standards of quality rise, but they’re still cheaper than full-fledged desktop apps.

eBay built a fully-functioning prototype in just 3 months. Here are some lessons learned.

1. Start with a good foundation. They started the AIR app because they had already been building web services and API for eBay. So all they really had to do is build a UI. All the web service hype from 2002 was indeed hype, but now, five years later, the concept is finally coming together in a very key and important way. These web services are a great way to connect desktop apps to the web. Store your business logic in the web services that the desktop apps can access.

2. Design takes a long time. Of the first 3 months, six weeks were spent on design alone. Why? (a) AIR offers a lot of freedom. If it was more restrictive, it would have been more straightforward. (b) They were pioneering things. There is not a prescribed manner to address a lot of the questions that come up. (c) Expectations have been raised for user experience.

3. Betas are really useful. I mean real betas, not marketing betas. They have thousands of users in the beta program and they get tons of feedback.

4. The most important AIR feature is… Freedom from constraints of the browser. No frustrating back button. No location bar.

5. Users don’t care about software platforms. A good platform, like AIR, just gets out of the way. Installation, auto software update, startup,  etc. Beta users haven’t complained about these kinds of things–the kinds of things that typically hinder Java apps or some other platforms.

During CFUnited, it didn’t look like I was going to be able to make it to MAX, which was ironic, since it’s in Chicago this year and I live not too far from Chicago.

Well, things worked out and now I’ll be going to MAX. See you all there. I’ll be taking notes feverishly during the sessions.

Here are some notes regarding some of the APIs for AIR that were showcased at the on AIR Bus Tour in Chicago.

Window API

Multi-window support. Transparent windows. Z-Ordering. All of the various aspects of OS windows can be applied to your AIR windows. When you use transparent windows with no chrome, the arrow will click through the transparent part of images as well. Nice.

File I/O

Reading and writing of files. No problem. Can launch native file dialogs. Can handle selection, selecting multiples, directories, etc. Async and sync versions of the APIs.  Would use async API if you’re doing very heavy processing.

Database Support

SQLite embedded database. Zero setup, uses a single file. Not for accessing remote databases. This is for using a completely local database. Easily storing data in a database format, but in a local manner.  He didn’t show any examples of this.

Drag and Drop / Clipboard

System level drag and drop support is there! AIR app to AIR app, or AIR app to OS app and back again. Or to the desktop. Can use it for handling URLs, files, text, or even AS objects.  When marking something as draggable, you can assign one or many “transfer formats”. So when you drag an item to another app, if it doesn’t accept one data type, perhaps it will recognize another data type. For instance, if you have an image and a text transfer format, the receiving app may not like the image format, but it recognizes the text format, so it proceeds without a problem.

Service Monitoring

Handles the online/offline support. Will monitor the network interface for changes. Will detect not just network connectivity, but you can test access to a particular service. Do I have access to http://my.address.com/myservice?

Conclusion

These APIs work in JavaScript too because of the bridge, but it all works very well in Flex.  Daniel Dura was the presenter, and hit site at http://www.danieldura.com has a lot of AIR information.

The ColdFusion community has been paying attention to IT journalism lately, for better or worse, and for good reason. Our environment is especially in a state of flux; many of us may had been concerned about the future of ColdFusion given Adobe’s acquisition of Macromedia, but those fears were allayed, especially now with Adobe making it so clear that they have invested respectable time and resources into improving ColdFusion with CF8. But the results of the acquisition are only just beginning to emerge. And as Adobe’s strategy becomes clearer, it is very evident that they are putting arguably more resources into other technology like Flash and Flex.

What ultimately prompted my thoughts was the article Web 2.0 Needs Adobe by Tom Yager. His discussion is very flattering for Adobe, although ColdFusion isn’t mentioned anywhere. Neither is it mentioned in Cringley’s equally flattering article An AIR of Invisibility. There’s a reason for this. They’re focusing on the user interface of apps, which is really what defines the perception of how responsive and powerful an app can be. Fretting about ColdFusion getting the back seat is like fretting that your favorite athlete wasn’t nominated for an Oscar; it wasn’t really up for consideration.

So, user interface. Now that’s something to fret about. Many of us don’t like to think about the UI, and that has to change! User interface has always been important when users form their impression of an app, and that high priority is applying more heavily to web apps as they begin to vie for user acceptance with their heavier desktop brethren.

Most ColdFusion developers are using HTML for their user interface. An industry migration will hopefully migrate that median toward AJAX-enhanced HTML or Flex interfaces for web apps, and of course AIR for desktop apps. ColdFusion won’t be going anywhere, as our internet connectivity is always going to need a server-side component.

So how are we to react to these articles’ evaluations of AJAX and Flex? In a way, they are depicting JavaScript (and thus AJAX) as a dinosaur with wings. It is powerful, it got a shot in the arm with the popularity of AJAX, and it can do amazing things. But it’s still a “dinosaur”. It is old technology trying to keep up. Enter Flash and Flex. The new kids on the block. They’re more modern–but they’ve had time to mature–and they just out-perform AJAX in what they can accomplish. Now tack on thoughts about how much AJAX functionality Adobe has put into CF8. What’s the point if AJAX is inferior to Flex? What does it all mean?

It’s a big internet out there. Various scenarios call for various solutions! Whereas it is a good idea for us as ColdFusion application developers to learn Flex and start using it when UI needs call for it, the ultimate point is that we start improving our UIs from plain HTML. Start putting more effort into the user interface. We’ve had it easy in the past when simpler, less sophisticated interfaces were accepted on the web, and that time is coming to an end as the web pushes forward as a viable application platform.

Is it urgent that we start learning Flex? I feel that AJAX and Flex will be sharing the web application space for a long time. Yes, Flex and Flash might be Adobe’s ticket for bringing web apps to the next level, but their commitment to AJAX is very clear. That is evident in the AJAX support in CF8 and AIR. Learn Flex if you can. If it’s just too much for you to handle right now, AJAX is a fine step–more palatable and familiar for HTML developers–that will let you focus on the more important point: Improving your app’s user interface.