There has been a lot of interest recently in Object Oriented Design and its relationship with User Interface Design. By far the most popular material at uidesign.net has something related to both OO and UI design.

One of the founding fathers of the OOUI movement is Dave Roberts of IBM. uidesign.net editor, David Anderson, took the opportunity to interview Dave after the TUPIS workshop at this year's UML 2000 conference in York, England.

Dave Roberts has been involved in UI Design for more than 15 years. He has worked with IBM on various generations of operating environments and was involved in developing the CUA87 and CUA91 standards. He was deeply involved in the notion of an Object Oriented user interface which led to the development of the OS/2 Workplace Shell and later to derivative work such as Taligent.

Dave is now a leader in the IBM Ease of Use group which continues to pursue OOUI theory through the development of the Object Views Interaction Design (OVID) method.

Forgive my skepticism, I still have some doubts about the OO approach to UI. Today at the TUPIS workshop I felt there were several participants advocating the notion that you create an OO model of the system which represents the User's Mental Model. You then build that OO model and the system is, by some magic, intuitive and easy to use.

I'm skeptical of this and don't believe that the user's concept of how something works and the actual OO analysis model are necessarily related. How would you address that skepticism?

We talk about the Designer's Model to distinguish it from the models you're talking about - the User's Model. We recognize that there will be User's Models and that the sum total of all the astute User's Models will be approximately equivalent to the Designer's Model, if [the designer] has done a good job of representing that model in the embodiment of the system. So that over time, [the designer] would hope that any user's mental model would approach a correct subset of the designer's model that has been built. We don't claim that initially the designer's model represents anybody's mental model. It represents a proposed mental model, that someone who knew the system perfectly might imagine.

Yes!

However, that might lead to the argument, "What is the design point for the system?" Is the design point, the designer's model from which you derive the appropriate business model? We would always recommend that you arrive at a designer's model and then develop a business process model that correctly supports that designer's model.

[The OOUI community] have had many discussions about where this notion breaks down. The point where a problem domain model does not or cannot support any particular user's mental model. This often happens as soon as there is a system error. When there is a total collapse in a system, users can't often see a recovery path from an error. This is because the business model that they are working with, was not correctly matched [to the designer's model].

In the late 80s [at IBM] we talked about the notion that you can't "stick lipstick on a bulldog". The notion that there is no point in sticking with a fraudulent system image (designer's model) and then proposing that everyone learn this fraudulent image. You either have to train people so that they fully understand the system design, this allows them to understand when things start to go wrong, when errors occur, or you have to fix your system design. Those pieces of the system which are really horrible, you don't mask these, you take them away through good redesign. You just can't dress up a bad designer's model with a little user interface work.

Last year Allen Holub made a name for himself in the OOUI world with several articles at Javaworld. I had a fundamental problem with his work. It advocated that you produce one single OO model of the system. The business objects were the only objects and each of them would know how to display itself. It was all based on the premise that you only ever need one view of an object.

My view on this was simple. A properly normalized OO analysis model and the user's mental model don't necessarily coincide. I just don't buy the idea that there is a 1 to 1 mapping between the problem domain objects and the cognitive objects of a user's mental model.

Holub's work has been lumped in with other work in the OOUI community. Have you been following it and what do you think of it?

I'm not familiar with the series of articles but I find it extraordinary that anyone would suggest that you only ever need one view of an object. I just can't image [ the domain model fulfilling that role ].

Reading Jef Raskin's recent book, The Humane Interface, I accepted his notion of a cognitive object. It had the effect of reawakening my interest in OOUI. In my own work I have seen evidence for cognitive objects as part of the user's model from usability testing.

Working with Terry Simpson of Connected-Systems, I observed that users of wireless web phones had a mental model of something we now call a "dialable object" i.e. anything that could conceivably have a phone number associated with it, they wanted to press the "call" button on the phone and expected the phone to then dial that object. We developed the concept that these "dialable" objects had a surface and an interior. A surface might be just the name of the object e.g. Mario's Restaurant, and the interior might be a detailed display which would include the name, the address, the phone number and the menu. Users had an expectation that the behavior of the object ought to be available whether they were viewing the surface or the interior.

For me this was an epiphany. A moment when I suddenly thought there was real value in looking again at OOUI as a valuable concept.

