The power of metaphor has long been recognized in user interface design and more broadly in human interaction circles. More recently metaphor also found its way into the software development process. This paper aims to combine occurrences of metaphor in the two fields with ideas from the field of model driven architecture. We suggest that it is possible to create conceptual patterns based on metaphor that allow a high level description of interaction models and user interfaces, and can at the same time serve as structural units for modeling software applications.
Enterprise-centric computing has come a long way already. At least as far as intra-enterprise solutions are concerned, complex integrated systems are being successfully implemented and deployed. That means the encapsulated business logic is largely in place and major enterprise software companies such as SAP are in principle able to deliver suites that can be applied to almost every aspect of a company’s operations.
What has however been neglected over a long period of time in
enterprise software is what Frankel in [
Section 2 starts by introducing important principles of metaphor in user interfaces, followed by section 3 where current uses of metaphor in software development and the Tools and Materials approach are briefly introduced. we go on with presenting our ideas on modeling using metaphorically motivated entities in section 4 and comment on the challenges in section 5. Section 6 briefly touches upon current work and section 7 concludes this paper.
Metaphors appear all over user interfaces. Although the concrete
embodiment of some of the most widely known user interface
metaphors such as the DESKTOP metaphor are being challenged at
times, only rarely does someone call for their total abolition [
Take for instance the well-known and widely adopted metaphor DELETING IS THROWING AWAY found in virtually all modern operating systems. The highly technical operation of deallocating a file name is presented to the user as dragging an unwanted item into a trash can. Even more so, for providing a better match between this metaphor’s source and the target a file does not get irreversibly deleted but is recoverable until the trash can, or recycle bin, is emptied. Note that one reason why this metaphor is working so well lies in the fact that the metaphor can be visualized quite nicely.
Barr in [
In a generative view on the Peircean triad the object constitutes the concept to be conveyed by the sign. In the present example that concept is deleting a file. The representamen is the directly perceivable portion of the sign, here in form of an indexical icon linking to a recycle bin. What an individual user makes of the representamen is called the interpretant. Ideally, object and interpretant show a strong resemblance for the majority of users thus denoting a sign that “works”. Important for user interface metaphors is the concept of unlimited semiosis meaning that one sign’s interpretant can form another signs representamen. In this way a multiply interwoven net of signs can really bring a user interface metaphor to life. Here the fact that one can actually drag a “file” into the “recycle bin” strongly supports the underlying DELETING IS THROWING AWAY metaphor.
Presenting user interface metaphors in this way might make
Marcus’ definition more clear who defines them “as the essential
concepts in computer-mediated communication that substitute for
the underlying code and terminology of operating systems,
applications, and data” [
Quite a lot of work has been published on the use of metaphor in
user interfaces and computing in general during the 1980s, but not
before a decade later did interest spark in addressing the role of
metaphor in the software design process. Rather than only being
utilized for explaining functionality that is already in place or
being planned for, metaphors are seen as an aid to the
construction of software systems. Madsen in [
The awareness of metaphor as a constructive tool in software
development was certainly raised considerably when Kent Beck in
[
Largely unique in this area is the Tools and Materials approach. Coming from software engineering, Züllighoven and his team proclaimed an application-oriented evolutionary software development process. They define application-orientation as the orientation towards the tasks in a given application domain. They also demand that processes defined within a software system be easily adaptable to any given working context and finally expect such a system to be thoroughly user-friendly [14, p. 102].
Simply speaking, the T&M approach utilizes a guiding metaphor and three concrete core metaphors or conceptual entities along with some others to structure any specific application domain. It sees users being placed at a well equipped EXPERT WORKPLACE working with TOOLS on MATERIALS and having AUTOMATONS which relieve them of repetitive tasks that do not require user interaction.
Züllighoven and his team argue that these metaphors which are
partly grounded in anthropology and partly on ergonomics are not
only universally understood, but also perfectly apt to describe
self-determined human work. The metaphors are deemed
sufficiently concrete to let users and developers alike associate
useful ideas and at the same time are easily transferable to
different application domains [
The true beauty of the T&M approach however lies in the fact that metaphors are not only means of observation and communication between all stakeholders in the software development process, but also the cornerstones of the software application's architecture. The approach comprises a complete set of design patterns that allow mapping the conceptual patterns onto an object-oriented software model and constitute a major constructive step toward actual software implementation [14, pp. 185-280]. Along these patterns also the open-source framework JWAM1 had been created that constitutes a readily implemented infrastructure around the metaphorical concepts mentioned above. 1 See http://sourceforge.net/projects/jwamenvironment/ for details.
Yet the approach can be improved. From an HCI perspective the
application-oriented T&M approach still falls a little short when it
comes to empathy for the end-user. The reason for this is that it is
only concerned about structuring an application domain but not
about how elements of the resulting software application are being
presented to end-users. Only a rather vaguely defined usage
model is offered, based on the T&M metaphors. We however
believe that merely structuring the software application the same
way as the application model, i.e. using a small set of
anthropologically and/or ergonomically motivated metaphors, will
not automatically lead to a good user interface for several reasons.
First, in order to work in a graphical user interface any implicit
metaphor of the form THAT PIECE OF FUNCTIONALITY IS A TOOL or
THIS DATA STRUCTURE IS A MATERIAL has to have a usable
metonymy, i.e. one or more parts that stand for the whole of the
metaphor. Those parts need to be visually representable, such as
the RECYCLE BIN from section 2, to allow users understand
possible actions in the user interface. While for TOOLS that seems
quite possible (see e.g. the TOOLBOX metaphor in Adobe
Photoshop), this will often be difficult when trying to represent
rather abstract MATERIALS like a bank account or a workflow
template as in [
Second, as Johnson and Lakoff have observed, "comprehending one aspect of a concept in terms of another will necessarily hide other aspects of the concept" [8, p. 10]. This means that we usually use vehicles of a number of metaphors greater than one to explain more abstract concepts. Not every aspect of functionality of an application is really best explained using only the TOOL or the MATERIAL metaphor.
What remains is the fact that Züllighoven and his team very successfully modeled application domains and software applications alike using the same set of structural metaphors in various major software projects (cf. [14, pp. 9-14]). The T&M approach therefore seems to be a good starting point for further work.
Software application models, e.g. using the UML notation, are a useful means of communication amongst developers to arrive at a common understanding of a software application's structure and functioning. The perception of models as "needless slideware" shared primarily amongst some followers of agile development practices is likely to be overcome by advances in the fields of Model Driven Architecture and Model Driven Software Development. New disciplines such as Agile Modeling and developments such as the Executable UML are already pointing into that direction.
The kind of models that denote the inner workings of software
applications is however in general not a good means of
communication when it comes to non-technical stakeholders.
Arlow and Neustadt in [
These observations lead to the search for conceptually
easy-tohandle entities for modeling interactive software applications on a
considerably higher level than objects and classes. Metaphorical
concepts such as described in section 3.1 would constitute a
natural basis for such modeling entities. These elements could be
used in “classical” software application models and at the same
time be incorporated into prototypes of all kinds. In this way
developers can communicate with end-users using a common
vocabulary, greatly reducing impending frictions. However to be
adaptable and still remain apt for an automated transformation
into Platform Independent Models (PIM) or other forms of less
abstract representation, any such interaction element needs to be
reasonably well defined. Section 6 touches on a concrete example.
Arlow and Neustadt [
In the same manner we hope to establish a set of archetype interaction patterns that encapsulate the sort of metaphorical concepts touched upon in sections 2 and 3. Benefits in terms of communication with stakeholders are only one side. Structuring of interactive software applications along metaphorically motivated entities should also yield the usage model and subsequently a blueprint for the user-interface.
Without doubt the ideas presented so far are highly ambitious and challenges may seem daunting. However they can be broken up and tackled one by one.
First, an adequate set of interactional archetypes would have to be found. It is likely to turn out that such a set can only be defined for a certain kind of application at a time. The kind of contemplable applications might be expressed quite generally by an underlying guiding metaphor such as the EXPERT WORKPLACE proposed by Züllighoven or by any other form of a usage model. In a second step one would have to think about how the metaphors or differently rooted concepts underlying those interactional archetypes could be visualized and presented to the user. A set of interrelated UI elements, user interface patterns, resulting from this step could e.g. be used as building blocks in a graphical development environment. They would be used to not only produce the user interface but also map out a meaningful skeleton for the software application's implementation. At the same time also technical implementations for the desired target platforms have to be developed. In an MDA scenario that target platform would be a PIM, while in traditional software development mapping to design patterns as mentioned in section 3.1 presents itself as a natural choice.
Last but not least this approach would only live up to its full potential if adequately supported by a development environment that revolves around the conceptual elements chosen as a basis for modeling. Ideally such a development environment also offers extensive support for visual prototyping and modeling, allowing for generating artifacts helpful in communication with nontechnical stakeholders.
We are currently utilizing the Tools and Materials metaphors from section 3.1 for modeling a cost planning application that is to be used for gathering budget planning data from a company’s cost center managers.
The application is composed from a number of distinct tools that can each be used to work on their specific materials. An important material within the application is e.g. the Planned Cost Spreadsheet which holds planning figures and formulae. The appropriate tool to work on it is a Spreadsheet tool which in turn contains a number of sub-tools that are also being reused elsewhere in the application. One such example of a multiply reused sub-tool would be an Annotation tool that allows adding comments and other unstructured data to materials, in this case to spreadsheets. The advantage of using the metaphorical notion of tools and materials in this modeling process lies in the fact that non-technical stakeholders will find the resulting components easy to understand and their interrelationship easy to comprehend. At the same time as modeling and describing the application by the means of tools and materials, we are also trying to get to the bottom of how to best compile and present such models to the technically less inclined and also how to best support the transition to more specific design models afterwards.
Most likely, the production of interactive software applications using metaphorical archetypes as suggested in this paper will not result in the best conceivable interaction and interface design ever. It will however allow for a much more intense involvement of non-technical parties in the software development process where such an involvement used to exceed the available resources. At the same time it allows for software product lines that don't only look similar, but actually really feel belonging together without additional effort. Apart from that the use of interactive archetypes should also speed up the overall software application development process.