Tips for Designing Powerful RIAs: An Interview with David Malouf and Bill Scott

The line between what we do on the web and what we do at our desk has significantly blurred. This presents opportunities for application developers that were previously unthinkable. Yet, it also presents challenges and puzzles to solve. We need to learn an entirely new interaction style, with new constraints and new boundary conditions. (For example, how do you make accessible AJAX work?)

UIE’s Jared M. Spool and Joshua Porter recently had the chance to talk with expert web application designers, Bill Scott and David Malouf, to discuss Rich Internet Application (RIA) development, AJAX, and other important issues surrounding the creation of sophisticated web apps.

Bill Scott is the Yahoo! AJAX Evangelist and a Design Manager for Yahoo!’s recently released Design Pattern Library. David Malouf is a Senior User Experience Designer at Symbol Technologies.

UIE: Let’s talk about Rich Internet applications and AJAX. At this point, is AJAX the predominant tool for creating RIAs? Are tools like Flash still coming into play?

Bill Scott: At Yahoo!, AJAX is predominant. AJAX has emerged as a cohesive set of technologies. But we still do a lot of work with Flash.

We chose to build our new web app, Yahoo! Maps, with Flash. However, one problem with Flash is that developers have to learn a completely new technology to build apps with it. One of the appeals of the AJAX technology is web developers can insert interactivity into the page incrementally and at a fairly low cost.

David Malouf: There’s something about the cost of entry for developers using AJAX. One of AJAX’s huge advantages is that developers can build on top of their existing platform and add more robustness to the existing platform.

Netflix’s rating system was one of the first impressive tools taking advantage of AJAX. By adding these ratings, Netflix made such a minor change to the concept of a commerce site, but the user experience dramatically changed. At first, Netflix’s developers only added a small bit of code. But over time, they’ve added more interactivity, robustness, and richness into the user interface.

However, I also see the environment changing. This month, Windows Vista launched, which I think offers great promise for Rich Internet Applications, in terms of keying into the Windows foundation platform, and all the other goodies it will bring into Windows XP — and even into the Mac OS.

In addition, Adobe is also currently doing a lot of work beyond Flash. They’re bringing their platform together so that PDF and Flash work together, both online and offline. I don’t think developers can ignore these technologies because they are advanced and extremely compelling.

Bill: AJAX and these other technologies have opened the door for these types of discussions. It’s going to be a really fun time going forward. It will be interesting to see what happens to the desktop as these desktop apps become rich internet desktop apps. We haven’t even really begun to see what’s going to happen in this space.

UIE: Many of our clients are still primarily creating HTML-based applications. HTML often forces them to fit complex application interactivity into a linear, page-based process. If development teams are considering AJAX, where would you tell them to start?

Bill: At Yahoo, we’ve started using design patterns to teach our Engineering and User Experience staff. We’ve publicly launched the Yahoo! Design Pattern Library patterned after Jennifer Tidwell and Martijn van Welie’s work. Jennifer wrote the book, “Designing Interfaces: Patterns for Effective Interaction Design,” which is a great resource. Martijn’s also done great work collecting a gallery of idioms and design techniques. (You can see the design patterns at Welie)

If developers are going to work in HTML and JavaScript, then they need to unlearn things they’ve done with other programming languages. JavaScript is a pretty powerful language that has some subtle differences from what most programmers are accustomed to with C++ or Java. In a way, developers are swimming upstream.

UIE: Is there a good starting point? Should developers look at Netflix’s approach and just find some small places to add JavaScript? Or should they put together a massive rethinking of their applications?

Bill: I think development teams can do both. I believe the incremental approach is the best way for developers to convince stakeholders to let them try these sorts of innovations. Having small successes usually makes the most sense. The best way to find these small wins is to identify the users’ pain points. We typically see that the tasks users need to accomplish most are also the tasks where they encounter the most barriers. Developers need to identify these paths and remove the roadblocks for users.