To me, this is obviously correct. If there is anything on a screen which could conceivably have a phone number associated with it, and you also have a "call" button which performs the action of dialing the number, then if the user selects the object, presses the "call" button then [the system] had better call it, whether it looks like a phone number or not.

Whereas, if you had another button or action available which performed, "Show more details" then selection of that would reveal the details. That's a different function from dialing. You shouldn't need to see the actual phone number to be able to do that.

So it was lucky that Jef Raskin came along this year and provided me with the language to describe this phenomena Here users were perceiving an entity which could be described as a cognitive object. Each object can have a surface, an exterior, if you like, and then an interior, its details.

For example, I could be an object in a system. My exterior might be my name, "David Anderson", or a GIF image of me. My interior might be my address, my employee number, my salary, my phone number and so on. Regardless of whether the user is viewing the exterior or the interior of the David Anderson object, actions which can be performed on that object ought to be available.

Yes, I agree.

At IBM we used to talk about this concept in a slightly different way. We talked about "User Perceivable Objects" which is something which the user believes is an object. The important word is "believes". It doesn't necessarily have a one to one correspondence with anything which is an object as far as the system is concerned (the domain model). Ideally, [a user perceivable object] would map directly to a domain object but it doesn't need to.

We used to say that, "regardless of the current form of an object, if it interacts with an appropriate tool then the appropriate data would be extracted from the object and used to perform the tool's operation".

In your example, the "call" button would be an appropriate tool. So an object such as David Anderson, or Giovanni's Restaurant, or something else which might have a phone number, in this particular case, when it was selected in conjunction with the "call" button tool, the system would telephone that object, without having to specifically open the object and select the phone number.

In early CUA91 demonstrations, we used an example to give people an idea of what an object might be as a unit. We took a form which was actually a car loan application form. We then showed, that by dragging an icon of a person, to the form, all sorts of personal data could be extracted from the person object and taken into the form.

We were treating the person as a user perceivable object and the form as a tool which needed certain elements of data. None of that data was actually visible in the form of the object which could be seen at that time, the person icon, but because it was an object all of the details: what was your current car owned?; your association with the business?; the last time you purchased a car?; your address, phone number?; could be extracted and placed directly onto the order form for a new car.

That was the fundamental notion that a User Perceivable Object could supply the appropriate information to whatever tools were around or available within the interface.

In the mid-1990s I was a big fan of the OOUI principles. I had been a big fan of the OS/2 workplace shell and I'd built products based on OS/2 - primarily because I needed a multitasking desktop operating system, the user interface wasn't the compelling reason for the platform selection.

However, in recent years, I have felt that OOUI was caught in a dead-end. The problem was one of metaphor overlapping with object definitions. Much of the object desktop idea didn't seem to work beyond the notion of dropping a document on the printer icon.

Perhaps you could give me some of the history of the OS/2 UI and the workplace shell and how that all developed over time?

I can really only give you the perspective we had within IBM. At that time there wasn't the cross company coopetition environment of sharing information that we have today. The culture at the time was one that didn't encourage discussion outwith the company and its various divisions.

All the UI work was rooted in an effort within IBM in the early 1980s to try and standardize look and feel on various pieces of technology. That really culminated in SAA, Systems Application Architecture and the styleguide for SAA which was CUA in 1987 [CUA87].

At the time, there were various software projects within IBM which planned to use the CUA87 styleguide as the basis for their user interfaces.

Yeeesss! Although CUA89 was much more closely aligned with that. CUA87 had to deal with issues like: how do you do this on a 3270 terminal; and how do you do this on an AS400 character screen. So CUA87 had a broad mission to be a styleguide for all platforms including GUI PC, character based PC, character based AS400 and character 3270 terminals. All in the same styleguide, which, of course, was quite a challenge.

In some ways it led to quite an incomprehensible styleguide. It featured a lot of areas where there was different advice for each device saying something like, "do this on one device, then do this other thing on the next device, and do something else completely different on another", and so on.

We completed the CUA87 styleguide and we started to look at applications which were planning to use the elements from the styleguide in order to govern the design of the applications. When we started to look at these in detail, we began to realize that if you put two applications side by side, there was no commonality between them. Despite the fact that they were using a common look and feel specification, when you looked across each one there were significant differences between the applications. So we started to ask the question, "Why was there no similarity? What was the problem?" That was the point at which we started to search for the answer to this. What was causing the dissimilarity?

