Designing For Flex

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

Flex Article Designing for Flex – Part 1: Overview and introduction to Flex Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com Adobe Flex is a new medium specifically created for designing and developing rich Internet applications, or RIAs. RIAs are a new breed of applications that break out of the constraints of traditional web and desktop environments to provide a more fluid, information-focused user experience. Flex makes it much easier to create these experiences, but it requires application designers and developers to think differently about the application design problem than they did when creating traditional web and desktop applications. The Designing for Flex series surveys new possibilities, techniques, and challenges designers and developers will confront when designing Flex rich Internet applications. Specifically, the series covers: planning and structuring Flex applications, special considerations for designing web versus desktop Flex applications, the design of rich content displays, appropriate use of motion in application design, improving an application
s efficiency of use, and ensuring your users feel safe using your application and trust it with their data. We have supplemented the series with an ever-growing set of components and sample code to assist you in applying the theory presented here. In the near future, we also plan to release the official set of "Flex Interface Guidelines" that describe in depth how to apply the Adobe standard for Flex application design to your projects. The Designing for Flex series includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html) Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) This content is a public draft. Please give us feedback in the Flex Interface Guide Forum. Planning for Flex application design is similar to application planning for other mediums, but places special emphasis on deeply understanding your users
goals, the content they use or create, and the tasks and workflows they go through to accomplish these goals. The next article in this series: Designing for Flex – Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) discusses this topic in detail. Flex applications eschew the strict page-to-page or window-to-window metaphor of the web and the desktop, and instead focus heavily on interactions within individual screens of the application. As a result, they must be structured somewhat differently from traditional websites or desktop applications. Flex applications are comprised of three types of structure: information structures, process structures, and creation structures, all of which must be designed differently. Structural design is discussed in Designing for Flex – Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) .

1 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

While Flex applications break outside of the constraints of traditional web and desktop applications, they also bring together the best aspects of these two mediums. Common features of web applications, such as back button support, bookmarking, and hyperlinks must be preserved on the web just as proper support for the file system, network connection changes, and windows and menu bars must be preserved on the desktop. In Designing for Flex – Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) , I discuss these web- and desktop-specific issues. Well-designed Flex applications put the user
s content first, helping her understand and visualize the information, then provide discoverable means to interact with the content if appropriate. Designing for Flex – Part 5: Designing content displays (available soon) describes how to use the powerful graphical capabilities of Flex to help users interact with their content. Flex offers the ability to employ motion as part of the design medium, yet in the past, motion in applications has often been abused. Designing for Flex – Part 6: Guiding with motion (available soon) describes how to use motion to teach and emphasize, not to distract and annoy. Computers are intended to improve human productivity, so for any application, efficiency of use is paramount. Well-designed Flex applications help speed up users both through snappy system performance and through providing appropriate assistance to help users complete their work faster and easier. Designing for Flex – Part 7: Making your application fast (available soon) discusses both of these aspects of efficiency of use. Finally, no application is useful or desirable if users cannot trust it with their data and their reputations. Good Flex applications must carefully safeguard both of these through technical measures and through keeping users informed of the consequences of their actions and empowering them to undo their mistakes. Designing for Flex – Part 8: Making your application safe (available soon) discusses which measures are necessary to achieve application safety and earn your users
trust. Flex offers you the opportunity to revolutionize the way your users interact with your application and your company. Incorporating the best practices discussed in this paper into your design thinking will put you on the right track towards making this opportunity a reality. This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

Discovering Flex

If you
re reading this document, chances are you
re getting ready to embark on a journey into the world of Flex application design. Perhaps you
re an interface or interaction designer who knows application design inside and out. Perhaps you
re a UI-savvy developer who builds applications that don
t just work, but work well. Or perhaps you
re a manager or business analyst who leads application design projects. Whether you come from the world of the web, the desktop, or are already experienced with Flex, this series offers a solid foundation of knowledge to apply and extend as you design and develop your next great Flex application. Flex applications have much in common with their web and desktop predecessors, but they also require a somewhat unique approach to design. This section covers: How Flex differs from other technology mediums Why Flex is an ideal technology for crafting rich Internet applications Why Flex gives you more freedom, yet requires you to design in a slightly different way than you did for HTML or desktop technologies.

The Flex rich Internet application

2 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

From the very beginning, we designed Flex to be the best platform available for designing and building RIAs. Flex RIAs enable designers and developers to build applications that break out of the old constraints of the web and the desktop to deliver experiences that are more useful, usable, and desirable for their intended users. However, Flex also introduces new design challenges to overcome and new user expectations to meet. These challenges and opportunities are caused by two aspects of well-designed Flex RIAs: They blend web and desktop idioms and thus must satisfy user expectations for both mediums. They open up new design possibilities through their ability to use motion in applications, render content in novel ways, and perform many computations and screen updates directly on the user
s computer while still having access to all the information services of the Internet. Flex applications blend the web and the desktop by borrowing the best from both mediums. Most Flex applications appear on a website, usually alongside traditional HTML content and applications. Users of these Flex applications have certain expectations of “web-ness” that goes along with the environment: They expect their browser
s back button to return them to the location they
d been to before. They expect to bookmark sections of your application and to add hyperlinks to other web pages that connect them directly to that section. They expect the visual appearance of your application to seamlessly match the branding of the rest of your website. Lastly, they expect to access your application anywhere, on any computer, regardless of their browser or operating system software.

Figure 1. The Cotswold Outdoor site is built in Flex and properly supports the browser back button functionality, a common idiom in web applications. Likewise, Flex also brings the feel and to some extent the look of the major desktop operating systems to the web. Flex provides out-of-the-box implementations of advanced desktop controls such as tabs, sliders, trees, and data grids as well as advanced desktop idioms such as drag and drop, direct selection, and in-place validation. Because these controls and idioms are readily available and consistently implemented, users come to expect a richness of interaction that they might not from a traditional website. More information on how to design an application that blends these two mediums is available in Designing for Flex – Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) .

3 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

Figure 2. Adobe Premiere Express implements many desktop idioms such as drag and drop, yet lives in the browser as a web-based Flex application. Flex opens up new design possibilities by enhancing standard web browsers with the Adobe Flash technology on which Flex is built. This technology is now available in two compatible runtime environments: Adobe Flash Player, a browser plug-in that is installed on 98% of the world
s internet-connected PCs; and Adobe AIR, a runtime that allows Flex applications to exist on the user
s desktop outside the confines of a web browser. Both runtimes provide a set of powerful, time-tested tools that open up new possibilities for web and desktop application design. These tools include: Powerful drawing and media APIs for using vector graphics, bitmap graphics, and high-quality video to build rich information displays for your application. Popular examples include the stock charts on Google Finance and the interactive video player on YouTube. More information on using these tools to help users understand and interact with their information appears in Designing for Flex – Part 5: Designing content (coming soon). Built-in support for motion and effects effects that creates new ways to guide users and provide meaningful feedback. I
ll discuss this further in Designing for Flex – Part 6: Guiding with motion (coming soon). A modern code execution engine that is powerful enough to enable hard-core developers to build any application behavior they wish, yet has its roots in a simple scripting language that empowers even non-programmers to express their ideas in code. This engine enables designers and developers to make use of the user
s computer, rather than the server, for many processing tasks involving validating data, safeguarding information, and caching results to reduce latency. More information on these topics appears in Designing for Flex – Part 7: Making your application fast (coming soon) and Designing for Flex – Part 8: Making your application safe (coming soon).

4 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

Figure 3. YouTube and Google Finance employ Flash technology for their video player and interactive stock charts to help users better understand the information they offer than a standard HTML page could on its own. These changes to the underlying technology and environment enable you to communicate with your users in new and exciting ways. However, they also require you to think a bit differently than you did when designing for other mediums. The following sections compare Flex with other popular client-side technologies to illustrate how this is so.

Flex and HTML

Since its beginnings as a simple markup language for hypertext documents, HTML has followed a model of "pages" and “links between pages.” Content flowed from the top to the bottom of the page. Markup tags defined the meaning of various blocks of content—specifying them as headers, paragraphs, images, and so forth. Although web designers pushed the envelope to create complex static layouts in HTML, they did little to change the basic page-to-page model until the rise of AJAX. The typical thought process for designing HTML-based web sites and applications closely mirrors this pages-and-hyperlinks model. Designers tend to create single pages and organize them into information hierarchies for users to navigate. Traditionally, they rarely thought much about interactions within a page because this was prohibitively difficult to achieve in the medium. This forced them to rely on potentially slow page reloads whenever they needed to update the screen. However, the pages-and hyperlinks model has its advantages as well: it is quite simple, maps well to web browser
s navigation models, and is already well understood by most computer users today.

5 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

(www.adobe.com#) Figure 4. A site map of a traditional HTML website (left) contrasted with a structural diagram of a Flex application (right). Note that the Flex application relies on providing more functionality within one screen instead of organizing content into a hierarchy of pages. Click for a larger view (www.adobe.com) . Although Flex applications also commonly have multiple top-level pages or sections, unlike HTML many more of the interesting interactions occur within a page rather than between them. Thus, Flex requires designers and developers to think more deeply about how the page itself will change in response to user input. At the same time, it
s important to maintain the simplicity of the page model as you employ these interactions to improve the user experience. With the advent of AJAX, some of these same concerns are now present even in HTML application design, and thus some of the guidance found in this document applies to the HTML medium as well. However, since AJAX is typically used to enhance existing HTML pages with small bits of rich interactive functionality, most HTML designers are generally not required to think as deeply about the intra-page interactions as are Flex application designers. However, these very interactions are what make Flex (and AJAX) applications so compelling. When used effectively, these technologies make it much easier for users to manipulate the application to accomplish their goals. More details on how intra-page interactions affect the structure of Flex applications appear in the chapter Designing for Flex – Part 3: Structuring Your Application (www.adobe.com/devnet/flex/articles/fig_pt3.html) .

6 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

Figure 5. Most web applications employ AJAX to incorporate small pieces of rich interactive functionality in a mostly traditional HTML page, such as the rating and commenting widget in the Flex Cookbook (left).

Figure 6. On the other hand, Flex applications such as Flex Store (www.adobe.com/devnet/flex/samples/flex_store/) consist almost entirely of rich interactive functionality blended together into a seamless user experience.

Flex and desktop clients

Before the rise of web application development, desktop-based “fat clients” were the most popular way to design,

7 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

develop, and deploy internet-enabled applications, and they are still used for many projects today. Desktop clients typically followed the WIMP style of user interface design (Windows, Icons, Menus, Pointing devices), and they were generally built using desktop user interface toolkits such as MFC, Cocoa, or Java Swing. They aggregated clusters of user interface controls or widgets (such as buttons, checkboxes, sliders, and data tables) into various application windows in which users could view their data and perform tasks by interacting with the widgets or the ubiquitous menu bars that appeared at the top of the window or the screen. For the designer, the primary question was how to use this palette of controls to lay out windows that would make sense to the user and help her accomplish her goals.

Figure 7. An example of a traditional fat client desktop application. Most of the interface consists of the standard controls defined by the platform
s toolkit, in this case Microsoft Windows. Like desktop client technologies, Flex provides a rich set of standard user interface controls. Unlike desktop technologies, Flex also provides access to the rich graphics and motion capabilities of the Flash Player, enabling designers and developers to extend the framework in myriad ways through custom artwork, motion, and interactivity. This enables designers to craft experiences that provide richer and more interactive visualizations of the user
s data than can be achieved with a standard control palette alone. Most desktop user interface toolkits have a strong notion of window management that is closely tied to the host operating system. Most Flex applications, however, eschew windows altogether as window-based interfaces are not expected on the web and for most web applications the benefits of multiple windows are outweighed by the time the user must spend flipping between and arranging them. (This is not true of Flex applications that target the Adobe Integrated Runtime (AIR). However, even Adobe AIR applications typically do not rely as heavily on multiple window support as traditional desktop applications do.) Instead, Flex favors integrating functionality that would ordinarily be spread across multiple windows into one seamless experience. The combination of the visual expressiveness of the Flash Player and the lack of window management requires us to think less in terms of arranging controls on the screen and more in terms of visualizing information for the user and letting her interact with that information in ways that will help her accomplish her goals.

Flex and traditional Flash

Understanding the difference between Flex and traditional Flash content created using the Adobe Flash authoring tool is often a challenge, mostly because they are both "Flash-based" technologies that are built on top

8 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

of the same core technology, Adobe Flash Player.

Figure 8. Homestar Runner is a popular example of a traditional Flash site that is oriented around a narrative, the original target for the Flash authoring tool. However, Flex and Flash differ dramatically in their models for design and development. Flash designers and developers created traditional Flash content around a time and animation metaphor; they built narratives to teach concepts, advertise products and services, or simply to tell stories for their own sake. (The humor site "Homestar Runner" is one of the more popular examples of storytelling for its own sake.) As the interactive development capabilities of the Flash Player became more powerful, some Flash gurus were able to push the envelope of the technology and create larger, more data-rich Flash experiences that rivaled the complexity of traditional applications, and thus we coined the term "Rich Internet Application" or "RIA" to describe these experiences. However, due to the inherent limits of the Flash tools and technology of the time, building complex applications that supported many user flows, interacted heavily with large amounts of user data, and required the support of large teams for long-term support and maintenance was prohibitively difficult and expensive. Thus, most traditional Flash content has remained focused on media and storytelling on the web. The Flex framework provides a more application-focused method of designing and developing RIAs that are deployed to the web or on the desktop. Unlike Flash, the primary organizing metaphor of Flex is not time and animation, but screens and states. Time and animation are still first-class citizens in Flex, but they are used instead to guide the user from one state transition to the next. Designers use motion in Flex to provide visual effects to improve user comprehension through feedback, not to organize the entire user experience as an interactive movie. Thus designing a Flex application is more like designing a traditional HTML or desktop application at the high level, but allows developers and designers to use the motion powers of Flash to make their application more fluid and seamless.

9 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

Figure 9. The linear animation model of Flash authoring contrasted with the nonlinear states model of Flex. The states model tends to work better for applications due to the many paths users can take through the system. Despite these differences, Flash and Flex are both part of the same platform and thus are capable of interoperating. If sections of an application make more sense to build using the animation-focused approach of the Flash authoring tool, you can do this and integrate them into your Flex applications as first-class citizens. Whether you have existing Flash content you want to use in a Flex application or simply prefer the Flash authoring tool for the job at hand, this interoperability means that deciding on Flex doesn
t mean deciding against Flash.

With great power comes great responsibility

By now you have seen how Flex differs from the user interface technology mediums that came before it. You have tasted its power and flexibility (no pun intended) and seen how designing applications that target the Flex framework requires thinking a little bit differently than you might be used to doing when designing applications for other mediums. However, it is always worth remembering that while Flex opens up whole new ways to communicate with your users and assist them in accomplishing their goals, it also introduces new potential stumbling blocks to watch out for. It behooves all of us, whether we are designers or developers, to use the power of this new medium effectively for the benefit of our users and our businesses. The articles in this series explain how to do just that. To learn more, read the next part of the series: (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) . 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.

10 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 1: Overview a...

http://www.adobe.com/devnet/flex/articles/fig_pt1_print.html

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

11 of 11

3/3/08 10:36 AM

Adobe - Developer Center : Designing for Flex – Part 2: Planning y...

http://www.adobe.com/devnet/flex/articles/fig_pt2_print.html

Flex Article Designing for Flex – Part 2: Planning your application Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com Before diving into the specific details of designing for Flex, let
s take a moment to discuss how to plan a Flex application. The planning process for designing a Flex RIA is similar to that required for any large-scale application project, but there are a few new activities and some old ones that deserve special attention due to their particular importance in Flex RIA planning. If you are already familiar with such activities, you might skip this article and proceed to Designing for Flex – Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) . This article covers: The five data points any Flex application designer or developer should know: the target market, the target users, their goals, their content, and their tasks. How to prepare for designing and visualizing your users
content. How to prepare for designing your application around users
tasks and workflows. Note that this article refers to several activities that appear in some overarching design or development processes. Flex does not require or prefer any particular process; you can be equally successful designing a Flex application with a process emphasizing up-front design activities (such as Goal-Directed Design or Contextual Design) as you can with a more iterative process that blends design and development (such as Scrum or other Agile methods). You can incorporate these activities into any process, or even follow them if you have no formal process at all. The Designing for Flex series includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html) Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) I suggest that you read Part 1 before proceeding. This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

Knowing your users

1 of 7

3/3/08 10:37 AM

Adobe - Developer Center : Designing for Flex – Part 2: Planning y...

http://www.adobe.com/devnet/flex/articles/fig_pt2_print.html

Traditional product planning typically starts with understanding your current or potential markets. Markets consist of people who will ultimately purchase your product (or, if your product is free, the people who will use your product). Markets are populations that are often defined in terms of demographics data that can be tied to purchasing power, although if your product is internal (such as an intranet application), or if you work for a non-profit or government organization, the way you define your market may be different. Understanding your market is just as important for products that happen to be Flex applications as they are for any other products. For applications, however, understanding your market is not sufficient. You must also clearly define and get inside the heads of your target users. Understanding users is often confused with understanding markets. Although the two are related they are not the same thing. Market data tends to be broad and quantitatively measurable (so that it can be correlated with revenue expectations). Examples of target markets might be "25 to 40 year old suburban mothers" or "the members of the R&D department" or "voting residents of the state of California." Clearly identifying this information is critical for pricing decisions, market messaging, and to guide effective user definition. However, marketing data by itself does not contain sufficient information for designing Flex applications. Understand your market demographics, but recognize this isn
t sufficient information to guide design alone. To obtain this information, you must take a closer look at the people behind the statistics. Use your marketing data as a starting point to identify the people who will use your product. Next, focus on qualitative data about their behavior: what they do, how they think, what they want to accomplish. Popular methods of acquiring this data include interviewing potential users about their needs and desires, visiting their work sites or homes to observe them doing tasks relevant to your product, asking them to keep diaries as they go through their day, and so on. Should you decide to engage in such activities, it is worthwhile to employ a user researcher to plan and conduct your research and to ensure that you are getting answers to the right questions that will help you make a better design. (Beyer and Holtzblatt
s book, Contextual Design, outlines a thorough process for conducting design research. Kuniavski
s book, Observing the User Experience, is an excellent, practitioner-focused reference on a variety of research techniques. You can find references to these books in Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) .) Whether you decide to do extensive research, light research, or no research at all, you must have answers to a few important questions.

