Desktop application considerations

Regardless of whether your application is sovereign or transient, there are a small set of concerns unique to AIR that may affect your design. These concerns include use of the file system, network connectivity, and desktop-specific controls and iconography.

Although familiar to application designers and developers, many users find the file system complex and difficult to use. Good Flex applications strive to hide this complexity. In general, desktop Flex applications should follow the continuous save pattern of their web brethren, avoiding the need for users to constantly remember to save (continuous save is discussed in detail in Designing for Flex – Part 8: Making your application safe). If the application is not creation- and document-oriented, this may be sufficient. Avoid forcing the user to work with the file system; use it only to remember useful information. Provide your own interface within your application to help users manage the content specific to your domain. Your application’s interface should focus only on content relevant to your users’ goals and should remove the irrelevant details of files and folders. Most of the Apple iLife applications follow this model as well as many AIR applications.

Figure 14. Adobe Media Player manages downloads and saved videos through the application, allowing its users to avoid ever having to hunt through the file system themselves.

If you must ask users to work directly with the file system, provide ways to make this process easier. Users often want to work on the same document they were working on recently; if they must hunt for it in the file system, this wastes time. All good desktop Flex applications should provide a recently used list of files so that users need not remember where they are stored. Eliminating this feature may save you a little bit of time and effort, but it makes your users’ lives very difficult. Similarly, all open dialogs must immediately open to folder containing the most recently opened file. Some applications should even provide a list of recent folders to make this process even easier.

Figure 15. Adobe Dreamweaver provides a list of recently used files right on the application’s welcome screen. This helps users locate documents they were just working with during the last hour, for instance.

Network connectivity is not completely unique to AIR; Flash Player-based web applications might also lose their network connection and need to communicate that the application can no longer function. However, Flex applications targeting AIR may support more extensive offline capabilities, so although losing the network connection may mean a reduction in functionality, the application might still be usable. Both types of Flex applications must clearly communicate a loss of network connectivity in a non-intrusive but easily noticed fashion. Poor ways of communicating loss of network connectivity include opening a dialog box (far too intrusive) and changing a small icon in the corner of the screen (insufficiently noticeable). Proper communication methods depend partly on the application, but a designer may wish to communicate the mode shift by changing the background color or image. If portions of the application’s functionality become unavailable, disable this functions and make it clear that they are only available online, perhaps with an in-line message or a tool tip.

Finally, a few controls typically appear only in desktop applications. Traditional menu bars are often inappropriate in Flash Player-based Flex applications as users may confuse them with the browser’s own menu bars. In desktop applications, users may expect them. Menu bars are not always required; many transient applications contain no menu bars so don’t assume that you need them. However, menu bars serve an important function in many desktop applications. They are particularly important in creation applications, where users expect to find the various tools provided by the app in its menus. Most users learn applications through trial and error, so menus are a critical pedagogical tool since they provide a standard way for the user to discover the functions available to him. Time and again, I’ve seen users search for a new piece of functionality by opening and scanning the top-level menus. Ensure that all important functions are available as menu items and appropriately named so that they will immediately stand out on a casual scan.

Figure 16. Complex desktop creation applications such as Adobe Fireworks use menus as a standard way to discover new functionality. If your desktop application offers many functions on one screen, consider using menus in a similar fashion.

Multiple application windows are another control that typically only appear in desktop applications. AIR supports multiple windows, but most Flex applications should keep their window count to a minimum. As discussed in Designing for Flex – Part 3: Structuring your application, Flex applications are typically organized into screens, which serve different user goals and are almost completely separate from one another. Use windows only for separate screens; although users may switch between them, you must keep this to a minimum as switching context interrupts users’ workflows and mental processes. Like screens in a web application, only use windows for self-contained workflows.

All Flex applications, whether destined for Flash Player or AIR, merge web and desktop idioms in novel ways. By carefully considering the environment your applications live in, you can blend these idioms seamlessly into a model that makes sense for your users and avoid a Frankenstein’s-monster-of-an-application that ignores user expectations.

To learn more, read the next part of the series, Designing for Flex - Part 5: Designing content displays.

This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

Acknowledgements

Although this article series has my name on it, many people contributed to its development. I’d like to thank my reviewers, Sho Kuwamoto, Phil Costa, Steven Heintz, Narciso Jaramillo, Josh Ulm, Jeremy Clark, Deb Galdes, Tom Hobbs, and Amy Wong for providing me with extremely helpful feedback. Special thanks to Sho Kuwamoto and Phil Costa for envisioning this project and pushing me to complete it and to my managers, Josh Ulm and Jeremy Clark, for finding the time for me to give it the attention it needed. Finally, extra-special thanks to Tom Hobbs, Narciso Jaramillo, Sho Kuwamoto and Peter Flynn for guiding my thinking on many of the topics that appear in the articles.

 

Page 6 of 6

Previous Page