So was this an initial awakening to the issues around a-modal design? By introducing applications which had no similarities between them, you were inadvertently introducing additional modes of operation into the system operation, despite the fact that you had a common set of guidelines for each?

It wasn't just a concern for modes. The real concern was that we were IBM; we had a styleguide; and if you bought two applications from IBM shouldn't you be able to use those without having to retrain completely when you move from one to the other.

Reducing the need for retraining was the key business driver for the initiative. So we began to look at the problems and came to the conclusion that it was because [the applications] didn't share the same [data] model. Although at that time we didn't call it a model, not back in 87.

We started to look at, "why does this part of the screen look the same but the rest [of the application] doesn't?" We concluded that it was because different applications were presenting the same collections of data but in different ways. We could see the similarities and we were sure that the users could see them too. So that was the observation which started the movement towards the OO work and the Workplace Shell work which came later.

The key to Workplace Shell design came when we looked at office applications. We looked at office suite proposals. All the applications in the suite were handling documents. So shouldn't the documents be the primary thing [in the interface] and then the things that you can do with them (the behavior) be the stuff that the applications do.

Well if you are going to do that then you need to design a whole system which manages documents for every application. So it isn't a big step to go from there to an object centric view of a system. An object centric system is just a generalization of a document centric system.

I know that part of the Workplace Shell work had a motivation based on a movement to component based software. A move away from big, kludgey, "thudware" applications where functionality was being duplicated across applications e.g. spell checking. The notion that code was just being cut'n'paste from one application to another which was begging for the question, "Why weren't tools like spell checkers supplied in the operating system as components?" Of course components like that could be reused!

Yes. Why wasn't there? The truth is that we never completed the engineering of such a system. In the designs, we had determined that there should be common services. Even basic things like an Open Dialog were specified as common services, as early as 87.

We were starting at the bottom with basic functionality and we never ever got as high as functions so advanced as spell checking. It's the nature of the business. You have to ship on a given day and you try to pack as much in to the release as possible but you just never get everything that you know needs to be there.

There was always a lot of debate about what should and should not be considered mandatory for any release.

Yes. That is indeed the deep regret that you get. You do all this inspirational design and you conclude that systems should be made from lightweight components, objects should plug into a shell and all those good things. Then you say, OK let's try and deliver this!

So then you look at a developer who says, "My product has to ship! It has to ship with all these functions, but you are not supplying those functions as common components in the operating system. Therefore, I have to ship them in my application".

Once you get that across three application vendors, all of a sudden, you have three different versions of something which should have been a common facility, a common function, a component e.g. a spell checker.

You are left with the regret that you are unable to leap in and persuade them that they should be providing that facility for the operating system as a common facility so that everyone can share it.

I think that we convinced people that it was the right way to go. It was the execution of the plan that failed.

Do you perceive that we are finally moving towards that now on the web with the emergence of Application Service Providers and the notion that you can aggregate components from several service providers into a single web page, coupled with the emergence of enabling technologies such as XML and XML-RPC (SOAP)?

This allows the notion that someone can setup, spellcheck.com and offer an XML service over http which is available to other applications on the web. Does that get us to where you hoped to go with OS/2 and Workplace Shell?

I think that it can happen and is happening. This idea is more like the sort of business model that we proposed. We had proposals where services would be incrementally paid for. An example might be a micropayment for each word which was spellchecked, billed as a service. I remember heated discussion of this notion in the late 1980s.

Once IBM had been seen to lose the lead in the desktop OS market, we lost the chance to push that sort of technology and those kinds of business models. You just can't push technology and business models like that until you have a common space where everyone can participate. With the web, the way it is now, we have a more open space. It doesn't have an individual ownership, the way the operating system market has. Over the last 10 years, unless you were Microsoft, it was pretty hard to supply services for every application which could become ubiquitous.

The web and its distribution model gave us the early version of an open platform. Somewhere that you could easily distribute free downloads of plug-ins, to give low levels of service and then sell higher levels of service later.