Figure 1. The aspects of application planning build on one another. Defining markets leads to identifying users, users articulate their goals in using your application, and their goals motivate the content they work with and the tasks they perform. All of this information helps you design a successful Flex application. First, you must understand your users
goals—their reasons for using your product. For example, if you are designing a financial application, do your users want to browse through the most up-to-date market information and have access to powerful and complex graphical analysis tools to help them decide how to invest their money? Or do they want to spend as little time as possible to get their finances in order? Both of these may be perfectly reasonable goals depending on who your target users are, but designing for one versus the other will result in a very different product. Trying to satisfy both types of people with the same user experience would only result in a frustrating experience for both types of user, a recipe for disaster when it comes to application design.

2 of 7

3/3/08 10:37 AM

Adobe - Developer Center : Designing for Flex – Part 2: Planning y...

http://www.adobe.com/devnet/flex/articles/fig_pt2_print.html

Understand your users
goals as they relate to your project. Second, you should understand the tools and artifacts your users employ in their work or play. If you are designing a portable music player, listen to your users
music collections. For a photo browser, examine their pictures. For a business administration support system, pore over your users
forms and records and databases. As you do so, ensure that you understand not just the artifact itself, but what users do with the artifact (if they do anything with it at all). Study the tools and artifacts your users use or produce today.

Figure 2. Get copies of key artifacts your users create or use regularly. It
s often a good idea to annotate these artifacts to explain what users do with them. The example above describes how someone uses a corporate reimbursement form. Finally, you should understand how your users are engaging in the activities your product intends to support today. For productivity software, we often call these "workflows" or "tasks." These are the words I will use, but you may wish to choose another word if your product is designed for other domains such as entertainment or education. Very few (if any) products introduce entirely new workflows; users are always accomplishing their goals somehow today. Even if you expect them to change their workflows to more efficient and delightful ones once they get their hands on your product, understanding how and why they do things today helps you ensure that the new ways will actually improve their lives. Document tasks your users perform today to accomplish their goals.

3 of 7

3/3/08 10:37 AM

Adobe - Developer Center : Designing for Flex – Part 2: Planning y...

http://www.adobe.com/devnet/flex/articles/fig_pt2_print.html

Figure 3. Tasks and workflows are often best represented using diagrams such as the ones above. It
s useful to annotate diagrams with current problems and opportunities that your Flex application should address. The true test of understanding is the ability to communicate. Once you feel confident you understand your users
goals, artifacts, and workflows, communicate them to the other members of your design and development team. Document this understanding so that you can easily refer back to it later in the design process. (Note: Personas are a popular, but by no means the only, way of communicating and recording user goals, workflows, and artifacts.) This will help remind you what your real users want when the difficult trade-offs of the design reveal themselves. Depending on your design challenge, you may also wish to answer questions about the environment in which your users work, the culture of their organization, or other details. But ensuring that you deeply understand these key aspects of how your users behave—what their goals are, what artifacts they use, and what activities they engage in—is critical to designing a great Flex application. The next two sections will explain why.

Planning for content

"Content" is a general term for the nouns of your Flex application. Content is at the center of your application
s value proposition; it is the work your users do, the products they buy, the media they watch or listen to, the messages they send to their friends. All user goals that involve using computer technology involve content, for computers are information machines and content is information in the broadest sense of the word.

4 of 7

3/3/08 10:37 AM

Adobe - Developer Center : Designing for Flex – Part 2: Planning y...

http://www.adobe.com/devnet/flex/articles/fig_pt2_print.html

Figure 4. An application
s content can take many forms. The examples above are only a tiny sample; any information humans create or consume could conceivably be content for a Flex application. Ensure that you understand the content your application will work with before you start designing. Flex and Flash provide powerful tools for visualizing and manipulating content. The core Flash Player graphics, sound, and video capabilities enable rich rendering of multiple media types. The Flex framework provides means of making this media dynamic by streaming it over the network and allows users to interact with it in novel ways. These tools enable you to bring content to the forefront of your application. Great Flex applications allow users to work directly with their content instead of forcing them to hunt through layers of application widgets and other chrome to locate it. To effectively design an application around its content you must have a solid understanding of what users do with that content. A good first step is to examine the tools and artifacts your target users use today. From this, make a list of the content users will work with in your application and describe its properties. For example, if you are designing a music player, your list may include songs, artists, albums, and playlists. This exercise is similar to data modeling in software development, except that instead of defining the technical structure of data for mapping onto the tables of a relational database, you are describing your content in the ways users will think about it while using your application. Once you have defined the types of content your application will support, obtain real samples of this content to use during the design process. Real sample content is an essential ingredient for design processes that produce content-focused applications. Without it, the design process will give excess attention to user interface widgets, leading to designs full of buttons, sliders, and other application chrome that prevent users from working efficiently with what they really care about—their content. List the types of content your users will access in your application and obtain real samples for reference.

Planning for tasks and flows

If content types are the "nouns" in your application, tasks and flows are its "verbs." Your application
s tasks and flows represent what your users will do with it, or how they will use it to accomplish their goals. Tasks and flows are often best represented as scenarios, or short stories about how a typical user will use your application to accomplish a given goal or sub-goal. An example scenario for an accounts payable system might be "Submitting Expenses": Steven returns to the office after a week-long business trip and needs to submit his expense report.

5 of 7

3/3/08 10:37 AM

Adobe - Developer Center : Designing for Flex – Part 2: Planning y...

http://www.adobe.com/devnet/flex/articles/fig_pt2_print.html

He pulls out a wad of receipts and fires up his web browser, then navigates to the expense reporting system. He presses the "new report" button and goes through each receipt, filling out a form that asks for the date, the cost, and the type of expense. When each expense item is done, a new item immediately appears for him to fill out. For one group meal, he needs to provide additional details explaining the purpose of the meal. A text field appears to let him enter this information. Once he
s gone through all the receipts, Steven presses the "submit report" button. A screen appears explaining how to mail his receipts to Accounts Payable to complete his report. Tasks and flows help you understand how your users want to navigate through your Flex application and which application capabilities they will wish to use in combination. Understanding your application as a tool that helps users accomplish these tasks is essential for good Flex design. You can
t design a fluid, seamless Flex navigation experience without mapping out in detail the ways a user will want to get from one place to another. Write scenarios to represent the primary tasks users must perform with your application. The tasks and flows you develop should be based on your understanding of your users
existing workflows, which you researched earlier in the planning stage. Understanding how users perform their current activities helps you define flows through your product that will feel natural and require less time to learn. Also, understanding why users go through each step of their tasks will ensure that you don
t miss any important nuances. Without this audit, you might design a system that doesn
t satisfy your users
needs and may leave them worse off than they were before (if they don
t simply refuse to use it).

Figure 5. Diagrams comparing alternate workflows for a hypothetical online bill pay system. In the old workflow, users must pay each bill separately (probably on different screens). In the new workflow, a user can pay all bills on one screen. Clearly, the new workflow is superior if users will frequently pay multiple bills at once. Usually, you should not directly translate the way your users accomplish their tasks today into the Flex application they will use tomorrow. You may need to take an extra step and translate the activities your users engage with presently to a new workflow you expect them to engage with in with your product (see Figure 5). Tasks and flows change over time as improvements in technology offer newer and easier ways to accomplish the same goal. Traveling from Washington, D.C. to Boston is a very different task today than it was 200 years ago; air travel is a much more efficient form of transportation than horse and buggy (delays at O
Hare notwithstanding). If you are too constrained by what your users do today, you risk failing to see how they will want to do their jobs tomorrow. Fortunately, the goals that underlie your users
activities rarely if ever change. Use your knowledge of these goals to imagine new possibilities, but test these ideas against your understanding of the content and tasks your users use today. This will enable you to design Flex applications that meet and exceed their expectations. To learn more, read the next part of the series: Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) . This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

6 of 7

3/3/08 10:37 AM

Adobe - Developer Center : Designing for Flex – Part 2: Planning y...

http://www.adobe.com/devnet/flex/articles/fig_pt2_print.html

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.

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

7 of 7

3/3/08 10:37 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Flex Article Designing for Flex – Part 3: Structuring your application Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com The structural design process answers questions such as: What is the most important information or functionality to present up front? How will the user complete his key tasks? How will he move from one part of the application to another in pursuit of his goal? How will he locate and evaluate the information he needs to make decisions on what to do next? Structural decisions have a significant impact on the usability and desirability of an application, and they often prove difficult to change late in the development process if you get them wrong. For these reasons it
s common practice in HTML application development to spend a significant amount of time creating wireframes, or low-fidelity representations of page structure, and flow diagrams that explain how users will navigate from one page to the next. Structure is equally important in Flex application design, but since Flex applications are organized differently from traditional HTML and desktop applications, thinking through the structure requires a slightly different perspective. This article covers: The three types of application structure: information, process, and creation. How to use these structures as building blocks for designing your own application
s structure. How to design the entry point, or front door, of your application to immediately engage your users. How to apply your knowledge of users
tasks to help them fluidly and effortlessly accomplish their goals. How to employ the principles of visual hierarchy to guide users within a screen as well as between them. The Designing for Flex series includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html) Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) I suggest that you read parts 1 and 2 before proceeding with this part of the series. This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

1 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Three types of structure

Designers and developers create Flex applications for a variety of reasons, to serve many different types of users doing many different activities. However, if you examine a broad spectrum of applications you may notice that their structures can be decomposed into three basic types: information structures, process structures, and creation structures. Examples of information structures include product browsers in online stores, executive dashboards, news readers, and media players. They are built around the application
s content and are primarily intended to communicate new information to their users. These structures help users draw new inferences and make informed decisions by displaying the application
s data in a form that assists the users in understanding the information in ways that further their goals. For most information structures, the goal is to get the appropriate information in front of the user with as little effort on her part as possible.

Figure 1. The Flex Store product browser, the Oakland Crimespotting map, and the Amgen Tour of California race tracking view are all examples of information structures. Examples of process structures include online banking bill-pay systems, store checkout processes, and product configurators. They are built around helping the user accomplish a specific task. They walk the user through the task, providing information as necessary to complete each step. They are more focused on receiving information from the user than information structures, although they must still remain focused on the user
s content and tasks. The goal of most process applications is to collect this information from the user as quickly and straightforwardly as possible.

Figure 2. An insurance claim wizard, the Flektor video editor, and the Adobe.com account information editor are all examples of process structures. Examples of creation structures include desktop publishing tools, video editors, and music sequencers. They enable their users to produce a new piece of content or make significant free-form modifications to an existing one. They visualize and edit content and provide a set of tools for making these edits. Creation structures are not as linear as process structures since the creation tasks they support combine available tools in ways that are

2 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

difficult for application designers to predict.

Figure 3. The Flex rich text editor, Adobe Photoshop, and Adobe Premiere Express are all examples of creation structures. Selecting among the aforementioned structures is not an either/or decision for typical Flex applications. Many make use of two of the structures or even all three depending on the need at hand. For example, most online stores use an information approach for their product browsing experience but switch to a process approach for their check out workflow. Likewise, a weblog authoring tool may use a process approach for creating a new entry to collect information such as the title and category, and then switch to a creation approach for authoring the actual article. The next section discusses how to choose among the structures wisely.

Figure 4. Most real applications make use of multiple structures. For example, Amazon.com uses an information structure for its product browsing experience, then switches to a process structure for its checkout experience.

Applying the structures

Choice of structure can have a significant impact on your application. Often this choice is not straightforward, or (even worse) the structure that appears to be the obvious choice may not be the correct one. For example, you could design a photo editing application using a creation structure, similar to Adobe Photoshop. But many casual photographers wish to perform only a few simple tasks on their photos, such as removing red eye or correcting light balance. For these users, a process approach would be more appropriate. To help avoid this pitfall, I will take a look at each structure in turn, discuss its advantages and disadvantages, and then describe how to apply the structure in your designs.

Designing information structures

3 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

In general, employ information structures when your users
primary goals involve browsing, comparing, or comprehending different pieces of information. Information structures excel at promoting learning and discovery. This structure emphasizes visual communication through rich graphical information displays and de-emphasizes navigation and other extraneous tasks that don
t serve these user goals. Employ information structures when your users
primary goals involve browsing, comparing, or comprehending different pieces of information. Almost all information structures should start by displaying the application
s content. If the subset of content or the method of displaying it is not yet clear, the application should make its best guess from the context. Allow the user to make adjustments by supplying additional preferences through adding filters, selecting from multiple views, and so forth. Give the content display the maximum amount of screen real estate; display controls and other application chrome only when necessary, or relegated to the edges of the screen if this is not possible. Ancillary functions of the application should follow a “hub and spoke” model that integrates all of the information display and adjustment functionality into the central hub and pushes ancillary functionality off into separate spokes that the user only need explore for occasional necessary use cases. (Note: Hagan River
s report “The Designer
s Guide to Web Applications” provides an excellent detailed description of the hub and spoke structural model.) For example, a scheduling application that displays a calendar with appointments as its main hub should allow the user to create and remove appointments directly from the hub itself. The user might perform a less frequent operation, such as making an appointment recurring, a spoke reached by pressing a button on the appointment itself. More information about designing the content of your application appears in the next article in the series, Designing for Flex – Part 4: Designing Content (www.adobe.com/devnet/flex/articles/fig_pt4.html) .

Figure 5a. Yahoo! Maps uses a hub and spoke model, where the map and directions form the primary information-structured hub, while ancillary operations such as printing the map and sending it to a friend appear as spokes accessible by the top toolbar.

4 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 5b. The structural diagram for Yahoo! Maps clearly follows a hub and spoke model Many large Flex applications will not fulfill all of their users
needs with a single type of information display. For this reason, many designers choose to offer multiple views of the application
s content. For example, operating systems provide icon, list, and details views of files in a directory. When designing these views, consider the different goals and tasks the user must perform with each. Don
t make the user switch to a different view unless the goal he is trying to accomplish is markedly different! More information on how to handle navigation appears in the later section, Fluid navigation (www.adobe.com/devnet/flex/articles/fig_pt3_06.html) .

Designing process structures

