The stated goal of this website is to promote the field of User Interface Design as a thorough engineering discipline which provides repeatability, robustness and measurability. A discipline which can be defined and followed by those less skilled in the art and yet still produce quality results.

This month I review a book by 4 renowned IBMers who make just such a claim for their new methodology. Its a book which advocates using UML as a notation to document the detail of the methodology.

Its timely arrival ought to make this an important book for the field. So does it make the grade?

Designing for the User with OVID:

Bridging User Interface Design and Software Engineering

by Dave Roberts, Dick Berry, Scott Isensee & John Mullaly, MacMillan, 1998

I really really wanted to like this book. It promises to fulfill the goal of UIDesign.net and deliver a repeatable methodology for UI Design whilst advocating documentation in UML. At first sight the book is thin and a quick flick through gives the impression of something clear and easy to read. There are lots of UML Class Diagrams and Sequence Diagrams. This really does look like something new and exciting for UI Design.

The Preface offers us a UML diagram detailing the CUA Designer's model which offers UML notation for Windows, Cursors, Views and the like. I was reminded of the David Ruble book reviewed in February. OVID we are told, means "Object, View and Interaction Design". It goes on to suggest that current CASE tools could be extended to use the OVID output and automatically produce outline code for an implementation. This really was exciting stuff.

Religion

Unfortunately, things began to go a bit down hill in the introduction. I had known that the authors were firmly in the OOUI camp of which I remain firmly sceptical. However, it became evident that OOUI and User Centered Design are the religious foundations to which OVID is firmly pegged. There was little to substantiate why either of these approaches are better and I was reminded of the HCI group at my university which were often berated for making unsubstantiated claims such as "Windows is better". Alarm bells began to ring when the book hinted that major software disasters could have been avoided if only the developers had used OVID. Airliners would not have crashed and patients would not have died. The "High and Mighty" aire of the whole piece was underscored by a quote from the poet Ovid, who we are told, "describes creation and change according to a grand design". I was left hoping for better once the real text got going.

Foundations

The first 3 chapters seek to give us the foundations of OVID. Chapter 1 seeks to define an OOUI and starts with a very woolly definition of Objects, Classes, Views and Instances. Curiously Views are not Objects or Classes. There is a hint that the authors are getting at the difference between business functionality or Problem Domain layer and View or UI layer but this clear and well understood distinction is never made in the book. It continues by showing us how to identify classes and describes a method which is very heavily dependent on inheritance. We are also given the impression that OOUI has never really gotten away from OS design and File Metaphor applications. These are the areas of expertise for the authors but I was hoping that they had come up with something which would be applicable to Line of Business, Transactional systems too. Chapter 1 gave me the impression that I might be disappointed and I was.

The muddy definitions get worse as we are waded out into the swamp which lies around composition and containment. Confused? I was. Things cleared up only slightly with the definition of Views and the suggestion that they can be sub-categorised into Composed, Contents, Properties, User Assistance and Help. This gave me the impression that the authors had stumbled onto a set of Archetypes for View classes, reminiscent of recent work by Peter Coad (in OO) and David C. Hay (in Data Modeling). Unfortunately, this idea is never expanded fully in the book.

The final section on the Benefits of OOUI left me unimpressed. In summary an OOUI implies that it is not Computer Oriented. Can you ever design a UI without at least considering the computer which is after all one half of the pair required before the system can dance the tango?

Chapter 2 was heavy revision of earlier stuff by the authors and others such as Donald Norman. Strangely Norman is never referenced and none of his books appear on the reading list at the end. We are walked through the User's Conceptual Model, the Designers Model, the Iceberg with some brief stuff on Graphic Design and Interaction.

Chapter 3 talks about the Software Development Lifecycle but in actual fact it is talking about the OVID software for the UI only. It never really mentions how this dovetails with the rest of the system development. There is nothing revolutionary in the text. Iterative, spiral development is advocated and we are reminded that its important to write requirements. The Tree swing example is trotted out for another run around the paddock yet again. The authors also list the team needed: A Domain Expert, a UI Designer, a Usability Specialist, a Graphic Designer, a Software Engineer. I found this description lightweight and niaive. There is no differentiation between the software engineer who designs the widgets, to the guy who designs the notification and PD hookup plumbing, to the application developer who simply builds the Views using the others work. Equally the other roles in the team could have been better elaborated.