The business model has always been the key inhibitor of that next step [to components]. You have got to have a business model which allows the revenue to flow from the intellectual capital provider of the spell checking service to the application provider who needs a spell checker in their application.

It has always been the business model which has held this development back. You can only afford to give away so much free service before you have to start charging. There are a lot of companies at the moment willing to take the risk of giving away a lot of free service [over the internet] in the hope of finding a charging model later.

So, it all comes back to the business model. Clearly you can do these component based services but it requires the business model to be sorted out clearly before it will be the normal way of life for the software industry.

I think that the technology will solve the problem as soon as the business model allows it to be solved in an economic fashion. At the moment we could provide all of these services [ over the internet ] for free but we wouldn't have a way of understanding who should pay for what and when.

We are now seeing endless legal battles over linking, referencing, deep linking, aggregating other sites into frames and so forth. When someone aggregates someone else's content, some businessman wants to get paid for that.

Another example might be the music business and Napster. Ultimately, that is all about who gets paid and for what.

Another example, off the web, might be DVDs and region codes. What user based decision would give you region codes? Clearly none!

Yes, I think that is true. The impact will vary from one situation to another. For example, when you make a business transaction on the web, a retail purchase, there are lots of questions over which set of laws govern the transaction, trust issues and other concerns. You could make much more usable commercial websites, if you didn't have to accommodate such concerns.

The users don't want the level of complexity which is introduced in order to determine how much tax is paid from one state to another, and how much they should pay for shipping, and other dialogues introduced to reinforce or ensure safe, trustworthy transactions. What the user wants is to know, "what is on offer?", "what are it's qualities?", and "how much does it cost?"

You can significantly simplify [ the user interface ] if you can figure out how to sort out the business issues without involving the user.

Then we have the issue of whether it is business in the small scale between organizations trying to figure who owes whom and how much, or in the large scale when it's international and governments are involved and it's about tax, and currency transactions and the like. It can get very complicated.

There is a user expectation that these issues are irrelevant and ought to be sorted out. Users believe that these issues are irrelevant when they are dealing in the internet age with ".com" companies. They believe that these companies can trade internationally, magically across nation state boundaries.

If they ever take the trouble to read the 3 pages of small print, or they get caught with a bill from a carrier for import duty on something they already thought they had paid for, only then does it hit them that this is a complicated business. The user experience is eroded.

We, as User Interface Designers, cannot solve these problems. We must put pressure on the business people and bring to their attention that users are concerned about this and that they expect it to get simpler.

Can you tell us a little bit more about OVID. Where do you see it going? and how much have you been using it within IBM? I understand that you have used it on perhaps 200 projects to date.

Yes, we have, but it isn't nearly as tight yet, as it might sound from having written a book about it.

No not as such!

One of our goals designing OVID was that we wanted to pick from available tools and use that as the support tool. As new tools come on the market then we make use of the newer functions which might be available to help.

In 1995, we were using Rational Rose and Booch Notation. We adapted what we could find in that tool to our purpose. As IBM purchased a lot of Rose licenses we have tended to stick with that as a tool and develop [OVID] just behind the tool development. [OVID] hasn't been a big enough driving force in the industry to justify our own tool development. Although we have seen some tools come and go but we never ever had a business case which would have allowed us to go out and compete in the tools marketplace.

Adopted sounds terribly formal!

I do see people using very similar notations. I have no goal to get everyone to adopt OVID. I want to make a statement about what I see as a good way to do things. The current notation is the best I can manage with the currently available tools. If people want to use it or vary it, then that is fine with me.

I'd like to think that we give people more than just the benefit of a notation. A notation gives you a way to communicate in a common language amongst a design team. A way to move a set of documentation through a process.

That is exactly the reason that we did this in the first instance.

The core reason we started OVID was that we saw people writing user interface specifications in prose, handing them to someone else, who was responsible for the code. Finally the last person who touched the code before it was shipped was the person who really got to make many of the vital design decisions.

The whole reason for moving to a notation everyone could use, a notation which was readily accepted by programmers, was to avoid that loss of the original design intention. The choice of notation as one which was acceptable to programmers was of key importance. If they wouldn't accept it and use it then it was a pointless process.

My own view on this is a simple and pragmatic one. If IBM with OVID has the front running notation which has the most developed and best vocabulary, then we ought to pick that and work with that to get to a point where there is a consensus amongst industry leaders.