Employ process structures when your users
primary goals involve providing information in as straightforward and efficient a fashion as possible. Process structures work best when users must enter a large amount of information at once or when they need guidance through a complex task. They allow designers and developers to walk users through an unfamiliar process. In information and creation structures, users must find the right combination of features to accomplish their goals, but process structures assemble this functionality into a linear workflow; users just follow the steps. Employ process structures when your users
primary goals involve providing information in an efficient, straightforward, and structured manner. Before designing a process structure, ask whether you really need it at all, or at least whether you need as much of it as you think you do. Many process structures force users to provide information that is unrelated to their goals, information that the system could have and should have figured out itself, or (worst of all) information that they just gave the system fifteen minutes ago. Always ask yourself if the information you are requesting is really necessary, whether it could be determined automatically, or if you even need the information at all. (Note: If the information you are requesting is for your benefit and not your users
, make it optional and clearly separate from the required information flow. Examples include demographics information for marketing or tracking purposes. If this information is really important to you, make it optional but offer the user some incentive for providing it.) The days of applications asking users to provide the IRQ port of their sound card because the computer was too dumb to figure it out itself are fortunately far behind us, but applications commit similar sins today for information such as zip codes (I just gave you my address) location preferences (couldn
t you show restaurants near my home by default?) and even taste preferences (I
ve visited this site looking for Ethiopian cuisine several times before, why make me re-enter it each time?). You can read more about how to ask for less information in Designing for Flex, Part 7: Making your application fast (www.adobe.comhttp://www.adobe.com/devnet/flex/articles/fig_pt7.html) .

5 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Once you
ve decided what information to ask for, you
ll want to consider how best to ask for it. Traditionally, designers implemented process structures using wizards—multi-screen dialog boxes with “Next” and “Previous” buttons to step users through a linear flow. Wizard-like interfaces are an option in Flex, but are not the only method. Many Flex applications present process structures on a single screen, defining the steps using visual organization principles instead of separate screens. Others use multi-state linear containers such as accordion controls to represent each step, while providing a more compact representation. The method you choose depends mostly on how separate the steps of your task are and thus how necessary it is to show the user how changes to the options of one step affect those of another. Regardless of the process structure you choose, provide ways for users to navigate to different steps in the process, even if they have already completed them or haven
t finished a prior step. This allows users to correct mistakes, skip information they aren
t yet ready to supply, and get a sense of how much they still have left. (Note: In some cases, you won
t be able to let users meaningfully “look ahead” because the options available in future steps depend on the selections made in previous steps. This still doesn
t prevent you from letting users go back.) Allow users to move through the process even if they have entered “invalid” information; often you should even allow them to save this information and correct it later. In the days of paper forms, users often entered notes or other temporary information into form fields with the intent of going back to it later; this important ability is often lost when these forms are translated to digital databases. Instead of rigidly refusing to accept temporary information, allow users to enter whatever information they like, then help them go back and locate fields that contain temporary notes later, when they have the final information available. It
s generally okay to allocate more space for controls and widgets in process structures than is acceptable in information- or creation structures. These controls may perform functions such as informing the user where she is in the process, allowing her to navigate to different steps. or explaining steps or options that aren
t immediately obvious. (Note: Many users do not read textual explanations, especially if they appear as a standard part of a common dialog. Use them sparingly, and replace them with graphical explanations or, better yet, ensure your input mechanisms communicate their function clearly enough as to not require explanation.) Superfluous chrome should still be eliminated.

Designing creation structures

Employ creation structures when your users
goals involve being creative—making entirely new content or making extensive changes to content used as a starting point. They are most useful when your users
goals call for free-form sequences that combine the functions of your application in ways you cannot fully predict. Creation structures allow experienced users a great deal of power and control, but they do so with some sacrifice in approachability for more casual users. Employ creation structures when your users
primary goals involve creating entirely new content or making significant changes to existing content. Always consider your own application
s domain and user goals when deciding which structures to employ. However, keep in mind that most people don
t use most of their applications regularly. Think of your own work; chances are you use a small handful of applications on a daily basis, but use of a much wider range of desktop and web applications weekly, monthly, or even more rarely. For this reason, it is often unwise to choose a creation structure as the organizing principle of your application. Consider using creation structures for smaller, more limited subtasks where they can be made simpler and easier to grasp even for casual users. Or don
t use them at all; As I mentioned earlier in the photo editor example, many creation structures should be replaced with process structures when designing for casual users with more predictable tasks. When designing creation structures, ensure that your users
content takes center stage. Allocate the most screen real estate to the creation surface. Place controls (such as toolbar buttons) off to the side or display them only

6 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

when users need them. This is more difficult to achieve than with an information structure since the number and variety of functions available at any one time will be much greater. Eliminate complex, control-heavy dialog boxes through direct manipulation techniques and carefully prioritize the editing functions you provide; many creation applications make the mistake of offering more functionality than the majority of their users need, to the detriment of the overall user experience.

Figure 6. Picnik is primarily creation-structured, yet it simplifies the photo editing task by keeping functionality to the essentials and providing options in context rather than requiring users to hunt for them in dialog boxes. If the creation structure in your application reaches a sufficient level of complexity, provide extensive task-oriented documentation to help users understand how to achieve their tasks within the tool. Make this documentation easily accessible from the application itself through prominent help search and contextual help buttons. Design this documentation not to be read cover-to-cover, but to be accessed in small chunks—to quickly answer users
questions when they get stuck so that they can easily get up and running again. Never use the documentation as a crutch for bad design; almost all users are highly documentation-averse and they should require it as little as possible.

7 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 7. The help system for Adobe Fireworks is written in a primarily task-oriented fashion. Instead of describing features such as “filters” as tools disconnected from user workflows, it discusses what the user is likely to want to do with filters, such as applying them to graphics, adjusting the color and tone of bitmaps, and creating custom filters.

Fluid navigation

In well-designed Flex applications, moving from one part of the application to another feels natural. The sections blend together and flow along with the users
tasks, guiding them towards completing their goals. This “flow” is due to two factors: effective use of motion during screen transitions (which will not be discussed here, but is covered in detail in Designing for Flex – Part 6: Guiding with motion) and embedding a deep understanding of the users
tasks and goals into the application design. This goal and task centered design makes it seem as though the application is anticipating users
needs and simply offering to take them where they want to go. This is called fluid navigation. When designing a fluid navigation experience, remember that any navigation should be avoided when possible. Navigation does not, by itself, do anything to help users accomplish their goals. It is a necessary by-product of using applications,similar to filling up the gas tank of your car. Filling up your tank does not directly get you to your destination any faster, but your car wouldn
t run if you didn
t put gas into it. Likewise, navigation actions don
t directly contribute to accomplishing user goals, so they should be kept to a minimum. Users should spend their time interacting with their content or accomplishing their tasks, not bouncing around from screen to screen in our designs. (Note: This example comes from About Face 2 by Alan Cooper and Robert Reimann (Wiley Publishing, Inc., 2003), a book that is full of many great analogies and explanations of core application design concepts.) Eliminate unnecessary navigation in your applications. That said, very few applications are so simple that they can eliminate navigation. So, how can you ensure this navigation is minimal, unobtrusive, and natural? The short answer is: by fundamentally shifting the way you think of organizing applications away from arranging pages or screens in a hierarchy or site map, and towards mapping the

8 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

flow of your screens directly to your users
key tasks. Most traditional HTML websites are organized into a hierarchical categorization system, often called a site map, which users access using navigation bars, breadcrumbs, and other web interface techniques. This works because these websites primarily contain many pages of static content and little to no dynamic content or application functionality. (Note: Even static websites are often poorly served by site maps alone. Most modern websites with large volumes of content consider search functionality a must.) Thus, using these sites is analogous to finding a book in a library; designers
goals are to help users navigate to the right content as quickly and easily as possible. Unfortunately, this approach works poorly for the fluid, dynamic applications that Flex supports. Taking a categorization approach to Flex application design results in experiences that are broken down into functions and sub-functions. Users must frequently navigate from a function in one part of the hierarchy to a function in a completely different part in order to accomplish their goals. This results in excessive time spent navigating the application and lots of user frustration. Instead of categorizing functions into a hierarchy, design navigation in Flex applications by focusing on user tasks and fine-tuning the experience to support them. Eliminate many of the abrupt screen transitions that force users to move from one context to another to accomplish their goals. Instead, de-emphasize disruptive, whole-screen transitions in favor of smaller, intra-screen changes that allow users to accomplish tasks without switching to a new context. Think of your application as a house, and the distinct screens or pages of the application as different rooms (Cooper & Reimann, 2003). In most houses, rooms are dedicated to serving a particular function centered on an overarching goal of the house
s inhabitants. For example, the kitchen is designed for preparing food. The dining room is devoted to eating food. The living room is used for lounging, talking, and watching television. Each of these rooms is self-contained; the house
s inhabitants need not leave it as long as they are engaged in accomplishing the same goal (cooking, eating, lounging, and so forth). It would be quite annoying if you had to move from the kitchen to the living room to peel potatoes, and you would not be a popular host if you forced your dinner party guests to move from the dining room to the hallway for the second course. Likewise, your applications should avoid asking users to move from screen to screen unless their goal fundamentally changes. Otherwise, users should be able to accomplish all tasks relevant to a goal on the same screen. This philosophy drastically reduces the number of screens necessary in a well-designed Flex application; even very large applications usually have less than 10 primary screens. Only use page-to-page transitions when the user is pursuing a clearly different goal. Use intra-screen changes to modify the screen as the user advances through tasks that are related to the same goal.

Figure 8. Picnik moves separate tasks onto separate screens, such as collecting images from Flickr or your computer
s hard drive, and making edits to an individual image. Picnik could take it one step further by combining the “Edit” and “Create” tasks into a single screen since manipulating photos and applying filters both relate to the same user goal: getting a particular look for a photo. Once you adopt the one-screen-per-goal philosophy, the good news is you
ll have far fewer screens to worry

9 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

about. The bad news is you
ll need to think much more carefully about the interactions within a screen, and you may need to modify your design toolset to do so. In traditional HTML applications, designers create wireframes or comps of key pages to depict the design. Since most of the actions available involve clicking links that will bring the user to a new page, these wireframes or comps, along with some annotation or other explanatory text, are often sufficient to illustrate how the application will behave. The changes within a page are typically minimal, so you can describe them with words or some additional pictures that show the page in each new state. Wireframes and comps are also a useful starting point for Flex application design, but they are too static to represent all the complexities of intra-screen interactions. Supplement your wireframes with storyboards to illustrate such interactions. All storyboards should describe how a user completes a key task by clearly illustrating the changes the screen goes through to help him arrive at his goal. List out your key tasks and create storyboards for each. Illustrate intra-screen changes by supplementing wireframes and comps with storyboards. Wireframes and storyboards are useful tools for thinking through many types of application task flows and behaviors, but to design and communicate the more highly interactive aspects of Flex application design you must build prototypes. Many designers skimp in this area since most projects lack the time or budget for complete interactive prototypes, but often you can choose the most important pieces of your Flex application to prototype and rely on wireframes or storyboards to communicate the rest. Custom content interactions (described in Designing for Flex – Part 4: Designing content (www.adobe.com/devnet/flex/articles/fig_pt4.html) ) and fluid motion effects and transitions (described in Designing for Flex, Part 6: Guiding with motion) can prove particularly important to prototype since the feel of the interaction is often just as important as its static visual appearance. but any set of interactions of sufficient complexity can be a candidate. Adobe Flash and Flex itself are popular tools for building interactive prototypes for user research, client communication, or simply to judge the feel of the interaction for yourself. Prototype key interactions in your application to tune and communicate the feel. The association between the user
s tasks and an application
s features is often complex and multifaceted. Users often combine multiple features to complete a single task, and may access the same feature to complete very different tasks. This makes it all the more important to understand and design around the user
s tasks from the outset. Resist the urge to merely assign features to screens and then link these screens together into loose task flows! Multiple tasks might require the same feature, but each task might need to use it slightly differently. Consider the example of a cell phone. A phone may have two screens, one for taking pictures with the built-in camera and one for sending SMS text messages. These are separate tasks, unless the user wishes to send a photo to a friend along with their text message. An application structured hierarchically by function may force the user to switch to the camera screen, take the photo, switch to the text messaging screen, choose the photo he just took from a list of the photos on his phone, write his text message, and press “send.” Obviously this is a sub-optimal user experience. A loosely task-oriented application may allow the user to select “send to a friend” after taking the photo, and then switch to the text messaging application. This is better, but still sub-optimal; the user can no longer see the photograph he just took as he writes his message. An ideal application would integrate the text messaging feature into the photo sending task flow; it would combine the two features into an interface tailored for the photo sending task. Unlike traditional HTML websites, the navigation structure of Flex applications should not resemble a hierarchy. Instead, it should resemble a small number of connected wheels, where each hub integrates most of the content and interactivity, and the spokes enable completion of ancillary tasks.

10 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Follow a “hub-and-spoke” navigation model, not a hierarchical site map.

Entry points

In well-designed Flex applications, the first screen your users see communicates how they can accomplish their primary goals. To do this, your application must have good entry points. To return to the house analogy, your application
s entry point is its front door. It
s critically important that it be both inviting and immediately straightforward to use. All users come to applications with a certain goal or set of goals in mind. The best entry point, therefore, is a clear, uninterrupted pathway towards that goal. Anything that gets in the way of the users
goal, whether it
s a “skip intro” movie, a difficult-to-navigate home screen, or any other distraction results in a poor initial experience. Design your application
s entry point to present useful tasks or information that clearly relate to your users goals with no interaction required on their part. The best way to reveal this pathway depends partly on your application
s primary structure. For applications that are primarily information-structured, use a meaningful display of the application
s content as your entry point. Most online stores get this right; they display a sampling of their wares immediately rather than forcing visitors to provide filter criteria on the type of product they
re looking for. Never show a blank screen and demand filter criteria before showing users one bit of content. Imagine an online store that forced you to fill out a long form or navigate a deep store directory before showing you anything. Such a system would be annoying to use; you came to find products, not to wander around the website. (Imagine if a physical store hid its goods in a back room and required you to describe what you want to the shopkeeper. Would you shop there?) Immediately present relevant content to your users for an information application
s entry point.

Figure 9. Amazon.com displays a set of relevant products as soon as you arrive at its home page. Although your application may not implement a relevance engine as complex as Amazon
s, consider how you can display more

11 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

relevant content immediately, without asking the user to provide any information before seeing it. Whenever possible, tailor the type of information you present based on the context the user is in. For example, if you are designing a mapping application and the user has frequently expressed interest in nightclubs before, you might display nightclubs on the map by default. In some cases you may need to ask the user to provide some additional context using a process structure before you can display anything useful. For example, airline booking systems typically need to know some details of your travel plans before they can show you a meaningful list of flights. Keep these details as few as possible and infer as much information as you can from context (for example, the airline system could guess at the user
s home airport based on their IP address or previous entries). More information is available in the Providing starting points section of Designing for Flex – Part 8: Making your application fast (available soon).

Figure 10. Yahoo! Maps infers the location of the city you live in from the addresses you provide it with. Once you
ve given it your home address, it uses this information to provide an even more specific entry point. Well-designed information applications provide information in a form that is easy to understand and draw inferences from. The entry point is your application
s first chance to show off this value. Be as informative as possible as soon as possible; this will invite your users to provide you with more information to get more detailed results. If your application primarily takes a process approach, make it easy for users to locate the task flows that interest them. Your entry point should provide a clear list of the tasks the application supports, described in the user
s language. For example, the automated teller kiosk of a bank generally allows you to withdraw money, deposit money, and check your account balance. So the first screen you see after inserting your bank card prominently lists each task; you simply select the one you wish to perform and you
re on your way. Clearly list the tasks your application supports for a process application
s entry point.

12 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 11. The Fidelity Mortgage Search application uses a task list as its entry point. Some applications must merge process structures with information structures. For example, many online banking websites display an account summary alongside a list of tasks such as “pay bills” and “transfer money”. These two can co-exist, but ensure that your information display requires minimal interaction, or that the interaction is performed in-context and doesn
t require lots of extraneous controls. This chrome distracts users from the tasks themselves, which may be the primary reason they visited the site. If your application primarily follows a creation-structured approach, you have a difficult job to do. Like information applications, the first thing the user sees should be the content they will be working with. But this is a chicken-and-egg problem; the user hasn
t created anything yet. If the user
s goal involves manipulating some existing piece of content, load up this content as a starting point, either by pulling it automatically from an available database or asking the user to provide it. For example, a document editor may display a list of recently edited documents for the user to choose from. If your user has no existing content of their own, consider providing pre-existing content for them to start with—a template or sample for them to modify. Building on top of pre-existing work is always easier than starting from scratch. . Provide a way to start with existing work for a creation application
s entry point. Regardless of your chosen structure, ensure that literally the first thing the user sees upon loading your application is a viable entry point that points them towards the completion of their goal. Perhaps the most common entry point is a log-in screen, but log-in screens make horrible entry points from the user
s perspective. They communicate “identify yourself or I refuse to deal with you.” Some applications must be so secure that they can do nothing until the user proves his identity. However, most applications, although they may contain some sensitive information, can do many things before asking the user to log in. Defer log-in requirements until they are absolutely necessary, such as if the user must save data to the server (even then, consider using a browser cookie instead) or access sensitive information such as credit card or address data. Fortunately, most e-commerce sites have figured this out already and never require a logon until it
s needed. You should strive to ensure that your applications follow their good example.

13 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 12. Kuler allows you to browse other users
color schemes and even create your own without ever asking you to log in. You only need to log in to an account to publish themes for others to view. Another example of a poor entry point is a “Loading…” screen that stays up for several seconds, which is unfortunately all too prevalent in Flex applications. Avoid long loading screens by delaying the download of unnecessary application sections and data. More information appears in the later article, Designing for Flex, Part 7: Making Your Application Fast (www.adobe.comhttp://www.adobe.com/devnet/flex/articles/fig_pt7.html) .

Visual hierarchy

The lowest level of structure in any application is the structure of individual screens. Sometimes designers disregard this structure in favor of elaborately mapping out the interconnections of the screens, but this is a mistake, especially for Flex applications that place such emphasis on the visual and interaction design of the primary application screens. Ensure that your screens are well-structured through effective and appropriate use of visual hierarchy. Applying visual hierarchy involves employing the visual variables of color, shape, texture, direction, size, and position to communicate to your users what is important, what can be skipped, and what may be important later. The difference between good and poor use of visual hierarchy is the difference between a clean, easy-to-understand application screen and a jumbled, incomprehensible mess, even if both screens contain the exact same content. Employ a solid visual hierarchy to communicate the important elements on the page and to guide the user
s eyes to the next part of their task.

14 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 13. This dialog box from Flex Builder is an example of poor use of visual hierarchy. The controls are jumbled together and all of the text has the same visual weight. Try scanning through the dialog to find the control for positioning the perspective switcher. Notice how long it takes; you need to read and process each control before moving on to the next.

15 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 14. This dialog, this time from Dreamweaver, uses visual hierarchy more effectively. Sections have headings indicated by lines and position, controls have more whitespace and meaningful alignment. Try scanning for the control to change the alignment of the accessibility caption. It likely took less time and mental energy. A common use of visual hierarchy occurs in almost any report. Most reports of any significant length—such as this one—have multiple sections and subsections. These sections are separated by headings. Headings are never in the exact same font, color, weight, and style as the body text. They are generally larger, bolder, and/or in a different color. They have more visual weight. In this article, for instance, the section headers are gray and surrounded by lines, which distinguishes them from the body text and causes them to stand out on a quick visual scan. If they were not visually distinguished from the body text, you wouldn
t be able to tell what was a heading and what was a paragraph; finding sections would become a nightmare. Headings are not the only page elements that communicate visual hierarchy, however. Anything on the page can communicate something about the visual structure (or even nothingness can; whitespace contributes to visual hierarchy as well). Colored backgrounds behind a group of elements connect them in the user
s mind, perhaps as a sidebar. (An old communication design instructor of mine called this technique “toast.”) A row of equally-sized, evenly-spaced buttons placed next to one another makes them related functions (such as on a toolbar) or even mutually-exclusive choices (such as in a dialog box). A large image draws the user
s eye and invites contemplation.

16 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 15a. Users rarely read every word on application screens. Instead, they unconsciously use the screen
s visual hierarchy to decide what to look at. For the Flex cookbook, most users likely see the large main headings first, then scan the subheadings, and only then read the content that interests them. Note that most of the page goes unread.

Figure 15b. Then, they scan the subheadings...

17 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

Figure 15c. ...and only then read the content that interests them. Note that most of the page goes unread. Ensure that your screens
visual hierarchy, just like everything else, clearly communicates to your users how to accomplish their goals. Use color to indicate buttons that represent default choices, or to warn against operations that might be destructive. (For instance, Wordpress colors buttons a deep warning red for operations that may damage data, such as “delete post”.) Use size to draw your user
s attention to the most important parts of the screen. Use position to guide the user
s eye through the ordering of elements on a form. (Read more about visual hierarchy and other communication design techniques in Mullet and Sano
s book “Designing Visual Interfaces.” Tidwell
s “Designing Interfaces” also contains an excellent discussion of visual hierarchy as well as other user interface design techniques.) Flex allows you to achieve any look that you wish; use this power wisely. Always keep in mind that visual design is a way to communicate with your users, and remember that as designers and developers, we often fall into that trap of thinking that we, who spend our entire day staring at the screens we design, see them very differently than our users will. Thinking about the visual hierarchy of your pages will help you avoid that trap. To learn more, read the next part of the series: (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) . 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.

18 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 3: Structuring...

http://www.adobe.com/devnet/flex/articles/fig_pt3_print.html

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

19 of 19

3/3/08 10:40 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Flex Article Designing for Flex – Part 4: Merging the web and the desktop Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com In Designing for Flex – Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) , I discussed how Flex brings together two formerly different mediums of software: the cross-platform, universally accessible yet technically constrained web application and the platform-dependent, locally installed yet richly interactive desktop client application. Although I have discussed many aspects of Flex that were originally derived from web idioms (content-focus, use of motion in Flash) and desktop idioms (saving files, controls and their uses), I
ll examine how the combination of the two mediums changes user expectations and how that can affect your Flex applications. Flex applications can live in one of two runtimes: the web-based Adobe Flash Player and the desktop-based Adobe Integrated Runtime (AIR). As you might expect, Flex applications that target the Flash Player feel more “web-like” to users whereas those targeting AIR feel more “desktop-like”. However, no Flex application should simply blindly copy the idioms of the old medium; Flex applications are rich Internet applications first and web or desktop applications second. However, the choice of environment has an effect on how users approach your applications, and you must take that into account when designing them. This article covers the following topics: The similarities and differences between web and desktop applications, and when to choose one versus the other. How to support existing user expectations for application behavior on the web. How to make Flex applications accessible to users with disabilities. How to design for desktop-specific concerns such as network connectivity, file system access, windows, and menu bars. The Designing for Flex series includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html) Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) I suggest that you read parts 1, 2 and 3 before proceeding with this part of the series.

1 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

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

Living on the web, living on the desktop

Web applications used to share very few similarities with their desktop cousins. Web apps were much more limited in the richness of their interactivity, while desktop apps were generally more limited in their connectivity and access to content. However, for the past few years this has become less and less true. With RIA technologies such as Flex and AJAX, web applications gained much of the richness of interaction that desktop applications enjoy, as I discussed in part 1. Likewise, many desktop applications started to incorporate traditional web idioms. iTunes includes a miniature web experience as part of its iTunes Music Store feature. Windows XP provides web-like navigation for its file system explorer. Many desktop applications now use hyperlinks as user interface widgets.

