=Paper=
{{Paper
|id=Vol-159/paper-9
|storemode=property
|title=Modelling Software Applications and User Interfaces Using Metaphorical Entities
|pdfUrl=https://ceur-ws.org/Vol-159/paper9.pdf
|volume=Vol-159
|dblpUrl=https://dblp.org/rec/conf/uml/NillS05
}}
==Modelling Software Applications and User Interfaces Using Metaphorical Entities==
Modeling Software Applications and User Interfaces
Using Metaphorical Entities
Christian Nill and Vishal Sikka
SAP Advanced Technology Center, SAP Labs LLC
3421 Hillview Avenue
Palo Alto, CA 94304, USA
{christian.nill, vishal.sikka} @sap.com
ABSTRACT that their actual tasks would suggest. Additionally, ever more
The power of metaphor has long been recognized in user interface sophisticated user interfaces of packaged consumer software as
design and more broadly in human interaction circles. More well as of web applications such as amazon.com add to the rising
recently metaphor also found its way into the software expectations on usability also in enterprise software applications.
development process. This paper aims to combine occurrences of In this paper we seek to offer building blocks for the model-driven
metaphor in the two fields with ideas from the field of model construction of inherently user-friendly enterprise software
driven architecture. We suggest that it is possible to create applications.
conceptual patterns based on metaphor that allow a high level Section 2 starts by introducing important principles of metaphor
description of interaction models and user interfaces, and can at in user interfaces, followed by section 3 where current uses of
the same time serve as structural units for modeling software metaphor in software development and the Tools and Materials
applications. approach are briefly introduced. we go on with presenting our
ideas on modeling using metaphorically motivated entities in
Categories and Subject Descriptors section 4 and comment on the challenges in section 5. Section 6
D.2.1 [Software Engineering]: Requirements/Specifications – briefly touches upon current work and section 7 concludes this
Methodologies paper.
D.2.2 [Software Engineering]: Design Tools and Techniques –
User interfaces. D.2.11 [Software Engineering]: Software
2. METAPHORS IN USER INTERFACES
Architectures – Domain-specific architectures, description Metaphors appear all over user interfaces. Although the concrete
embodiment of some of the most widely known user interface
languages H.1.2 [Models and Principles]: User/Machine
metaphors such as the DESKTOP metaphor are being challenged at
Systems – Human factors H.5.2 [Information Interfaces and
times, only rarely does someone call for their total abolition [13].
Presentation]: User Interfaces – Graphical User Interfaces, User-
Taking Lakoff and Johnson’s influential findings into account,
Centered Design
such a turning-away from metaphors would have to fail altogether
anyway, as “metaphor is pervasive in everyday life, not just in
General Terms language but in thought and action. Our ordinary conceptual
Design, Human Factors system, in terms of which we both think and act, is fundamentally
metaphorical in nature” [8, p.3]. Metaphor must not be
Keywords understood only as a linguistic construct but rather as a
fundamental cognitive mechanism that allows us “to use one
Metaphor, MDA, Design Patterns, Software Application
highly structured and clearly delineated concept to structure
Development, User-Interface Design, Interaction Design, Tools
another” [8, p. 61].
and Materials Approach
Take for instance the well-known and widely adopted metaphor
DELETING IS THROWING AWAY found in virtually all modern
1. INTRODUCTION operating systems. The highly technical operation of deallocating
Enterprise-centric computing has come a long way already. At a file name is presented to the user as dragging an unwanted item
least as far as intra-enterprise solutions are concerned, complex into a trash can. Even more so, for providing a better match
integrated systems are being successfully implemented and between this metaphor’s source and the target a file does not get
deployed. That means the encapsulated business logic is largely in irreversibly deleted but is recoverable until the trash can, or
place and major enterprise software companies such as SAP are in recycle bin, is emptied. Note that one reason why this metaphor is
principle able to deliver suites that can be applied to almost every working so well lies in the fact that the metaphor can be
aspect of a company’s operations. visualized quite nicely.
What has however been neglected over a long period of time in Barr in [3] has examined the semiotic foundations of user
enterprise software is what Frankel in [5] calls the user interface metaphors following the triadic notion of signs by
interaction logic and consequently also the user presentation. Far Charles Sanders Peirce (1839 – 1914). Figure 1 attempts their
too often end-users of enterprise software are forced to think in visualization along the example just introduced. A sign in
terms of database operations and transactions rather than in terms semiotics is generally “something that stands for something else,
to someone in some capacity" [11], which means that among being planned for, metaphors are seen as an aid to the
many other things, metaphors as well as icons can be treated as construction of software systems. Madsen in [9] reports on the
signs. great influence of the selection of originating metaphors on the
shape of the resulting system. She then proposes specific
guidelines regarding the generation, evaluation and development
of metaphors underlying software systems.
The awareness of metaphor as a constructive tool in software
development was certainly raised considerably when Kent Beck in
[4] listed the system metaphor as one of the original 12 principles
of extreme programming, although in his work he did not
elaborate greatly on its correct use within the XP methodology.
An even more high-level use for a special kind of metaphors in
enterprise architecture modeling was proposed by Khoury in [7].
He sees an ideal vehicle for structuring enterprise applications in
organizational metaphors. As opposed to concrete metaphors like
the RECYCLE BIN mentioned in section 2, organizational metaphors
are motivated by societal structures. Examples for sources of these
metaphors comprise e.g. auctions, games, or committees.
3.1 The Tools and Materials approach
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
Figure 1: Unlimited Semiosis applied to a "Recycle Bin" icon such a system to be thoroughly user-friendly [14, p. 102].
and the DELETING IS THROWING AWAY metaphor in the semiotic
triangle. 3.1.1 Overview
In a generative view on the Peircean triad the object constitutes Simply speaking, the T&M approach utilizes a guiding metaphor
the concept to be conveyed by the sign. In the present example and three concrete core metaphors or conceptual entities along
that concept is deleting a file. The representamen is the directly with some others to structure any specific application domain. It
perceivable portion of the sign, here in form of an indexical icon sees users being placed at a well equipped EXPERT WORKPLACE
linking to a recycle bin. What an individual user makes of the working with TOOLS on MATERIALS and having AUTOMATONS
representamen is called the interpretant. Ideally, object and which relieve them of repetitive tasks that do not require user
interpretant show a strong resemblance for the majority of users interaction.
thus denoting a sign that “works”. Important for user interface
Züllighoven and his team argue that these metaphors which are
metaphors is the concept of unlimited semiosis meaning that one
partly grounded in anthropology and partly on ergonomics are not
sign’s interpretant can form another signs representamen. In this
only universally understood, but also perfectly apt to describe
way a multiply interwoven net of signs can really bring a user
self-determined human work. The metaphors are deemed
interface metaphor to life. Here the fact that one can actually drag
sufficiently concrete to let users and developers alike associate
a “file” into the “recycle bin” strongly supports the underlying
useful ideas and at the same time are easily transferable to
DELETING IS THROWING AWAY metaphor.
different application domains [12].
Presenting user interface metaphors in this way might make
The true beauty of the T&M approach however lies in the fact that
Marcus’ definition more clear who defines them “as the essential
metaphors are not only means of observation and communication
concepts in computer-mediated communication that substitute for
between all stakeholders in the software development process, but
the underlying code and terminology of operating systems,
also the cornerstones of the software application's architecture.
applications, and data” [10]. However, note in particular from the
The approach comprises a complete set of design patterns that
comments above that for a user interface metaphor to work it
allow mapping the conceptual patterns onto an object-oriented
needs to be educible. Otherwise it would need to be explained to
software model and constitute a major constructive step toward
the user beforehand which is clearly suboptimal.
actual software implementation [14, pp. 185-280]. Along these
patterns also the open-source framework JWAM1 had been
3. APPLICATION DEVELOPMENT created that constitutes a readily implemented infrastructure
Quite a lot of work has been published on the use of metaphor in around the metaphorical concepts mentioned above.
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
1
utilized for explaining functionality that is already in place or See http://sourceforge.net/projects/jwamenvironment/ for details.
3.1.2 Criticism fidelity" prototypes at an early stage are in the course being
Yet the approach can be improved. From an HCI perspective the substituted by more sophisticated and functionally accurate ones
application-oriented T&M approach still falls a little short when it later on. These prototypes form the backbone for end-user
comes to empathy for the end-user. The reason for this is that it is involvement once the initial requirements gathering has been
only concerned about structuring an application domain but not concluded. End-users, as well as other non-technical stakeholders,
about how elements of the resulting software application are being will express their thoughts related to visual elements of these
presented to end-users. Only a rather vaguely defined usage prototypes. In a sense these prototypes act as high-level
model is offered, based on the T&M metaphors. We however interaction models that non-technical people utilize for
believe that merely structuring the software application the same understanding and talking about the software application being
way as the application model, i.e. using a small set of developed.
anthropologically and/or ergonomically motivated metaphors, will These observations lead to the search for conceptually easy-to-
not automatically lead to a good user interface for several reasons. handle entities for modeling interactive software applications on a
First, in order to work in a graphical user interface any implicit considerably higher level than objects and classes. Metaphorical
metaphor of the form THAT PIECE OF FUNCTIONALITY IS A TOOL or concepts such as described in section 3.1 would constitute a
THIS DATA STRUCTURE IS A MATERIAL has to have a usable natural basis for such modeling entities. These elements could be
metonymy, i.e. one or more parts that stand for the whole of the used in “classical” software application models and at the same
metaphor. Those parts need to be visually representable, such as time be incorporated into prototypes of all kinds. In this way
the RECYCLE BIN from section 2, to allow users understand developers can communicate with end-users using a common
possible actions in the user interface. While for TOOLS that seems vocabulary, greatly reducing impending frictions. However to be
quite possible (see e.g. the TOOLBOX metaphor in Adobe adaptable and still remain apt for an automated transformation
Photoshop), this will often be difficult when trying to represent into Platform Independent Models (PIM) or other forms of less
rather abstract MATERIALS like a bank account or a workflow abstract representation, any such interaction element needs to be
template as in [6]. reasonably well defined. Section 6 touches on a concrete example.
Second, as Johnson and Lakoff have observed, "comprehending Arlow and Neustadt [1] succeeded in a very similar approach
one aspect of a concept in terms of another will necessarily hide concentrating on the enterprise tier or encapsulated business logic
other aspects of the concept" [8, p. 10]. This means that we (again using Frankel's nomenclature [5]). They developed so-
usually use vehicles of a number of metaphors greater than one to called enterprise archetype patterns for the UML that could be
explain more abstract concepts. Not every aspect of functionality applied to the greatest number of businesses. Their patterns
of an application is really best explained using only the TOOL or include generic concepts such as product, inventory, order, and so
the MATERIAL metaphor. on which can be used as modeling entities in UML diagrams.
Every such archetype pattern usually spans a considerable number
3.1.3 Concluding Remark of classes. The huge advantage of these elements lies in their
What remains is the fact that Züllighoven and his team very semantic richness and the hiding of technical details, so that even
successfully modeled application domains and software non-technically inclined stakeholders such as managers and
applications alike using the same set of structural metaphors in domain experts can more fruitfully participate in the shaping of
various major software projects (cf. [14, pp. 9-14]). The T&M application models. Yet these patterns can be easily transformed
approach therefore seems to be a good starting point for further into standard UML diagrams and thus do not deviate from the
work. fundamental ideas behind MDA.
In the same manner we hope to establish a set of archetype
4. MODELING interaction patterns that encapsulate the sort of metaphorical
Software application models, e.g. using the UML notation, are a concepts touched upon in sections 2 and 3. Benefits in terms of
useful means of communication amongst developers to arrive at a communication with stakeholders are only one side. Structuring of
common understanding of a software application's structure and interactive software applications along metaphorically motivated
functioning. The perception of models as "needless slideware" entities should also yield the usage model and subsequently a
shared primarily amongst some followers of agile development blueprint for the user-interface.
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 5. CHALLENGES
developments such as the Executable UML are already pointing Without doubt the ideas presented so far are highly ambitious and
into that direction. challenges may seem daunting. However they can be broken up
and tackled one by one.
The kind of models that denote the inner workings of software
applications is however in general not a good means of First, an adequate set of interactional archetypes would have to be
communication when it comes to non-technical stakeholders. found. It is likely to turn out that such a set can only be defined
Arlow and Neustadt in [1] report on the poor levels of for a certain kind of application at a time. The kind of
comprehension that domain experts, users, and non-technical contemplable applications might be expressed quite generally by
managers demonstrate when interpreting UML models of almost an underlying guiding metaphor such as the EXPERT WORKPLACE
any kind. That is why virtually all practical implementations of proposed by Züllighoven or by any other form of a usage model.
user-centered design methodologies put an emphasis on often In a second step one would have to think about how the
iterating a user feedback cycle based on prototypes [2]. "Low- metaphors or differently rooted concepts underlying those
interactional archetypes could be visualized and presented to the resources. At the same time it allows for software product lines
user. A set of interrelated UI elements, user interface patterns, that don't only look similar, but actually really feel belonging
resulting from this step could e.g. be used as building blocks in a together without additional effort. Apart from that the use of
graphical development environment. They would be used to not interactive archetypes should also speed up the overall software
only produce the user interface but also map out a meaningful application development process.
skeleton for the software application's implementation.
At the same time also technical implementations for the desired 8. REFERENCES
target platforms have to be developed. In an MDA scenario that [1] Arlow, J. and Neustadt, I. Enterprise Patterns and MDA -
target platform would be a PIM, while in traditional software Building Better Software with Archetype Patterns and UML.
development mapping to design patterns as mentioned in section Object Technology Series. Addison-Wesley, Boston, MA,
3.1 presents itself as a natural choice. 2003.
[2] Ashley, J. and Desmond, K. Oracle. Interactions, 9(2):81–
Last but not least this approach would only live up to its full
86, 2002.
potential if adequately supported by a development environment
that revolves around the conceptual elements chosen as a basis for [3] Barr, P., Biddle, R., and Noble, J. A semiotic model of user
modeling. Ideally such a development environment also offers interface metaphor. In The 6th International Workshops on
extensive support for visual prototyping and modeling, allowing Organisational Semiotics, Reading, UK, 2003.
for generating artifacts helpful in communication with non- [4] Beck, K. Extreme Programming Explained: Embrace
technical stakeholders. Change. Addison-Wesley, Boston, MA, first edition, 1999.
[5] Frankel, D. S. Model Driven Architecture: Applying MDA to
6. CURRENT WORK Enterprise Computing. OMG Press. Wiley Publishing, Inc.,
We are currently utilizing the Tools and Materials metaphors from Indianapolis, IN, 2003.
section 3.1 for modeling a cost planning application that is to be
[6] Gryczan, G., Wulf, M., and Züllighoven, H. Prozeßmuster
used for gathering budget planning data from a company’s cost
für die situierte Koordination kooperativer Arbeit. In
center managers.
Herausforderung Telekooperation (D-CSCW ’96), pages 89–
The application is composed from a number of distinct tools that 103. Springer, Berlin, Germany, 1996..
can each be used to work on their specific materials. An important
[7] Khoury, G. R. and Simoff, S. J. Enterprise architecture
material within the application is e.g. the Planned Cost
modelling using elastic metaphors. In Proceedings of the
Spreadsheet which holds planning figures and formulae. The
first Asian-Pacific conference on Conceptual modelling,
appropriate tool to work on it is a Spreadsheet tool which in turn
pages 65–69, Darlinghurst, Australia, 2004.
contains a number of sub-tools that are also being reused
elsewhere in the application. One such example of a multiply [8] Lakoff, G. and Johnson, M. Metaphors We Live By. The
reused sub-tool would be an Annotation tool that allows adding University of Chicago Press, Chicago, IL, 1980.
comments and other unstructured data to materials, in this case to [9] Madsen, K. H. A guide to metaphorical design.
spreadsheets. The advantage of using the metaphorical notion of Communications of the ACM, 37(12):57–62, 1994.
tools and materials in this modeling process lies in the fact that
non-technical stakeholders will find the resulting components [10] Marcus, A. Metaphors and user interfaces in the 21st
easy to understand and their interrelationship easy to comprehend. century. Interactions, 9(2):7–10, 2002.
At the same time as modeling and describing the application by [11] Peirce, C. S. Collected Writings. Harvard University Press,
the means of tools and materials, we are also trying to get to the Cambridge, MA, 1958.
bottom of how to best compile and present such models to the [12] Rose, H., editor. Objektorientierte Produktionsarbeit, pages
technically less inclined and also how to best support the 23–54. Campus Verlag, Frankfurt, Germany, 1996.
transition to more specific design models afterwards. [13] Tristram, C. The next computer interface. Technology
Review, 104(10):52–61, December 2001.
7. CONCLUSION [14] Züllighoven, H. et al. Object-oriented construction
Most likely, the production of interactive software applications
handbook: developing application-oriented software with
using metaphorical archetypes as suggested in this paper will not
the tools and materials approach. Morgan Kaufmann, San
result in the best conceivable interaction and interface design
Francisco, CA, 2004
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