That would require two key things: IBM would have to open the standard and relinquish any proprietary ownership of it; and at the same time, some other egos in the field would have to take a step back and say, "Yes, we recognize that Dave Roberts has the leading notation, we accept that there is a demand to solve this problem, so let us start with the OVID notation and work from there."

That gives me no problems at all. From the IBM side, we are not hiding anything. We publish what we can about OVID when we can. I'm happy for others to be using it.

I'm not sure whether it is truly the front runner or not.

Well I have seen several other similar attempts some of which have been mentioned at uidesign.net over the last two years. However, it seems that OVID has the most elaborate and complete vocabulary so far.

It doesn't solve all of the problems though. I would like to see a method for representing the Unit of Work on the diagram, for example.

Yes, the Unit of Work is an interesting topic. It was good to be at TUPIS and discuss that a lot more.

There has never been a notation that we have been really comfortable adopting and because we didn't feel that we had a role in promoting a notation to the wider community, then we haven't pushed on issues such as unit of work. We have pushed issues such as Views and User Perceivable Objects, representations of Actions.

We have also looked at ways to auto-generate the user interface directly from the UML diagram. This is particularly useful for people who find it incredibly difficult to work in abstract notations. At some stage it is important to have a tool which will quickly generate a visualization of the diagram for those people who cannot follow the abstraction and who want to see the concrete design emerging.

Yes, I made this point too and possibly overly labored on it.

In the real world, the notation will not be used much outside the development lab. The designers and clients want to work in concrete storyboards which are clearly understandable and can be followed by the lay person.

Often people from a computer science background have a problem with the notion that you start with the concrete and you abstract from there in order to simplify, identify commonality and spot opportunities for reuse. Larry Constantine has this right when he talks of scenarios, the concrete and then Essential Use Cases which are abstract.

Of course, it's a cycle. You start with something concrete, you abstract and then you design a solution which is later manifested as something concrete.

As a total design team, you have to be in the abstract and in the concrete, simultaneously. It may not be that every member of the team can think in both formats but the team as a whole must be able to realize the concrete and think in the abstract, simultaneously.

Some people work best in the abstract or perhaps the opposite. Within the process, there needs to be team members who can gatekeep between these. We often find that a graphic designer can only work in the concrete. So we need to have another team member who can abstract from that graphic design work and communicate the abstraction to other team members who work with the abstract models.

Something which has pleased me immensely recently, is the ability to now link any file from an abstract element in Rational Rose. So you can link any class to say an image file. So now we have the ability to link the concrete design as an image to the abstract design as a UML diagram.

The one thing that I can't yet do is link a State directly to a picture of an object in that particular state.

I can see why that would be useful. It fits in nicely with some of the work on Statecharts which has been published at uidesign.net. If you can express the model of a UI as a Statechart then it makes sense that you should be able to hyperlink from the model to actual appearance.

Are you using Statecharts within OVID?

Yes. However, we insist on doing the State Tables. We use Statecharts for the initial design of the State model because it is a nice way to show the normal path through the space. It is important to transform that Statechart into a State Table and look at all the holes in the State Table where potential user interactions meet potential object states and think through each of those cases. Catching all of these exceptions makes the difference between a reasonable design and a really good design. It forces the designer to consider things like, "Why might the user press the 'Submit' button on an incomplete order, and what should happen next?" It is important to look at all of these exception states and events which might cause them.

I ask all the interviewees at uidesign.net this next question. I'm being a little unfair on you as you haven't had any advance warning.

If someone reading this interview should take away only one lesson from it, what would it be? What is the one most important thing about user interface design?

Gosh! I wish I had some notice. It's a tough question.

Design is always hard. There is always something that you never thought of which manifests itself at the end of the process and proves to be the most challenging. As a result, you must adopt a process which expects the unexpected and is flexible to change.

Waterfall methodology is definitely out. Iterative methods are essential.

There is an implication that multiple perspectives are essential. The big snag at the end might come from a marketing guy who suddenly says, "We can't sell a product which works this way." So the hardest problem to solve turned out to be a marketing one and nothing directly to do with UI design.

So, you need to adopt a multi-disciplined approach which copes with change. That is what is essential to move user interface design forward as a profession.