Figure 1. Flex Store is a web application, yet it employs many desktop idioms such as drag-and-drop. Adobe Bridge is a desktop application, yet parts of the application, such as Adobe Stock Photos, mostly consist of embedded web content. What does this mean for you? Fortunately, it means that designing a modern Flex application for the web is not very different from designing a modern Flex application for the desktop. Just because you
re designing a Flex application for the desktop-based AIR doesn
t mean you should load it up with menus and toolbars and control panels just to make it look like Microsoft Office
97. Likewise, just because you
re designing a Flex application destined for the web-based Flash Player doesn
t mean you should haphazardly add forms and navigation side bars just to make it “consistent” with traditional HTML web applications. All Flex applications should be content-focused, employ fluid navigation, use motion to guide users, and follow all the other principles articulated in the articles of this series. In general, web and desktop Flex applications should look and feel quite similar. Design Flex applications as RIAs first, and desktop or web applications second.

2 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 2. Kuler, a web-based Flex application, and Digital Editions, a desktop Flex application, share many similarities in appearance and structure even though they are deployed into different environments. Since both enivornments enable you to create rich application experiences, why create a web application versus a desktop application? Or should you do both, since most Flex code can run in both environments? The fact is there are still several inherent attributes of each environment that may make it well- or ill-suited to the particular goals of your application. Web-based applications have two essential advantages over desktop-based ones: they are always available from any machine with a network connection with no installation and they are fully integrated with the web environment. If your users have multiple machines or machines that they do not fully control (such as public terminals in libraries), you should probably build a web application. Even more importantly, an installation process—even a lightweight one such as the Adobe AIR installation process—is a serious deterrent to many web users who are initially only casually interested in your application. Offer a web experience when you expect your users won
t be motivated enough to install a desktop application. Offer a web experience when your application must be accessible from any machine and fully integrated with the web environment.

3 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 3. Users only undertake desktop application install procedures, such as the one pictured above, when they know they want the application and completely trust its source. Only deploy your application as a desktop app if your users know and trust your company and want the application badly enough to install it. Unlike desktop applications, web applications are accessible to search engines and URLs. Other website owners can
t link to desktop applications, nor can search engines spider their content. Although your content may be accessible through a web service API, this doesn
t provide the same level of easy integration with other sites and search engines. Offer a web experience if this level of integration is important to you.

Figure 4. Web applications have unique URLs, allowing other websites, such as blogs to link to them and within them. Here, you can see the Amgen Tour of California application linked to directly from a blog that recommends it. Desktop-based applications have their own set of advantages. Unlike web applications, they have a presence on the user
s computer. They integrate more closely with the host operating system. And they can allow offline usage by leveraging the user
s file system for storage. Offer a desktop experience when your application must have a presence on the user
s computer and integrate more seamlessly with the host operating system.

4 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Desktop applications usually appear as an icon in the Start Menu on Windows or the Applications folder on Mac OS X. If users use your application often, this provides easier access since they don
t need to launch a web browser and go to a bookmark. Offer a desktop experience if your users will find this quick access useful and they are unlikely to feel that you are cluttering up their applications list with a rarely-used tool.

Figure 5. Desktop AIR applications, such as Adobe Media Player, are installed on the user
s local machine and appear in the Windows Start Menu and Macintosh Applications folder. This gives them more prominence on the user
s system than web-based Flex applications enjoy. For security reasons, web browsers often place restrictions on web applications
integration with the host operating system. Some common desktop idioms are impossible to implement on the web, such as creating and opening files, and copying and pasting certain types of content. Also, only desktop applications can directly access the users
hard drive. Using the hard drive, the application can store a wealth of information on the user
s machine and still provide significant functionality when not connected to the Internet. Offer a desktop experience if the use of web-restricted idioms would help users accomplish their goals, especially if you expect users to need your application when no Internet connection is available.

5 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 6. Digital Editions, like most desktop applications, allows users to open files directly from their file system. Desktop Flex applications have all of the capabilities of native applications, including file system access and drag-and-drop/copy-and-paste functionality between the application and the host operating system. As you
ve seen, Flex applications deployed to the web and the desktop are very similar but have some inherently different advantages and disadvantages. The remaining sections of this chapter will examine how these advantages and disadvantages might affect the design of your applications.

Browser expectations

Flex applications that run in Adobe Flash Player and live on the web, whether they augment or replace conventional HTML-based interfaces, must fit in to users
understanding of how the web works. This boils down to two fundamental concepts in web interactions: the browser navigation buttons and URLs. The browser navigation buttons, often just called “the back button” are ubiquitous in web browsers and ubiquitously used by web users. Whenever an experienced web user changes his mind about a navigation decision or wishes to return to somewhere he has been before, he immediately moves the mouse and clicks the back button. Historically, Flash-based websites have not supported the back button; pressing it exits the application altogether (even if the user had unsaved data, violating the “never lose data” rule discussed in Designing for Flex, Part 8: Making your application safe”). Fortunately, Flex supports the back button through its history management feature. URLs are part of the fundamental design of the web. Users will try to bookmark and create links to everything that feels like a web page. Although Flex does not technically have the concept of “pages” as in HTML, Flex applications are split into multiple screens and have many states within those screens. To users, these feel similar to HTML
s pages, so you must ensure that they behave like pages. To satisfy user expectations, Flex applications must map the concepts of browser navigation and URLs to their own notions of screens and states. Each individually navigable state must have its own unique URL and appear in the back/forward history of the web browser. But what constitutes an “individually navigable state”? Clearly, different top-level screens count. However, different states within the same screen may also count. Examples include states of navigators (such as tabs and accordion controls) and different filters applied to a content control (such as tile lists and data grids). However,

6 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

some states only make sense in the context of a task flow and do not count as navigable states. Examples include the hover feedback on buttons and simple selection of items in a list that is not accompanied by the display of additional information. As a rule of thumb, if a state communicates new information that stands on its own, it is a navigable state and must be reachable via URLs and the back button. Provide URLs that a user can bookmark and back button support for all navigable states.

Figure 7. In the Flex Store, the “Home” and “Products” sections are clearly distinct navigable states. In addition, changes to the filter criteria that result in a different list of phones also constitute separate navigable states, and should have separate URLs associated with them (although as of this writing Flex Store does not support URLs for any of its states).

Figure 8. Hovering over a phone in Flex Store changes the view; it adds a beveled highlight and in-context controls. However, this does not constitute a separate navigable state and need not have its own unique URL. Desktop Flex applications that run in Adobe AIR may also benefit from having back and forward buttons, but for desktop apps, this feature is optional. If you do choose to provide back/forward buttons in your desktop application, ensure that they follow the same navigation model used in web-based Flex applications. Some creation-focused applications present very little in the way of navigable content and can get away with breaking web expectations due to their un-web-like appearance and functionality. These applications should open in browser windows that contain none of the chrome, such as the URL bar or back/forward/home buttons, so that users realize these functions are not available in this application. However, the vast majority of Flex applications should integrate with these browser functions

7 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 9. Fauxto takes a primarily creation-structured approach and thus can remove the browser chrome, including the back/forward navigation and URL bar. Most Flex applications, however, should not use this approach. Application-generated documents have unique concerns that deserve their own discussion. The user may have created these documents directly using the tools of a creation-focused structure or the system may have generated them on the user
s behalf as the result of input into a process structure or other input interface. Examples include uploaded photographs, message board posts, order summaries or invoices from online shopping sites. These documents must have their own URLs so users can bookmark them and even modify them later if that makes sense for the problem domain.

Flex accessibility

Accessibility for disabled users is an important concern for most web and desktop applications. In many countries, any application created for the government must meet certain accessibility requirements by law. Even those applications that have no legal obligations may not wish to alienate users with disabilities. Although it is not strictly a web/desktop issue, Flex accessibility contains elements of both desktop and web approaches. I will discuss how to use these mechanisms to support disabled users here. When someone mentions accessibility, most designers and developers think of support for screen readers and keyboard-only navigation. Flex supports both of these features. For the standard component set, this requires little extra work so long as you compile your application with accessibility support enabled (it is not enabled by default). Usually you only need to set the tab order so that the tab key moves between the controls in a logical order. This is important even to non-disabled users, as many users frequently use the tab key to move between form fields while entering data.

8 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 10. Diagram showing the expected tab ordering through a hypothetical order form. For users from western nations, tab order should generally move left-to-right, top-to-bottom within a section. Ensure that you tab through all the controls of one section before jumping to the next. Most disabled users, however, are not blind and do not require the use of a screen reader. Most are low-vision users; they can see the screen but have difficulty reading small text or distinguishing elements with low contrast. Many users also lack fine motor skills and may have difficulty using small controls. Do not overlook the importance of providing colors and font sizes that are legible to low-vision users and control sizes that are easy to manipulate. One option is to simply provide high-contrast colors and sufficiently large fonts and controls in your application to begin with. This is the best option if a large percentage of your users will be low-vision. For applications with only a small percentage of low-vision users, however, this may make the design less desirable to users with normal vision. Instead, use Flex
s style sheets to provide alternate versions of the application design which increase the font size, the size of controls, and the contrast of colors. Provide support for low-vision users by offering a version with high contrast colors and larger type and controls.

9 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 11. Adobe.com supports type size adjustment for low-vision users (although it could, perhaps, support it more gracefully). Flash has a bad reputation for lacking support for accessibility, but this is no longer true. With no more effort than is typically required for an HTML web application, you can make Flex applications equally accessible to disabled users.

Moving to the desktop

Most desktop applications can be classified into one of two types, sovereign applications and transient applications (Alan Cooper and Robert Reimann developed this distinction in their excellent 2003 book, About Face 2.0). Sovereign applications fully consume the user
s attention for fairly long periods of time. They are usually best used in full-screen mode, they contain a wide variety of tools and features, and they support many different tasks. Many sovereign applications are creation applications, although this is not exclusively true. Examples include Adobe Photoshop, Microsoft Word, and Intuit TurboTax.

10 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 12. Adobe Flex Builder is an example of a sovereign desktop application. Note the extensive use of small icons, multiple views of information, and the large number of functions available at one time. Sovereign applications are designed to absorb the user
s attention for long periods. Transient applications, on the other hand, are opened and used only briefly for a small number of fairly short tasks. Users rarely use them in full-screen mode since they generally share screen space alongside sovereign or other transient applications. Examples include Microsoft Windows
Calculator, most Apple Dashboard widgets, and desktop display preferences dialogs. Some transient applications may also have sovereign modes, for example, Apple iTunes is transient while listening to music in the background but also has sovereign aspects since many users spend time using it to organize and import their music.

11 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

Figure 13. Adium, an instant messaging client, is an example of a transient application. Users spend little time in the environment and tend to hop in and out, so there are few controls and functions. Transient applications are designed to be used occasionally and/or sporadically. Sovereign and transient applications should be designed quite differently. Since sovereign applications monopolize users
attention, they can consume more screen real estate, use smaller controls, and employ more complex and involved (but still useable and desirable) interactions. Transient applications must keep interactions simple and focused around the few tasks the application supports. Controls must be large and clearly distinguishable. Since users come to the application infrequently, they will not spend time finding fiddly little user interface elements; all tasks should be immediately and transparently obvious. Design sovereign applications to consume more screen real estate and employ more focused interactions and smaller controls. Design transient applications with simple interactions, larger controls, and clearer task flows. Think carefully about these two categories before designing your application. Consider the user goals, content, and tasks you must support before choosing an application type. Many AIR applications will be transient applications, and transient applications are designed quite differently from the large sovereign applications that most designers and developers think of when they imagine a desktop application.

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.

12 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

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. Hide the complexity of the file system.

13 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

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. Clearly communicate functionality changes caused due to a loss of network connectivity. 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.

14 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

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 (www.adobe.com/devnet/flex/articles/fig_pt3.html) , 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. Avoid spawning windows in desktop applications unless the windows map to disjoint pages. 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 (www.adobe.com/devnet/flex/articles/fig_pt5.html) . 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.

15 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 4: Merging th...

http://www.adobe.com/devnet/flex/articles/fig_pt4_print.html

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

16 of 16

3/3/08 10:41 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Flex Article Designing for Flex – Part 5: Designing content displays Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com An unfortunate myth prevalent among application designers and developers is that you should primarily focus on designing the chrome of the application, then provide space for the content. Some almost view content as an afterthought: a big box with an "X" through it in the wireframes, a place to put the stuff the database guys spit out, a consumer of screen real estate. Yet for most applications, content is what users care about; buttons, tabs, and panels are just a means for them to work with their content. Well-designed Flex applications, therefore, turn this philosophy on its head. Content displays are the key element of Flex application design. Application chrome exists only to support these displays, if indeed it must exist at all. This chapter covers: Information design – designing applications around their content. How to design interfaces that allow users to navigate content. How to design interfaces that allow users to manipulate content. How to provide feedback on user actions in a content-focused interface. How to employ standard controls in a content-focused interface. How to design controls so that they don't take focus away from the content. This is part 5 in the Designing for Flex series, which includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html) Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) I suggest that you read the previous parts before proceeding with this part of the series. This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

Information design

Designing content displays is not a new idea. The field of information design has tackled the problem for hundreds

1 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

of years in pre-web mediums such as print and television. (The term "information design" has only existed since the 1970s, but the practice predates it. Some even claim the practice goes back to the beginnings of human communication with the earliest cave paintings.) Information designers create all sorts of communication artifacts, from street signs to subway maps to instructional diagrams. To effectively design content displays, you must think like an information designer. Content can take many forms. For a personal digital assistant, the content might include appointments, dates, and tasks. A flight booking system might include flight data, travel itineraries, and tickets. A trip planner might include routes, maps, and directions. To design content effectively, you must put it at the center of your design thinking. Start with real examples of the content you expect users to view and manipulate in your application and understand the tasks users want to perform with it. For information-centered application structures, you may wish to re-frame these tasks in terms of questions users might ask about their content: "What's the cheapest flight I can take to Beijing during the first weekend of August?" "What appointments do I have to make today? " or "What's the fastest way to get downtown during rush hour?". Design content displays around questions your users will ask about the content. Once you have sample content and key user questions, your goal is to design a content display that helps users understand the answers to these questions. If the questions are diverse enough that you must provide multiple views of the content, design each view separately while keeping in mind which view will answer which questions. Don't worry about navigation bars or other application chrome at this point; first ensure that you have the information design right, then consider how to add in any necessary interaction. Design content displays first, then add controls and other application chrome afterwards.

Figure 1a. Designing effective content displays should always start with samples of real content. This image shows the first step in the design process of the media center application: a set of sample content loosely organized into a "library" and "store."

2 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 1b. Once you have the sample content, organize the content display so that your users can accomplish their tasks and/or find answers to their questions. Don't worry about interaction yet; pretend you are designing a physical information display such as a poster or a sign, as if this were the only information your users need to see. For the media center, for instance, we've organized the albums into groups our users were interested in seeing: the top-rated albums, their personal favorite albums, and a full list of all albums.

Figure 1c. After you've designed the static display, add interactive elements so users can navigate their information dynamically. Keep controls to a minimum; don't provide more functionality than users need as this can distract them from the functionality they will actually use. (Original design credit: Ty Lettau) Once you are satisfied with the design of your static content display, annotate it with the minimum set of

3 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

navigation, filter, and manipulation controls you need to help your users answer their questions. Well-designed content should take center stage; avoid the temptation to cram controls onto the screen to surface all of the application's functionality at a glance.

Figure 2a. Many of Apple's Dashboard widgets avoid control clutter by moving the small number of configuration controls onto the flip side of the widget, leaving the main side wholly devoted to a content display of the weather, stocks, time, train schedules, and so forth.

Figure 2b. Yahoo Maps (www.adobe.comhttp://maps.yahoo.com/broadband#env=a) is a larger application and requires more controls to enable users to complete their tasks, but the designers gave the majority of the space to displaying the map itself. Controls are overlaid over the map in unobtrusive ways. One important difference between designing content displays for Flex applications versus traditional web and desktop applications is that in Flex content displays should employ navigation sparingly if at all. Instead of providing many separate but similar detail views, Flex applications should strive to integrate the most relevant content details into the primary content display itself. A common pattern in interface design is "master/detail" or "organizer/workspace," where content items are displayed in a list or tree with only some of their information showing. When the user selects one item, the application displays the full details for that item either by transitioning to another screen or by displaying it in another panel visible on the screen. This is a good pattern and can be applied quite effectively, but it often encourages designers to provide insufficient information in the list itself; users must click on several items in sequence to see the details that interest them. To make comparisons, the users must hold in their short-term memories the details of a previous item they wish to compare to the currently selected one. Gmail innovated in this area by displaying not just the sender's name and the subject of the e-mail in their main list, but a snippet

4 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

displaying the first line of the message itself as well. Integrate highly related information into a single content display whenever possible. Avoid splitting information across multiple screens or states.

Figure 3a. Gmail helps reduce the constant switching back-and-forth between the message list and the individual message display typical of other email clients by integrating more information about each message into the message list itself. Users can view all participants in an e-mail thread as well as a snippet of the most recent message without ever leaving the message list view.

5 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 3b. Adobe Media Player employs master/detail while also displaying details in place where appropriate. To support a large number of videos, it uses a master-detail model when drilling down into subcategories. Since this prevents users from comparing information across categories, the main screen displays an initial set of videos directly in place underneath the category name, which helps users better understand the categories themselves. Flex's mechanisms for displaying and interacting with lists of content are very flexible, and allow designers to bring rich information content into the list itself. Make use of this ability by considering what your users really need to see to answer their questions instead of shunting this information off to another screen out of habit. Having all this content in one place necessitates careful and skillful communication design. Appropriate use of visual hierarchy among the elements of the content, as discussed in Designing for Flex – Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) , is critical to ensure the user understands this wealth of information. Many Flex applications could benefit from having a skilled information designer on the team to effectively apply visual information design principles to the application's interface.

Navigating and manipulating content

Well-designed content shouldn't require much navigation, and unless you are building a creation application, your content shouldn't require much manipulation either. However, many content databases are vast enough that users must browse and search them to locate specific content, compare content, or simply explore what's available. Traditional websites and applications often employ information hierarchies as a content organization strategy. Each piece of content is assigned to a category, and users must browse to the right category to locate the content they're interested in. Many companies spend lots of money designing and researching the right categorization system to match users' expectations. Categories have their place in Flex application design, especially if you keep them shallow and lightweight, but in general you should avoid hierarchies. Adobe's LiveCycle Form Manager product takes such a hierarchical approach, which reduces its usability. All forms appear somewhere in a tree control, forcing users to perform a new

6 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

task—find their form—before they can get on to their real task: filling out their request. Most hierarchical systems require users to perform a navigation task before they arrive at interesting content, and as mentioned in Designing for Flex - Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) , information-centered structures should seek to bring users to their content as quickly and effortlessly as possible. Moreover, hierarchies fail to satisfy an important aspect of good Flex application design: they make it difficult for the user to explore the content.

