back takes widgets to the next level with Adobe AIR

by Michael Sylvie and Rick Harrison

Weather is quite possibly the perfect content for widgets and applications — it impacts everyone, everywhere in a way that is personal yet universally understood. Weather is always changing, so people tend to check it multiple times a day. We depend on weather reports to help us plan our lives, so convenience and reliability are paramount in a weather application.

Our goal at is to give people the weather information they want wherever and whenever they want it. Over the years, we have created a range of weather widgets, gadgets, and applications, so that users of various operating systems, browsers, and devices can access our forecasts and alerts in their preferred method of delivery. As you can imagine, the time and effort spent developing, supporting, and marketing these applications can be considerable. So when our team first discovered Adobe AIR, we immediately recognized that by creating just one desktop weather widget capable of running on a range of operating systems we could reach a wider range of users and ultimately cut down the time and cost of development efforts.

Jumping into AIR

We didn't initially realize the full power of AIR, so when we began working through our new weather widget's user interface, we put too many limitations on our thinking. Our early designs were for much more traditional widgets that matched the look and feel of our existing applications with a defined border that takes up space on your desktop instead of becoming part of it (see Figure 1).

Two early concepts for the Stratus AIR widget, which we abandoned once we realized we could break the border barrier.

Figure 1. Two early concepts for the Stratus AIR widget,
which we abandoned once we realized we could break the border barrier.

The release version of’s Adobe AIR widget, open and closed.

Figure 2. The release version of's Adobe AIR widget, open and closed.

Thinking outside the box

As with any new platform or framework, we encountered some challenges during the development process from both a technical and aesthetic perspective, including:

Our first order of business was deciding what tools we should use to build our weather widget. Adobe AIR gives developers the option of building applications using Adobe Flash, Adobe Flex, HTML, or Ajax. Because the members of the R&D team are most familiar with JavaScript, Java, Objective-C, HTML/CSS, and PHP, we decided to use standard web technologies such as HTML, CSS, and JavaScript. This gave us an advantage because our developers were in familiar territory, even though they had never worked with AIR.

Once development began, we quickly ran into a technical hurdle — a conflict occurred when both a click event and a drag event were being fired at the same time. Users needed to be able to click the widget to drag it around the desktop, but the application also contains clickable icons that perform functions such as expanding and contracting the size of the widget, or launching our website for more information. The conflicting click-and-drag events initially caused our widget to crash.

We solved this problem by modifying the click events of the individual elements in the application. We built functionality into the application to detect whether the widget is being dragged. If it is, the click event is cancelled to give priority to the drag event. The fix wasn't complicated, and Adobe provided some important insights on how to keep certain elements of the application separate. This prevented an element from having more than one event assigned to it. For example, certain portions of the application are assigned to dragging, and other portions are triggered by clicking them. After we learned this basic ground rule, technical development went smoothly.

Development challenges also arose with the widget's aesthetics. The light, clean appearance of the widget's transparent background was a big hit from the beginning, but it sometimes made reading the weather data difficult.

Because the weather data wasn't displayed in a more traditional graphical container, the text and weather icons appeared to sit right on the user's desktop, which meant that users with busy background images on their desktops might have trouble reading displayed weather information. After playing with different options, we settled on what turned out to be an easy solution — we gave users the ability to select text color. As a result, we decided to enable users to customize the widget further by giving them two sets of weather icons to choose from (which has turned out to be a popular feature). The challenge from a development perspective was to create a preference storage facility to hold the user's selected preferences regardless of the widget's state (no matter whether the application is open, expanded, or minimized). We quickly solved this problem through the JavaScript API that Adobe AIR provided to interface with a SQLite database.

After internal and external testing, we were pleased to discover that the widget was a success and required few changes in the final stage of development, which was somewhat surprising given its novel transparent design. We realized toward the end of development that throughout the process we relied almost entirely on social media to stay in touch with the Adobe team, as well as for internal communications. Blogs, message boards, and Twitter often took the place of e-mail and phone calls, as long as the subject matter wasn't too sensitive. Twitter in particular is one of our favorite ways to address quick problems and provide a little stress relief throughout the day.

Learning to fly

As we've grown our widget-development program, we have quickly learned that users are even more sensitive to size than we thought — the smaller the widget, the more likely it is to be used regularly. Therefore, we chose the smallest possible size that would still allow us to provide all the information we thought was most useful. We tried to represent as much information as we could by using icons to save space. During testing, we noticed that some users were confused by some of the icons we created, so we had to fine-tune the UI over multiple rounds of testing. We also included a PDF help document that could be accessed as one of the widget's right-click (or Control-click, depending on platform) options, which explained the widget's features and icons.

From a technical perspective, AIR exceeded our expectations during testing as we found it truly worked across PC, Mac, and Linux operating systems.

Reaching cloud nine with Stratus

We launched our Stratus widget at the end of February 2009 (see Figure 2) and have been humbled by the kind words and positive reviews it has garnered. So far, only one issue has come up post-launch that we did not encounter during testing: the fact that the widget appears as a task in the taskbar on PCs. Multiple PC users have said they do not want the widget to reside in the taskbar. This is one of the top issues on our list for version 1.1. We intend to give users the option of having the widget appear in the taskbar or the system tray based on personal preference. If you have any additional feedback, we'd love to hear it.

In the end our development experience with Adobe AIR was incredibly positive, and we have already started brainstorming other applications we can build using this environment.

‹ Back

Rick Harrison is a long-time member of's R&D Development Team, where his focus is on the creation of mobile and desktop widgets and applications.

Michael Sylvie oversees a team of developers for's R&D Group. In his peripatetic career he has also worked in the financial, nonprofit, and advertising fields.