It’s interesting to look at how Netflix approached this problem. Sean Kane, Netflix’s Director of User Interface Engineering, gives a great talk about their process. Sean discusses how Netflix identifies their users’ pain points through usability testing and design research. From this research, they determine what innovations (usually in the area of AJAX) will help them.

David: I think many development teams are still thinking of AJAX as a solution to technical problems, instead of as a design solution. When development teams consider what changes are necessary to improve the user experience, the designers need to be involved right away. It’s essential for designers to identify the main problem areas for users when they’re trying to complete their tasks.

One area that I think is a quick win for development teams is using AJAX for validation purposes in forms. Development teams can do so much with AJAX to improve the user experience when submitting forms. It’s a quick hit that anybody can add to an existing page.

Bill: That is actually a great lead-in for what we are going to talk about at the UIE Web App Summit this January. It gets to the heart of the principles for designing rich web experience.

Whether it’s Flash or AJAX or another technology, I have found that development teams are hungry for information that deals with the high level principles of design. In most organizations, people are making decisions that are design decisions as well as engineering decisions, just because of the pragmatic nature of our business. I think it’s important that teams get back to the very basic principles of interaction. Things we’ve learned on the desktop definitely apply to the web.

UIE: You talked earlier about the benefits of design patterns. Can you tell us more about how Yahoo’s Design Pattern Library came about?

Bill: The original Yahoo Design Pattern Library started in about 2004. The idea was to collect together best practices from a three-pronged approach.

We collected interaction design patterns, pulling together the best practices from our interaction designers or information architects. We also collected visual design practices, which were similar to traditional style guidelines except in smaller chunks, such as exact spacing and typography specifications and best practices for which fonts to use. Finally, we gathered the code associated with the practices. All of this material forms the toolkit we hoped would satisfy the interaction design community, the visual design community, and the engineers.

It’s been going pretty well. At Yahoo!, we have about a hundred patterns in our internal pattern library. It’s available on a content management system under Drupal. Therefore, anybody can basically add a pattern, which then goes through a vetting and review process, and gets rated as to whether it’s the “Yahoo way” or not.

Earlier this year, I worked to expose some of this work externally and started documenting new patterns that we hadn’t yet captured internally. Developers can access these publicly at our Yahoo! Design Pattern Library. I’ve gotten a lot of positive feedback so far. Development teams really can get a jumpstart on many design concepts there.

UIE: Design patterns were originally invented by Christopher Alexander. He outlined several parts to the design pattern: a title, problem context, a constraint section, and a canonical solution. Can you explain how these pieces work?

Bill: For each design pattern, there’s a title, the example, the problem context, some usage notes, and the solution. We’ve found that having a standard way to read each pattern makes the processing of information much faster.

The design pattern title is really important because it has to be something that’s hopefully memorable and fairly intuitive to what the pattern is trying to solve. And that’s not an easy thing to do. It’s usually pretty challenging.

Under the title, we show a Synthesizing Example. In some cases, the example is animated to show the interaction in process, if it’s an interaction and not a technique.

Then, we have a Problem Statement. That problem statement provides the context of use. You know that’s what designers always say, “Well, it depends.” This is the, “depends action.” It describes the problem context. Then, we follow that with a Usage Area with some guidelines for usage and a canonical solution section.

We also have a number of other details with our patterns that we include in a sidebar. For example, we often include additional articles on the pattern, a code example, and a section on accessibility.

You Might Also Like

• Your Necessary First Step to Creating Powerful UX Metrics by Jared M. Spool When an organization's leadership values design, it falls on UX design leaders to show how good design is continuing to deliver that value. And in organizations where the executive leadership…
• The Powerful Ritual of Daily Design Review by Jared M. Spool Even though I expected it, I was stunned when I turned the corner and saw it. Along one wall of the 20-foot-long corridor we’d just entered, there were rows and…