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 AccuWeather.com 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.
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).
Figure 1. Two early concepts for the AccuWeather.com Stratus AIR widget,
which we abandoned once we realized we could break the border barrier.
Figure 2. The release version of AccuWeather.com's Adobe AIR widget, open and closed.
As with any new platform or framework, we encountered some challenges during the development process from both a technical and aesthetic perspective, including:
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.
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.
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.
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.
Rick Harrison is a long-time member of AccuWeather.com'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 AccuWeather.com's R&D Group. In his peripatetic career he has also worked in the financial, nonprofit, and advertising fields.