Figure 4. Adobe LiveCycle Form Manager is an example of an interface that should be less hierarchical. The hierarchy forces users to guess which category their form lies under before they may begin their real task. Categories can be confusing; for example, should the form for converting paid time-off hours to cash fall under the "Attendance and Leave" category or the "Payroll" category? Typical content browsing on the web usually involves filling out a search form, then browsing results to locate the most interesting content. If the user wants to make tweaks to his search parameters, he usually needs to hit the back button, re-fill out the form, and browse a new set of results. This experience is optimized for locating a particular, predetermined piece of content, but not for effectively exploring the content space. Sometimes, users don't come to applications with a precise idea of what they are looking for. Instead, they have a general sense of what they need and want to refine their decision based on what content is available. Even when users do know exactly what they want, they may also wish to explore similar content and make comparisons, such as between competing products in an online store. For these reasons, you should design content experiences that are easy to explore. Make it easy for users to not just find content, but explore content. Aim to seamlessly integrate searching and filtering functionality with the content browsing experience. Instead of breaking your interface into separate search, navigation, and results pages, think of your interface as a unified view into your content where users can directly specify the attributes of the content they actually want to see. Ensure that users can modify search and filter parameters easily and see results instantly. The less time they spend jumping back and forth between a filter form and the results view, the more time they can focus on viewing and understanding their content.

7 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Support content exploration by making search and filter controls instantly responsive to user changes.

Figure 5a. The INM Library site uses an attribute-based content navigation strategy. This allows users to locate documents based not only on their category (or "type") but also by keyword, year, or source.

Figure 5b. The Flex Support Forums employ a hierarchical navigation strategy. Users may only view content associated with one category at a time, making it more difficult to find posts that cross categories.

8 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 5c. Yahoo! Search employs a search/results navigation strategy; users may only locate web pages based on keyword. There are several ways to navigate content. A textual or graphical results list is one of the most common, with filter controls accompanying the results display. However, some content, such as spatial data, is easier to view on a pannable, zoomable surface. This change in the interaction model doesn't change the need to support exploration; mapping applications became much more effective when Google Maps made dragging and exploring the map easy compared to earlier interfaces that employed clunky directional arrows and screen refreshes. Most Flex applications don't need to provide extensive content manipulation features. Unless you are designing a creation application, avoid overloading your users with manipulation options. When users need to manipulate content, keep the operations as straightforward and discoverable as possible. Favor direct means of manipulating content over indirect ones; for example, instead of adding a button to move an item from one list to another, allow the user to drag and drop it. Drag and drop is a common interaction in Flex applications; always offer it as a means of reordering and moving pieces of content. Consider exposing other content manipulation operations using in-place controls, discussed in the later section, "Merging controls and content (www.adobe.com/devnet/flex/articles/fig_pt5_04.html) ." Favor direct means of manipulating content over indirect ones.

9 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 6. Netflix's interface for organizing a movie queue was originally based on indirect manipulation; to reorder a queue the user either had to change the numbers next to each movie or use the "move to top" button. Recognizing that users had difficulty achieving a precise ordering with this interface, Netflix added the ability to drag and drop movies from one position in the queue to another—a direct manipulation strategy. Especially for information structures such as search results displays, map navigations, and charts and graphs that you can manipulate, focus your design efforts on the interactive content displays to ensure that they are straightforward and feel right in real use. If you only have time to prototype parts of your application, prototype the content displays. Whether or not these interactions feel right can make or break your entire Flex application.

Merging content with feedback

An all-too-common idiom that has plagued applications since some of the earliest GUIs is the pop-up dialog box. Designers and developers use pop-up dialog boxes for a variety of purposes, including providing feedback on an operation, warning users of destructive operations, notifying them of errors, or even explaining the purpose of a feature (sometimes with the ever-popular "Don't show me again" checkbox). They are probably common because they are easy to design and program. Sadly, they provide a terrible experience for users.

10 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 7. Pop-up dialog boxes like the one above are rampant in traditionally designed applications, yet they are one of the rudest and most intrusive ways of providing users with feedback and other information. To the user, pop-up dialog boxes aren't much better than pop-up advertisements on the web. They interrupt and demand immediate attention. However, they often don't contain interesting information, and as a result users often close them without even looking at them. They are a rude and intrusive way of providing feedback and should be employed as rarely as possible. But if you shouldn't use pop-up dialog boxes, what should you do when you need to provide information, warn users, or notify them of errors? The answer is in designing these messages into information displays using modeless feedback. Modeless feedback allows you to integrate information into the user's flow without breaking her flow. For example, if you have a list of photo thumbnails and it's important to users to know their real dimensions, consider placing the dimensions below the thumbnail instead of making the user bring up a dialog box with this information. If you need to warn the user of an operation's consequences, consider attaching a callout to the operation's button or control. Favor modeless feedback integrated with content over modal pop-up dialog boxes.

11 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 8a. Adobe Photoshop Lightroom uses modeless feedback to inform users that their commands were properly executed. After performing the "undo" command, the modeless message above appears over the content then unobtrusively fades out on its own.

Figure 8b. Microsoft Outlook employs modeless feedback when alerting users that they have received new

12 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

e-mail messages. The notification box above appears in the bottom-right corner of the screen even when Outlook is minimized or hidden. Notice that Outlook's modeless notifier also includes relevant details about the e-mail message: the sender, the subject, and a snippet of the message text.

Figure 8c. OmniGraffle offers a different kind of modeless feedback directly on the document canvas. As users drag shapes around, a tooltip pops up displaying the x and y location and guides appear giving alignment and spacing hints. Unlike Outlook and Lightroom, OmniGraffle's modeless feedback doesn't display a textual message, but it does unobtrusively display helpful information. For each of these examples, imagine how much worse the user experience would be if the designers had chosen to employ pop-up dialog boxes instead of modeless feedback! Flex's validators offer a solid implementation of a modeless feedback idiom that is built into the framework. Instead of popping up a dialog box when a user makes an error entering values into a form field, validators display a red callout box next to the form field with a message explaining what is wrong and what the proper format should be. This has three advantages over a pop-up dialog box: it is far less annoying; it is more contextual, making it clearer which form field contains the erroneous entry; and it doesn't interrupt the user's flow in case she would prefer to return and correct the error later.

Figure 9. Flex's built-in validators are a convenient way to provide modeless feedback for form validation errors. Validators highlight fields that contain invalid input and provide modeless callouts to explain what's wrong. They are far less intrusive than the traditional method of displaying a modal dialog box when the user exits a field or attempts to submit the form. When designing or developing an application, ask yourself how many of the pop-up dialog boxes you employ are really necessary, and whether they could be better executed as modeless feedback.

Merging controls and content

Much of this article has discussed how to design content without the use of controls, and has even actively

13 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

discouraged their use. However, almost all applications will require the familiar interaction patterns made available through traditional application controls. How, then, can you employ controls in a way that doesn't overwhelm your content? First, consider whether a full-on control is necessary to satisfy your users' goals. Often elements within the content itself can become interactive and respond to hovers, clicks, drags, and other user input to display additional or new information. The downside of such "chromeless controls" is that they can be difficult to discover; they don't look like they should be interactive, so users might assume they aren't. The way around this difficulty lies in using affordances to distinguish interactive elements of the screen from static ones. An affordance is a visual treatment applied to an interactive screen element that suggests what users can do with it. The most common example of an affordance is hover highlighting, which should almost always be employed for the sake of consistency. Depending on the situation, you may want to employ other affordances to communicate not just that an element is interactive but also what users should do with it. A common example is knurling: the small ridges added to, for example, scrollbar thumbs. Knurling affords grabbing and moving in the direction of the knurling itself, since in physical objects knurling actually helps users turn or slide smooth surfaces by providing additional friction. Employ affordances to clarify which items within your content are interactive.

Figure 10a. Adobe Media Player uses hover highlighting to indicate that the thumbnails of shows are clickable. This helps users discover that the thumbnail is interactive and not just a static information display.

14 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 10b. Google Maps is also interactive content. Users may drag the map to view portions that appear of the screen. In this case, the form of the content itself affords dragging; maps are usually larger than what appears in the limited viewport, and this fact plus the presence of the zoom and pan controls helps users understand that dragging is an option. The open hand cursor also helps, but imagine if the content were a tiled group of photos instead of a map; fewer users would discover the drag operation since dragging usually does not accompany thumbnail lists. When controls are necessary, consider displaying them in the context of the content itself. For example, say that you have a list of websites on a server and the user might generate a report on the usage statistics for any one of them. Instead of requiring the user to select an item and then locate a toolbar button to generate the report, provide the generate report button along with all the rest of the appropriate functionality alongside the list item itself. (Note that this pattern does not work well when users wish to multi-select items and apply an operation to all of them at once.) Display controls in the context of the content they manipulate. Oftentimes having all controls visible alongside all content elements on the screen leads to a very cluttered interface design. Instead of displaying all controls all the time, consider showing an item's controls only when the user has expressed interest in operating on it by hovering over or selecting it. You might put the relevant controls in an overlay on top of the item. Another option, especially popular in managed layouts such as lists, is to expand the item to show additional controls and content on selection. However, use this idiom with caution. Hiding controls behind selection or hover actions can make them much harder for casual users to discover. Only employ this idiom if users naturally select or hover over the content of interest before they need the controls. Perform adequate user testing to ensure this is the case.

15 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 11a. Picnik uses in-context controls throughout their UI. For example, when users apply an effect the configuration options appear directly underneath the filter within the filters list. This makes it much easier for users to customize their filters right after applying them.

Figure 11b. Flex Store employs in-context controls when hovering over an item to allow users to add it to their shopping cart, compare it with another item, or view the item's full details.

16 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

In information structures, controls are not the primary focus of the user and should be minimized, but they must be discoverable if the user's goals involve navigating or manipulating the information display. By making these controls contextual, you can have your cake and eat it too; the controls will appear exactly when the user needs them, but won't clutter the screen and interfere with viewing the information itself when he does not.

Designing controls

When controls appear in Flex applications, they must often match the visual styles of the application's content as well as the overall brand of the web application and the larger web presence in which it often lives. Fortunately, this is easy in Flex: you can customize almost every aspect of the application's visual appearance using the Flex styling and skinning mechanisms.

Figure 12. You can change the appearance of the Flex controls using two mechanisms: styling and skinning. Styling involves changing the properties of the default control appearance to create variations on the standard look. Skinning involves completely replacing the standard look with custom artwork created using the Adobe Creative Suite tools such as Adobe Photoshop, Adobe Illustrator, Adobe Flash, and Adobe Fireworks. Skins are much more flexible than styles, but also tend to take longer to create. There are, however, some caveats. One of the primary benefits of standard control libraries is standardization: users are familiar with these controls and how they behave. If you change the controls too dramatically, you will lose this benefit. Nonstandard controls force users to learn how to manipulate the chrome of the interface and distract them from what they really want to focus on—their content and their tasks. To users, the most important aspect of standard controls is their behavior. For example, users expect scrollbars to implement a certain set of behaviors: the thumb should grow to indicate how much of the full scroll area is in view, clicking on the track should move the thumb to the clicked location, pressing the arrow buttons should move the scroll area up or down one notch, and so forth. If a scrollbar does not implement these behaviors or does not implement them correctly, users will struggle with the control even if its visual appearance is identical to standard Windows or Macintosh scrollbars. (In fact, this is especially important if its visual appearance is identical to standard scrollbars. The most confusing controls are those that appear to be standard controls, but behave in subtly different ways.) Flex's off-the-shelf controls also follow these standard behaviors. For this reason, never re-implement your own controls when an off-the-shelf control is available. Never re-implement your own controls when a suitable off-the-shelf control is available. Instead, customize the off-the-shelf control to suit your needs.

17 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

Figure 13. The diagram above explains the expected behavior of a scrollbar component. Like many standard controls, scrollbars contain many subtle features that users have come to rely on. If a scrollbar in your application does not implement all of these features, users will be very confused and annoyed. Instead, reuse the existing Flex scrollbar component and customize its appearance using skinning and styling. The visual appearance of standard controls is important, but controls generally need not be visually identical to the ones users are already familiar with in order for their consistency benefits to carry over. However, radical changes to the visual appearance of controls can be quite confusing for users. In general, use Flex styling to adjust the visual appearance of the default Flex look (called Aeon). Aeon is quite flexible and often sufficient to achieve a branded look and feel. If you determine a more custom appearance is necessary for your application, you will likely need to use the skinning mechanism. Skins allow you to achieve any visual appearance you desire, but when misused they also allow you to render them unidentifiable to your users. Ensure that you preserve and distinguish the major visual elements of the control; for example, a scrollbar should still contain an up and down arrow, a track, and a resizable thumb. As always, ensure that the elements are sufficiently visually distinct so that all of your users can make them out, even users with low vision. To learn more, stay tuned for the next part of the series, Part 6: Guiding with motion, which will be available soon. 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.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License

18 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 5: Designing ...

http://www.adobe.com/devnet/flex/articles/fig_pt5_print.html

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

19 of 19

3/3/08 10:42 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

Flex Article Designing for Flex – Part 6: Guiding with motion Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com Motion has been a key element of Adobe Flash since its very beginning. The ability to animate objects on the web is integral to the technology and was originally one of its main selling points. As discussed in Designing for Flex – Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) , Flash originally used its animation capabilities to tell stories, whether to teach, to sell, or to entertain. But with Flex, the Flash platform has moved into application design, bringing all the communicative power of its motion technology with it. Unfortunately, due to some high-profile mistakes, motion has received something of a bad reputation in application design and development circles. I say "unfortunately" because, when used properly, motion can be a powerful tool for making applications more useful, usable, and desirable. Using motion, you can eliminate the jerky jumps from screen to screen that disturb and deeply disorient users. However, improper use of motion will distract and annoy users, impeding them from reaching their goals. This chapter covers: The differences between motion design in Flex applications and motion design in other media. How to use motion to leverage users' instinctual understanding of the physical world to enhance your application's usability. How to use screen to screen transitions to help guide users to the next area of interest and make it clear how to return. How to use motion effects to provide feedback and focus your users' attention. The Designing for Flex series includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html) Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) I suggest that you read the previous parts before proceeding with this part of the series. This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

1 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

Motion in other media

Many designers have focused on the design of motion in the past century, mostly in the cinema and broadcast media and more recently in computer games. Directors and cinematographers in the movie industry must deeply consider the properties of motion and its impact on the static image; cinematic experiences are much more complex than simply pointing the camera at the action. Animators, both traditional and modern CGI artists, must consider motion design at an even deeper level; they craft motion as a native medium to recreate natural movements or to purposely exaggerate physics for amusement or on-screen effect. An entire art form exists around these disciplines that can take years to master.

