New technology is a double-edged sword. If you catch the wave of change at just the right moment, you can gain a competitive advantage if that technology turns out to deliver on its initial promise. Of course, building on new technology is risky. eBay decided to take a chance when we launched a project code-named San Dimas in the summer of 2006. Our goal was to build a sophisticated, branded desktop applications with online and offline unctionality that would enable our customers to use eBay services outside of the browser from their desktops. San Dimas was built on Adobe AIR (formerly Apollo), a new platform which we weren't even able to start using until a month after the project launched.

Since then, San Dimas (now named eBay Desktop and since October 1, 2007, in public beta) and Adobe AIR have both gone through multiple iterations since last summer. And through the development process we learned a great deal about Adobe AIR and building a desktop application in the Internet age. In this article I'll distill what we learned into five lessons, with the hope that our insights from the project will help the community of developers and companies building rich desktop applications continue to grow.

Lesson 1: Start with a good foundation

Although eBay Desktop has a radically different user interface (UI) from the eBay website (see Figure 1), it wasn't built totally from scratch. The eBay web services platform has been in development since 1999, and eBay Desktop takes advantage of those web services to connect to the eBay backend systems. The desktop client connects directly to the eBay web services gateway instead of having a separate server infrastructure that sits in the middle. While creating such a middle tier may have allowed us to optimize certain operations and potentially cut down on the amount of code written on the client-side, we didn't want to risk introducing scalability constraints that would hamper growth of the application's user base.

Figure 1. The eBay Desktop user interface

Since the project began, we haven't had to make any changes to our web services to support eBay Desktop. If we had, it would have put the project schedule at serious risk (and believe me, there was enough risk involved already). Robust investment in a web services platform, even when the potential future uses aren't clear, can pay off.

If you are starting out developing an Adobe AIR application, I recommend that you consider a service-oriented architecture (SOA) or web services architecture. Doing so will ensure you don't tie yourself too closely to one type of client—whether that be browser-based, desktop, or something else.

Lesson 2: Design takes a long time

We spent three months developing an initial prototype of the eBay Desktop application that was shown at MAX 2006. Of the three months, six weeks was spent on the design before we started coding. Effective UI, a design firm that eBay partnered with to work on the application, have years of experience with Flex, and they were able to apply many of their existing design processes for AIR. But being on the desktop forced us all to revisit certain design assumptions that are common for browser-based applications—like tabs, link-based navigation, and more. Desktop applications have their own set of design paradigms, but we didn't want to build a traditional desktop application. We tried to approach the problem from the abstract by trying to to answer the question: "What would the ideal eBay user experience be like?" And as we progressed through the design iterations, we knew what we liked (and what we didn't) when we saw it.

I don’t think that Adobe AIR apps can or should have a consistent navigation, but I would encourage the sharing of ideas so that designers and developers can see what works and what doesn't within a certain context. The last few years of web application innovation have shown that good application design does not require adherence to standards—after all, would Google Maps have been the same if it had adhered to existing "standards" for acceptable ways to navigate a map?

I must admit that being half-way into the project with nothing to show for our work except for designs made me quite nervous! The up-front investment in design work did paid off, however, and the design to development workflow made possible by the Adobe platform ensured that the designs we came up were something that could be implemented without comprimise.

Adobe AIR offers developers a lot of freedom, and because of this you may find yourself having a difficult time deciding on a design for your application. You could apply existing web design paradigms to your project, but this may not lead to an optimal user experience

Lesson 3: Beta testing is extremely useful

The eBay Desktop application was released as a limited beta for several months. Our beta users provided fantastic feedback on the application (as well as Adobe AIR) and some of these findings may apply to projects outside eBay development.

First impressions matter, and a bit of visual flourish goes a long way. Our beta users have been very positive about the overall look and feel of the application. It helped that we paid attention to making the home screen visually attractive, even though in the early builds it was not entirely functional. Users also stated that they love the picture flipping effect, which shuffles the eBay item pictures like a deck of cards. It is details like this that will make your application memorable and define its identity, so remember to pay close attention to them—your users will!

Users are most familiar with the browser, but they are willing to run applications outside of the browser. However, many of our beta users made comments that suggested that they missed certain features that were only possible in the browser. One user complained about not being able to use RoboForm (a browser plug-in) with the application. Another user complained about the application lacking the familiar "green arrows" (referring to the browser’s next and back buttons, not the application itself). The overall sense that I gathered from our beta users, however, is that they are willing to try new things. Although browsers are by no means ideal for building many kinds of applications (not surprising, since browsers were built for documents, not applications), they offer some elements such as standard navigation methods ("escape valves" like the Stop and Refresh buttons) that you may want to consider implementing in your application.

Speed matters. A lot. Our initial beta release had a number of performance issues, which is not uncommon with beta software (and platforms). We found it surprising that beta users seemed unwilling to work with the application due to slow performance, and many of the "deeper" features didn't initally receive much testing. No user enjoys working with slow software, even if the application offers features that may save the user time. Our development team moved quickly to address these performance issues, and once we improved the application’s performance, our users were much more willing to explore and experiment.

Launching beta websites or applications to generate early buzz is in vogue, but the insights gathered during our beta cycle has convinced me that they are well worth the time and effort—assuming that you intend to actually listen to beta users, and are prepared to change your development plans if user feedback dictates it. If you are planning to develop an application using Adobe AIR, I highly recommend gathering early feedback from users through a beta program. We entered private beta very early in our development cycle, and with hindsight it was indeed the right decision to hold off on allowing anyone to freely download the beta. Limiting the number of users helped us ensure a more intimate connection between our team and the beta users. Because you had to request access in order to get it, the beta users tended to be very engaged. We focused our marketing of the beta program to technology conferences and blogs that tend to be frequented by individuals, who like being on the leading edge, and we got a good response from these efforts.

Lesson 4: Freedom from browser design constraints is key

Although Adobe AIR provides many useful features for developing desktop applications, such as file APIs, windowing support, and a complete HTML renderer, I have found that the most important feature of Adobe AIR is that it is not a web browser. Standard browser user experience metaphors, like the back button and location bar, impose a set of assumptions about how web applications should work—assumptions that might work well for some types of applications, but not for all. For all the magic shown by some leading Ajax-powered web applications, they still have a long way to go in terms of improving performance, features, and user experience.

As I mention in Lesson 3, although many users are willing to try new things, users today expect things to work like they do in the browser. This imposes a very high bar for applications that implement navigational metaphors or user experience paradigms that go beyond the traditional browser-based application world.

Lesson 5: Users don't care about Adobe AIR

And that's a good thing! Adobe AIR does a great job of getting out of the way. It has an excellent installation experience—applications can bundle the runtime with the application, and installation can be triggered from a Flash movie in the browser, which has worked very well with the eBay Desktop application. Adobe AIR provides a very useful application update framework. And Adobe AIR applications behave like any other desktop application. These little details really matter, and I'm glad that Adobe has paid attention to them in Adobe AIR. One measure of the success of Adobe AIR will be if users don't even realize it is there.

Where to go from here

For more information about Adobe AIR, visit the product page.

For more inspiration, check out the sample applications in the Adobe AIR Developer Center for Flex, Flash, and HTML/Ajax, as well as the Adobe AIR Developer Derby winners and the apps showcase.

To get started building Flex apps on AIR go to the Getting Started section of the Adobe AIR Developer Center for Flex or dig into Developing Adobe AIR applications with Adobe Flex. To dive right in and begin building AIR applications in Flex Builder, follow the simple steps in Developing AIR application with Flex on Adobe LiveDocs or explore popular Adobe AIR APIs by working with the AIR Quick Starts.

About the author