Organizations across a wide variety of markets are moving quickly to plan, implement and leverage the power of Rich Internet Applications (RIAs) to engage their customers in fluid, desktop-like online experiences. These experiences are proving to be both highly valued by their customers, in terms of what they offer, as well as beneficial to bottom-line considerations such as online conversion. However, organizations need to understand that for all of their inherent benefits and advantages, RIAs require a new set of approaches for project planning, design and execution.

Key questions RIA design teams should ask themselves at the project outset include:

• What is the proper balance within the experience between known and established user interface metaphors (e.g. the hyperlink, the pulldown, the button, etc.) vs. newer RIA controls that the general Web user population may have less familiarity with
  (e.g. sliders, accordion panels, drag and drop)?


• To what extent will users expect the RIA to behave just as a Web page-based application would when it comes to key application/browser interactions – the back button, bookmarking, page printing?


• What are the trade-offs that may need to be brokered in the design process between the proposed experience and the application speed, performance, and responsiveness? How confident is the team that the identified design direction won’t force a technical engineering effort that far exceeds the initially expected development schedule and budget?

This article will provide key strategies and approaches to addressing these issues that any team embarking on an RIA implementation should be prepared for. From a best practices perspective, strategies for modifying approaches to more “traditional” Web design processes for RIAs include:

Earlier Expression of Proposed Interactive Behaviors in the Design Process:

Low fidelity design artifacts (such as wireframes) still have a role to play in RIA design, just as they do in page-based Web design projects. But because interactive behaviors the array of possible controls for RIAs can differ dramatically from current, established Web UI conventions, interactive prototypes should be created as early as possible in the design process. Illustrating intended interactions with simple prototype models will reap enormous benefits in terms of aligning key business stakeholders to the design vision and insure validity of any early stage
consumer/user feedback. Even if they are only simple animations of wireframes authored in PowerPoint, they will demonstrate proposed functionality much more clearly to audiences than more static documentation formats such as wireframe annotation or static screen mock-ups.

Create Use Case Scenarios That Include Application/Browser Interactions:

Make sure that use cases and test scenarios (either usability testing or functional/quality assurance testing) include scenarios that examine all aspects of how the application should and will behave with common browser functions such as back/forward button interactions, bookmarking, etc. In addition, think through what should happen with populated input fields and controls when a user back buttons – will the information be retained as they move forward again? If you only plan on retaining data via a save function, should you prompt the user and provide a dialog to save when they click back, insuring they won’t accidentally lose all of their work? Unlike standard Web form/page based applications, RIAs will not “inherently” integrate or perform as expected within the browsing environment, so these scenarios need to be identified, designed to, and functionally defined to a greater extent in the RIA design process.

Bring Technology Resources into the Process as Early as Possible:

The balance and trade-off between selection of a RIA development tool set (e.g. Ajax or Flash Flex), performance and application responsiveness, and QA/testing environments is much more complex and “attached” to design direction than in more traditional Web application design. For example, a Flash based RIA may rely much more on client PC processing power/available RAM than a Web application ever would. QA groups that have established tools, resources, and processes to test regular Web based application performance will likely be focused on server-side response times in order to gauge application performance. They are not even considering evaluating what the “true” end user experience of the RIA will be like based on client-side processing power. For these kinds of reasons, lead IT and QA resource team members should be exposed to the design direction of the RIA as early as possible so they can understand the new ramifications and needs that a large, enterprise scale RIA represents. Which, in turn, may prompt some necessary trade-offs and modification of the design to offset issues that would be far too complex or expensive to implement and support.

While RIAs represent a wide array of possibilities and an exciting new set of tools for marketers, designers, and organizations, like anything else, they require an approach that best leverages their advantages but mitigates the risks of the new complexities
they introduce.

view printable PDF>>