Dick Berry (reberry@us.ibm.com)
Dave Roberts
Scott Isensee
John Mullaly
User interface designers face a big challenge. On one hand are the implementors, the programmers struggling to churn out enough content to make steadily doubling telecomputing capacity pay off for its users. On the other hand are the users, Apple's "rest of us," those who determine worth through buying the software that pays everybody else's salaries.
Getting these groups to work together is no job for quick fixes. But this book doesn't promise that; just a novel way to facilititate interaction and collaboration between programmers and users. This is a refreshing alternative to the pervasive assumption that users and implementors will inevitably misunderstand one another. I plan to encorporate this approach in my own work and hope you will see the worth of this in your work also.
I would rather not admit how long it took for me to appreciate that differences between individuals are not small. Even in culturally homogeneous circles; even when we speak the same language and were educated in similar schools, the differences in how people view the world and express our identity within it can be as different as between the warring Hutu and Tutsi. Although the result of today's communication struggles are rarely as bloody, they are just as devastating to the quality of technical creations such as software.
For example, consider Unix's command-line user interface. Kernighan's Software Tools, to pick one book among many, described a philosophy that implementors such as myself continue to find deeply compelling -- that software tools should be small, should handle very narrow jobs and should be combined with other tools to solve the problem at hand.
As a result, early Unix tools such as mail did not paginate on the grounds that this "should" be handled by a separate tool. When users complained, then, that their mail scrolled by too fast to read, this was the user's fault for not understanding the small tools philosophy. It took years to recognize this problem as a miscommunication between people with very different views of the world, not as the "fault" of either side.
By contrast, consider the philosophy behind IBM's RealPhone application (discussed in this book). The core value is that software should be consistent with how the users view their world without sending them to the manual to learn how they "ought" to think about their work.
The point is not that the implementor's worldview is wrongminded and extinct. Quite the opposite. Today's user-friendly applications are indisputably produced by implementors who have perfectly sound reasons for seeing the world differently from other people. After all, our (the implementors) job requires that we see the computer from the other side of the screen. Although users have sound reasons for concentrating on surface appearance; how things appear on the screen, we have equally valid reasons for concentrating on underlying form; how it all works inside.
In Zen and the Art of Motorcycle Maintenance; An Inquiry into Values Robert Pirsig develops a distinction between "romantic" and "classical" ways of understanding. The romantic way of understanding is a user's artistic appreciation of surface appearance. The "classical" way is an implementor's "scientific" appreciation for underlying form.
This distinction between "romantic" and "classical" helps to challenge the myth that these two ways of understanding cannot coexist. Pirsig argues that although there is a deep chasm between these two worldviews, it is possible to bridge it. His name for this bridge is none other than "Quality," the feeling we get when a product satisfies both our classical and romantic needs.
Nonetheless this myth flourishes today. Consider Dilbert for example, Scott Adam's cartoon hero of cubicle dwellers everywhere. Dilbert is the typical classical thinker, pursuing an engineer's focus on underlying form. Dilbert's antagonist, "The Boss," pursues a manager's romantic focus on surface appearance. Each week the reader is encouraged to believe that the two views are irreconcilable; that Dilbert's relationship with The Boss will continue to disappoint; that no bridge can transcend the chasm between them; that Pirsig's Quality is not a possibility within post modern organizational life.
This myth is so prevalent, and so malevolent, that it is refreshing to find a technical book that starts from exactly the opposite premise. Developing Software Using OVID assumes from the outset that diversity is the solution, not the problem. It then moves on to provide techniques for bridging the chasm in worldview and vocabulary that would otherwise keep users and implementors from cooperating (due to lack of understanding). Reduced to bare essentials, the user interface designer's task is to translate the user's view of the solution into problem statements implementors can understand, as follows:
As Dilbert (and Bosnia and Rwanda) shows, it's not easy to get people with different world views, skills, norms and terminology to work together. But this is exactly what must be done to build software that doesn't disappoint. The user interface designer just stands in the middle, translating signals from each side into meanings the other is able to understand. Its really just as simple as that. And as hard.
The belief that people with diverse world views, priorities and languages can leverage their diversity as a strength ultimately drew me from Software Engineering to my current work in Organizational Learning. This belief resulted from a growing conviction that users actually do know what they need. Their understanding, however, is in terms of surface appearance, a "hip" artistic way of understanding that isn't accessible to engineers trained to a "square" scientific focus on underlying form.
This gap between users and engineers is an often noticed but seldom recognized issue. In this book, IBM not only recognizes the impact of the issue, but goes further to address the issue through the use of OVID. The gap is not likely to close in on its own, so this book is of critical importance in our endeavors to leverage differing worldviews in order to successfully develop software in combination with users, user interface designers and programmers.
| Virtual School | Middle of Nowhere | Brad Cox |
|---|