Figure 1. Motion design for animation and film is an art form that requires years to master. Motion design tools such as Adobe After Effects are correspondingly powerful, complex, and unapproachable to non-specialists. Fortunately, most Flex RIAs do not demand this level of motion design expertise. Fortunately, applications are much less demanding of the motion expertise of their designers. Movies, television shows, and games all aim to weave elaborate narratives with motion that involve highly realistic, often three-dimensional objects interacting with each other in complex ways. Applications, on the other hand, benefit from visual simplicity; they aim not to tell elaborate stories but to guide users to the information or endpoints they wish to reach. Extensive or unnecessarily sophisticated use of motion may distract from this purpose. Thus, applications are not only able to get away with a simpler view of motion than movies and games, but they actively benefit from such simplicity. In the past, many websites and applications went overboard with motion and became distracting to their intended users. Perhaps the most painful example for Flash was the old "skip intro" movies that started appearing on websites starting in the late nineties. Skip-intros were offensive primarily because they got in the user's way, preventing him from immediately accessing the content and tasks the user had come to the website for. A similar example from the desktop world is Microsoft's Clippy, who was annoying for a variety of reasons, one of which was his tendency to sit in the corner of the screen and fidget, breaking the concentration of users who were trying to work. (Note: Never play a continuously looping animation in your application, excepting soft glows or other nonintrusive effects that are too subtle to draw attention. Fortunately this terrible practice isn't nearly as prevalent as it used to be, but we must still guard against it every chance we get.) To avoid repeating these mistakes, consider how motion affects human perception. Examining how motion impacts human behavior in the physical world can help you design effective motion in Flex applications.

2 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

The physical world and applications

In the physical world, objects behave very differently from the way they do in the world of traditional computer applications. When objects move, they travel the space between them. When they grow, they visibly expand rather than snapping to a new, larger size. When they vanish from sight, it is usually because they have moved outside our range of vision or have become occluded by another object. Humans understand this behavior of physical objects instinctually, and thus we have a set of preconceived interpretations of what happened when objects vanish or change positions when we turn our backs on them. In traditional web and desktop applications, objects do not behave this way. They teleport from one location of the screen to another. They get bigger instantaneously. They vanish with no apparent clues as to where they went. In a world like this one, all of our instinctual knowledge goes out the window. (A painful way to discover this is to watch a computer novice try to multitask between two applications. When one application's window pops up over the other applications, many users believe that they somehow made the first application disappear and all the work they had done with it is lost.) Figure 2a. When panels move around in Adobe Dreamweaver, they "teleport" from one position to another. This is very different from how objects behave in the real world. Click play to see this example. Figure 2b. Unlike Dreamweaver, when panels move in Adobe Connect they traverse the intervening space and grow instead of snapping to a new size. This feels much more natural. Click play to see this example. Those of us who work with computers regularly have trained ourselves to follow a different mental model when working with typical applications, and we've superficially become used to its eccentricities. But at a deeper level, this odd computer behavior disturbs us and detracts from the experience of using them. Much of the appeal of the modern Macintosh operating system is its rich physicality—drawers slide out, windows shrink when minimized, document icons pop forward when opened. Like the Macintosh, Flex applications should take advantage of human understanding of motion in the physical world and apply these perceptual principles to the motion design of their own panels, content, controls, and other interface objects. Through the use of physical principles, Flex applications should employ motion to help reinforce their task flows and guide users through their content. Employ motion to apply physical principles that help users understand the workings of your application. Figure 3. Part of the appeal of Mac OS X is the rich physicality of its motion. In this demonstration, a window expands from its minimized state in the dock, the folder structure slides to the left as new folder contents appear on the right, and finally a file's icon briefly expands and fades out when opened. Each transition mimics a related real-world motion, helping the user understand the file system's mental model by mapping it onto an instinctually understood physical model. Click play to see this example. Not all motion in Flex applications is literally an analog of physical behavior. Cross-fades, for example, do not appear in the physical world yet are often appropriate when removing details of a screen or panel that are no longer necessary. Yet cross-fades help users understand that the details are changing without creating a confusing jumble of moving objects that a slide or resize effect would when applied to many objects at once. Even here, motion helps users understand what happened as they navigate through the application. Motion in the physical world has a natural attention-drawing effect on humans. Our peripheral vision is very good at picking up sudden motion and our natural instinct is to immediately turn to focus on whatever caused it, since this was a pretty good way of minimizing our chances of getting eaten by tigers trying to sneak up on us. (Have you ever sat in a restaurant or bar trying to hold a conversation with a television playing behind the person you're speaking to? Then you likely understand this principle already.) This is the reason Clippy and the banner ads are so irritating and distracting, but it's also a good way to temporarily draw users' attention to a part of the interface they are not currently focused on but which may interest them. Motion can help draw users to the next step towards completing their goals.

3 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

Employ motion to subtly draw users' attention.

Transitions and effects

From this understanding of motion in the real world and its effects on humans, we can infer two primary uses of motion in application design: 1. To help users understand the workings of the application and increase its desirability by leveraging their instinctual understanding of physical objects, and 2. To focus the user's attention and provide effective feedback on the results of an action or to guide them to the next step in accomplishing their current goal. Flex provides facilities for realizing both of these uses of motion, and it calls them "transitions" and "effects," respectively. Traditional, narrative-oriented motion design environments conceive of time as the primary organizing principle that begins at the start of the experience and ticks off the seconds until its end. In Flex's nonlinear model, however, motion happens primarily during transitions, the things that happen between two application states. Transitions allow Flex applications to avoid the jumpy, abrupt movement of objects that traditional applications suffer from. When objects move, they move smoothly through the intervening space. When they change size, they grow or shrink. And in well-designed Flex applications, the metaphor of physicality is perfectly preserved; if the screen slides to the right to show different content or functionality, sliding it to the left will bring the old content back. If a drawer slams shut, pulling it out will open it back up again. Figure 4. The hypothetical photo browser application above demonstrates a transition in action; the panel containing the search box smoothly animates open to reveal the search results. The motion reinforces the panel's identity in the user's mind across the two application states. Click play to see this example. Well-designed transitions keep the user fully informed about where they are, where they have been, and how they get back. They also inform the user of what has changed in the application's state and how to revert it or change it again. And it does these things through mechanisms that require no learning since users instinctually understand them from the physical world. Use transitions to keep the user informed about where they are, where they have been, and how they get back.

Effects also employ our instinctual knowledge of physical motion to enhance the user's understanding, but they are more localized to individual objects. They excel not at guiding the user through application navigation paths, but at drawing and channeling users' attention to the next step in their current task and in providing rich feedback in response to user actions. For example, you might employ a glow effect when a user's mouse hovers over a piece of content to indicate she can interact with it, or cause an image to grow when selected, making it more visible. Use effects to draw the user
s attention and provide feedback. Figure 5. The hover behavior of the hypothetical photo browser demonstrates an effect in action—as the user places her mouse over each photo, it softly pulses to indicate that the photo may be interacted with. Effects excel at providing feedback on the level of individual objects. Click play to see this example. When employing effects and transitions, avoid using motion in gimmicky or gratuitous ways. If the motion you

4 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

employ is not intended to have one of the aforementioned purposes, carefully consider whether it warrants inclusion in your application at all. It's easy to become enamored of motion and use it inappropriately; for an example, view a demo of the "Wobbly Windows" effect in the Gnome Luminosity project. It adds nothing to the user's understanding of the application and serves only to distract from the experience of using it. Such gratuitous effects make great demos but are best avoided in real-world applications. Avoid gimmicky or gratuitous motion.

Transitions—motion that teaches

Designing effective transitions can be tricky. This section provides some principles and advice that will help you do so. In the mid-nineties there were a number of interfaces based on overly literal representations of physical spaces inside the computer, Microsoft Bob being perhaps the most well-known example. These interfaces employed excessively decorative information design and interaction patterns that didn't translate well to the computer's input devices. All failed. Applying physical principles to the motion design of your application doesn't mean blindly copying reality. Instead, incorporate these principles into interactions that are appropriate for the device's purpose and capabilities. Figure 6. Online "books" are cool experiments in UI technology, but most take the metaphor very literally. Users must drag pages halfway across the screen to turn them, a difficult task with a mouse. Besides, an appropriate information display for a physical book may not be appropriate for the screen—consider information designs that take advantage of computing technology, not ones that attempt to replicate designs in other media with different properties. Click play to see this example Instead of trying to craft a "virtual world" inside the computer, use the motion properties of physical objects to guide your decisions on how your Flex interface elements should move. Keep track of where onscreen objects are located in each state and how they flow from state to state. Remember the properties of physicality discussed earlier; physical objects traverse the space between them when they move or change size. Persist the identity of objects in users' minds by smoothly moving or resizing them from their old location to their new one. When objects move off of the screen or otherwise become unavailable, allow users to retrieve them by navigating to the space they went to. Use the motion properties of physical objects to guide your decisions on how your Flex interface elements should move. Figure 7a. The hypothetical insurance claim form shown above uses motion effectively to create the illusion of navigating through a physical space. As the user moves from one page to the next, the old page slides out while the new one slides in. Click play to see this example

5 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

Figure 7b. The motion transitions in the insurance form help the user understand the system's model for how the form is organized. Because pages slide to the left and right as the user proceeds through the wizard, she builds up a mental model of the currently visible page sitting alongside the other form pages, and moving to the next page merely advances the viewing area to the next page in the list. There are cases, however, where you must bend the rules of physicality for the purposes of comprehension. Many screen elements are visually complex—panels contain many controls, diagrams contain many shapes and colors, lists contain a variety of complex content. As a result, literally moving or resizing them as-is may appear visually disturbing and confusing; too much is going on at once for users to process (not to mention that from a technical perspective this may be difficult to achieve without adversely affecting performance). To fix this, employ animation proxies in place of the object itself during the transition. Adobe Connect, for example, fades out the content of panels before rearranging them when the user switches layouts. Although it is acceptable to temporarily simplify the object during the transition, it must still retain enough of its visual characteristics to be recognizable as the same object. Otherwise you risk sending the wrong message to the user. Physicality must always be in the service of aiding comprehension; if it gets in the way of understanding the interface, understandability should win out. Employ proxies during animations for visually complex objects. Figure 8. Adobe Acrobat Connect employs proxies when animating pods. Notice how the contents of each pod fades out before the pod moves and resizes, then fades back in at the new size. Click play to see this example When employing a physical metaphor, some state transitions may contain many shifting objects, resulting in quite a bit of movement in a short amount of time. All this motion occurring in parallel risks overwhelming the user, which can be worse than an abrupt screen shift. To avoid this, sequence the movement in a state transition into logical chunks that overlap only slightly if at all. Each section of the sequence should express one concept only. For example, if the user deletes several items from a list, fade out the items first, then slide the remaining items up to occupy their former space. If a screen transition involves rearranging some panels in the layout and introducing some new panels, move the existing panels first, and then fade in the new ones. Sequence the movement in state transitions into logical chunks that overlap only slightly if at all. Figure 9. Adobe Media Player uses sequenced transitions throughout its user interface. Notice how the left panel contents fade out, then the videos move, and finally the right panel contents fade in. Each motion overlaps slightly but the overall transition is sequenced in a way that makes it understandable. Click play to see this example You can also sequence your state transitions to help the user understand how to complete their task. For example, if a user will generally want to enter information in a set of panels in sequence, introduce them to the layout in this same sequence to reinforce this ordering.

Effects—motion that emphasizes

Animated effects draw users' attention to objects of particular importance. This section describes some common ways to employ effects. The most direct use of effects is to emphasize an item that has unusual permanent or temporary importance that the user may not otherwise notice. A default button or other control may glow to draw the user's attention to it as the next step in their task. A piece of content that has appeared, disappeared, or changed due to some user action may use an effect to indicate this change. For example, an instant messaging application may use subtle effects to draw the user's attention when a person on their IM list has logged in, logged out, or messaged them.

6 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

Use effects to emphasize an item that has unusual permanent or temporary importance that the user may not otherwise notice. Figure 10. The Converse shoe configurator uses effects to indicate to the user what his next action should be. When the user has selected all the colors for his shoe, the next bar in the accordion control glows to indicate he should click on it to proceed to the next step in the task. Click play to see this example. Most other uses of effects are special cases of this one. For example, some elements of the interface may need to express the progress of an asynchronous operation, such as loading a video stream. This operation may play an animated effect to indicate it is still ongoing. The effect may be on some decoration of the content, such as a spinning wheel or progress bar, or it may be on the content itself. The merging of the loading progress bar with the video time bar is one such example; the behavior of interlaced images on the web that load progressively higher-resolution versions as more information is downloaded is another.

Figure 11. Many video players, such as the one in Adobe Media Player above, express the progress of the video load by filling up the background of the play bar with a lighter color. This helps the user understand how much of the video remains to load and how much he can view without waiting. Transient notifiers, a replacement for the intrusive dialog boxes we discouraged in Designing for Flex - Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) , commonly employ a subtle fade effect when they appear and disappear. Transient notifiers provide or emphasize small bits of information to users, then fade out over time. This information may notify the user of the result of some background activity, such as the receipt of new e-mail or a new instant message. It may also provide modeless feedback of the result of some operation the user performed. Use transient notifiers to unobtrusively present small bits of temporarily important information. System-triggered notifiers that draw users' attention away from their current task must be carefully designed and sparingly applied. If the user finds the information provided by a system-triggered notifier interesting and relevant, they will find the modeless tip useful yet nonintrusive. However, if the information is not interesting or appears too frequently, the notifier can quickly become irritating and annoying. Only draw the user's attention when you are sure the content you are presenting is something she wants to see. The bubble notifier in Windows was a nice

7 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

idea in theory, but its overuse by programs that felt the need to provide users with irrelevant information (such as Microsoft's own "Would you like us to clean up your desktop icons for you?" message) rendered it more of an irritation than a convenience. System-triggered notifiers are like fats and oils—use them sparingly. Use system-triggered notifiers sparingly. Figure 12a. iChat makes good use of a system-triggered notifier when alerting users when someone has instant messaged them. Since most people who have iChat open want to know when they are messaged, having the bubble animate in the upper-left corner of the screen is not unwanted intrusion. Moreover, the bubble is small and easily ignored if the user is embroiled in another task she does not wish to interrupt. Click play to see this example.

Figure 12b. Flash Player used to notify users of new updates using the Windows bubble notifier. Although well-intentioned, this annoyed many users by popping up too frequently and at times when the intrusion was not wanted. Unlike receiving an instant message, updating a software application is not as relevant to users' goals and thus must tread more carefully with system-triggered notifications. To learn more, stay tuned for the next part of the series, Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) , which will be available soon. 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.

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

8 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 6: Guiding wi...

http://www.adobe.com/devnet/flex/articles/fig_pt6_print.html

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

9 of 9

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Flex Article Designing for Flex – Part 7: Making your application fast Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com If you were hoping this chapter would delve into technical details on performance tuning in Flex, my apologies to disappoint you. Although I will discuss some design techniques for improving the responsiveness of networked Flex applications, this chapter primarily focuses on efficiency of use, or giving users a faster and more productive experience overall. There are several aspects of applications that can lead to reductions in user productivity. One of them is certainly application sluggishness; if users have to wait for disks to spin and algorithms to crunch and networks to pipe bits back and forth for too long, it breaks their concentration and interferes with their goals. However, when users must re-enter information they provided previously or provide data the application could have figured out on its own, this also negatively impacts the user's perception of the application's performance. Depending on the situation, it may be acceptable to wait an extra second or two for the application to load if it means spending less time performing rote tasks once it does. When determining how to make your application faster, you must first consider how best to speed up the user, and only speed up the system if that is truly the most important barrier to productivity. (For example, a user researcher friend of mine once interviewed users of one of our applications asking which performance problems irritated them the most, expecting to hear about sluggish operations and spinning hourglass cursors. To his surprise many of the responses he received did not complain about system performance, but about how it took them too many steps to complete frequent tasks!) This chapter covers: How to eliminate unnecessary steps from common user tasks. How to find ways to automate repetitive tasks and remember information. How to give users a head start by providing good application starting points. How to improve your application's responsiveness by focusing on the parts that make the biggest difference to users. How to manage user expectations for operations that are necessarily time consuming. The Designing for Flex series includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html)

1 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) I suggest that you read the previous parts before proceeding with this part of the series. This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

Eliminating work

Computers are really good at two things: remembering things and performing computations. When connected to other computers, they become good at discovering what these other computers know. Most humans are very bad at all three of these tasks. Useful applications let computers do what they're good at: eliminating work for users. Use the impeccable memory and powerful processing abilities of computers to eliminate work for your users. There are three primary ways to eliminate work: by cutting unnecessary steps out of the common tasks your users perform, by automating steps so that they are handled behind the scenes by the system, and by inferring an intelligent starting point for your application based on the context of the user's arrival. Shortening tasks One of the most straightforward ways of eliminating work is to take a good, hard look at the tasks users perform with your application and mercilessly slice out any unnecessary steps. But if this is so easy, why are overly-long task flows so common in modern software? There are a variety of reasons. First off, the designers and developers of the system may not have understood exactly what users would do with their application and what the common workflows would be. If you did your homework by outlining the key user tasks as described in Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) and optimizing your application's design around them you should already have a huge leg up over these folks. Understanding your users' true tasks, both before you design and after your application has been released into the world, is the best way to know where to focus your efforts when designing and redesigning your Flex application. (Conducting sound user research instead of relying on guesswork, however educated, becomes more and more important as your application evolves. If you only informally chat with a handful of users, you risk designing your application around outlier workflows and missing the mark for the majority of your customers.) Discover your users
real tasks to better understand what flows you must make more efficient.

Figure 1. This diagram of the hypothetical bill pay system from Part 2 (www.adobe.com/devnet/flex/articles/fig_pt2.html) demonstrates how a redesigned task flow can greatly improve user efficiency by eliminating unnecessary steps from a process. Sometimes, unfortunately, tasks are made unnecessarily complex intentionally, not because of mere oversight. The least forgivable of these involve inserting steps manufactured by the system's designers, such as needless confirmation dialog boxes or pop-ups that do nothing other than report normal operation ("The network

2 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

connection has been re-established. Ok?"). Never bother the user with information or questions that have nothing to do with accomplishing their current goal unless the consequences are truly dire and require her immediate attention. These consequences occur much less often than many application designers and developers seem to believe.

Figure 2. Adobe's CS3 updater tosses up many classic examples of pointless dialogs. Many users may wish to approve updates to Adobe Photoshop, Adobe Illustrator, Adobe Dreamweaver, etc., but to pester the user to update the updater itself?! Joseph Heller would be proud. Another source of manufactured work comes from organizational flaws rather than technical ones. Sometimes, for business or marketing reasons, applications demand unnecessary information from their users. No matter how important this data is, it's not worth degrading the user experience. As mentioned in Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) , if this data really is important, make it optional but offer an incentive for users to provide it. (The design team for a major website was once trying to find ways to reduce drop offs during the user registration process. They found the biggest offender was their long and elaborate registration form that demanded to know just about everything about the user short of his dating history. When they contacted marketing to determine how they could pare this down, they found to their horror that no one was even using this information anymore; it only existed to waste users' time and caused a loss of business for the website.) Never bother your users with information or questions that have nothing to do with accomplishing their goals.

3 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Figure 3. This registration form from Adobe.com clearly marks which fields are required and which are optional, simplifying the registration process. The form could be further improved by making more fields optional (does Adobe really need to know my city and country?) and by separating optional information into a separate section that follows the required information.

Automating work

Instead of manufacturing demands for the users' attention, focus on employing the impeccable memory and computational power of computers to relieve such demands. Users provide lots of information during the course of using computers, and unfortunately many applications are terribly forgetful. If the user provides a Flex application with his address, the application should not have to ask for it ever again. If the user has been working with a document for the past three days, he shouldn't have to hunt through the file system every time he wants to open it; the application should remember and provide an easy way to open this recently accessed document. Never require users to reenter information they already provided.

4 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Figure 4a. Amazon.com remembers shipping addresses and payment information so that users don't have to re-enter this data every time they make a new purchase. This is one of the most common examples of application memory in action on the web.

5 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Figure 4b. Adobe Fireworks CS3 displays a list of recently-opened documents on its welcome screen so that users can easily open a document they've worked on in the recent past. This is a common example of application memory in desktop software.

Figure 4c. Adobe Dreamweaver, along with most other Adobe applications, remembers changes users make to the default workspace layout (such as opening and moving panels) and automatically persists them even when the application is closed and reopened. Dreamweaver's application memory is detailed and expansive, which allows its users to spend less time configuring the application and more time working on their web pages. Flex applications are almost always connected to the Internet, which opens up whole new opportunities for eliminating work for the user. Unlike traditional desktop applications they are not limited to remembering the information the user himself provided, but are also capable of reaching out to other Internet services and retrieving

6 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

information on the user's behalf. They can retrieve difficult-to-remember numerical information such as ZIP codes or ISBNs from web services using the addresses and book titles, so users need no longer bother with the ID numbers. If the user wants to have a photo professionally printed, the application can simply determine the nearest print shop with the best deal itself and not make the user do this legwork.

Figure 5. Firefox's Internet search bar has an auto-complete feature that not only remembers its user's previous searches (the terms above the line) but also presents common search terms that other people have entered into Google. This helps users enter search terms faster and more accurately even if they themselves never performed this search before. Finally, many applications can eliminate work by accepting more flexible input formats and performing other computation tasks for the user's benefit. A common example is in input form fields; far too many applications are rigid in which types of input they accept. If the address isn't in precisely the format the system expects, that's an error the user must deal with. If the user dares to use a dash to separate the area code in a telephone number instead of parentheses... bam, error. Good Flex applications are flexible about user input. If users enter phone numbers in several different ways, the application can be smart enough to figure it out. Of course, if the user enters "asdf" instead of a phone number the application may not be able to do much with that, but how many users will do this? Far fewer than will try "415.555.1234" instead of "(415)555-1234". (Note: Many of Google's applications excel at this, and it's one of the reasons for their success. You can enter just about any reasonable string that represents a location into Google Maps and it will come back with the right map.) Be flexible about the input formats your application accepts.

7 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Figure 6. Although primarily intended for plotting street addresses, Google Maps is very flexible in the input it accepts. Here, I typed "hotels in sf" and Google Maps found a list of hotels in the city and plotted their location on the map for me. The application is smart enough to accept alternate formats for this input, so "hotels near sf" or "sf hotels" works just as well. The most common objection to automating work to speed up the user is that the application won't always be correct. Don't worry about always being correct. Users can correct occasional mistakes if the application clearly states when it had to make a guess and offers an opportunity for correction. Instead of worrying about correctness, consider whether the system is saving the user time by providing a "good enough" starting point, or whether the user must spend more time second-guessing the system than it would take them to perform the task on their own. You'd be surprised how often automation saves time even when it isn't infallible. Automate tasks whenever it will save users' time, but always allow them to verify and correct system mistakes.

Providing starting points

A common special case of eliminating work involves providing intelligent starting points. In the old days, most applications made no assumptions about what users would do with them when the application first opened. The first launch and every subsequent one was a blank slate, and it was up to users to repeatedly navigate to those sections of the application they frequently used. Good Flex applications are smarter than this, and start the user off

8 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

right where he wants to be. (Sometimes this is referred to as "personalization," but I dislike that term. It sounds too much like the ever-present "Welcome, Rob!" message on the top of the home screen, as if that's supposed to make the application feel all warm and personal even though it stubbornly forgets everything I've done with it since I used it last.) Second use starting points are often more straightforward to design and implement than first use ones. The most common approach is to follow a "last state" strategy; if the user returns to the application it should start out in the state that he left it in. This has a couple of benefits. First off, for many domains the thing the user was doing last is very likely where he'll want to pick up when he returns. Second, it mimics the behavior of physical objects, most of which remain in the state they were left in unless someone else modifies them. As discussed in Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) , mimicking physical objects can help users understand interfaces intuitively, so last state behavior tends to make sense to users.

Figure 7. iGoogle, Google's customizable homepage, employs a last state strategy. Every time a user returns to iGoogle it is in exactly the state she left it in; the same widgets in the same locations and configurations. This behavior feels very straightforward to users; so much so that most don't even notice the application is working behind the scenes to remember their actions. Unfortunately last state strategies don't work well all the time. If I already purchased a product from an online store it's unlikely I want to go back to that product page the next time (though I may wish to return to my order to make corrections or check the shipping estimate). They also rarely work for first use starting points, since if the user has never used the application before it has no information on where he's been. Yet first impressions are lasting ones, so you still don't want to force the user to do a lot of navigation before locating the parts of your Flex app that interest him. What, then, can you do? Instead of relying on past behavior, you must examine the context of the new user's arrival and see if you can infer anything from this context. For example, good calendaring applications don't plop the user down at January 1st, 1970; they start at "today," which they can easily determine by looking at the system's clock. Good mapping applications don't start out with a huge map of the United States. They zoom in on the city the user lives in since most likely his desired destination lies there. (Notice it's possible to get too personal. Most mapping applications shouldn't start out by showing the user his own house since he likely already knows the area around where he

9 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

lives.) Good online stores recognize when a user has come from a search engine and use the search terms to immediately show relevant products. Offer users sensible starting points by remembering the state they left your application in or by inferring an appropriate starting point from their context.

Figure 8. Google infers the user's language based on the country his IP address originates from. Thus if a Japanese user accesses Google, he immediately receives the Japanese language version of the website without having to view an English website and figure out how to switch his locale. Unfortunately, the current web environment is rather poor in context when a new user arrives with no pre-existing account. This will need to change for the experiences of the future to become reality, but in the meantime leverage the context you do have to tailor your users' starting points to fit their goals.

Improving responsiveness

Sometimes applications are structured well—they focus on eliminating work and provide excellent starting points based on their users' goals and tasks—yet they fall down on more traditional efficiency concerns; the application is just too slow. Heavily-networked Flex applications can easily fall into this trap, for the Internet is a notoriously unreliable beast. This section focuses on how users' perceptions of performance impact their experience of using applications and how that should affect where you spend your design and development efforts. When tuning application performance, focus on the functions where the actual speed is most at odds with what users expect the speed to be. Absolute performance metrics have no meaning when divorced from the context of user expectations; an O(n2) algorithm or a 10-second response time might be completely fine or unacceptably slow depending on how long the application's users expect the operation to take. There are three distinct kinds of operations with very different associated levels of expected performance: physical changes, screen loads, and big jobs. Physical changes are operations that appear to the user to be mere manipulations of interface objects. These should appear near instantaneous to users. Examples include dragging and dropping a photo from one list to

10 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

another, expanding a closed branch of a tree control, changing the filter criteria of a list, and getting the highlight feedback when hovering over a button. A good rule of thumb is: if a browser page refresh would be undesirable between one state and the next, necessitating the use of AJAX or Flex in a browser-based application, then you're probably dealing with a physical change.

Figure 9a. Most state changes to standard controls are examples of physical changes, such as moving from the up state of a button to the down state when the user presses on it.

Figure 9b. Drag and drop is another example of a physical change, since the user physically moves the object from one location to another. Screen loads occur when the user first navigates to the application or when she moves to a completely different section (which should only occur when she begins work towards a new goal, see Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) ). Screen loads usually need not be instantaneous, but they should take less than 10 seconds. The more time you take between one second and ten, the more motivation your users need to have to wait it out. If you structured your application well, users will be starting a new task whenever a screen load occurs, so a moment's wait is acceptable. An example of a screen load is when a user moves from the online bill pay system of a banking site to the investment services system.

