Interaction design is used to create useful, usable, and desirable software products for its users. However, there are groups of people who interact daily with software products but do not benefit from interaction design: software developers. These are the people that build our software, yet the tools they use are woefully inadequate.
Software development suffers from longitudinal usability issues. Software development tools (commonly known as IDEs, or integrated development environments) ask developers to continuously make small and seemingly unimportant decisions, which have subtle, long-term, and often large consequences. Without paying attention to “good software design,” maturing software becomes increasingly inert. Software design, however, cannot be qualified as good or bad in isolation. It is dependent on two external factors: the expected change patterns and the software developer performing the changes. When change requirements exceed the skills or expertise of the software developer, three symptoms can be observed:
- A change requires gathering of know-how.
- A change is performed at many locations.
- A change consists of values that depend on one another.
What is common to all these symptoms is that they involve “conventions.” A convention consists of implicit rules, which are required to perform a change. The existence of conventions indicates considerable usability issues.
Conventions are physically separated from the software. In the best case they appear as comments or in separate documentation. But usually, they reside in the mind of the software developer, subject to being forgotten.
Conventions increase cognitive load for the software developer. Owing to the nature of conventions, the software developer has to apply them repeatedly. Manual repetition provokes errors, which need correction. Consciously followed or not, conventions certainly create cognitive load.
Conventions have an explosive nature. As software grows, more and more conventions overlap with each other. Consequently, the combinatorial interaction among them grows exponentially.
The existence of these conventions can point toward a definition of “good software design”the state of software when developers can perform anticipated changes without proliferation of conventions.
When software is changed with a focus on supporting a particular functionality, the holistic design of the software gets out of balancethe conventions proliferate or become unknown. Changes to individual pieces of software, therefore, need to actively anticipate the future of “the whole” through a process of refactoring. Refactoring is the process of increasing software flexibility while user visible functionality is preserved. At each step the software is restructured by separation into units of concerns. The idea is to repeat refactoring until the product has regained the state of good software designuntil the software is in a state where developers can perform anticipated changes without proliferation of conventions.
However, refactoring has limits. Refactoring comes to a halt as it reaches the border of the programming language. The idiosyncrasies of the used programming language prevent the remaining conventions from being refactored or factored out. There is a name for such conventions: design patterns. The book Design Patterns states : “Our design patterns capture many of the structures that result from refactoring.” In other words, design patterns are residual conventions after refactoring for good software design.
It is noteworthy that certain design patterns have been successfully factored out for some programming languages [2, 3]. These findings confirm that what constitutes a design pattern depends on what is considered good software design. Otherwise, design patterns would not have been discovered in the first place.
Design patterns are specific to programming paradigms. Programming paradigms represent the core programming concepts understood by the software developer. While many claim to be programming paradigms, only a few qualify as fundamental:
- Imperative programming
- Functional programming
- Object-oriented programming (OOP)
- Model-driven engineering
These paradigms are characterized by their restrictive view. The names they carry signal that the entire software is expressed in terms of a single concept: Everything is an instruction, a function, an object, or a model.
Design patterns exist for all these paradigms. The original Design Patterns  includes 23 design patterns for OOP. For imperative programming OOP itself is a design pattern. For pure functional programming languages, a monad is a design pattern to implement states or functions with side effects. Model-based paradigms are expected to accompany design patterns when overcoming their inherent static nature.
The existing paradigms were never intended for generic use. Except for imperative programming, the paradigms emerged as byproducts from the need to solve problems in particular domains:
- Functional programming: artificial intelligence (LISP, 1956)
- Object-oriented programming: simulation (Simula, 1962)
- Model-driven engineering: object-oriented design (UML, 1996)
The arbitrariness of the paradigms is responsible for making proliferation of conventions inevitable. As loosely defined as they are, there is no hint that they were formed by conscious design. Programming languages reuse and extend these arbitrary paradigms. The ones that commit themselves to a single paradigm proudly state that they are pure object-oriented or pure functional. Other programming languages can be classified as hybrid or even multiparadigm languages. Although programming languages include syntactic sugar as conveniences for commonly provoked conventions, the paradigms remain fundamentally unaltered.
Integrated development environments (IDEs) ease software development by integrating the most popular tools supporting a programming language under one graphical user interface (GUI). Popular IDEs like Eclipse include convenience features like quick fix, code assist, templates, and refactoring actions. While these features ease the application of conventions, they cannot eliminate the conventions imposed by the underlying programming paradigms.
Software development tools are a result of a process pattern typical to a young field: bottom-up development. Reuse is being practiced at a grand scale; neither programming language nor IDE invests energy to fix the problems rooted in the programming paradigms. While programming languages and IDEs are to some extent designed, programming paradigms are reused without consideration of long-term effects. Software development tools have scarcely evolved from a technology that has been conceived arbitrarily.
The obvious alternative to bottom-up development is top-down development. Neither bottom-up nor top-down development can be qualified as better or worse; both approaches are necessary to build any good system. To understand a new system, it has to be built bottom up, resulting in a functional but not very usable system. However, insight and confidence for building a better system result, and those are the preconditions for developing top down. Hence, top-down development is not just an alternative, but also a natural successor to bottom-up development.
While bottom-up development is pragmatic, top-down development requires planning and great staying power. As the successful construction of software development tools has demonstrated for decades, the remaining requirement to mitigate the risks of top-down development is a sound design method: interaction design. Interaction design is systematic, user-centric, and holistic. Some important implications of using interaction design to define software development tools deserve elaboration.
Interaction designers use persona as a model for simulating users interacting with technology. However, technology does not receive the same honor; it is assumed to be adaptive to the user, with no further personality or characterization.
In the context of software development, the computer deserves to be represented by a persona. A software developer has deep understanding and trust in the computer; she instructs the computer to perform tasks instead of doing them herself. In the eyes of the software developer, the computer behaves more like a human with extreme skills and obedience. While computers have no goals, they have the purpose of serving the user. When the computer is given an identity, the interaction designer can assign it a code of behavior, i.e., design principles. The principles are comparable to those in Isaak Asimov’s “Laws of Robotics,” albeit in a less dramatic tone. A good product asks for appropriate trust and respect from the user, more so if the user is a software developer. By allowing the interaction designer to take this into account, responsibilities are better distributed, unfolding in a better collaboration.
Current programming paradigms evoke mental models that have little to do with the nature of a computer. They reduce the computer to a function, an object, or a model. By shaping mental models that are neither suited for the developer nor for the computer, compromises occur that result in the usability issues we face today. A metaphor for the computer is needed. Today we still have a misconception of what a computer is. The Merriam-Webster dictionary defines the term as “a programmable usually electronic device that can store, retrieve, and process data.” Other dictionaries have been holding on to equally timid definitions for the past 30 years. What is a computer?
The main purpose of a software development tool is programming. Thus, defining the concept model implies finding the appropriate programming paradigm. With a good metaphor, most of the concept model can be easily derived. While there are usually limits to the metaphor’s affinity to the concept model, as long as the concept model does not violate the spirit of the metaphor, both metaphor and concept model support the user’s understanding of the product.
When a metaphor cannot reveal every detail of the concept model, the concept model should be as simple as possible. Existing programming paradigms have steep learning curves because their concept models are arbitrary and receive little help from their metaphors. As programming is inherently complex, we cannot expect a metaphor to reveal the entire concept model. To define the simplest concept model, this question must be answered: What is the essence of programming?
Once the concept model is defined, it is necessary to communicate it to the user. The user interface is a medium to reconcile between the mental model and the concept model. While the concrete interaction is different for every user-interface technology, the purpose of synchronization remains the same. As the concept model is technology agnostic and is defined under consideration of the software developer’s mental model, it is truly reusable.
While the concept model could be applied to modern peripheral technologies like AJAX or Microsoft Surface, the biggest surprise may happen for the most typical setup of monitors, keyboard, and mouse: visual programming. Today’s user interfaces are not limited to text. Programs are complex by nature and deserve a more tangible representation. As interaction design focuses on the best possible communication of concept models using the available technology, it is likely that the resulting user interface would exploit capabilities outside editing textual documents.
While the prospect of visual programming languages raised great expectations in the ‘90s, so far they have failed in replacing textual general purpose programming languages. What are the reasons to stay optimistic?
Visual programming is not a paradigm by itself. At the rise of GUIs, programming-language researchers tried to transition from textual to visual programming by transforming the syntactical aspect of the programming language to the graphical representation of programs. Stuck with the old programming paradigms, the new representation did not add significant value. Visual programming failed due to bottom-up development.
With interaction design, visual programming can be revisited with confidence. The holistic approach of interaction design extends beyond fancy user-interface design. By following the steps of defining a metaphor, the concept model, and the user interface, design development occurs systematically. Visual programming is not a goal but a natural result of applying interaction design to appropriate peripheral technology.
The future is bright. Performing interaction design for software development environments will deliver a reusable concept model, including a new programming paradigm that considers long-term software development and maintenance. By applying the concept model to appropriate technologies, higher levels of interaction with the computer can result.
Claude Knaus is an independent researcher, drawing from his rich experience in the software industry. As a former software architect, he is determined to bridge the gap between software engineering and interaction design. At companies such as SGI, IBM, Khronos, Eyescale, and Esmertec, he has gained insights into the oil and gas, avionics, automotive, and mobile industries. His technology background covers the range from virtual reality to embedded systems and integrated development environments.
©2008 ACM 1072-5220/08/0700 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.