Providing systems that are more usable and useful.
Potentially, new Information Technology can provide significant benefits in terms of increased productivity for businesses, increased pleasure for individuals and increased effectiveness for communities. Yet, these potentials are often not reached in practice because building effective and efficient systems, especially those in which groups of human beings are “in the loop”, is difficult and time-consuming. Landauer, (1995) among many others, has shown that interactive IT systems developed without proper professional attention to usability result in minimal productivity gains (on the order of 1%/annum). A study of systems that did include proper professional attention to usability resulted in an average per annum increase in productivity of 30%. The cumulative effect of these differences over a decade is staggering. Yet, it is still often the case that applications are developed which ignore or oversimplify the human aspects of complex systems with the result that the systems are error-prone, inefficient, and frustrating. These problems, in turn, provide a significant barrier to the adoption of new systems. Reducing this barrier can directly increase IBM revenue. How can this barrier be reduced?
Significant improvements in the usability of applications can result from instantiating significant, reusable software components into a middleware layer from which developers can select needed functionality. For example, a social network analysis provides useful input for many office applications. Knowing who communicates with whom can be useful in disambiguating e-mail recipients, in collaborative filtering for web browsing, in putting together teams, in skills mining, in focusing sales effort on opinion leaders and so on. But developers of any one application are unlikely to have the time or the knowledge to include a social network analysis. Similarly, many applications can provide data for a social network analysis. Again, developers of any one application are highly unlikely to provide the monitoring functionality to collect such data. What we propose is that putting such functionality into a middleware layer will enable developers to invoke, rather than design, build, and debug such functionality. An added benefit for the end user is that any explicit information need only be input once, not once per application. For this vision of useful and usable application software to be realized, however, the development team must become aware of the existence of such functionality and understand how to use it. We believe we can greatly expand the pool of people capable of this via Pattern Languages. Patterns essentially encapsulate, in succinct diagrams, natural language, and/or pseudo-code, the essence of a recurring problem, its analysis and its solution. A Pattern Language is an inter-related set of such Patterns with cross-references.
Pattern Languages have wide utility in providing a way to access and understand the functionality provided by specialists. In particular, our initial focus is on providing a Socio-Technical Pattern Language. The past twenty years of research, development, and practice in individual user interface design has led to conventions that, while not perfect, work reasonably well much of the time. These practices have been instantiated in GUI tool kits, style guides, pattern languages, and guidelines. Increasingly, however, corporate customers as well as governmental agencies and communities are interested in systems that facilitate the productivity of teams, organizations, and even foster communication and cooperation across semi-permeable organizational boundaries. Knowledge of the socio-technical aspects of systems is currently fragmentary. The knowledge that does exist has not been codified in ways directly useful for development teams.
A Socio-Technical Pattern Language will encapsulate such knowledge in a highly understandable, usable, and useful form for the overall software development cycle. Pattern Languages serve as a lingua franca and can help facilitate meaningful conversations among marketers, end users, computer scientists, graphics designers, financial decision makers, and junior programmers about the purpose of a system, the desired functionality, and the shape of the instantiation of that functionality. Pattern Languages are useful throughout the software development process. They can help developers understand and analyze problems and create designs. Because a Pattern tends to collect together those sub-problems that must be dealt with in concert, a Pattern Language can also serve as a useful guide for project management structure, for testing and debugging, for maintenance, for documentation, and for migration; indeed, it can even help guide marketing and sales efforts by providing a succinct way of relating functionality to benefits. Theoretically, any form of “design rationale” might be useful in these same ways throughout the software life cycle. Inducing developers to write detailed “design rationale” documents de novo, however, has in practice proven extremely difficult. By contrast, once a community of practice becomes familiar with a Pattern Language, it is much easier to simply refer to the utilized Patterns and add a few notations.
Pattern Languages are useful, however, not only in solving problems; they are one of the few intellectual tools specifically useful in finding problems. Essentially, this means that a Socio-Technical Pattern Language can help lead people to perceive unmet needs and thereby design and build previously unanticipated systems, perhaps even expand IT into completely new industries.
1. Pattern Languages are incrementally useful. Unlike a “methodology” or a “mathematical formula”, the utility of the Pattern Language begins with the writing of the very first pattern and every additional pattern adds some value.
2. A Pattern Language can be developed by a community of practitioners. Unlike the development of a complex methodology, a Pattern can be easily proposed to the community by a practitioner even during an engagement. Even a partial Pattern can be publicly posted for comment. A practitioner may simply post an unsolved problem and describe a context in two paragraphs. Because Patterns can be developed incrementally, with open discussion, largely by the practitioners themselves, they are much more likely to become widely used within that community.
3. The process of developing the Pattern Language builds social capital in the community of practice.
4. The Pattern Language serves as an educational tool.
5. The effectiveness of individual practitioners depends to some extent on having access to the Pattern Language and the community that uses that Pattern Language. This could significantly reduce turnover rates as well as the impact of remaining turnover.