Figure 10. Flektor performs a screen load after the user selects a quick start. When the user clicks any of the quick start options, the loading screen appears, then Flektor transitions to the screen with the appropriate quick start feature.

11 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Big jobs are long-running operations that users expect to take some time. Users request them infrequently and often only after much preparation. Big jobs can get away with taking longer than 10 seconds, especially if the user can run them in the background while getting other work done. Examples include report generation and aggregation of search results from multiple websites. Note that user expectations of what should take a long time change; it used to take hours to compile program code, nowadays it must take no more than a few seconds.

Figure 11. Backup operations are a good example of a big job. Users carefully prepare for them, run them infrequently, and expect them to take a long time. Note that these types of operations run from high performance expectations to low. This implies that when seeking to improve responsiveness, you should start by examining the little physical changes in your application rather than the complex, long-running algorithms. Focus performance tuning efforts on those portions of the application where the actual speed of operations is most at odds with user expectations. Improving the responsiveness of physical changes usually means lots of caching. Slow network loads and complex calculations must not occur at the moment of physical change but at a time when speed is less important. There are two basic options: take the performance hit when the screen loads or run the operation in the background while the user is preoccupied with less performance-intensive tasks. The latter is particularly attractive as it allows you to perform time-intensive tasks without the user realizing anything is happening. Both of these strategies suffer from a single barrier; you must anticipate what the user is going to do if you are to preload or precompute it for her. But this may not be as difficult as imagination makes it out to be. Oftentimes there are only a few commands users are likely to issue or content they are likely to view. If in doubt, consider computing everything and simply discarding any results that turn out to be unnecessary. Processors are already blindingly fast and networks are getting faster; both spend most of their time idle, ironically waiting until just the moment results are needed—when the user makes a request—before springing into action. By this time it may be too late to satisfy the user's performance expectations.

12 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Pre-compute results while the application is idle and cache results to speed up future operations. Sometimes, precomputing or preloading data is not an option; if your Flex application lets users search a large database, there may be little you can do until some search parameters are available since the database may be way too big to preload in its entirety. If the task will take more than a second, consider whether it can be broken down into smaller pieces to make it seem shorter to the user. For example, load and display search results bit by bit as they become available; the user can only deal with one screenful at a time anyway. You can employ this strategy to great effect with all kinds of otherwise sluggish physical changes. Break down long tasks into smaller bits so that the results can be presented to the user as they become available. Whenever possible, leverage the asynchronous nature of the Flash Player and the Internet itself to perform slow operations in the background while the user does other things such as viewing content and thinking. Although there may be times when you or your developers will need to break out the old algorithm performance analysis book, most performance gains in Flex applications come not from actually making things faster, but by moving work around so that the application feels faster to the user.

Managing expectations

In a perfect world, no operation would ever take longer than 0.2 seconds, the threshold beneath which humans notice no delay. Unfortunately, this isn't always the case. Physical changes must be measured in sub-second time increments, but screen loads and big jobs may take much longer. How can we manage the expectations of waiting users to ensure they don't become frustrated with our Flex application? Appropriate feedback for the nature of the job and the length of the load is the answer. For operations that take less than a second, no special feedback is necessary; except for low-level mechanical physical changes such as a button's response to a mouse click, this is below the level at which users expect a response. Operations that take longer than a second but less than ten seconds must provide feedback that something is happening or the user may not realize the application is processing his request. Sometimes applications use a spinning hourglass cursor, sometimes an animated loading graphic is more appropriate. Either way, the purpose is to reassure the user that the application is making progress and will be with them shortly. (Be careful of using slow-moving animations to indicate loading status. Slow motion is equated to slow loads in users' minds, so even if a screen load is fairly snappy when measured in seconds it may feel much slower because of the sluggish-seeming speed of the motion.)

13 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

Figure 12. Spinners, such as this one from the Facebook game Scrabulous, give a generic indication that progress is happening and are appropriate for short operations that take less than ten seconds. If an operation must take longer than 10 seconds, the application must do more than merely indicate that something is happening. The user now needs to know how long the application expects her to wait. Progress bars are a common control for providing this sort of feedback, although they have a mixed track record of accuracy. Your prediction must be sufficiently accurate for the user to make decisions on what she should do in the meantime: should she sit and wait? Go write some e-mail? Take a coffee break? Go home early because this thing won't be done until tomorrow morning at best? Sometimes, in addition to a time estimate the application can provide details on what it is doing at the moment as part of the progress indication. This is only appropriate if these details are meaningful to the user and not technical minutiae. If the application is currently searching for flights from Austrian Airlines, that might be interesting, but if it's computing bezier curves for embedded SVG graphics, that is both boring and intimidating to most users and the application should keep it to itself. Use an appropriate feedback mechanism for long operations based on the nature of the job and the expected length of time the job will take.

Figure 13. Progress bars, such as this one in the Adobe Media Player installer, are a popular control for informing the user how long a big job is going to run. Notice that this installer includes a Cancel button - all big jobs should offer a functional cancel command in case the user runs the job by accident or changes her mind after

14 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

starting it.

Figure 14. Kayak, the web airfare aggregator, displays a progress bar while it searches websites for the lowest airfares but also displays lots of additional information on the sites it is searching and the results it has found so far. In this case, these additional details are useful and relevant to the users' goals, so displaying them is helpful and not intimidating. Any operation that takes longer than 10 seconds must allow the user to cancel it. The user may have mistakenly invoked the operation, or even if he intended to invoke it, he may change his mind after realizing how long the operation is going to take. A button labeled "Cancel" that aborts the operation with no undesirable side effects allows him to quickly correct the mistake. Systems that do not provide such a button (or that do nothing when the button is pressed) prove highly frustrating to users who must sit at their desks and tap their feet, waiting impatiently for the system to catch up to them. Big jobs should usually be asynchronous. The user should be able to go back and check on the operation's progress, but the wait won't seem as long if he is able to continue to use the application to perform other work while the big job chunks away in the background.

Figure 15. Flex Builder makes a big job asynchronous when compiling a large project. Users may continue to

15 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 7: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt7_print.html

work with the application while their code is compiling; in the bottom right corner a little progress indicator appears to keep them informed of the progress of the big job. Providing appropriate feedback can be an effective technique, but it should be the last resort when attempting to speed up an application. Users will forgive you if the occasional big job takes awhile to run if the application is an efficient pleasure to use in all other respects. But if the dreaded spinning hourglass pops up every time users click on something, don't expect to win many kudos from them. Provide wait feedback only as a last resort. To learn more, stay tuned for the next part of the series, Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) . This content is a public draft. Please give us feedback in the Flex Interface Guide Forum (www.adobe.com/go/fig_feedback) .

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.

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

16 of 16

3/3/08 10:53 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

Flex Article Designing for Flex – Part 8: Making your application safe Rob Adams Adobe (www.adobe.comhttp://www.adobe.com) www.usereccentric.com When many people discuss application safety they think of security, and security is an important part of the picture. Fundamentally, however, making your application feel safe to users means making them feel in control. Ensure that your users understand what the system is doing; every time they must make a decision, ensure they understand what the full consequences of that decision will be while there's still time to change it. Applications that communicate clearly and forgive mistakes empower users to boldly try new things and are not just safer for them to use but easier for them to learn as well, since most users learn new applications by trial and error, not by reading pages and pages of documentation. But as anyone who has lost hours or even days worth of work to an application malfunction or a poorly marked destructive operation can attest, applications that are careless with data and unforgiving of slips and mistakes break users' trust, and many never regain it. This article primarily discusses applications that are not safety-critical in the grand scheme of things. Although losing all the work a user created for the past few hours is extremely frustrating and unproductive and sending an e-mail to many unintended recipients can be quite embarrassing, these scenarios pale in comparison to situations in which people can lose their lives or become permanently disabled due to application safety failures, situations that often arise in medical device design, aircraft control systems, and other safety-critical domains. If you are working a safety-critical application, many of the principles discussed here as well as numerous others become even more critically important, and the priority of proper user and system testing changes from "we'll do the best we can" to "this product will not ship until we have absolute certainty it won't kill anybody." Read this article… but don't let it stand in for a rigorous process for designing safety-critical hardware and software systems. This article covers: How to protect your users' data by implementing continuous save How to forgive user mistakes by providing undo and cancel operations How to make users aware of the consequences of irreversible actions by providing appropriately prominent feedback How to keep your application secure through appropriately implemented security mechanisms. This is the last part in the Designing for Flex series, which includes the following articles:

Part 1: Overview and discovering Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) Part 2: Planning your application (www.adobe.com/devnet/flex/articles/fig_pt2.html) Part 3: Structuring your application (www.adobe.com/devnet/flex/articles/fig_pt3.html) Part 4: Merging the web and the desktop (www.adobe.com/devnet/flex/articles/fig_pt4.html) Part 5: Designing content displays (www.adobe.com/devnet/flex/articles/fig_pt5.html) Part 6: Guiding with motion (www.adobe.com/devnet/flex/articles/fig_pt6.html) Part 7: Making your application fast (www.adobe.com/devnet/flex/articles/fig_pt7.html) Part 8: Making your application safe (www.adobe.com/devnet/flex/articles/fig_pt8.html) Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html)

1 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) I suggest that you read the previous parts before proceeding with this part of the series. This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.

Never lose data

This is the first rule of application safety. Nothing frustrates users and destroys their productivity and their morale more than losing hours of work because of some stupid software mistake. It hardly matters whether the mistake was due to a technical glitch in the system's intended functionality or because the application intentionally failed to take proper precautions. Lost data is lost data, and it should never, ever happen. Never lose your users
data. Unlike traditional desktop applications, Flex applications are usually connected to the network. This has significant implications for one standard software idiom—the Save operation. "Save" has never made much sense from the user's perspective; the distinction between working memory and permanent storage was an implementation detail that never should have been exposed. But the web environment introduces new complexities. First, documents might need to be saved to the server, an environment the user is unfamiliar with. Second, the fickleness of network connections may cause the client/server communication to get cut off unexpectedly; users need to feel assured that they won't lose their work if this happens. Fortunately, there is a simple solution that sidesteps these problems. Instead of requiring users to explicitly save their work, always implement continuous save. Always provide continuous save.

Figure 1. Gmail continuously auto-saves drafts of the user's e-mail messages as he or she types. If the user's browser crashes or session times out, the user loses very little of his/her work. Note the "Draft autosaved" message next to the Send/Saved/Discard buttons.

2 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

Continuous save eliminates the notion of a user-initiated "save" operation that commits the contents of working memory to disk. Instead, the application manages the permanent storage medium for the user, whether that medium is the hard disk or some server location. From the user's perspective, he is just working, and if he leaves the application and returns, his work is still there in the state he left it in. This is how things work in the physical world, which doesn't have a concept of working memory and permanent storage mediums for such creative tasks as carpentry, automotive repair, and ink-and-paper writing. The most common objection to continuous save is "What if the user doesn't want to save his changes? What if he is just fooling around and doesn't want his changes to affect the file?" This is easy to solve. When the user opens a document for editing, make a backup copy on the permanent storage medium. Then provide a "Revert" operation that returns the file to its pre-opened state. Which do you do more often: save files or close them without saving? If you're like most people, you almost always want your work to be saved and only occasionally wish to discard it. Thus, it makes much more sense to have an explicit operation for discarding rather than saving. (More details on replacing the "save" operation are available in About Face 2, listed in Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) .) Continuous save has two huge benefits. First, it prevents the user from accidentally forgetting to press the save button and losing his work. This can be a particularly insidious problem with systems that log the user out after a certain amount of inactivity, which isn't uncommon among Flex applications. Second, it minimizes loss of work when the application crashes. Applications should never crash, but they do, so you must plan for this contingency. If a crash occurs, a Flex application should restore itself to the exact location the user was at before the crash, with as much of the user's data pre-loaded into the screen as is available. Crashes could occur at any time and the Internet is notoriously unreliable. Moreover, due to bandwidth concerns, it may be impractical to constantly stream data to the server every time the user presses a key. Continuous save shouldn't fully rely on network connection availability. Instead, your application should store data in Flash Player's Local Shared Objects or in disk files if targeting the Adobe AIR client between network operations. This behavior must be invisible to the user; from his perspective, he should simply be working on his data, secure in the knowledge that your Flex application is carefully guarding everything he sends its way.

Forgive errors

Application failures are only one way that safety failures can happen. The other is often called "user error," which is a misnomer since often the fault lies with a poorly designed application, not the user. Well-designed Flex applications are forgiving of user mistakes and smart enough to prevent safety failures even if the user appears to be requesting them. This section describes how. The most important safety feature of any application is "undo." A properly implemented undo instantly forgives any mistake, using the computer's powerful memory to immediately revert things back to the way they were before the problem occurred. Undo makes users confident that they can explore the application and try out unknown functionality; if something they didn't desire or expect happens, they can always select the undo option. All applications should provide some means of undoing mistaken operations.

Figure 2a. In desktop applications like Adobe Fireworks, the Undo and Redo operations are standard menu items that appear in the Edit menu. Most desktop tools include this feature; users sorely miss it when it is lacking.

3 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

