Accessibility

Flex Article

 

Designing for Flex – Part 4: Merging the web and the desktop


Table of Contents

  1. Introduction
  2. Living on the web, living on the desktop
  3. Browser expectations
  4. Flex accessibility
  5. Moving to the desktop
  6. Desktop application considerations
Comments

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

checkmark Provide URLs that a user can bookmark and back button support for all navigable states.

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

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.

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

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.

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.

Page 3 of 6
Previous Page
Next Page