Managing Rich Internet Applications [7]

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 RIA technologies, introduced The RIA Behavior Model, and introduced 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.

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.

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

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.

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.

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 step-by-step process –- a waterfall methodology –- 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.

Previously I introduced the RIA Behavior Model shown here. Consider in particular the grey 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.

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. For example, that terminology is used in The Design of Sites by Doug van Duyne et al (see Chapter 1). However, Customer-Centered Design: A New Approach To Web Usability by Kreta Chandler and Karen Hyatt, while interesting (see Chapter 1), does not have much to say about the development process.

My graphic here is based on Chapter 5 of 'The Design of Sites', entitled 'Processes for Developing Customer-Centered Sites'. That book, having been published in 2003, is not about RIAs. Nor does it mention agile development per se, which is hardly surprising considering that the agile manifesto was crafted during the time when van Duyne et al were writing their manuscript.

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

Another book I have recommended previously, Usability for the Web by Tom Brinck, Darren Gergle, and Scott D. Wood, 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.

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.