|
This article was originally published in the Oct 2008 issue (Vol 13, No. 4) About the Author David Dick is a familiar face at the UUX SIG. He edited the Newsletter for over ten years and is now the Assistant Manager for the SIG. He is also an STC Associate Fellow and an accomplished swing dancer who is currently taking Lindy Hop lessons. |
Pawan Vora. Author of Web Application Design Patterns. By David Dick, Assistant Manager of the Usability and User Experience SIG
Meanwhile, Pawan Vora, a user interface designer, was collecting screenshots and notes to start an informal design scrapbook. Then he began doing tutorials and workshops on design patterns for the Usability Professionals Association (UPA) and the Human Factors and Ergonomics Society (HFES). His work eventually led to a book deal with Morgan Kaufmann. I have been reviewing the manuscript for Mr. Vora's book Web Application Design Patterns which describes how today's Web 2.0 applications are designed and how they work. The book is finished and will be published next year. I am preparing a book review for publication in a future issue of Usability Interface. The publisher arranged for me to interview Mr. Vora in order to learn more how design patterns contribute to usability and accessibility of Web applications. The following is my interview with Pawan Vora, user interface designer and author of Web Application Design Patterns. Available here for pre-order on Amazon.com. Mr. Vora, what motivated you to write the book, and what do you consider most challenging? I have been interested in designing user interfaces since I was introduced to human-computer interaction in graduate school. After graduating and designing user interfaces for a few years, often I would go through my previous designs to see how I had solved a problem before, and if there were any specific nuances that I should be aware of in the current situation. If I had not encountered the problem before, I usually tried to look at how others had solved the same problem and see if there were any similarities in the designs, If so, I would see if they were applicable to my situation. I tried to organize my designs on my computer, but they were often difficult to find and I would have to go through the user interface specifications or other documents and see if I could find design rationale and other relevant implementation details. When I started reading about design patterns (The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience by Douglas K. van Duyne book and Designing Interfaces: Patterns for Effective Interaction Design by Jennifer Tidwell), I thought that was an efficient way to collect good design practices, refer to them as needed, and document the rationale for why a design worked. This is when I started collecting screenshots and writing notes to start an informal collection of patterns. I didn't call them patterns then, it was just my design scrapbook. After a year or so, I got an opportunity to apply the idea of design patterns in my consulting business for three different companies, and I was convinced of their usefulness. Then I started doing tutorials and workshops on design patterns at UPA and HFES. I was thinking about documenting the user interface design patterns for web applications and making them available online (similar to what Martjin van Welie and Jennifer Tidwell had done). Martjin van Welie and Jennifer Tidwell were among the first to make design patterns available online at www.welie.com/ and at www.time-tripper.com/uipatterns/ respectively. Seeing how they documented design patterns, I considered doing the same for web applications. I thought that would make it easy for me to not have to identify all the patterns right away, so I can do it incrementally. That's about the time Morgan Kaufmann approached me about the book. I thought I would give it a try and write a proposal to see what happens. Once the proposal was accepted, it was difficult to say no because I had already started doing some research for the proposal and I thought I could actually pull it off. I had never written a book, so I thought it would be a good learning experience. Writing a book would discipline me to perform the necessary research, and perhaps I would be able to help a few designers in the process as well. What do you consider characteristics of user-friendly rich Internet applications (RIAs)? At a high level, I'd say they allow direct manipulation with clear affordances, minimize (or eliminate) page refresh delays, and use animations/transitions to convey state changes. They do all this in a way that, like other usable designs, is transparent; they are not noticed by users. Many of the RIAs are also visually appealing, and give an impression of "cool" when users first see them. I think that's an important characteristic because that often gives users a clue as to the type of experience an application might offer. But once users go past its "coolness," RIAs should still help users get their work done efficiently and effectively. How would you evaluate the usability and accessibility of a rich Internet application? It's not any different from typical usability testing: identify target users and ask them to accomplish relevant tasks using the application. But there are a few things I do before running a formal usability test on a rich Internet app. First, I try to understand how well the rich interactivity is (or will be) implemented in the application. I have seen applications that claim to be "rich," but are implemented as traditional web apps. Recently I reviewed a web app that was implemented using Flex to take advantage of its rich interactivity, but had the same design as a traditional web application. It required users to launch a dialog with a list of items in order to select one, which could have easily accomplished using AUTO-SUGGEST; it required them to go to a separate edit page when it could have used EDIT-IN-PLACE.; it required use of up and down buttons to reorder items rather than using DRAG-AND-DROP; and there were several other "non-rich" interactions. I do not want to imply that traditional non-rich web applications are not usable, just that using a specific technology doesn't necessarily lead to a rich application; it requires designers to have a different mindset when building the application. If I find "richness" lacking in an application, I try to understand whether any technical constraints were making the designers adopt non-rich approaches and see if they can be remedied. I believe that combining rich and non-rich interactions, at least for the primary tasks in an application, can compromise its usability. Next, I look at the response time for each interaction, and try to identify performance bottlenecks. Even with "rich" technology, one cannot avoid some delays. In such instances, designers must incorporate appropriate feedback mechanisms or progress indicators to keep users informed. Identifying performance bottlenecks becomes difficult when the application is still at the prototyping stage because it doesn't have enough data and seems very responsive. I usually ask developers about the expected delay and appropriate feedback mechanisms before conducting usability tests. Finally, I try to use the application by keyboard only to check for accessibility. If I can't access the application by keyboard, then I know that the application is not going to be accessible. As I mention in my chapter on Rich Internet Applications, it's difficult to make an RIA completely accessible. So I try to discuss with the design and development team if they are using unobtrusive ways of implementing style sheets and JavaScript to make the application accessible, or if they are considering offering an accessible version of application to users. Can an application contain too many design patterns that would impact usability? I guess it depends on the size of the application. For very large applications with several add-ons, it can include many patterns. For example, a suite of applications such as Zoho or Google Docs, or collaborative applications available on Acrobat.com, I can imagine using many patterns. Designers should always try to minimize the total number of patterns, though, and ensure that they do not contradict each other. For example, if in one area of the application, users can double-click an item to edit it (e.g., renaming a tab), another part of the application shouldn't require them to choose "rename" from a drop-down. Often, it's not the number of patterns but trying too hard to use a pattern that leads to poor usability. So designers should try hard not to fall in love with a pattern and see where it can be used. They shouldn't think: I love this "carousel" design. I wonder where I can use it in my application. Designers should try to match users' goals (and tasks) to design patterns. If designers really understand the problem that they are trying to solve, they will end up choosing the right patterns and balancing them across the application. What suggestions do you have about documenting the design of a web application? Just do it! :-) Don't wait to document everything or make sure the structure is just right. A pattern name and a bunch of annotated screenshots are a good way to get started. The important thing is to start collecting good design practices as soon as possible. Imagine if a three-person team decided to collect examples for 1 pattern a week. At the end of the year, they will have close to 150 patterns that they can reference. I would also like to suggest using a Wiki to make it easy for others to contribute and maintain a repository of patterns. And feel free to use my book to get a jump start. |
|||||
| All articles are property of the author or publication providing reprint permission. Reprinting this content in part or in whole requires permission from the source. | ||||||
|