« Software Engineering Matters | Home | Waterfall Methods: Past and Ever-Present »

Managing RIA's [7]: Developing Usable RIA's

Illustration: Monitor and AJAX

This is the seventh post in a series devoted to the challenges of Service Level Management (SLM) for Rich Internet Applications (RIAs). In these applications, some processing is transferred to the Web client while some remains on the application server.

Previous posts introduced the subject and the SLM topics I plan to address, reviewed the principal RIA technologies, introduced The RIA Behavior Model, introduced the application measurement topic and discussed RIA measurement challenges.

RIA usability and the site development process

Having discussed the measurement challenges posed by RIAs, I intend next to consider the demands that RIA development may make of SLM processes that have been designed and fine-tuned to manage traditional Web applications.

I covered some of this ground in a Webinar on How to Overcome the Challenges of Rich Internet Applications. So in this post I will lay out the general framework of that material, using the illustrative figures I created for the Webinar.

In previous posts I have introduced and discussed a simple four-part framework for thinking about Web Site Usability. I divided usability into four dimensions, each of which is essential to the ultimate success of any site -- Availability, Responsiveness, Clarity, and Utility.

Illustration: Typical customer's experience of usability: availability, responsiveness, clarity, and utility

Figure 1. A customer's view of site usability

The graphic presents the four essential qualities in the order of their significance, at least for all first-time visitors to a site.

Interestingly, companies developing Web sites or eBusiness applications tend to approach these four aspects in exactly the reverse order, as shown in the next figure.

Illustration: Typical usability concerns during site development: utility, clarity, responsiveness, and availability

Figure 2. Development view of site usability

A business goal leads to a design process, which in turn results in an application being built and then rolled out into production. And at each point along the way, people do their best to make the outcome a success. But is that enough?

Well, if you take this approach you may get lucky. But to be safe you really have to take a more systematic approach to Service Level Management, like ITSO.

[On this subject, it is hard for me to be brief, because 10 years ago I actually wrote a 750-page book [Amazon] about it. But here goes!]

I have always believed that you cannot separate issues of software performance from the software development life cycle (SDLC). The best way to ensure acceptable performance is to follow the discipline of Software Perfrmance Engineering -- to build in the desired level of performance, just as a mechanical engineer would. The next figure attempts to sum up this idea.

Illustration: Building usability into a site throughought the software development life cycle

Figure 3. Building in usability throughout the life cycle

I think everyone can agree that there is an application development life cycle – applications have to be designed, developed, tested, and deployed. People may argue about the details, but for the purposes of this discussion we can set aside those religious debates about methodologies.

All I care about here is that each stage of your development process -- whatever it is -- must include a deliberate focus on performance (or SLM), alongside other aspects of site usability. If you want an application to achieve certain levels of service, don't expect that to just happen on its own. You have to agree on your objectives, then design, develop, and test your application with those objectives firmly in mind, and measure and manage the application to make sure you are actually achieving your objectives. Of course, there's nothing particularly radical or new about this idea, but the added complexity of RIA's increases the risk of failure if we don't actually follow these well-established best practices.

The RIA development process

If you want to implement a really usable Rich Internet Application, you're probably going to need to beef up your site development processes to get everyone on the same page. That's because up to now the Web Usability (with a capital 'U') profession has concentrated on the dimension I call Clarity.

Their exclusive focus on Web page design and Information Architecture was possible only because the traditional structure of a Web applications was so constrained by the limitations of the Web browser technology they had at their disposal. When all Web applications implemented the same simple thin-client model, they did not have to worry too much about application complexity.

But as we evolve to building RIAs with a separate client-side engine, the site development process must deal with the kinds of complex issues that arise during the design of distributed applications. In the past, Web designers have not had to deal with anything as technical as this. They certainly can't buy a book on 'Web Usability' and read about these kinds of issues.

Confirming this perspective, I recently heard Scott Dietzen, President and CTO of Zimbra, speaking about Ajax at an MIT/Stanford VLAB meeting. To illustrate his statements that 'Ajax is still hard' and 'You can't crank out a good Ajax application quickly' he revealed that Zimbra has had to interview 40 JavaScript developers for every one they have hired. This is telling evidence of the difference between traditional Web applications and RIAs.

And you really do have to work hard to get everyone on the same page, because typically the people in the various participating departments usually don't have a clear picture of just how much it takes to build a successful Web application.

Illustration: The politics of application development

Figure 4. The politics of application development

As illustrated here, they naturally focus first on their own problems and challenges. The graphic is meant to be a bit tongue-in-cheek, but it does reflect the political realities of application development.

Several groups contribute to the success of any site, and each group thinks that their contribution is the most important! Apart maybe from those who work in IT, who tend to complain that they could deliver much better service levels if only the developers would hand them more robust and stable applications to manage.

These attitudes are not just the result of people having an inflated sense of their own importance. Most people honestly don't understand just how much work the other players have to do. This is already true today, and with the added compexity introduced by Rich Internet Applications everyone will have even more to think about. This is likely to increase their isolation from the other participants, unless the development process requires close cooperation.

