Monday, December 17, 2007

Documenting the Design of Rich Internet Applications: A Visual Language for State

Documenting Ajax applications ...

"Ajax and Rich Internet Applications (RIAs) have revolutionized the way users interact with Web sites. However, documenting the design of any page that uses Ajax is a challenge, because the page—and, more importantly, components on the page—can have different states, depending on how users interact with the page’s components.

When I use the term state, I refer to a page or a page component that displays different information—content or user interface (UI) elements—depending on a user’s interactions or the information available to the system. For example, the following components have state:

* a navigation bar whose links appear in boldface to indicate a user’s current location within a Web site
* a link that changes from Register to Sign in depending on whether a user is logged in
* an Ajax widget that lets a user add a tag to a picture

Since the information on a page or within a UI component on a page depends on the available information, rarely does all of the information that might appear within a component appear in that component at once. So, when we describe state, we have to identify both the information that is available for display and the conditions under which to display it. Said another way, as a user interacts with a UI component, what information should appear in that UI component?

So, how do we document both the state-to-state interactions on a page or in a component, as well as the types of interactions that modify their states? Designers have proposed various ways of bridging this gap—particularly storyboards and prototypes. Both of these techniques have their strengths.

Storyboards—much like scenarios—let you communicate the intent of a page’s functionality. However, unless its functionality is simple, documenting all of its conditions and their resulting states can be cumbersome.

Prototypes let you demonstrate functionality to stakeholders and engineers, but prototypes are difficult to use as documentation. For example, if you design ten states for a UI component, how does an engineer know the conditions under which each of the ten states appears? You could annotate each condition, but doesn’t that defeat the purpose of the prototype?"    (Continued via UXmatters)    [Usability Resources]


Post a Comment

<< Home

<< Home