Methodology

Chapter 4 thru 6 describe the OVID methodology. It clearly states that OVID is a User Centric Design methodology and then moves on to tell us that we must gather requirements. There is a discussion of the difference between functional and user requirements and some useful references on requirements gathering. We are told that User Requirements can be gathered using task analysis and a choice of two methods is given. The first HTA (hierarchical task analysis) is said to "create an abstract interaction design ... without the details of the UI design". Huh! So lets get this straight. We do an Interaction design in order that we can gather the requirements for our Interaction Design. Hmmm. The second alternative is little better. Those of you who follow this website will know that it is not a friend of Use Cases. Advocates of Use Cases who recognise that they can be problematic, have suggested that the UI Design is done before the Use Cases are written. This ensures that the Use Cases do not pre-empt the Interaction Design. OVID proposes that Use Cases are written as the requirement gathering tool for the UI Design. It even states that Use Cases are "specifying the interaction that takes place". Amazingly, the authors fail to spot that they advocate writing an interaction design in order to then analyse and design an interaction design. OVID would appear to be the name of dog which chases its tail.

Chapter 5 takes us to the Design stage and this is where the UML comes in. OVID proposes Finding Objects, Finding Views and Building State Diagrams. The advice given for Finding Objects using noun extraction from the Task Analysis is fair enough and well adopted across the industry. However, better techniques have emerged recently. The modeling technique advocated here is very different from what we learned at the beginning of the book. There is no inheritance in the worked example. Indeed I got the impression that a completely different author was involved. What the book fails abjectly to point out is that this is Problem Domain modeling. It has nothing to do with the View Layer.

Views come later. Views are added to the existing UML model and Views we are told create additional tasks which need to be analysed. The emerging model shows no clear separation between Model and View. I found this confusing. I was further confused by the section on combining Views which is shown using UML dependancy which look very like Interface Implementation. Actually, OVID uses Dependancy to imply that one can navigate from one View to another. I didn't feel that this communicated clearly enough. I was further confused by the lack of a containment relationship between Views. Surely, one View can compose several other smaller ones?

Sequence Diagrams are then introduced to document a detailed task. This allows Views (suddenly they are classes again) to talk to Objects as we move across Views and into the Model layer objects. The page and a half isn't nearly enough to explain this fully.

Then we move onto State Diagrams. This was covered admirably by Ian Horrocks in his book reviewed in March, where he demonstrated that Finite State Tables simply don't scale for UI Design. OVID advocates Finite State Tables and fails to mention State Charts. Actually, this is because the State Diagrams in question are actually documenting system states in the problem domain and not the internal controller states in the UI. The states within View classes are never considered.

Finally, there is Chapter 6 which explains implementation. It advocates two models. The original Design model and a new Implementation model. This has been shown to be problematic and keeping two models in synch with code development with full traceability back to requirements is always next to impossible. We are shown briefly how to model the development environment (which is Lotus Notes in the example). We are then walked through two examples but in far too little detail. At no time did I get the impression that I could go away and build something using OVID.

Support

The book is padded with a lightweight discussion on Prototypes and the pros and cons of low fidelity vs high fidelity. This is followed in Chapter 8 with a similar superficial look at Usability testing. Then there are the Conclusions in Chapter 9 which fail to convince. The book is essentially finished and there is still so much more left to be discussed such as Transaction Scoping and Exception Handling.

Summary

145 pages of real material. The authors have to be praised for attempting to document a real methodology for UI Design. They seek to move UI Design away from the realm of "black magic" and into a science. The stated goal for this website. They seek to do many things right such as adopting UML notation without extending it at all. However, it is a lightweight attempt which offers little more than the advice that we should gather requirements, perform analysis, do a design, implement in code and finally test. There is very little tangible advice on how to do this to a sufficient level of detail that one would feel confident to go and repeat the process for real.

The book seems obsessed with User Centred Design and an OO Approach without ever justifying these. The exercises at the end hint at perhaps a purpose as an academic text. Certainly, the lack of Transaction scoping, statecharts, exception handling, low level widget interaction, mandatory vs optional input, on-line help and most obviously no reference to Problem Domain or System Interface layers of code, go to highlight that this is not a book about real systems.

Recommendation

2/5 - Needed to be 600 pages of real in-depth content. An academic exercise for the classroom only!