Figure 2b. Sadly, Undo is a feature that is missing from most web applications. Fortunately, this is changing; Gmail supports a single level of undo that appears as a link next to the orange notification message that appears after an operation has completed. However, it isn't always clear how to expose the undo operation to users in a Flex application. In the desktop world, undo is usually the first item in the "edit" menu. For Flex applications that contain menus this works well, but not all do; generally these are limited to creation-focused applications or sufficiently complex information-focused applications. Other information-focused or simpler creation-focused applications should provide an always-available button in the primary control bar. Task-focused applications, on the other hand, should generally think of undo as "cancel." All completed tasks should be represented in the application and should have an associated operation to cancel their effects for as long as this as possible. If this is no longer possible, for instance if an order has already shipped, the cancel command should provide information on what options, if any, remain to the user. Tasks that must be canceled before a certain time limit must clearly communicate to the user how long he has to change his mind after he completes his task. Forgive user mistakes by allowing the user to back out of them later using undo or cancel.

4 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

Figure 3. ETrade's bill pay system allows users to view a list of pending payments and cancel payments they no longer wish to send out. In task-focused designs like this, cancellation often takes the place of undo. (Note: This design was modified slightly to remove sensitive information.)

Clearly communicate consequences

Many of the more popular desktop and web applications provide reasonable facilities for protecting users' data and forgiving errors. However, there are very few shining examples of the third aspect of application safety: clear feedback. Most applications don't do enough to help users understand the consequences of potentially unsafe actions before it's too late. For example, web browsers generally have secure and insecure communication modes. When users switch between these modes, the only feedback they receive is a tiny lock icon that appears down in the status bar. Very few users see this feedback, yet it is one of the most important pieces of information; users want to feel confident that the sensitive information they're sending to the website won't be potentially exposed to criminals. A much clearer way to present the security status would be to modify the form elements themselves or perhaps even the entire browser window, making the insecure and secure modes highly and visually distinct. Most e-mail clients also fail to clearly communicate the consequences of a frequent user mistake. Many have been burned by accidentally hitting the "reply all" button instead of sending a message just to the author. Yet they can hardly be blamed; the message destination appears only as e-mail addresses on the "To" field. Yet most users head straight for the subject or body, since their immediate goal is to get that message written. Since sending messages to the wrong recipients can be embarrassing for users, e-mail applications should communicate the recipients more prominently; the message environment should actually look different when a message is sent to all recipients than it does when only the author is to receive the message. E-mail clients that are tied into corporate e-mail systems, such as Outlook, could go even further and distinguish messages sent to distribution lists from messages sent to individuals.

Figure 4. Buzzword takes a step in the right direction with its document sharing interface. Users must explicitly specify who has access to their document by providing e-mail addresses, and the names of each person always

5 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

appears in the bar down at the bottom. This makes it much clearer who has access to the currently open document. Good Flex applications should consider the safety of the operations they provide, especially if those operations are not reversible, such as a user sending his/her credit card information over an insecure connection or an e-mail to a wide list of recipients. Ensure that the consequences of potentially unsafe actions are prominently displayed, not hidden away in small icons on the edges of the screen. Provide feedback appropriate to the severity of the consequences of a user action.

Security and passwords

Security is an important consideration for any software application, especially networked Flex applications, but unfortunately interfaces designed solely for security often make the application more difficult to use. Ironically, this frequently makes the application less secure as well. Users are quite good at circumventing security "features" that get in their way. Passwords are one of the top offenders; security-minded designers and developers force passwords on users routinely, only to find rampant use of weak passwords, passwords written on sticky notes attached to monitors, or the same password used for multiple different websites. Forcing users to enter strong passwords only exacerbates the problem. Many systems that require passwords don't really need the security they afford. Many websites have password retrieval systems that allow the user to enter, say, his mother's maiden name or the answer to some other difficult-to-guess question. If the security question is there in case the user forgets his password and it's so much easier to remember than the password itself, why not just use the security question instead of having a password at all? For many applications this would be quite sufficient, much easier for the user, and no less secure than having a password-plus-security-retrieval-question system. Avoid unnecessarily draconian security measures.

6 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

Figure 5. The Interaction Design Association's website employs an innovative password-free login mechanism. Instead of requiring visitors to register, which may be a significant barrier for those who only wish to participate in a discussion forum, the website asks for the user's name and e-mail address. It then sends a confirmation e-mail containing a link for the user to click on and confirm his identity. Once this is done, a browser cookie ensures the process need not be repeated on the user's machine. Although clearly not appropriate for all websites, this mechanism eliminates the hassle of registration and password memorization while still providing adequate security for the users' needs. Instead of forcing obscure security technologies down users' throats, clearly communicate the consequences of user actions as discussed in the previous section. If an operation has security implications, make those implications clear. For instance, consider a system that allows users to make files publicly accessible through a network by selecting a check box on a form, an operation that does not clearly communicate the consequences of the action. A better approach would be to define a distinct public space where users can move their files to make them available to others. This space should be visually distinct from normal private spaces to communicate its function to users. Improve usability and security by providing adequate feedback on the consequences of user actions while there is still time to change them.

Conclusion

This concludes the Designing for Flex article series. By now you are well-versed in the key topics of Flex RIA design, from planning and user research to structural design/information architecture to detailed visual and interaction design. Over the course of the article series, I have distilled a number of design best practices which are collected together in Appendix A: List of best practices (www.adobe.com/devnet/flex/articles/fig_appendixa.html) . Use this list to remind you of the best practices while designing your application or to validate your existing application or proposed design. Although the articles in this series have covered the design principles and practices most relevant to Flex RIA design, the field of design is much larger than could possibly be surveyed here. Appendix B: For further reading (www.adobe.com/devnet/flex/articles/fig_appendixb.html) contains a list of books and web sites that offer more information about design best practices that go beyond the focus of this series. All of them are good next steps if you wish to further your knowledge of application design. The field of RIA design is still young. Although the best practices espoused in this series are based on design knowledge developed in other mediums and Adobe's experience designing RIAs, we as a profession do not yet know enough to offer comprehensive guidance. As a result, some of the best practices may evolve, new ones may be added, and old ones may turn out not to apply. This is both a challenging and an exciting time to be an RIA designer; there are still many discoveries yet to be made. As you make your own discoveries, share them with us through the Flex Interface Guide Forum or the Send feedback (www.adobe.com/cfusion/mmform/index.cfm?name=brc_tutorial_feedback) link in the sidebar of these articles. We are always interested to hear about new challenges and solutions in real-world Flex applications. Best of luck with your next great Flex application!

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

7 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Part 8: Making you...

http://www.adobe.com/devnet/flex/articles/fig_pt8_print.html

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.

This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with.

Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

8 of 8

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Appendix A: Best ...

http://www.adobe.com/devnet/flex/articles/fig_appendixa.html

Flex Article Designing for Flex – Appendix A: Best practices This list of best practices was written for the Designing for Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) series. To learn more about designing rich Internet applications and rich desktop applications, check out the Flex Interface Guide (www.adobe.com/devnet/flex/?navID=fig) on the Flex Developer Center.

Planning your application

Understand your market demographics, but recognize this isn
t sufficient information to guide design alone. Understand your users
goals as they relate to your product. Study the tools and artifacts your users use or produce today. Document tasks your users perform today to accomplish their goals List the types of content your users will access in your application and obtain real samples for reference. Write scenarios to represent the primary tasks users must perform with your application.

Structuring your application

Employ information structures when your users
primary goals involve browsing, comparing, or comprehending different pieces of information. Employ process structures when your users
primary goals involve providing information in an efficient, straightforward, and structured manner. Employ creation structures when your users
primary goals involve creating entirely new content or making significant changes to existing content. Eliminate unnecessary navigation in your applications. Only use page-to-page transitions when the user is pursuing a clearly different goal. Use intra-screen changes to modify the screen as the user advances through tasks that are related to the same goal. Illustrate intra-screen changes by supplementing wireframes and comps with storyboards. Prototype key interactions in your application to tune and communicate the feel. Follow a “hub-and-spoke” navigation model, not a hierarchical site map. Design your application
s entry point to present useful tasks or information that clearly relate to your users goals with no interaction required on their part. Immediately present relevant content to your users for an information application
s entry point. Clearly list the tasks your application supports for a process application
s entry point. Provide a way to start with existing work for a creation application
s entry point. Employ sound visual hierarchy to communicate the important elements on the page and to guide the user
s eyes to the next part of their task.

1 of 4

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Appendix A: Best ...

http://www.adobe.com/devnet/flex/articles/fig_appendixa.html

Merging the web and the desktop

Design Flex applications as RIAs first, and desktop or web applications second. Offer a web experience when your application must be accessible from any machine and fully integrated with the web environment. Offer a desktop experience when your application must have a presence on the user
s computer and integrate more seamlessly with the host operating system. Provide URLs that a user can bookmark and back button support for all navigable states. Provide support for low-vision users by offering a version with high contrast colors and larger type and controls. Design sovereign applications to consume more screen real estate and employ more focused interactions and smaller controls. Design transient applications with simple interactions, larger controls, and clearer task flows. Hide the complexity of the file system. Clearly communicate functionality changes caused due to a loss of network connectivity. Avoid spawning windows in desktop applications unless the windows map to disjoint pages.

Designing content displays

Design content displays around questions your users will ask about the content. Design content displays first, then add controls and other application chrome afterwards. Integrate highly related information into a single content display whenever possible. Avoid splitting information across multiple screens or states. Make it easy for users to not just find content, but explore content. Support content exploration by making search and filtering controls instantly responsive to user changes. Favor direct means of manipulating content over indirect ones. Favor modeless feedback integrated with content over modal pop-up dialog boxes. Employ affordances to clarify which items within your content are interactive. Display controls in the context of the content they manipulate. Never re-implement your own controls when a suitable off-the-shelf control is available. Instead, customize the off-the-shelf control to suit your needs.

Guiding with motion

Employ motion to apply physical principles that help users understand the workings of your application. Employ motion to subtly draw users
attention. Use transitions to keep the user informed about where they are, where they have been, and how they get

2 of 4

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Appendix A: Best ...

http://www.adobe.com/devnet/flex/articles/fig_appendixa.html

back. Use effects to draw the user
s attention and provide feedback. Avoid gimmicky or gratuitous motion. Use the motion properties of physical objects to guide your decisions on how your Flex interface elements should move. Employ proxies during animations for visually complex objects. Sequence the movement in state transitions into logical chunks that overlap only slightly if at all. Use effects to emphasize an item that has unusual permanent or temporary importance that the user may not otherwise notice. Use transient notifiers to unobtrusively present small bits of temporarily important information. Use system-triggered notifiers sparingly.

Making your application fast

Use the impeccable memory and powerful processing abilities of computers to eliminate work for your users. Discover your users
real tasks to better understand what flows you must make more efficient. Never bother your users with information or questions that have nothing to do with accomplishing their goals. Never require users to reenter information they already provided. Be flexible about the input formats your application accepts. Automate tasks whenever it will save users time, but always allow them to verify and correct system mistakes. Offer users sensible starting points by remembering the state they left your application in or by inferring an appropriate starting point from their context. Focus performance tuning efforts on those portions of the application where the actual speed of operations is most at odds with user expectations. Pre-compute results while the application is idle and cache results to speed up future operations. Break down long tasks into smaller bits so that the results can be presented to the user as they become available. Use an appropriate feedback mechanism for long operations based on the nature of the job and the expected length of time the job will take. Provide wait feedback only as a last resort.

Making Your Application Safe

Never lose your users' data. Always provide continuous save. Forgive user mistakes by allowing them to back out of them later using undo or cancel. Provide feedback appropriate to the severity of the consequences of a user action.

3 of 4

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Appendix A: Best ...

http://www.adobe.com/devnet/flex/articles/fig_appendixa.html

Avoid unnecessarily draconian security measures. Improve usability and security by providing adequate feedback on the consequences of user actions while there is still time to change them.

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.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with. Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

4 of 4

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Appendix B: For fu...

http://www.adobe.com/devnet/flex/articles/fig_appendixb.html

Flex Article Designing for Flex – Appendix B: For further reading This list of resources was written for the Designing for Flex (www.adobe.com/devnet/flex/articles/fig_pt1.html) series. To learn more about designing rich Internet applications and rich desktop applications, check out the Flex Interface Guide (www.adobe.com/devnet/flex/?navID=fig) on the Flex Developer Center. This article series covered a broad range of topics highly relevant to Flex application design at a fairly high level. Fortunately, few if any of the ideas presented here were new and many are covered extensively in other publications. If you find yourself itching to learn more about a particular topic, you may find some of the resources below invaluable.

About Face 2: The Essentials of Interaction Design Alan Cooper & Robert Reimann. Wiley Publishing Inc. (2003) ISBN: 0-7645-26413 Widely considered the bible of Interaction Design, About Face 2: The Essentials of Interaction Design, covers everything from researching users to best practices for software behavior to detailed visual communication standards. Many of the ideas in "Planning your application," "Making your application fast," and "Making your application safe" appear in much greater detail in About Face 2: The Essentials of Interaction Design. Note that a new version, About Face 3, is now available, written by Alan Cooper, Robert Reimann and David Cronin. Contextual Design: Defining Customer-Centered Systems Hugh Beyer & Karen Holtzblatt. Academic Press. (1998) ISBN: 1-55860-411-1 Beyer and Holtzblatt present a fully-developed research and design process in this informative text on design research. Although few designers, developers, and user researchers follow the Contextual Design: Defining Customer-Centered Systems process to the letter, many make extensive use of some of the more popular research and design techniques it contains such as contextual inquiry, work modeling, and paper prototyping. The techniques discussed in "Planning your application" are based on commonly practiced portions of Contextual Design: Defining Customer-Centered Systems. The Designer
s Guide to Web Applications Part I: Structure and Flows Hagan Rivers. User Interface Engineering. (2006) Hagan Rivers describes the "hub and spoke" and "interview" structural design patterns in this paper and explains how to apply them to application design. Although her examples are more in the style of traditional HTML applications than rich Flex applications, her two core patterns can form a basis for designing information and process structures as described in "Structuring your application." Designing for Interaction Dan Saffer. New Riders. (2007) ISBN: 0-321-43206-1 Dan Saffer
s introduction to the theory and practice of interaction design is one of the best books available for those interested in getting into the field. The book defines interaction design and surveys techniques ranging from qualitative research to wireframing to device design. Although possibly too introductory for experienced interaction designers, it is an invaluable resource for those outside or new to the field. (Full disclosure: The author is a personal friend of mine, however, I don
t get kickbacks despite repeated attempts on my part.) Designing Interfaces Jenifer Tidwell. O
Reilly Media Inc. (2006) ISBN: 0-596-00803-1 Designing Interfaces consists of a library of interaction "design patterns," or solutions to specific appliction design problems. The patterns cover everything from application organization to navigation to page structure to visual and control design. The book is an excellent reference for any designer or UI developer to have on their shelf. The ideas behind the patterns appear in almost every chapter of this paper. Designing Visual Interfaces

1 of 3

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Appendix B: For fu...

http://www.adobe.com/devnet/flex/articles/fig_appendixb.html

Kevin Mullet & Darrell Sano. SunSoft Press. (1995) ISBN: 0-13-303389-9 Mullet & Sano
s book is a bit dated in its examples but not in its principles. The text covers primarily visual design principles including the visual hierarchy concepts discussed in "Structuring your application" and some of the information design principles discussed in "Designing content displays." Although lacking in coverage of deeper interaction design issues, this is an excellent primer on visual design as a communication tool and reminds us that visuals aren
t primarily about making the application "pretty."

Magic Ink: Information Software and the Graphical User Interface Bret Victor. Go to article. (2006) Retrieved August 6, 2007. Although perhaps unnecessarily provocative in tone, Bret Victor
s article does an excellent job of describing the importance of designing applications around content and information rather than controls and other user interface elements. The article covers many of the principles that appear in "Designing content displays" in greater detail. Observing the User Experience: A Practitioner's Guide to User Research Mike Kuniavski. Morgan Kaufmann. (2003) ISBN: 1558609237 Kuniavski
s book is an invaluable reference for design research techniques, such as those mentioned in "Planning your application." He covers a wide variety of research methodologies and provides detailed tips and instructions on how to apply each of them. Although perhaps not as good as having a dedicated design researcher on staff, reading this book is the next best thing. Reconciling Market Segments and Personas Elaine Brechin. Go to article. Retrieved August 6, 2007. Brechin
s article covers the differences between understanding markets and understanding users, and makes the case for why both are necessary for application design in much greater depth than I have attempted in this paper. Her article is an excellent read for those who aren
t yet sold on the necessity of understanding users from a qualitative perspective. Understanding Comics: The Invisible Art Scott McCloud. HarperCollins. (1993) ISBN: 0-06-097625-X Although not a text on application design, Scott McCloud
s well-known book on the art of comics covers many of the principles necessary for sound Flex application design. He discusses visual communication and motion principles in an easy-to-read comic book format. Many interface designers also use his techniques when drafting scenarios and storyboards, as discussed in "Structuring your application." Usability of Flash Applications and Tools: Design Guidelines for Flash-Based Functionality on the Web Hoa Loranger & Jakob Nielsen. Nielsen Norman Group. (2002) This report provides a comprehensive and exhaustive coverage of usability problems and solutions with traditional Flash-based RIAs. Most of the principles discussed still apply to Flex applications. Use it as a checklist to ensure your application is not falling into traps already uncovered by its predecessors. The Visual Display of Quantitative Information Edward R. Tufte. Graphics Press. (2001) ISBN: 978-0961392147 Tufte
s classic book on information design describes principles of data visualization as a means of assisting human understanding. Although he focuses primarily on the visualization of statistical data, many of the ideas apply to other types of content as well. The book covers topics introduced in the article "Designing content displays." Visible Narratives: Understanding Visual Organization Luke Wroblewski. Boxes and Arrows. (2003). Go to article. Retrieved August 6, 2007. Luke Wroblewski
s article gives a nice primer on visual hierarchy and its use in the design of web applications. Although not as in depth as "Designing visual interfaces," it is short and easy to follow. I recommend it to anyone new to the topic who needs a brief introduction to the visual organizational principles described in "Structuring your application."

2 of 3

3/3/08 10:54 AM

Adobe - Developer Center : Designing for Flex – Appendix B: For fu...

http://www.adobe.com/devnet/flex/articles/fig_appendixb.html

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.

About the author

Rob Adams works for Adobe Systems, Inc. in San Francisco, California. He started at Macromedia, Inc. in 2004 and has worked on the Flash authoring tool, Flash Player, and Fireworks, but nowadays works primarily on the Flex product line. He is involved with the design of the core framework itself as well as the designer/developer tools such as Flex Builder and Creative Suite. Although his primary focus is on design research, he also does some design work, promotes sound design practices both within Adobe and without, and makes himself a general pain in the necks of the designers, product managers, and engineers he works with. Copyright © 2008 Adobe Systems Incorporated. All rights reserved.

3 of 3

3/3/08 10:54 AM