SAP DESIGN GUILD

Book Review: Making the Web Work

Book | Author | Review

By Gerd Waloszek, SAP AG, Product Design Center – 07/24/2003

This review takes a personal look at Bob Baxley's recent book Making the Web Work.

 

Book

Cover of Making the Web Work     

Bob Baxley
Making the Web Work
New Riders Publishing, 2002
ISBN: 0-7357-1196-8

Design: Web Design, Web Applications, Methodology

Book Website

 

Author

Photo of Bob BaxleyBob Baxley is a practicing designer who lives and works in Silicon Valley. Specializing in interaction design for both Web applications and services as well as desktop products, Bob has worked in a variety of corporate and startup environments. He began his career in 1990 as the designer for ClarisWorks, and later worked on a variety of projects for Adobe Systems, Apple Computer, Epiphany, Net Objects, Ameritrade and others. Currently, Bob runs the Design and Usability teams at myCFO, a leading wealth management firm. (From book/Website, shortened)

 

Review

As author and co-author of several guidelines for SAP's Web applications, I was especially interested in reviewing Bob Baxley's book "Making the Web Work," one of the few books that deal with Web applications instead of content-based Websites. Bob Baxley had two goals when he wrote his book: First to provide designers with solutions for common Web-interface problems. Second to offer his "universal model of a user interface" to the design community, or in his words, offer "a standard methodology for deconstructing and prioritizing the issues involved in the design of interactive products in general and Web applications in particular." Taken together, this is an ambitious objective, I will comment on this in my conclusion.

When the SAP Design Guild Website went live, the Resources section was organized according to the four phases that encompass the whole application development process: Analyze, Design, Implement, and Verify. According to this breakdown, Baxley focuses on the Design phase. His book comprises five parts, the first of which lays the foundations and includes an introduction to personas and scenarios. The next three parts correspond to the tiers of Baxley's model, with a chapter devoted to each layer within a tier. The final part examines two major Websites through the lens of the presented model. Each chapter is followed by a short summary.

The Model

Let me start with Baxley's model of the user interface (UI). It consists of three tiers (or layers) each of which again consists of three layers. These tiers and the layers within them range from conceptual design, to interaction design, to "touch-up" work, that is, the design of the presentation. The three tiers and their layers are:

Note that this model is not restricted to Web applications. The figure below provides an overview of it:

Box Baxley's model

Figure: Box Baxley's model (from book Website; click image for larger version)

Just a few comments on the model.

All in all, I think this is a good model. I agree with the notion that there is a "natural" sequence of steps in interface design, which ranges from the abstract steps that cover structure and navigation, to interaction design, to "visual touchup", which prioritizes layout over actual look. Such a view has nothing to do with the "importance" of steps but simply with how development projects should be organized: Certain steps must be taken before others. In reality there are, of course, good reasons for many large variations, but it is always useful to keep the general picture in mind. I am eager to see how much impact Baxley's model will have on the UI community.

There is one element of the model that strikes me as curious: The two axes "impact on usability" and "user awareness" below the graphic. The axes both point in opposite directions (despite the double arrows in the figure): Where one is low, the other is high, and vice versa. I wonder what the graphic design community will say about this. Differing understandings of user interface issues, such as legibility, have recently brought about many quarrels between graphic designers and usability specialists, some of which can be found in the chapter on the style layer. Often, graphic designers found their work discredited by usability specialists due to the fact that the latter set different priorities with respect to the user interface. UI practitioners may also recall that when they presented prototypes, they were often questioned about interface colors or other superficial prototype features, rather than about its structure and interaction, which was the actual focus of the prototype. In projects, it is often hard to separate issues and to focus discussions on the relevant ones. Hopefully, Baxley's model, once generally adopted, will lead to a better understanding of the concerns.

Web Applications

Part III of the book covers the core interests of user interface designers and deals with the behavior tier, or rather the interaction issues of Web applications. As this review is written for an SAP Website, I would like to point out to the readers a couple key differences between what SAP terms Web applications and Web applications in general.

Baxley lists online stores, financial services, travel services, information portals, and online services as typical examples of Web applications. SAP, having its roots in form-based enterprise software, mostly offers largely simplified, form-based business applications for the Web. Examples of these include procurement software, the SAP Retail Store, and Employee Self-Service (ESS) applications (of course, SAP offers an online store, too).

Apart from the very first breed of Web applications, all SAP Web applications are based on a control library; plain HTML controls are rarely used. Thus, many of the design problems covered in Baxley's book are addressed by control developers at SAP, while Web application developers are primarily responsible for arranging controls on a page, just like their enterprise software colleagues. Interestingly, the leap from database to Web applications is not as wide as one might expect: Compared to pure desktop applications, both have a simple interaction model and a reduced set of often simplified controls.

Moreover, SAP delivers standard software, not software developed for a single customer. Applications are adapted to the requirements of respective customers, with Web applications requiring more work than GUI-based software. That means that at SAP, most work on the presentation layer, covered in Part IV of Baxley's book, is delegated either to the control developers or the consultants who customize an application on-site.

Does all this mean that Baxley's book has nothing to offer for Web application designers in the SAP environment? Not at all. From an interaction point of view, the selection and proper use of interface elements is at the core of user interface design. I also found a lot of agreement with SAP's Web guidelines. The basic difference is that developers of SAP Web applications select from a fixed set of proprietary controls and therefore can ignore most of the presentation issues.

One of Baxley's imperatives is the separation of views and forms, the first serving information presentation, the latter editing and manipulating data. This usually isn't a problem for SAP Web applications because many of them are primarily form-based. It is interesting to note, however, that apart from some slight variations, many of the guidelines for designing forms have not changed since the advent of the Web.

As with the SAP guidelines, the question arises: On which evidence are Baxley's recommendations based? Are they based on research, general practice, convention, personal experience, or authority? Perhaps we will have "real" research-based guidelines for the Web some day in the future: At the CHI 2003 conference, such Web guidelines were presented. Currently, however, these are of little use in the context of designing control-based Web applications.

Conclusion

Did Baxley achieve his aim of providing both a model for the design community and useful guidance for Web application design in his book? I am not sure whether his prospective audience (practicing designers, product marketers, and software engineers) will be patient enough to swallow both in one "package." In my experience, designers and developers want to read as little as possible; they prefer simple cookbook rules that get them going. It would be an interesting exercise to extract all the many useful rules in the book and collect them in a compact guidebook. As already mentioned, there would be much agreement with SAP's Web guidelines but also some interesting conflicts that deserve a closer look. I doubt, however, that this would be in Baxley's interest because he wants to "sell" both model and guidelines. After all, he recently offered a "stand-alone" version of his model in his DUX 2003 paper Universal Model of a User Interface.

The following comment may reflect my own personal preferences and/or my (European) cultural background, but I find the book often too wordy. I also find that it offers too many examples for readers who have experience in user interface design. Perhaps they are offered for the benefit of graphic designers. In addition to this, although the book's structure is well defined, its layout and visual style make it hard to find the key information. For this, one must refer to the excellent index.

Despite all these issues, I highly recommend Baxley's book to user interface designers. And I am interested to see whether the majority of them will find the time to digest it and to accept both, the guidance and the model.

 

References

Bob Baxley (2003). Universal Model of a User Interface. DUX 2003 Case Studies, Informing DUX.

Research-based Web and usability guidelines: usability.gov/guidelines/

 

top top