Illustration: The four dimensions of usability are equally essential

Figure 5. The four dimensions of usability are equally essential

So the first lessons your development processes must drive home are that all participants play an equally vital role in delivering a usable application, because all four dimensions of usability are equally vital to the success of the application.

The importance of being agile

Building successful RIAs will also require more communication. We've been talking about the importance of SLM within the life cycle. But the problem with describing the software life cycle using a list activities like the one in the third illustration above (introducing the development life cycle) is that such lists tend to imply a waterfall methodology -- a step-by-step process in which we must complete one activity before moving on to the next. That approach to the development process is certainly not going to be an effective way to develop Rich Internet Applications.

Illustration: The RIA Behavior Reference Model

Figure 6. The RIA Behavior Reference Model

Previously I introduced the RIA Behavior Model shown here. Consider in particular the dark green boxes along the top, representing the application's design and usage environment, or context. As I wrote at the time:

A user's satisfaction with any application depends on ... how well the application design matches their needs at the time, their way of thinking, and their behavior when they are using it.

Their experience of response time depends on the combined behaviors of the client and server components of the application, which in turn depend on the application design, the underlying server infrastructure design, and of course the user's Internet connection speed. The most effective RIA will be one whose creators took into account these factors at each stage of its development life cycle, and who created the necessary management processes to ensure its success when in production.

Now imagine trying to focus on any one of the four aspects of usability without paying attention to the others. It can't be done. Application utility is tied to user behavior, which is driven by the clarity of the site, the design of the client-side engine, and the responsiveness of interactions between the client engine and the server components. And the design and implementation of those components will ultimately also determine application availability.

Illustration: Keeping all four dimensions of usability in focus throughout the life cycle

Figure 7. Keeping all four dimensions of usability in focus

Since the four dimensions of usability are so intertwined, I conclude that to ensure a successful outcome, we must adopt a development process that keeps all four usability goals in focus, all the way through the life cycle.

This approach is called agile software development. Agile methods use an iterative approach to design, development and testing that keeps all the different participants ('stakeholders') involved -- marketing or business owners, Web designers, application developers, and the IT staff who understand what it takes to manage a site in production. They all have to communicate and share their different areas of expertise throughout the process.

In the Web design literature, methods similar to this have sometimes been referred to as customer-centered design. Kreta Chandler and Karen Hyatt's book, Customer-Centered Design: A New Approach To Web Usability [HP], while interesting (see Chapter 1), does not have much to say about the development process. But the terminology of customer-centered design is used in The Design of Sites by Doug van Duyne et al -- for example, see Chapter 1.

Illustration: An example of a customer-centered design methodology

Figure 8. Customer-centered design

This graphic is based on Chapter 5 of 'The Design of Sites', entitled 'Processes for Developing Customer-Centered Sites'.

The book does not offer any design guidance for RIAs, nor does it mention agile development per se. However, these omissions are hardly surprising considering that it was published in 2003, when RIA technologies had not been widely adopted. And the agile manifesto was being crafted during the time when the authors were also writing their manuscript.

Even so, it does suggest the kind of iterative approach to the development process that I believe is essential when developing RIAs. Chapter 5 concludes:

The principles and techniques of customer-centered design and iterative prototyping are embedded in every stage. Many firms have similar processes, though the stages and deliverables might have slightly different names.

-- The Design of Sites by Douglas K. Van Duyne, James A. Landay and Jason I. Hong.

Another book I have recommended previously, Usability for the Web, is structured around the major stages of an iterative development process. In Chapter 1 they write:

At each stage we want to cycle between refining our design and evaluating our latest refinement, iterating until we've achieved a level of usability that we're satisfied with before continuing to the next stage. Evaluation at each stage allows us to incorporate user and client feedback loops to optimize the design.

At each evaluation, we determine whether our design is adequate for continuing on. We do this by establishing benchmarks, or target usability goals.

-- Usability for the Web by Tom Brinck, Darren Gergle, and Scott D. Wood.

These ideas did not emerge for the first time with the advent of the Rich Internet Application -- they are merely descriptions of good development practices. But the added complexity of the RIA model makes it essential that we actually put these kinds of methods into practice.

[This post was first published on Blogger on April 10, 2006. Some this material later appeared in the white paper [pdf] Rich Internet Applications: Design, Measurement, and Management Challenges].

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)


Your content is very useful and helpful to me. Specially concerning to Life Cycle Development. If we took the old Software Engineering practices we find this:

OO programming paradigm
Iterative-Incremental life cycle
RUP methodology

Nowadays with Web 2.0, RIAs, etc that approach doesn't fit. What are the better practices for RIA development? There exist equivalent for that trilogy?

I'm a little confuse, everybody talks about SOA and Patterns but I don't found a "formula" to start a RIA project. Maybe it does't exist, but a least I would like to know what would be the best approach.

March 17, 2008 | Unregistered CommenterJoseph

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>