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:
This is part 5 in the Designing for Flex series, which includes the following articles:
I suggest that you read the previous parts before proceeding with this part of the series.
Download all parts of the FIG series as PDF files that you can print and read offline: adobe_flex_interface_guide.zip (ZIP, 5.7MB)
This content is a public draft. Please give us feedback in the Flex Interface Guide Forum.
Designing content displays is not a new idea. The field of information design has tackled the problem for hundreds 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."

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 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 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 displaying the first line of the message itself as well.
![]()

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.


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, 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.
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 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, 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.
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.

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."
Favor direct means of manipulating content over indirect ones.

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.
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.

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.

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 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.
Much of this article has discussed how to design content without the use of controls, and has even actively 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.

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.

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.
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.
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.
![]()

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.
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
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.