In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
MoRoCo 2013: Models and their Role in
Collaboration
Alexander Nolte1, Michael Prilla1, Peter Rittgen2, Stefan Oppl3
1
Department Information and Technology Management, University of Bochum,
Germany
nolte@iaw.rub.de, prilla@iaw.rub.de
2
School of Business and IT, University of Borås, Sweden
peter.rittgen@hb.se
3
Department of Business Information Systems, Johannes Kepler University of
Linz, Austria
stefan.oppl@jku.at
Abstract. Using visual representations of work or business processes can be considered
a common practice in modern organizations. These models serve a large variety of
different purposes such as documentation of current practices, or informing and planning
change or software development. Given the nature of work and businesses they reflect it
is reasonable to develop and use them collaboratively. There are, however, also many
downsides to collaborative model usage and development in current practice. Among
others, models are often not fully understood and are thus not used by people who work
in the processes the models represent, resulting in limited impact of process redesign on
everyday work. Furthermore, only a minority of people within organizations actually use
models, even though they have been proven to be very useful especially for collaborative
work. Given the increasing popularity of models in organizations, understanding and
defining their role in collaboration is of vital interest for the CSCW community and
therefore this workshop aims at bringing together researchers and practitioners and
forming a community for research in this area.
1
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Introduction
The usage of visual representations of static parts of an organization (e.g.
diagrams depicting hierarchies in the organization’s structure or a company’s
competences), dynamic aspects (e.g. work and business processes) or results of
creative problem-solving sessions (e.g. brainstorming results) can be considered a
common practice in modern organizations. These visual representations include
process models, conceptual models and mind maps. They are used for multiple
tasks such as software development, design and engineering, process optimization
and reengineering as well as marketing and strategic development. Obviously,
these models are hardly ever artifacts that are used and developed by single users
for their own personal needs. They are rather developed for larger target groups
throughout an organization to support them in sense making and creating a shared
understanding about cooperative work and its interfaces. Consequently, they are
both used by many people and developed collaboratively. However, the number of
people that are affected by these representations is usually larger than the number
of people who participate actively in their development. The need to create
communicable and comprehensible models is thus evident.
Alongside the increasing usage and popularity of visual representations in
organizations, there also is growing interest in their usage and development in the
CSCW1 community. This comprises not only the usage and development by
modeling experts, but explicitly takes users into account that are no experts in
modeling, thus including factors that might motivate or hinder them to use models
and actively participate in their development. The emerging importance of this
new field of CSCW research is reflected by workshops (e.g. “TAProViz” at BPM
2012 and “CollabViz” at ECSCW 2011), tracks at international conferences (e.g.
“Collaborative Modeling” at HICSS 2009, 2010, 2011 and 2012), papers at
various CSCW related conferences (e.g. Baacke, Rohner, Winter & Fitterer, 2009;
Brosch, Seidl, Wieland, Wimmer & Langer, 2009; Herrmann & Nolte, 2010;
Klebl, Hackel & Lukosch, 2009; Nolte & Prilla, 2012), journal contributions
(Heer, Bostock & Ogievetsky, 2010; Renger, Kolfschoten & De Vreede, 2008;
Rittgen, 2010; Yuille & Macdonald, 2010) and journal special issues (Prilla,
Nolte, Herrmann, Kolfschoten, & Lukosch, 2013; Rittgen, 2009, 2012).
Additionally, there are various parallel approaches in related research
communities such as Group Decision Support, Business Process Management and
Group Support Systems.
However, despite the fact that modeling is a popular approach in practice and
thus, many models exist in organizations, they are only used by a minority of the
people. This consequently leads to them only playing a minor role in everyday
work of the employees of an organization. This is quite surprising considering the
fact that models have proven to be very useful for cooperative work, especially
1 Computer-Supported Cooperative Work
2
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
when planning it. Furthermore, the number of people creating models stands in
stark contrast to the number of people that are actually affected by planning based
on these models. Even if they are created collaboratively by process stakeholders,
they often have little impact on the people that are actually working in these
processes (cf. Prilla, 2010) and thus do not transcend into work practice. The
reasons for this are manifold. First, there are few insights on how to spread
models and sustain their usage in organizations thus coupling them with activities
and artifacts of everyday work. This explicitly includes a lack of knowledge about
factors that might motivate or hinder model usage and development. Furthermore,
up to now, little is known about how people interact with models that are no
modeling experts. By interaction of these non-expert users, we not only refer to
model creation, but also their usage in people’s daily work for e.g. discussion,
knowledge elicitation and creating a common understanding. Non-expert
interaction with them however proves to be an issue, as people that are involved
in processes usually are no modeling experts. Interaction in this context includes
enabling people to use modeling languages and thus to directly contribute to
model development, as well as providing other means such as textual or visual
annotations to enable indirect contributions. This leads to the question of how
models can be coupled with other artifacts of everyday work, which might prove
to be beneficial for their usage and ultimately increase their impact.
Besides the usage of models by non-experts, there is an additional research gap
in the collaborative construction of visual representations. Usually, the creation
and modification of models is restricted to collocated workshops and similar
modes of interaction and collaboration, where experts are required to facilitate
and support the modeling process. Despite their applicability and feasibility in
many situations, these workshops simply do not fit the need to rapidly adjust
processes to changing conditions inside and outside an organization. Given the
distributed nature of many organizations, these workshops also do not sufficiently
reflect the need to include expertise distributed across different locations.
Therefore, finding ways to enable dislocated users to contribute actively to model
creation and maintenance in a collaborative modeling process is necessary.
Given the increasing usage of visual representations in organizations, their
collaborative and distributed use, creation and sustainment is of vital interest for
the CSCW community, which has a long tradition of researching the usage of
common artifacts, the influence on collaboration by artifacts and their
collaborative creation. This workshop therefore aims at being a starting point in
forming a community for research in this area.
It is a follow up to a workshop on “'Collaborative usage and development of
models and visualization” which was held at ECSCW 2011 in Aarhus.
Proceedings of which can be found online at http://ftp.informatik.rwth-
aachen.de/Publications/CEUR-WS/Vol-777/. Selected papers from the workshop
3
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
will also be published in a special issue of the International Journal for
eCollaboration (Prilla et al., 2013).
Scope and aim of MoRoCo
The goal of MoRoCo is to bring together researchers, lecturers and practitioners
from different fields, who are interested in the collaborative usage and
development and maintenance of structured visual representations such as process
models, conceptual models or mind maps. This includes experiences from
empirical case studies, teaching and the introduction of models and modeling into
organizations. The workshop aims at building a large picture of research on the
role that models play in collaborative work in order to set up a common research
agenda. The topics of the workshop thus include but are not restricted to:
The process of cooperative modeling: design cycles, model negotiation, view
integration, roles of participants in modeling, team organization, etc.
Sustaining model usage and maintenance in organizations
Motivating involvement and active usage of models
Involving non-experts in model development and usage
Increasing the range of involvement: from core stakeholders to all stakeholders
Coupling models with activities and entities of work
Roles of models for collaboration e.g. guides / maps
Models as instruments for consensus building
The role of models in spanning inter or intra organizational boundaries
Integrating visual modeling and model dialogues in natural language
“Meta”-modeling: structuring the dialogue around models
Access to models: Creating a model friendly cooperation environment
Alignment of different understandings about collaborative work during
modeling
Empirical evidence for positive effects of modeling and model use
The aim of MoRoCo is not to discuss the advantages and disadvantages of
different modeling notations. It rather puts strong emphasis in the role of models
in collaborative work including their collaborative development, collaborative
interaction with them as well as intertwining them with activities and artifacts of
everyday work.
Accepted papers
Eight papers have been accepted for the workshop after a thorough review by an
international program committee. These contributions reflect the broad scope of
the workshop in contributing to a variety of aspects in the area of how models
affect and are affected by collaboration.
4
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
In their paper Cooperation on Models and Models for Cooperation Gross and
Beckmann take a theoretically based stance on collaborative model and model
usage by applying Goffman’s framework of social interaction to these tasks. From
this perspective, they derive support needs for collaborative model usage and
development.
Two papers approach the interplay of modeling and creativity and outline how
creative processes can be supported methodologically and technologically. In his
paper Facilitating and Prompting of collaborative Reflection Process Models
Thomas Herrmann and Kai-Uwe Loser report on an approach to support socially
distributed reflection of diagrammatic process models. They identify two
fundamental concepts for reflection support: identification of model parts that can
be reflected on in disjoint social groups and computer-supported prompting to
substitute the role of a facilitator when reflecting in multiple groups. The paper
offers examples of how these concepts could be implemented using the SeeMe
modeling language and the socio-technical walkthrough. Bartelt, Vogel and
Warnecke also aim at supporting the interplay between creativity and modeling
within their work on Collaborative Creativity: From Hand Drawn Sketches to
Formal Domain Specific Models and Back Again. They discuss Scribbler, a
system for collaborative creation of hand-drawn models and their transformation
to formal domain-specific models (e.g. based on EMF) using sketch recognition.
Their toolset provides support for adaptively recognizing freehand drawings of
models created by multiple users and transforming them to formal EMF-models
and back again for further processing. The toolset is designed for collaborative
operation and provides a set of features that support the traceability of the
development history of models.
Using models to support collaboration in organizational environment almost
always involves laymen modelers, i.e. people who are experts in their area of
work but have no experiences in creating models or working with them. The
challenge of involving these people in modeling processes is discussed in three
papers presented at the workshop. In his paper Towards Role-distributed
Collaborative Business Process Elicitation, Stefan Oppl describes an approach in
letting different roles (stakeholders) in a modeling project model the processes
separated from each other and how to get resulting models into a commonly
agreed on model. Hoppenbrouwers, Thijssen and Vogels discuss in
Operationalizing Dialogue Games for Collaborative Modeling, how dialogue
games can be used for collaborative modeling. They present a methodology and a
prototypical tool that support the process of structuring and guiding conversations
for modeling. The paper focusses on the procedural guidelines necessary to
implement a dialogue game for modeling and gives a good impression of how it
could be facilitated. The description of the support system gives an overview of
how facilitation could be aided by software. In Beyond Collaborative Model
Usage and Development – A Model Lifecycle Approach for Lay User Modeling,
5
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Nolte and Prilla discuss the foundations of collaborative modeling with laymen.
They propose that we need concepts to engage users without modeling
capabilities into self-directed, user-managed processes of using and working on
models. They also presents a corresponding model lifecycle as well as suitable
interaction and participation modes, using examples from their work on
integrating lay-users into model usage and development.
Empirical studies on the effects of applying collaborative modeling in practical
settings on the modeling process and outcome are rarely available so far. One
paper that will be presented at the workshop has approached this topic. In their
paper The Added Value of Collaborative Modeling for Legal Business Rule
Management van Stokkum, Heiner, Hoppenbrouwers and Mulder describe a case
where collaborative modeling is used within the area of legal modeling. Particular
emphasis lies on combining business rule management with collaborative
modeling in order to create a broader acceptance for new rules that are being
applied. The paper thus provides an interesting and novel environment for
collaborative modeling techniques.
Poppe, Recker, Johnson and Brown argue that distributed collaborative
modeling requires support for visual cues used in co-located collaboration. In
Using natural user-interfaces for collaborative process modelling in virtual
environments they present their approach based on a 3D virtual world to facilitate
remote collaborative process model creation and validation. However, the added
complexity of having to navigate a virtual environment and using an avatar for
communication makes it difficult for novice users. An improved version of a 3D
modeling tool is supposed to address these issues by providing natural user
interfaces for non-verbal communication, navigation and model manipulation.
Program committee
Christian Bartelt, Clausthal University of Technology, Germany
Eike Bernhard, Queensland University of Technology, Australia
Sebastian Döweling, SAP Research Darmstadt, Germany
Benjamim Fonseca, UTAD / INESC TEC, Portugal
Stijn Hoppenbrouwers, HAN University of Applied Sciences, Netherlands
John Krogstie, Norwegian University of Science and Technology, Norway
Stephan Lukosch, TU Delft, Netherlands
Jan Mendling, Vienna University of Economics and Business, Austria
Hajo Reijers, Eindhoven University of Technology, Netherlands
Etiënne Rouwette, Radboud University Nijmegen, Netherlands
Barbara Weber, University of Innsbruck, Austria
6
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
References
Baacke, Rohner, Winter, and Fitterer, (2009): 'Component-Based Distributed
Modeling of Collaborative Service Processes - A Methodology for the
Identification of Reference Process Building Blocks.', HICSS pp. 1–10,
IEEE Computer Society.
Brosch, Seidl, Wieland, Wimmer, and Langer, (2009): 'We can work it out:
Collaborative Conflict Resolution in Model Versioning', Proceedings of
the 11th European Conference on Computer Supported Cooperative Work
(ECSCW 2009) pp. 207–214, Springer.
Heer, Bostock, and Ogievetsky, (2010): 'A tour through the visualization zoo',
Commun. ACM, 53 6, pp. 59–67.
Herrmann, and Nolte, (2010): 'The Integration of Collaborative Process Modeling
and Electronic Brainstorming in Co-Located Meetings', In G. Kolfschoten,
T. Herrmann, & S. Lukosch (Eds.), CRIWG 2010, LNCS 6257 pp. 145–
160, Springer-Verlag Berlin Heidelberg.
Klebl, Hackel, and Lukosch, (2009): 'The Application of Design Patterns for the
Adaptation of a Modeling Tool in Collaborative Engineering', In L.
Carriço, N. Baloian, & B. Fonseca (Eds.), Groupware: Design,
Implementation, and Use, Lecture Notes in Computer Science Vol. 5784,
pp. 262–269, Springer Berlin / Heidelberg.
Nolte, and Prilla, (2012): 'Normal users cooperating on process models: Is it
possible at all?', CRIWG 2012, LNCS 7493 pp. 57–72, Berlin: Springer.
Prilla, (2010): Wissensmanagement-Unterstützung für die Erzeugung und
Nutzung von Prozessmodellen als wissensvermittelnde Artefakte, Eul
Verlag.
Prilla, Nolte, Herrmann, Kolfschoten, and Lukosch, (2013): 'Special Issue on
Collaborative Usage and Development of Models', International Journal
of eCollaboration, 9 4.
Renger, Kolfschoten, and De Vreede, (2008): 'Challenges in collaborative
modelling: a literature review and research agenda', International Journal
of Simulation and Process Modelling, 4 3, pp. 248–263.
Rittgen, (2009): 'Special Issue on Collaborative Business and Information
Systems Design', International Journal of eCollaboration, 5 4.
Rittgen, (2010): 'Collaborative Modeling: Roles, Activities and Team
Organization', International Journal of Information System Modeling and
Design (IJISMD), 1 3, pp. 1–19.
7
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Rittgen, (2012): 'Special Issue on Collaborative Modelling', International Journal
of Organisational Design and Engineering, 2 1.
Yuille, and Macdonald, (2010): 'FEATURE The social life of visualization',
interactions, 17 1, pp. 28–31.
8
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Cooperation on Models and
Models for Cooperation
Tom Gross, Christoph Beckmann
Human-Computer Interaction Group, University of Bamberg, Germany
(.(at)uni-bamberg.de)
Abstract. In this paper we would like to propose a Janus head perspective on
cooperation and models: on the one hand cooperation on models is a very important type
of activity for groups who want to create shared models that are accepted by the group
members; on the other hand models for cooperation are an essential basis to develop
user-centred cooperative systems.
Keywords. Cooperation on models; models for cooperation; patterns.
1 Introduction
The organisers of this workshop on ‘MoRoCo – Models and their Role in
Collaboration’ at the European Conference on Computer-Supported Cooperative
Work - ECSCW 2013, point out in their call for papers that ‘using visual
representations for work or business processes can be considered a common
practice in modern organisations. These models serve a large variety of different
purposes such as documentation of current practices, or informing and planning
change or software development.’ (Nolte et al. 2013). Indeed, models play an
important role in Computer-Supported Cooperative Work (CSCW) as shared
artefacts in teams that are conceived, developed, and maintained by the teams.
Besides cooperation on models, models that structure the cooperation process
are an essential part of cooperation technology. Developing software that supports
teams cooperating—this software is often referred to as groupware—is a
challenging task and has been researched for more than two decades (Gross 2013;
Marca & Bock 1992). Groupware often has a strong influence on how teams will
work together. And, in fact, the effectiveness and efficiency of the teamwork as
9
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
well as the satisfaction of the individual team members strongly depend on the
quality of the concepts underlying the respective cooperative technology. Schmidt
(2011, p. vii) points out: ‘the development of computing technologies have from
the very beginning been tightly interwoven with the development of cooperative
work’. Schmidt (2011, p. vii) continues that: ‘our understanding of the
coordinative practices, for which these coordination technologies are being
developed, is quite deficient, leaving systems designers and software engineers to
base their system designs on rudimentary technologies. The result is that these
vitally important systems, though technically sound, typically are experienced as
cumbersome, inefficient, rigid, crude’.
In the light of this Janus head perspective—that cooperation on models is an
important part of CSCW, and that the models underlying the cooperative
technology do fundamentally influence its success—this paper looks at the role of
models for cooperation that can be used as basic concepts for cooperative
technology that in return is used for cooperation on models. In the next section we
give a brief overview of the history of models and patterns. We then introduce and
suggest as a point of departure and the framework of Erving Goffman (esp.
(1959)) who studied social interaction among humans and their use of their
technical environment for several decades and derived a framework for social
interaction. Finally, we summarise our contribution.
2 Models and Patterns
Models and patterns have a long tradition. They have early been used in
architecture, most prominently by Christopher Alexander (1977). Alexander used
introduced a pattern language to describe solutions that were repeatedly applied to
reoccurring design challenges in the design of buildings.
Later, in Software Engineering design patterns serve a similar purpose—design
patterns here have been considered as a successful approach for documenting and
reusing knowledge providing a ‘way of supporting object-oriented design’
(Sommerville 2007, p. 422). Software design patterns basically have the following
structure: a pattern name, a description of the problem, a description of the
solution, and the consequences of the use of the pattern (Gamma et al. 1994).
Design patterns are also used for documenting knowledge and experience with
the development of cooperative technology. Schuemmer and Lukosch (2007,
p. 22) write that ‘developers building groupware applications are challenged with
technical problems that are outside the focus of average software developers’.
Martin and Sommerville (2004) analysed social interaction and translated their
results into the format of design patterns. They (2004, p. 61) point out that
‘patterns of cooperative interaction highlight similar findings across studies
related to particular socio-technical configurations, and the accompanying
activities given those configurations. They start to address the question of how we
10
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
generalise from ethnographic studies to provide guidance for system designers
and other users’ and ‘patterns can be of relevance and practical use to researchers
and practitioners from technical or social scientific backgrounds who have an
interest in social aspects of systems design’.
All these patterns provide valuable input for generating models underlying
cooperative technology. And they are interesting artefacts to study when
developing tools that aim at supporting teams working on them.
Yet, software design patterns primarily help structuring software, and
cooperative design patterns are primarily based on the analysis of existing
cooperative systems or on some ethnographical studies. In the next section we
introduce Goffman’s framework of social interaction, which is based on decades
of observations.
3 Goffman’s Framework of Social Interaction
Goffman’s framework of social interaction is based on decades of observations
and study of related work of Goffman and provides a substantial peace of
knowledge and insight into the way social interaction among humans works.
Goffman uses the metaphor of a theatre stage and points out that humans in
any kind of social interaction do a performance in front of other humans who are
listening and watching and interpreting the performance. Goffman writes: ‘for the
purpose of this report, interaction (that is, face-to-face interaction) may be roughly
defined as the reciprocal influence of individuals upon one another's actions when
in one another's immediate physical presence’ and ‘a “performance” may be
defined as all the activity of a given participant on a given occasion which serves
to influence in any way any of the other participants’ (1959, p. 15).
His concepts that are most relevant with respect to modelling social interaction
as basis for cooperative technology can be grouped into three categories: primary
participants, performance, and secondary participants. Figure 1 depicts these three
categories and the concepts they contain respectively.
Primary participants are humans who act according to their social status (i.e.,
socio-economic standing in the society). They perform a routine (i.e., a ‘pre-
established pattern of action which is unfolded during a performance’ (Goffman
1959, p. 16)). According to Goffman humans have kinds of ideal interactions with
each other: the optimistic ideal of full harmony (i.e., being in harmony with
oneself and with others), which according to Goffman is hard to achieve; and the
pragmatic ideal as a projection that should be in accordance with reality and that
others can accept—at least temporarily—without showing deep and inner feelings
of the self.
An interaction takes place between at least one performer and one person in the
audience. The performer defines a situation through a projection of reality as
expressions of a character bound to a certain social role in front of the audience.
11
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Figure 1. Concepts of social interaction from Goffman’s framework of social interaction.
The performer anticipates the audience and continuously adapts the performance
accordingly. Audiences can be of three different types: Present audience refers to
persons who attend the performance, receive expressions, verify these in
accordance to the projected situation and reality, and respond accordingly. Unseen
audience are imaginary persons; the performer can use them in order to anticipate
a performance. Finally, week audience are real persons who are not present at the
performance (e.g., other performers giving similar performances).
Multiple performers can act as a performance team. The members of a
performance team need to fit together as a whole—to either present similar
individual performances to amplify a projection, or to present dissimilar
performances that complement to a projection.
For a performance, performers prepare a set of fronts shown to the audience.
Fronts consist of material and immaterial parts. The material part is the sign
equipment and are all properties required to give a convincing performance. The
immaterial part is the personal front and refers to a performer’s types of behaviour
such as speech patterns. During interaction performers appear on stage through a
character. A character as figure is composed of a ‘front’, which is adapted to the
audience and performance. In a performance team, the team as whole has a united
front (e.g., according to a professional status) and each member has a character
with an associated front to invoke during staging.
A performance as social interaction is a finite cycle of expressions to define a
situation and responses to feedback the validity of the expressions. Characters
plays routines during performances to convey acceptable and to conceal
inacceptable expressions—in a performance team multiple characters will follow
this behaviour. Expressions are information that is communicated by a character,
which use ‘sign-vehicles’ (i.e., information carriers). There are wanted
12
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
expressions that are acceptable and foster a situation as a valid projection of
reality, and unwanted expressions that are inacceptable and inappropriate for a
given performance in front of a particular audience. In order to manifest a
performance that is coherent, a performer strives to communicate expressions
consistently through their characters towards an audience. Thus a performer’s
character endeavours to conceal unwanted expressions. Responses are feedback
from the audience, which continuously verifies the performance according to the
defined situation and the overall reality as well as to the front of the character, and
responds the result to the performer.
Disruptions can result from wrong or undefined projection—a consequence of
a false or doubtful projection of reality based on contradictive expressions or
discrediting actions. To prevent accidental disruptions a performer and an
audience can agree on: the ‘working consensus’ as an agreement on the definition
of the situation to describe a temporal value system among all participants;
‘reciprocity’ that means that performers guise their characters to act according to
the situation (i.e., provoke neither intentionally nor factually misunderstandings)
and that the audience responds to performance according to the situation (i.e.,
allege neither consciously nor unconsciously false behaviour); and ‘interactional
modus vivendi’ that describes that an individual in the audience only responds to
expressions that are important for the individual; the individual in the audience
remains silent in things which are only important to others.
Stages provide a setting for the interaction and are embroidered with decorative
properties (i.e., decorum). They support performers when fostering a situation.
Both performers and the audience have access to the stage. The backstage is a
region, which only performers can access to prepare and evaluate their
performance. Also team members suspend backstage. The outside region denotes
to neither stage nor backstage. Although it will be excluded in a performance,
performers will prepare and use a dedicated front for the outside (e.g., the façade
of buildings of a company).
We put other participants of Goffman’s framework who are of minor important
for cooperative technology in the category secondary participants. Participants
who are involved, but are not participating in a performance are: team support
(colleagues who constitute the weak audience, training specialists that build up a
desirable performance and service specialists that maintain a performance,
confidants that listen to a performer’s sins, and renegades that preserve a idealistic
moral stand that a performer or team did not kept), and sidekicks that support a
single performer during performance, but in a subordinate role. Non-persons are
present but neither participate nor are involved in a performance (e.g., servants).
Outsiders are neither performers nor audience and have little or no knowledge of
the performance. They can access the outside region; however they can invade a
performance and cause a collision of performances: the outsider sees a
13
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
performance that eventually is reserved for the future when the outsider is part of
the audience.
Overall, Goffman’s framework provides an inspiring point of departure when
conceiving of basic concepts for a model of cooperation. These concepts can be
brought together in a shared model that can then—in a cooperative endeavour—
be worked on in a group. The group can work on a model for any domain or
business, but it can also work on a model that represents its own structure and
roles of actors and ways of interaction among actors and with third parties.
4 Informing the Design of Modelling
The framework of social interaction of Goffman provides multifarious insights
that have the potential to positively influence cooperation on models as well as
models for cooperation.
Cooperation on models—based on the concepts above—can be characterised
as follows. During the cooperation process there are typically active group
members and passive group members. A group members’ expressions in terms of
activities can include oral or written communication, new additions to models,
changes of their own parts of a model, changes of parts of the model that have
been created by others, and so forth. Passive group members might watch the
active person and respond (e.g., confirm that changes to their parts of the model
are welcome). On the other hand the active group members might have
sophisticated routines that allow them not only to concentrate on their own
communication and activities, but also on the others’ reactions. Active members
can tightly cooperate with other active members in performance teams. The team
support might include lab administrators who are responsible for maintain the
distributed modelling software and hardware. Researchers have only very recently
started looking at these subtleties of users’ performances and others responses to
them. For instance, Birnholtz et al. presented a study of collaborative writing and
point out that: ‘people are also concerned about how their behaviours—and they
themselves—will be perceived by others’ (2013, p. 961). Despite the fact that this
study was on collaborative writing and not editing models, it showed interesting
evidence that active users in team do care about other users responses to their
performance.
Models for cooperation should use Goffman’s notions as input for entities.
According to Goffman several roles need to be considered by modellers of
cooperative processes: performers who actively communicate and change
artefacts, performance teams which consist of multiple performers, as well as
audiences which can be present and visible to the active performer, unseen and
weak audiences which are absent yet important. Furthermore, models for
cooperation might foresee secondary participants such as team support or
outsiders. In early cooperative systems and early research (cf. e.g., Rodden 1991
14
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
for an overview) the notion of a role was clear-cut to and distinct. For instance, a
chair-person has specific rights and duties, and a participant has others. More
recently—and in accordance with Goffman—roles have been seen as emerging
and evolving over time (Finholt et al. 2012). Schmidt (2011, p. 31) writes: ‘the
apparent stability of organizational roles and patterns of communication is a
superficial hide … Cooperative work arrangements should rather be conceived as
emerging formations that change dynamically in accordance with the
requirements of the situation, and cooperative work involves, inescapably, the
vicissitudes of distributed decision making. These characteristics have important
implications for CSCW systems design’.
As these short examples show, it is important for system designers with respect
to cooperation on models and models for cooperation, to find a balance between
having a structured, effective, and efficient process and providing lightweight
adequate adaptability, flexibility, and spontaneity (Gross & Marquardt 2010;
Schirmer & Gross 2011). This has been pointed out very early in the CSCW
literature (esp. Bannon & Schmidt 1989), but neglected by some system
designers.
5 Conclusions
This introduction of key concepts from Goffman’s framework of social
interaction is only a starting point towards a more comprehensive discussion of
key concepts—in the sense of reoccurring design patterns—of models for
cooperation underlying cooperative technology. Conversely, since these key
concepts and their mutual relationships can evolve into complex models it would
be great to have approaches and tools to cooperatively work on them. Goffman’s
framework is just one part of the overall picture; other researchers have been
using other frameworks, most prominently activity theory (Kaptelinin & Nardi
1997; Nardi 1996) or distributed cognition (Hutchins 1995) (Perry 2003).
In this workshop I would like to share thoughts on how cooperation on models
actually works in practice and how tools supporting this type of cooperation can
be conceived, while at the same time—from a Janus head perspective—looking at
the structure of this cooperation process on models and taking it as the shared
artefact that the team is actually working on.
References
Alexander, C., Ishikawa, S. and Silverstein, M. (1977). A Pattern Language: Towns, Buildings,
Construction. Oxford University Press, Oxford, UK.
Bannon, L.J. and Schmidt, K. (1989). CSCW: Four Characters in Search of a Context. In
Proceedings of the First European Conference on Computer-Supported Cooperative Work -
ECSCW'89 (Sept. 13-15, Gatwick, UK). Elsevier, Dordrecht. pp. 358-372.
15
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Birnholtz, J.P., Steinhardt, S.B. and Pavese, A. (2013). Write Here, Write Now! An Experimental
Study of Group Maintenance in Collaborative Writing. In Proceedings of the Conference on
Human Factors in Computing Systems - CHI 2013 (Apr. 27-May 2, Paris, France). ACM,
N.Y. pp. 961-970.
Finholt, T.A., Tellioglu, H., Inkpen, K.M. and Gross, T., eds. (2012). Proceedings of the 2012
International ACM Conference on Supporting Group Work - Group 2012. ACM, N.Y.
Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994). Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, Reading, MA.
Goffman, E. (1959). The Presentation of Self in Everyday Life. Doubleday Anchor Books, N.Y.
Gross, T. (2013). Supporting Effortless Coordination: 25 Years of Awareness Research. Computer
Supported Cooperative Work: The Journal of Collaborative Computing 22, 4-6.
Gross, T. and Marquardt, N. (Sept. 2010). Creating, Editing, and Sharing Complex Ubiquitous
Computing Environment Configurations with CollaborationBus. Scalable Computing:
Practice and Experience - Scientific International Journal for Parallel and Distributed
Computing (SCPE) 11, 3. pp. 289-303.
Hutchins, E., ed. (1995). Cognition in the Wild. MIT Press, Cambridge, MA.
Kaptelinin, V. and Nardi, B.A. Activity Theory: Basic Concepts and Applications. Presented at
Tutorial #11 at the Conference on Human Factors in Computing Systems - CHI'97 (Mar. 22-
27, Atlanta, GA). 1997.
Marca, D. and Bock, G., eds. (1992). Groupware: Software for Computer-Supported Cooperative
Work. IEEE Computer Society Press, Los Alamitos.
Martin, D. and Sommerville, I. (Mar. 2004). Patterns of Cooperative Interaction: Linking
Ethnomethodology and Design. ACM Transactions on Computer-Human Interaction 11, 1.
pp. 59-89.
Nardi, B.A. (1996). Context and Consciousness: Activity Theory and Human-Computer
Interaction. MIT Press, Cambridge, MA.
Nolte, A., Prilla, M., Rittgen, P. and Oppl, S. Call for Papers: Workshop "MoRoCo - Models and
their Role in Collaboration" at ECSCW 2013.
http://moroco2013.files.wordpress.com/2013/05/moroco-2013-call.pdf, 2013. (Accessed
7/5/2013).
Perry, M. (2003). Distributed Cognition. In Carroll, J.M., ed. HCI Models, Theories, and
Frameworks - Towards a Multidisciplinary Science. Morgan Kaufmann Publishers, San
Francisco, CA. pp. 193-223.
Rodden, T. (1991). A Survey of CSCW Systems. Interacting with Computers 3, 3. pp. 319-353.
Schirmer, M. and Gross, T. (Oct.-Dec. 2011). Lightweight Editing of Distributed Ubiquitous
Environments - The CollaborationBus Aqua Editor. International Journal of Distributed
Systems and Technologies (IJDST) 2, 4. pp. 57-73.
Schmidt, K. (2011). Cooperative Work and Coordinative Practices - Contributions to the
Conceptual Foundations of Computer-Supported Cooperative Work (CSCW). Springer-
Verlag, Heidelberg.
Schuemmer, T. and Lukosch, S. (2007). Patterns for Computer-Mediated Interaction. Wiley, N.Y.
Sommerville, I. (2007). Software Engineering 8. Pearson Education Limited, Harlow, England.
16
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Facilitating and Prompting of Collabora-
tive Reflection of Process Models
Thomas Herrmann, Kai-Uwe Loser
Ruhr-University Bochum, Germany, Institute for Applied Work Science
Thomas.herrmann@rub.de; kai-uwe.loser@rub.de
Abstract. Systematical collaborative modeling usually needs a facilitator. We suggest
that a large part of revising existing drafts of a process model requires facilitated reflec-
tion of what has already been achieved in the light of the experiences of the collaborating
participants. This reflection can be awkward and inefficient if it takes place in a whole
group of 8 to 12 stakeholders. Therefore delegating the reflection to breakout groups is
reasonable but requires technically based ways of facilitation support to avoid the need to
employ several facilitators. This technical support is mainly feasible for identifying rea-
sonable segments on which a step-by-step consideration can be based, and for prompt-
ing the participants to ensure a systematic reflection.
Introduction
Collaborative modeling of business processes pursues the goal to discuss different
perspectives and integrate various competences on the one hand and to make the
completion of a process model more efficient. Since both goals can be conflicting,
coordination is necessary as it is usually provided by a facilitator (Renger,
Kolfschoten, & De Vreede, 2008; Rittgen, 2010). The facilitator provides support
so that different experiences and opinions with respect to the process being mod-
eled are taken into consideration. During the course of collaborative modeling the
emerging model has to be repeatedly inspected. The inspection is a type of valida-
tion which is closely intertwined with additional elicitation of information and
ongoing modeling activities. Due to the complexity of a two dimensional repre-
sentation, logical dependencies, various types of relationships etc. the parts and
17
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
elements have to be deliberately reconsidered several times. A first draft of a
business process model should be carefully reflected by combining the compe-
tence and experience of several stakeholders which represent various perspectives
being relevant for the model under construction. This combination of several per-
spectives in the course of collaborative reflection leads to comparisons of diverg-
ing opinions and to negotiations of the process model, and therefore is time con-
suming. Consequently, it may easily happen that important issues are neglected.
These difficulties can be viewed upon from the perspective of cognitive theory:
By their research on knowledge integration, Stasser and colleagues found that test
persons who were required to collaboratively solve complex problems did not
value relevant information which was explicitly exchanged during their discussion
(Stasser & Stewart, 1992). The reasons for this behavior are not completely clari-
fied; it is obvious that the knowledge integration of various parties requires extra
effort. With respect to creativity of groups, several obstacles were identified
(Diehl & Stroebe, 1987) which affect the efficiency and creativity of group work,
such as production blocking, free riding, evaluation apprehension etc..
To overcome these problems, a facilitator can prompt the participants to develop
new ideas and to refer to the contributions of each other and to integrate them into
a shared process model. A core principle of this kind of facilitation is to visualize
every participant’s comments or contributions. Conklin’s dialogue mapping
(Conklin, 2005) can be considered as an early example of this kind of visualiza-
tion.
We have developed the method of the socio-technical walkthrough with which a
process model is inspected and discussed step-by step. The walkthrough method
(Yourdon, 1989) is employed in many contexts to support design projects with a
systematic method to reconsider the already achieved results. The systematization
and the deliberate inspection of every design element and their relationships re-
quires a facilitator who has to identify appropriate segments of a model which are
inspected within one step, and who has to ensure that every segment is discussed
under certain aspects. However, this kind of facilitating all cooperative interac-
tions and visualizing there outcome may prove as very time consuming (Nolte &
Prilla, 2012). In larger groups of 8-12 participants, who are usually needed to rep-
resent the relevant perspectives, the walkthrough method causes phases where
most of the group members have to stay passive in a listening mode. Therefore it
is reasonable to alternate the work in the whole group of stakeholders with periods
of work in solitude or in breakout groups. Since some functions of a facilitator are
inevitable, we propose two strategies to complement the work of a facilitator with
technical functionality:
1. Support of participants to define the appropriate clusters into which the pro-
cess model is segmented and where each segment becomes a subject of de-
liberate discussion
18
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
2. Prompting to support the reflection of selected segments by individuals or
by breakout groups
The sociotechnical walkthrough
We briefly describe the basic principles of the socio-technical walkthrough
(STWT) to clarify the kind of support which is needed for guiding the work of
breakout groups (T. Herrmann, Kunau, Loser, & Menold, 2004; Thomas
Herrmann, 2009). As Figure 1 shows the STWT is applied in a series of work-
shops. They take place as co-located meetings since the negotiation of diverging
opinions requires a close contact between the participants. Each meeting can be
used to reconsider a collaboratively modeled work or business process under one
or two aspects e.g. whether the displayed activities are really necessary, how they
can be supported etc. In preparation of a workshop the facilitator creates a dia-
gram which represents the results of previous work. The facilitator develops a
plan of how to inspect the complete diagram step by step. A crucial challenge is to
define the segments for the single steps. If they are too small, a lot of comments of
the participants will refer to aspects which belong to another segment. If the de-
fined segments are too large it might easily happen that important details are ne-
glected.
Figure 1: Process overview of STWT's
STWT-workshops are characterized by the following facilitation activities (cf.
Figure 1):
Asking prepared questions: The facilitator discloses some parts of the dia-
gram e.g. by using hide-and-show mechanisms. Each phase of such a dis-
closure is one step (of about 7-15 per workshop) which is accompanied by
one or two prepared questions such as: “What is the next sensible activity?”,
“Which information support is needed for this activity?”.
19
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Collecting contributions such as answers, hints, proposals, comments, refer-
ences to further documents etc. It is important that the stakeholders com-
ment from their various viewpoints and that these contributions leave im-
mediate traces in the process model diagram. By modifying the model, the
results of the discussion are simultaneously documented.
Focusing on the diagram: The diagram – especially the segment under dis-
cussion – serves as a focus which integrates the various experiences and
perspectives of the participants into a larger picture.
In summary, the goals of the STWT are:
Combining various perspectives, when considering the segments under sev-
eral aspects (represented by questions)
Relating every element to its context
Reflecting the characteristics of a segment in relation to the experience of
the participating experts and stakeholders.
Research on the STWT revealed that it has to be extended by means of creativity
support. The linearity of the STWT is not feasible to support associative thinking
and brainstorming (Thomas Herrmann, Nolte, & Prilla, 2013).
In the following we want to discuss and propose how the STWT-oriented collabo-
ration can become more efficient, if the walkthroughs are delegated to breakout
groups. For instance, with three breakout groups a model could be discussed and
modified under three different aspects. In such a constellation it is not reasonable
to engage three facilitators but to technically support the groups themselves to run
a systematic walkthrough.
Support of segmentation
A first measure is to support the groups to define the segments – under which they
intend to walk through the model – by themselves. This can happen by asking the
members of the whole group to identify for every element of a process model
which other two or three elements of the model are most closely related to them –
from a semantic point of view.
To demonstrate this we ran a first small explorative study. We asked eight people
to identify relations between the sub-elements shown in Figure 2: “The elements
of this diagram are labeled with differently colored points. Please add points of
the same color to two other elements which you consider as closely related to the
element with the same color”. However we did not show them the nested structure
of the model to avoid a pre-orientation on certain clusters. The results of eight
people’s proposals for defining relationships between the elements were manually
entered into the model by establishing directed relations and annotating their car-
dinality depending on how many participants have indicated the relationship. At
20
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
the first glance, nearly every element was connected with more than 5 other ele-
ments.
Figure 2: Part of a diagram for which reasonable segments had to be identified
Figure 3: Results of collaborative identification of segments of a part of a process diagram
To make a structure of segmentation visible we carried out the following opera-
tions:
21
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
1. All relations are weighted by the number of their occurrence (see Figure
3). For this purpose, the counts of the two directions of a relation are
added.
2. All relations of a weight of N are deleted, starting with N=1,
3. The deletion of a relation is not conducted if this deletion causes that an
element remains without any relation to the others.
4. N is increased until no deletion can be carried out.
Surprisingly, the resulting clusters do not match the clusters being provided by the
nesting structure in Figure 2. The super-elements (such as “processing request”)
are usually proposed by a modeler or the facilitator. Usually the nesting structure
is employed to define the segments of the walkthrough. The experimental study
revealed that this strategy might not be always appropriate. The tested method of
building segments also revealed that the suggested semantic relationships of a
drafted model might need to be revised. Further research will have to deal with an
extended functionality which helps to handle models with a larger, realistic num-
ber of elements and supports the automatic identification of appropriate clusters to
define the steps of a walkthrough.
Support of prompting
One important task of the facilitator is to provide prompts which stimulate the
participants to reflect the status of a process model and to make contributions.
Appropriate prompting is discussed as a method to increase the creativity level of
facilitated brainstorming (Santanen, Briggs, & de Vreede, 2004). From a cognitive
view, prompting can help to overcome the linearity of thinking and to combine
the relevant aspects of a process in unusual ways (T. Herrmann, 2009). Further-
more, prompting has been widely researched in the context of learning and teach-
ing, especially for computer supported collaborative learning (CSCL). Prompting
(Thillmann, Künsting, Wirth, & Leutner, 2009) can be seen as a part of scaffold-
ing which mostly consists of a guidance through a procedure which combines
several mandatory and optional activities. The STWT is an instance of such a pro-
cedure. The prompts remind people to not forget steps which might be helpful in
certain situations. CSCL-research pursues the concept to provide those prompts
by technical functions during human-computer interaction which help the collabo-
rating participants to conduct important steps in the process of learning.
We have applied the research on prompting in the context of supporting reflection
at the workplace (Prilla, Degeling, & Herrmann, 2012); the intention is to guide
people to articulate their experience with certain work situations by either describ-
ing the situation or noting down the result of their reflection. Subsequently, these
articulations can be shared with other people who made similar experiences. The
22
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
interaction with others may help to find solutions and to support each other to
bring these solutions into reality.
With respect to the socio-technical walkthrough, the following activities could
be prompted:
The leading question can be repeated for each segment;
Participants can be asked for their opinion;
“What-if-“ or “what-else-“questions can be used to stimulate creativity;
Participants are reminded to leave tracks of their discussion in the mod-
el;
After each modification the collaborators can be asked to declare
whether they agree with it;
The participants can be asked to see the segment under discussion and
its modification in the context of the whole process model;
The collaborators can be asked whether they agree to proceed with the
next segment.
By delegating this prompting to the technical functionality, the participants do
not have to care by themselves about the systematization and coordination of the
walkthrough but can focus on the content of the collaboratively modeled process
in relation to their expertise.
Summary: Reflection support for collaborative model-
ing
All in all the described concepts for support of collaborative modeling can be re-
lated to research which intends the support of reflection at work. Selecting an ap-
propriate unit, to which reflection refers, focusing on it without neglecting the
larger context and continuous prompting which avoids the neglecting of important
aspects of the participants’ perspectives and of documenting the results can be
considered as relevant principles which should be technically supported. This
helps to conduct systematical reconsideration and negotiation of drafts during
collaborative modeling in breakout groups without employing a facilitator for
each group. Besides the use for STWTs, it might also be possible to use the sup-
port for other types of collaborative work on artefacts. Further research has to
prototype solutions for this kind of support and to run experiments to refine these
solutions for interactive identification of segments and for appropriate prompting.
The main technical challenge with respect to prompting is to make it as unobtru-
sive as possible and to adapt it to the users’ needs for scaffolding. Other aspects
for research are to consider the limitations of knowledge integration if work on
models is delegated to break out groups which only include a reduced scope of
perspectives. Therefore, appropriate means of facilitation methods have to be
identified to bring the perspectives of several breakout groups together.
23
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
References
Conklin, J. (2005): Dialogue mapping. Wiley, Chichester.
Diehl, M., & Stroebe, W. (1987): 'Productivity loss in brainstorming groups: toward the solution
of a riddle'. Journal of personality and social psychology, 53(3), pp. 497–509.
Herrmann, T. (2009): 'Design Heuristics for Computer Supported Collaborative Creativity'. Sys-
tem Sciences, 2009. HICSS’09. 42nd Hawaii International Conference on (S. 1–10).
Herrmann, T., Kunau, G., Loser, K. U., & Menold, N. (2004): 'Socio-technical walkthrough: de-
signing technology along work processes'. Proceedings of the eighth conference on Participa-
tory design: Artful integration: interweaving media, materials and practices-Volume 1, pp.
132–141.
Herrmann, Thomas. (2009): 'Systems Design with the Socio-Technical Walkthrough'. In B. Whit-
worth & A. de Moor (Hrsg.), Handbook of Research on Socio-Technical Design and Social
Networking Systems. Information Science Reference.
Herrmann, Thomas, Nolte, A., & Prilla, M. (2013): 'Awareness support for combining individual
and collaborative process design in co-located meetings'. Computer Supported Cooperative
Work (CSCW), 22(2), pp. 241–270. doi:10.1007/s10606-012-9179-x
Nolte, A., & Prilla, M. (2012): 'Normal users cooperating on process models: Is it possible at all?'.
CRIWG 2012, LNCS 7493 (S. 57–72). Berlin: Springer.
Prilla, M., Degeling, M., & Herrmann, T. (2012): 'Collaborative Reflection at Work: Supporting
Informal Learning at a Healthcare Workplace'. Proceedings of the ACM International Confer-
ence on Supporting Group (GROUP 2012).
Renger, M., Kolfschoten, G. L., & De Vreede, G. J. (2008): 'Challenges in collaborative model-
ling: a literature review and research agenda'. International Journal of Simulation and Process
Modelling, 4(3), pp. 248–263.
Rittgen, P. (2010): 'Collaborative Modeling: Roles, Activities and Team Organization'. Interna-
tional Journal of Information System Modeling and Design (IJISMD), 1(3), pp. 1–19.
Santanen, E. L., Briggs, R. O., & de Vreede, G.-J. (2004): 'Causal relationships in creative prob-
lem solving: comparing facilitation interventions for ideation'. Journal of Management Infor-
mation Systems, 20(4), pp. 167–198.
Stasser, G., & Stewart, D. (1992): 'Discovery of hidden profiles by decision-making groups: solv-
ing a problem versus making a judgement'. Journal of personality and social psychology, 63(3),
pp. 426–434.
Thillmann, H., Künsting, J., Wirth, J., & Leutner, D. (2009): 'Is it Merely a Question of “What” to
Prompt or Also “When” to Prompt?'. Zeitschrift für Pädagogische Psychologie, 23(2), pp. 105–
115.
Yourdon, E. (1989): Structured walkthroughs. Prentice-Hall Englewood Cliffs, NJ.
24
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Collaborative Creativity: From Hand
Drawn Sketches to Formal Domain
Specific Models and Back Again
Christian Bartelt, Martin Vogel, Tim Warnecke
Software Systems Engineering - Department for Computer Science
University of Clausthal, Germany
{christian.bartelt, m.vogel, tim.warnecke}@tu-clausthal.de
Abstract. Most of the time developers make extensive use of software tools in a software
development process to support them in their day-to-day work. One of the first and most
important phases is the design phase. Here tools are missing which support the creative
and collaborative workflow (parallel/distributed). At the moment software designers uses
classic whiteboards in team meetings to express their ideas. Subsequently a coworker
uses a mobile phone or a camera to take photos of the work and remodel the picture with
a modeling tool. That process is very inconvenient, error-prone and hinders a creative
modeling cycle. For overcoming this ineffective process this paper shows a new
approach to use digital whiteboards to transform free hand sketches in formal models
and back again while modeling in a distributed team. The approach is completely
independent from a pre-defined modeling language. It provides an interactive training
mode to learn new graphical syntax elements and map these elements to formal meta-
model entities. Based on the approach a collaborative sketch and modeling infrastructure
was implemented.
Video: https://www.youtube.com/watch?v=0i3M9djPrRM
[Mirror: http://sse-world.de/index.php?cID=3611]
Motivation and State-of-the-Art
Nowadays, software development is a creative and distributed team process. The
early and creative design phase is very important for successful software projects.
25
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Normally software designers do not use modeling tools like MagicDraw UML
(MagicDraw 2013) in this early phase because of their inconvenient operation.
Modeling tools are made for precise model design, but not for creative sketching.
That is the reason why software designers using whiteboards in team meetings to
visualize and communicate their ideas within the group (Cherubini et al. 2007).
Nevertheless, after a successful team meeting, one of the designers has to
transform the drawn sketches in formal models using the previously rejected
modeling tools. Those transformations are error-prone because for e.g. the
designer tries to optimize the diagram or forgets some elements. Thus it is
possible that the new formal diagram cannot be recognized by the other team
members in a later meeting because of its changed appearance.
Another widely known problem in this domain describes that everybody has to
be present to accomplish such a creative meeting. If a team is spread all over the
country or worse over the world it needs a lot of effort, money, and time to get
them all to one place. One possible solution is to use Screen Sharing Software
like TeamViewer (TeamViewer 2013) to share some kind of drawing software
and additionally utilize a telephone conference system. An issue here is that two
or more software applications are used together and none of them is particular
conceptualized for software designers.
Figure 1: Use cases
In Figure 1 three typical modeling use cases in the creative engineering phase
are depicted. The first use case (UC 1) describes two distributed teams are
working parallel on the same sketch model. UC 2 shows how a sketched model,
which was drawn by a team of designers and transformed to a formal domain
specific model. This transformed model is based on Ecore, which is now usable
with a corresponding EMF- or GMF-Editor (whereas the whole history of origins
of the sketch is preserved). This allows a single user to extend and change the
model based on the results and feedback of the previous team meeting. UC 3
illustrates how such a modified model is transformed back to a sketched model.
26
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Because Scribbler knows how the sketched model looked before all changes
made in the GMF-Editor can be visualized, e.g. an element was deleted or added.
The last both use cases make it possible to establish a creative life cycle which
starts with a onetime configuration. This configuration consists of a knowledge
base, which contains of previously learned sketches for the chosen DSL, and a
mapping between those sketches and elements of the DSL meta model (Ecore). It
should be noted, that this configuration can also be done after drawing sketches.
After the team drew some sketches the sketch model is transformed, with help of
the configuration, to a formal model (UC 2) which is suitable for a GMF-editor.
In this editor a single user modifies the model based on the feedback of the
meeting before. After he finished his modifications, the model is transformed
back to a sketch model and given back to the team (UC 3). All modifications done
in the GMF-Editor are visualized and the remaining, but unchanged, sketches
look like in the first meeting. Thus the team is able to better recognize what
happened in the last meeting. To improve the process of recognizing a sketch,
which is made some days or weeks before, the designer can also use the
implemented history viewer which recorded every stroke made on the canvas.
With similarities to these use cases in the last few years several research
initiatives are started with the topic intuitive modeling respectively model
sketching. In (Sangiorgi & Barbosa 2010) a recognition mechanism for sketched
model elements was presented. This mechanism uses a similarity calculation
between drawing traces based on the Levenshtein distance (Levenshtein 1966)
and is also a foundation for the research here explained. Some innovative research
results about sketch recognition in the area of requirements modeling was
described in (Wüest, Seyff, and Glinz 2013). Some further recognition techniques
based on vector comparison between sketches and GEF/GMF model elements
were published in (Scharf 2013).
Scribbler – The Collaborative Sketching/Modeling
Infrastructure for Domain Specific Models
The developed sketching/modeling platform Scribbler picks up the upon
explained use cases. Therefore, it must overcome several challenges like sketch
recognition, formal model synthesis from recognized sketches, sketch synthesis
from formal model, and an efficient mechanism to allow distributed parallel
sketching. Furthermore, the approach should be easy/user friendly adaptable for
sketching any kind of domain specific syntax.
27
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Sketch Recognition and Knowledgebase
A sketch is per definition a freehand drawing, consisting of some individual
elements, which is not yet finished and tries to transport some kind of idea
(Davies 1990). Following from this a sketch and its elements has meanings for the
people who work with it, but for computers sketch elements are only a set of x-
and y-coordinates and maybe colours. These coordinates must be interpreted in a
way such the computer knows what the drawing person had in mind. Aggravated
by the fact that every human being sketches figures a little bit different, four main
problems must be taken into account when recognizing a figure. First the drawing
order of a figure alters between different users, second the size of a figure changes
with attempt, third a figure can be inclined to the right or left side and last users
often don’t draw solid lines.
To solve these problems, Scribbler uses an extended and modified version of
an algorithm described by (Coyette et al. 2007). In a first step of the procedure a
sequence of numbers based on the intersections with a predefined grid is
produced. In the example in Figure 2 the sequence of the circle is 1 1 2 3 4 5 8 9
12 13 14 15 because two intersections are detected in field 1, one additional
intersection in field 2, one additional intersection in field 3 and so on.
Figure 2: Sketch Recognition
This is pretty straight forward, but not every drawn object has a unique
numerical sequence. A circle could have the same sequence as a square because
they have the same intersections with the used grid. In a second step the incline
for every intersection of the drawn line is measured and mapped to a number
corresponding to the scheme shown on the right side of Figure 2. This generates a
second numerical sequence for both sketches, which is now completely different.
After constructing such a pair of sequences a knowledgebase of previously
drawn figures is needed to compare them with new drawn sketches and finding a
match using Levenshtein distance (Levenshtein 1966). Building such a
knowledgebase needs some kind of learning environment, which is done in
Scribbler with an own dialog.
28
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Figure 3: Learning environment
This dialog is shown in Figure 3 and consists of a training canvas (1) and a list
of elements (2) which were already learned. The user is also able to add new
versions of a sketch by redrawing it over and over (leads to better recognition
results) again and to create new sketches by adding them to the list. Every drawn
sketch will be automatically added to the knowledgebase. The knowledgebase is
stored in a file, which can be exchanged with other users. For collaborative work
recognizing of sketches is important, because the team gets a visual feedback of
what happened. If the feedback is not that result which they actually discussed,
the team can react immediately and change the type of the sketch to the desired
one.
From Sketches to Formal Models and Back Again
Transforming a hand drawn sketch to a formal Ecore (EMF 2013) based model
describes a process of mapping sketches to elements of the given meta model. At
first glance this sounds easy but a lot of information, like for example position,
size and the history of origins, is lost if hand drawn model elements are just
mapped to their corresponding EMF counterparts. Transforming the EMF model
back to a hand drawn sketch is not possible any more without theses information.
Due to this problem a new file type was needed. In this file three types of
information are stored at the same time for every element. The first is the
meaning of an element defined by the corresponding meta model. The second is
the graphical representation given by the Graphical Modeling Framework (GMF
2013) such as, for example a UML class is a rectangle with an additional
horizontal stroke. The last type of information stored the coordinates of the hand
drawn strokes and the history of origins logged by Scribbler. This new file type
sets Scribbler in the position to transform hand drawn sketches to ECore based
models and back again without loss of information.
Collaboration: Drawing together and saving the history of origins
Another problem with hand drawn sketches is that the incurrence of its elements
is not traceable anymore. This is especially problematic if a sketch was drawn
some days or weeks ago and someone tries to remember what happened in the
29
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
meeting (Cherubini et al. 2007). Scribbler solves the problem by saving all
drawing actions which happened on the canvas in a file for later use. The core of
it fires for every user action an event, e.g. drawing or moving. Events are stored
in a queue for the plugins. This queue is stored in a file with the whole sketch
model. Thus, the history of origins still remains. For the transformation from
sketches in formal models, the history is also stored in the new model file. After
this step it is possible to review the whole drawing process of the sketch in a user
defined speed and to stop and restart it whenever the user wants to.
Figure 4: History viewer
Figure 4 shows the user interface of the history viewer. It looks like an
audio/video tool with a play button and a slider for the timeline. Thus, the history
of origins of the model can play back. This feature is important for collaborative
modeling, because if a new member joins the team, he can comprehend how the
model is originated in the team. He can jump to every position in the origination
process. Further the history viewer might be used in future for contextual
modeling. This means that the team navigates to the position, which they want to
modify and change the information in the sketch. After the modification they
navigate to the end of the timeline and continue the work at the model. The
modification saved in the history of origins.
Another component of Scribbler is the collaboration platform. Since Scribbler
is an intuitive modelling tool, which is inspired by a standard whiteboard, it is
necessary to construct a collaborative lock-free environment in which everyone
immediately sees if a user starts a new sketch, how he draws it and the name of
the user. Implementing such a collaborative environment is a challenge because
every client doesn’t use necessarily the same hardware and software. This fact
leads to two new problems. Different devices have different screen resolutions
and bandwidths.
Solving problem number one, Scribbler scales up every drawn sketch to a
fictional resolution and scales them down to the actual resolution of the
corresponding device. This procedure ensures that every screen size is supported
no matter how big or small it is. Problem number two is solved by transferring
only mouse movements/events and the coordinates, so no screen sharing is
necessary. Furthermore, the server saves every draw session. This feature allows
sending all transmitted data to a new connecting client and pushing him to the
current stage of work. Additionally the server has the ability to save the cached
data of a session in a local file. Thus it is possible to load and continue such an
older session or view it in the history viewer. Thereby every member of a team
can prepare for the next meeting or evaluate the session afterwards.
30
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Tool Implementation
Scribbler is just a simple paint program which supports only basic operations like
draw, move, scale, delete, save and load. Every drawn sketch consists of a series
of raw dates, like, for example, coordinates and mouse movements. Scribbler
gains its sketch recognition and collaboration skills through plugins.
Figure 5: Tool Scribbler
A screenshot of the tool is shown in Figure 5. At the top of it (1) all current
loaded plugins are represented with an icon. In the center (2) is the canvas and
last but not least the toolbar is located at the bottom (3), which consists of four
colors, an edit button and a rubber.
Evaluation
During the project duration three industry partners from different domains used
the Scribbler for their daily work – with customers and for architectural and
structure meetings - for about four weeks. Every team had an experimental setup
composed of a digital whiteboard and some tablet pcs and a catalogue of
questions to evaluate the Scribbler. The results of the evaluation as described
below. The three teams used the Scribbler only for collaborative work –
especially the history viewer and the server sessions - to prepare the next meeting.
The teams assessed this functionality as valuable and it is very helpful for their
daily work. Furthermore, they used the learning environment to insert their own
elements for their own domain languages. Scribbler was able to learn all of these
elements and the recognition rate was very good. Concerning the usability and the
training period every participant rated the Scribbler as good.
31
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Conclusion
Ensuing from the requirements regarding an intuitive modeling infrastructure that
does not hinders the creative engineering process the sketching/modeling
platform Scribbler was developed. Scribblers allows a distributed, parallel
(collaborative) sketching of engineering models on digital whiteboards, the
transformation of sketches in (semi-)formal domain specific models and back
again, an easy and interactive learning of new domain specific syntax elements,
and a recording/playback of the modeling/sketching history. The fundamental
concepts of all these features are explained in this paper. Furthermore the
implemented software infrastructure is presented. For future work the recording
of further context information during the sketching modeling process (e.g. voices
of modelers within the history of model evolution etc.) is planned.
This research work was supported by “German Federal Ministry of Education
and Research” (BMBF) within the Project “KoMo – From Sketch to Model:
Cooperative Modeling with Domain Specific Languages” (2011-2013).
References
Cherubini, Mauro et al. 2007. «Let’s go to the whiteboard: how and why software developers use
drawings» in . Proceedings of the SIGCHI Conference on Human Factors in Computing
Systems, 557–566. CHI ’07. New York, NY, USA: ACM.
doi:10.1145/1240624.1240714. http://doi.acm.org/10.1145/1240624.1240714.
Coyette, Adrien et al. 2007. «Trainable sketch recognizer for graphical user interface design» in .
Proceedings of the 11th IFIP TC 13 international conference on Human-computer
interaction, 124–135. INTERACT’07. Berlin, Heidelberg: Springer-Verlag.
http://dl.acm.org/citation.cfm?id=1776994.1777013.
Davies, Diana. 1990. Harrap’s Illustrated Dictionary of Art and Artists. Chambers.
EMF. 2013. «EMF». www.eclipse.org/modeling/emf/.
GMF. 2013. «GMF». www.eclipse.org/modeling/gmp/.
Levenshtein, Vladimir I. 1966. «Binary Codes Capable of Correcting Deletions, Insertions and
Reversals» in . Soviet Physics Doklady, 10:707 – 710.
MagicDraw. 2013. «NoMagic - MagicDraw». www.nomagic.com/products/magicdraw.html.
Sangiorgi, Ugo Braga & Barbosa, Simone D. J. 2010. «SKETCH: Modeling Using Freehand
Drawing in Eclipse Graphical Editors» in . Proc. FlexiTools Workshop.
doi:http://www.ics.uci.edu/ tproenca/icse2010/flexitools/papers/10.pdf.
Scharf, Andreas. 2013. «Scribble - A Framework for Integrating Intelligent Input Methods into
Graphical Diagram Editors» in . Software Engineering 2013 Workshopband (inkl.
Doktorandensymposium), 591–596. http://www.se2013.rwth-
aachen.de/downloads/proceedings/SE2013WS.pdf.
TeamViewer. 2013. «TeamViewer». www.teamviewer.com.
Wüest, Dustin; Seyff, Norbert & Glinz, Martin. 2013. «FlexiSketch: A Mobile Sketching Tool for
Software Modeling» in Uhler, David et al. (arg.). Mobile Computing, Applications, and
Services, 225–244. Lecture Notes of the Institute for Computer Sciences, Social
Informatics and Telecommunications Engineering 110. Springer Berlin Heidelberg.
http://link.springer.com/chapter/10.1007/978-3-642-36632-1_13.
32
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Towards Role-distributed Collaborative Busi-
ness Process Elicitation
Stefan Oppl
Department of Business Information Systems – Communications Engineering, Kepler
University of Linz, Austria
stefan.oppl@jku.at
Abstract. Elicitation of business process knowledge can be facilitated by conceptual mod-
els of collaborative work. Models of collaborative business processes with actors partic-
ipating in different roles are complex constructs with flows of individual activities that are
coupled via acts of communication. The process of elicitation in such cases can benefit
from separating the modeling process for each role and let actors focus on their own contri-
bution to work and their communication with other roles. This paper identifies concepts for
model elicitation and modeling support that enable a modeling process distributed across
roles and identify collaboration issues while maintaining one consistent overall model rep-
resentation. A modeling methodology implementing these concepts is presented and first
results of exploratory tests are discussed.
Introduction
In the last years, business process models have become a recognized means for rep-
resentation of knowledge about collaborative work in organizations (Gasson, 2005).
They can be used for communication of information about work and facilitate elic-
itation and alignment of business process knowledge (Rittgen, 2007). The creation
of sound and fully specified business process models, in addition, allows to go be-
yond communication support and enables further processing like validation, opti-
mization and execution of the model (Giaglis, 2001).
Business process models are a representation of organizational work with ac-
tivities distributed over different actors. Elicitation of information about work thus
33
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
has to involve all relevant stakeholders to form a comprehensive model of the work
process Antunes et al. (2013). and focus on collecting information from the ac-
tual workers to avoid intermediate expert modelers, who may lack tacit knowledge
about the actual implementation of work (ibid.). Involving the stakeholders during
modeling confronts them with different viewpoints and conceptions of how the col-
laboration should be implemented (Stuit et al., 2011), which need to be aligned in
the process of creating the model.
The goal of the research the present work contributes to is to enable stakeholders
to directly create models of business processes without intermediaries and facilitate
the uncovering and eventual resolution of different conceptions of the collaborative
work process. At the same time, the resulting process models should allow for for-
mal validation and further processing, e.g. in workflow support systems. Similar
objectives have been targeted in earlier research (e.g. Herrmann et al. (2007) or
Rittgen (2010)). The approach presented here follows a different approach by let-
ting stakeholders focus on solely their individual role in a process (i.e. their activi-
ties and communication with others) in contrast to existing works, where an overall
view on the whole business process is maintained for all stakeholders. Focusing
on the individual contribution to a work process leads to more detailed and refined
models that better reflect the actual perception of their work (Dann, 1992) and also
enables to explicitly identify different conceptions on the need for communication
during work. The objective of the present paper is to explore approaches for model
elicitation that enable capturing process knowledge separately for each involved
role and support the identification of conflicts in the perceived work process and
facilitate the resolution of this issues.
In the next section, the process elicitation approach is described. The follow-
ing section outlines the requirements on methodological support during elicitation.
Focussing on methodology, the subsequent section introduces the concept of role-
distributed modeling and describes three different ways of creating role-distributed
models. The final section briefly reports on the first in conducting role-distributed
modeling and outlines the next research steps.
Elicitation Approach
Depicting collaborative work in business process models requires a clear under-
standing of the concepts relevant for modeling. Following the approach of role-
centric modeling, i.e. describing who is doing what and communicating with whom
in the course of collaborative work, the relevant concepts used in the area of business
process modeling are “actor”, “role”, “activity” and “communication” (Soderstrom
et al., 2002).
Actors are individuals who are actively participating in a work process. Activ-
ities of different actors hare carried out in parallel without immediate interaction
with others and are coupled via explicit acts of communication (i.e. transferring
work results from one actor to another). Decisions on which activities are carried
out from a number of options are made by the actor based upon the outcome of a
34
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
prior activity or the content of incoming communication.
Business processes are not only valid for one specific set of actors but are spec-
ified in a more abstract way for a set of interacting roles. A role is an area of
responsibility in a business process. Consequently, several actors are able to take a
certain role in a business process. Communication acts are carried out among roles
and interlink the activities carried out by actors acting in a certain role.
When designing support for eliciting knowledge about work processes, the dif-
ferent kinds of activities described above have to be considered as fundamental
model elements. We distinguish the following types of activities: (a) individual ac-
tivities carried out by an role (including decisions); and (b) communication acts to
link individual activities of different roles: (b1) outgoing communication acts, i.e.
actively sending work results or (b2) incoming communication acts, i.e. receiving
work results.
A modeling language used to support role-distributed business process model-
ing has to provide constructs that allow for structuring the model along role bound-
aries in order to allow for visualizing a model distributed along the involved roles
and keep the model parts interrelated (Adamides and Karacapilidis, 2006). Mod-
eling languages using the “role”-concept or equally interpretable constructs as the
primary factor of structuring meet this requirement (Giaglis, 2001). UML Activity
Diagrams (de Cesare and Serrano, 2006), BPMN (White, 2004), or S-BPM Fleis-
chmann et al. (2012) are examples of business process modeling languages that
enable this structuring approach and at the same time have existing tool support for
validation or execution.
Separating a process along the involved roles has implications for modeling
support. Modelers need support for interlinking and aligning different contributions
to a business process and ultimately deriving a commonly agreed upon model of the
business process. Each role’s contribution to work is created as a separate part of the
model. As noted above, one role can be taken by several actors in an organization.
Different actors introduce different viewpoints about how one role’s contribution
can be implemented (Herrmann et al., 2002). These different viewpoints require
alignment to derive one single, commonly agreed upon view on a business process.
Consequently, an elicitation instrument has to support collaborative modeling of
role behavior. All participating actors in this case share the same part of the model.
The role-based process parts are interconnected by communication acts, which
are represented by flows of discrete messages. The following activities can occur
in modeling communication (using the concept “message” to represent transmitted
results of work): (a) send a message to another role; (b) get notified that a message
has been sent to one’s own role; (c) request a message from another role to be able
to proceed with one’s own part of the process; and (d) get notified that another role
requests a message to be able to proceed with its part of the process.
The first two communication acts (a and b) are sufficient to describe all com-
munication situations if the business process is modeled in fully sequential manner.
This, however, requires actors to wait for another role to send a message before
they can proceed with modeling their own process part. Communication acts c and
35
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
d are introduced to avoid these delays in modeling and to explicitly allow to express
expectations on modeling that might require further discussion. Elicitation support
has to allow the specification of these different types of messages as well as the
resolution of inconsistent communication acts across roles.
Support for Role-distributed Elicitation
A role-distributed modeling support concept is presented here to explore method-
ological options to meet the requirements described above. A simple modeling lan-
guage is used for this purpose, following the minimal requirements on a modeling
language supporting role-distributed modeling as specified above. Three different
types of modeling elements are used:
Activity modeling elements are used for representing activities carried out by
a role as well as acts for sending and receiving messages. The semantics of the
element (i.e. do something, send, receive) is determined during modeling time.
Message elements are used to either send a message (outgoing message element) to
another role or request a message from another role (incoming message element).
Their respective incoming or outgoing message counterparts are added to the com-
munication partner’s modeling surface to link. Incoming messages or message re-
quests, however, do not necessarily need to be processed by the communication
partner immediately. They are pooled in tray areas that visualize all unprocessed
messages (cf. Figure 1).
Figure 1. Example setting of role-distributed models in an intermediate stage during modeling.
The use of the three modeling elements are visualized in Figure 1, which shows
an elicitation process in an intermediate stage for illustration purposes. The depicted
scenario consists of two interacting roles. The behavior of role 1 is modeled by three
actors, two actors provide input for role 2. The modeling surfaces include trays for
coupling to the respective other role on one of their borders.
Activities (labelled with lower-case letters in Figure 1) are placed on the surface
and are associated following their sequential order. Optional paths are represented
36
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
by decision parameters placed next to the according association link (labelled with
upper-case letters in Figure 1).
The two model parts are interlinked using message elements (labelled with num-
bers). Following the coupling concept, message elements always exist in pairs of
two. The semantics of a message element changes depending on wether attached
to an activity element or kept in the tray area: (a) an incoming message attached
to an activity (e.g. activities a, c, or h in Figure 1) represents the act of processing
a received message; (b) an outgoing attached to an activity (e.g. activities e, i, or
j in Figure 1) represents the act of sending a message to a communication partner;
(c) an incoming message placed in an tray area represents a message that is offered
by a communication partner, but has not yet been processed; and (d) an outgoing
message placed in an tray area represents a message that is expected by a commu-
nication partner, but has not yet been created and sent.
The messages kept in the tray areas make mutual expectations and potential
communication flaws explicitly visible. Requested messages or unused incoming
messages that remain in one of the trays always point at a mismatch beween the
expectations and the current behavior of the communication partners. During elici-
tation, this visualization of communication problems triggers negotiation and align-
ment activities that allow for the specification of a sound overall model.
Three different procedural approaches for distributed model elicitation can be
identified following the concept of behavior and communication specification de-
scribed above. They differ in the point in time when message specification happens.
In ex-ante communication negotiation, all messages are specified collaboratively by
the involved actors before the roles’ behaviors are described. The messages are
initially placed in the tray areas for each role and a then used during behavior mod-
eling. In ex-post communication negotiation, each role’s behavior including all out-
going and required incoming messages are modeled separately. In a consolidation
step, the communication among the roles is then aligned by mutually matching re-
quested and sent messages. In ongoing communication negotiation, messages are
put into the trays of communication partners immediately as they are specified dur-
ing behavior modeling. Inconsistencies or different understandings are discussed
immediately.
All three approaches stress different aspects of the modeling process and appear
to be suitable for different modeling purposes. Ex-ante communication negotia-
tion creates an common overall picture of the work process to start with and leaves
identification of communication problems to the subsequent distributed modeling
phase. Uncovered communication problems then require an additional round of
alignment. Ex-post communication negotiation by contrast forces modelers to ini-
tially only focus on their own contribution to the work process. The identification
of inconsistent communication acts is most likely here. The alignment of commu-
nications acts could lead to the need for a subsequent revision of roles’ behavior
models, if fundamental inconsistencies, e.g. conflicting communication sequences,
are identified. Ongoing communication negotiation avoids the need for fundamen-
tal revisions of either behavior models or communication acts, as both are specified
37
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
simultaneously. Different viewpoints are immediately visible and can be discussed
ad-hoc. This immediacy, at the same time, can be challenging for modelers, as they
are continuously confronted with incoming messages or message requests while at
the same time describing their own behavior.
The three approaches are described here without any preference and are cur-
rently subject to closer examination with regards to their practical applicability. The
first experiences gained from these explorations are described in the next section.
Initial Experiences and Future Work
The modeling concept so far has been deployed in all three methodological varia-
tions in two different practical settings. In all cases, the models were built using
paper-based modeling cards without any technical modeling support. In case A,
the process of assembling a pneumatic cylinder was subject of elicitation. The ac-
tors were 8 students (6 male, 2 female) of business information systems, who were
trained in the production process for 2.5 days as part of a practical course. All stu-
dents already had extensive experiences in business process modeling. The process
involved four different roles, of which each was taken be two students. All three
methodological approaches were conducted using three different but equally com-
plex variations of the production process. Case B was taken from healthcare sector,
where 6 healthcare professionals (4 female, 2 male) modeled the admission process
of an elderly client to long-term care (involving 4 roles in total). None of them had
prior experiences with modeling, neither were they confronted with explicit process
models in their professional life. All three methodological approaches were used in
different steps of the elicitation process.
Overall, all participants in either case were able to create correct models (in
terms of how the modeling elements were used and linked to other model parts).
Differences, however, occurred during the modeling process, which can be at-
tributed to the different backgrounds and prior experiences in modeling. Modelers
with no experiences in modeling (in case B) repeatedly showed problems in under-
standing or correctly using the message elements. They were not able to consis-
tently distinguish between the act of sending or receiving a message and the mes-
sage itself and consequently had problems in assigning designators to messages.
This problem was less evident in ex-ante communication negotiation, where people
were not introduced to sending and receiving activities. The misconceptions could
largely be overcome by providing examples of correctly designated messages.
The unexperienced modelers in case B preferred ex-post communication negoti-
ation over the other two variants. They were unable to handle the complexity of the
ongoing message negotiation setting and did not manage to incorporate the incom-
ing messages while modeling their own role’s behavior. Ex-ante communication
specification was perceived to cause superficial effort, as they felt they had to go
through their work process twice to first identify their communication and then to
actually create the model. Two modelers also felt constrained by the already exist-
ing messages in modeling their role’s behavior. The ability to uncover inconsistent
38
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
communication expectations in ex-post communication negotiation was repeatedly
noted as the most useful aspect of the whole modeling session.
Preferences were different for the experienced modelers in case A. They pre-
ferred ongoing message negotiation as it was perceived most efficient and being
the fastest way to reach a consistent overall model. Ex-ante message negotiation
was considered a well suited approach and hardly led to the need for revisions after
behavior modeling. It was generally preferred over ex-post message negotiation,
which was considered to be cumbersome and hardly providing any added value.
As no clear preference for any methodological approach can be identified, fu-
ture research will further examine the effects of the different points in time during
modeling when communication acts are made explicit. The next steps are to resolve
issues in understanding the semantics of the modeling elements — in particular the
message element — for inexperienced modelers. In a further step, advantages and
disadvantages of the different methodological approaches for different combina-
tions of modeling goals, and prior modeling experiences of the participants will be
examined. A more elaborate empirical setting will be used to overcome the limita-
tions of the explorations described above, which mainly suffer from limited com-
parability and observably different complexity of the modeling subjects (with the
production process being more accurately describable than the healthcare process).
A second strain of research and development currently worked on is tool sup-
port. Based upon an existing interactive tabletop modeling environment (Oppl and
Stary, 2011), means to support a technically augmented distributed modeling work-
flow, including the currently omitted requirements on communication support, are
currently implemented. Additionally, a mapping between the the modeling lan-
guage used here and S-BPM (Fleischmann et al., 2012) is currently worked on,
which will allow to validate and execute the created models. This will enable to
identify model errors that can remain undiscovered due to the distributed nature of
model elicitation (such as dead-locks by mutually waiting for messages to be sent).
Summarizing, the approach presented here is a first step towards business pro-
cess model elicitation that explicitly uncovers existing or potential collaboration
issues in organizational work processes. The modeling approach enables to inde-
pendently create models for each involved role and aligning the communication
acts among these roles in the course of the modeling act. The resulting models
can directly be mapped to modeling languages that are supported by BPM tools
for validation or workflow support. While the initial experiences with applying the
modeling approach in practical settings are promising, future research has to adress
methodological considerations to facilitate model alignment across roles as well as
technical means of modeling support.
Acknowledgments
The research leading to these results has received funding from the European Commission within
the Marie Curie Industry and Academia Partnerships & Pathways (IAPP) programme under grant
agreement no 286083 (IANES).
39
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
References
Adamides, E. D. and N. Karacapilidis (2006): ‘A knowledge centred framework for collaborative
business process modelling’. Business Process Management Journal, vol. 12, no. 5, pp. 557–575.
Antunes, P., D. Simões, L. Carriço, and J. A. Pino (2013): ‘An end-user approach to business process
modeling’. Journal of Network and Computer Applications.
Dann, H. D. (1992): ‘Variation von Lege-Strukturen zur Wissensrepräsentation’. In: B. Scheele
(ed.): Struktur-Lege-Verfahren als Dialog-Konsens-Methodik. Aschendorff, pp. 2–41.
de Cesare, S. and A. Serrano (2006): ‘Collaborative Modeling Using UML and Business Process
Simulation’. In: Proceedings of HICSS’06. IEEE Press.
Fleischmann, A., W. Schmidt, C. Stary, S. Obermeier, and E. Börger (2012): Subject-Oriented Busi-
ness Process Management. Springer.
Gasson, S. (2005): ‘The Dynamics of Sensemaking, Knowledge, and Expertise in Collaborative,
Boundary-Spanning Design’. Journal of Computer-Mediated Communication, vol. 10, no. 4, pp.
00–00.
Giaglis, G. M. R. (2001): ‘A Taxonomy of Business Process Modeling and Information Systems
Modeling Techniques’. International Journal of Flexible Manufacturing Systems, vol. 13, no. 2,
pp. 209–228.
Herrmann, T., M. Hoffmann, G. Kunau, and K. U. Loser (2002): ‘Modelling Cooperative Work:
Chances and Risks of Structuring’. In: Cooperative Systems Design, A Challenge of the Mobility
Age. Proceedings of COOP 2002. pp. 53–70, IOS press.
Herrmann, T., K. U. Loser, and I. Jahnke (2007): ‘Sociotechnical walkthrough: a means for knowl-
edge integration’. The Learning Organization, vol. 14, no. 5, pp. 450–464.
Oppl, S. and C. Stary (2011): ‘Effects of a Tabletop Interface on the Co-Construction of Concept
Maps’. In: Proceedings of the 13th IFIP TC13 Conference on Human-Computer Interaction
(INTERACT 2011). pp. 443–460, Springer.
Rittgen, P. (2007): ‘Negotiating Models’. In: J. Krogstie, A. Opdahl, and G. Sindre (eds.): Advanced
Information Systems Engineering. Springer Berlin / Heidelberg, pp. 561–573.
Rittgen, P. (2010): ‘Success factors of e-collaboration in business process modeling’. In: Advanced
Information Systems Engineering. pp. 24–37.
Soderstrom, E., B. Andersson, P. Johannesson, E. Perjons, and B. Wangler (2002): ‘Towards a frame-
work for comparing process modelling languages’. In: Proceedings of the 14th International
Conference on Advanced Information Systems Engineering, CAiSE. pp. 600–611, Springer.
Stuit, M., H. Wortmann, N. Szirbik, and J. Roodenburg (2011): ‘Multi-view interaction modelling
of human collaboration processes: a business process study of head and neck cancer care in a
Dutch academic hospital’. Journal of Biomedical Informatics.
White, S. A. (2004): ‘Introduction to BPMN’. BPTrends.
40
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Operationalizing Dialogue Games for
Collaborative Modeling
Stijn Hoppenbrouwers1,2, Rob Thijssen1 and Jan Vogels1
1
Radboud University Nijmegen, the Netherlands
2
HAN University of Applied Sciences, Arnhem, the Netherlands
stijn.hoppenbrouwers@han.nl,
jan.h.vogels@gmail.com,
thijssen_rob@hotmail.com
Abstract. In our ongoing attempt to create and support workable “rules of play” for
effective, goal-driven conversations in the context of collaborative modeling, we have
now reached a stage in which a first operational setup for such ‘dialogue games’ has
been developed and tested. In this paper we present the basic, generic structure of a
game-like procedure description, based on a prototype game for conceptual (information)
modeling. The procedure has been tested and refined in a modest design cycle and has
been demonstrated to work realistically. Its generic structure is meant to be applicable for
different types of conceptual modeling, e.g. process modeling, goal modeling, task
modeling, and so on (requiring specific rules and configurations for the different types).
However, in this paper we merely aim to present our basic approach. An illustrative
example is provided.
Dialogue Games
Dialogue Games are an innovative and, admittedly, experimental interaction form
meant to support, structure and guide conversations for modeling. This
functionality is desirable in context of helping people (in particular, novice
analysts and modelers) to efficiently and effectively proceed in a goal-driven,
focused collaborative effort to create a rational conceptualization or model
(Hoppenbrouwers & Rouwette, 2012). Building on previous work, we present the
outline of a workable set-up for dialogue games that can be used as a basis for a
41
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
set of such games, to be used in education and possibly also in practice in fields
like requirements modeling, business modeling, process modeling, etc.
Dialogue games originated as a theoretical concept from argumentation theory
going back to Wittgenstein’s “language games”. More recently they have been
operationalized in the form of structured chats (Ravenscroft & McAlister, 2006)
using the simple mechanism of openers: offering a small set of preset text
fragments from which chat participants can choose to start a chat entry. For
example, basic openers could be: “I have a question: …”, or “That is a bad idea
because …”.
These openers guide participants in structuring the chat, and also make this
structure visible. They create clear, natural structure in the log resulting from the
chat. (Hoppenbrouwers & Rouwette, 2012) first employed this idea in context of
collaborative modeling. The underlying concept here is that every collaborative
modeling effort essentially is a conversation producing that model
(Ssebuggwawo, Hoppenbrouwers, & Proper, 2009). As the conversation
progresses, the model advances, every step being traceable in the log. The chat
includes not only propositions for additions or changes to the developing model,
but also the extensive conversation about the propositions: questions, answers,
argumentation, negotiation.
(Hoppenbrouwers & Rouwette, 2012) showed that the opener mechanism can
be extended to include semantic and syntactic structuring besides discourse
structuring, by means of providing not only openers but also ‘fill-in’ patterns for
answers. For example, as an answer to the (predefined) question “Please give the
actor role responsible for executing this activity”, the predefined answer
structures offered in that context could be:
• “The actor role responsible for activity [ACT] is [AR]”
• “Sorry, I cannot answer that question”
By making the structured chat opener mechanisms context sensitive, it is
possible to purposefully shift conceptual and conversational focus, dynamically
entering consecutive Focused Conceptualization modes or ‘FoCons’
(Hoppenbrouwers & Wilmont, 2010). FoCons represent brief spans in a
conversation in which a clear and limited focus is maintained, for example “list
all roles for process P and their related activities”. Which focus to choose at what
point in the conversation is typically decided by a facilitator. We offer a
workable, game-like structure (“rules of play”) providing guidance and support in
such conversations-for-modelling, to both the facilitator (primarily asking
questions) and one or more participants (mostly doing the answering). The spirit
of this setup is not unlike that of a semi-structured interview, but with more
expicit, model-oriented goals and structure. By also providing some generic
conversational openers throughout the game, it is possible to blend highly focused
conversation with more generic questioning and answering. Also, it is possible to
combine the use of dialogue games with existing diagramming tools
42
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
(Hoppenbrouwers & Rouwette, 2012), for example SeeMe (Herrmann, 2009).
Finally, the setup is meant to be combined with practices and principles from
group facilitation and collaboration engineering (Hoppenbrouwers & van
Stokkum, 2012).
Below we will briefly present the main aspects of a prototype implementation
of our dialogue game concept. The game outline presented is an integration of
two related projects in which prototypes were developed cyclically (testing
leading to improvements) and finally evaluated through more tests, leading to
observations, remarks from test subjects, and their completing brief
questionnaires addressing matters like understandability and playability of the
game, perception of purpose and usefulness, and participant experience. For more
on this, we refer to the original master’s theses: (Vogels, 2013) and (Thijssen,
2013).
Game Structure and Rules
The dialogue game sketched in this section aims at the creation of a specific
dialogue game for the conceptualization phase of model elicitation following the
FCO-IM method for conceptual information modeling (Bakema, Zwart, & van
der Lek, 2002). For our current purpose this method should be seen as a case and
illustration. It was chosen because its operationalization is a main interest in our
research group, and because it includes a well described elicitation procedure. We
focus mainly on the generic setup, which should be useful for a broad range of
modeling or conceptualization games. The illustrative examples, however, still
concern basic FCO-IM conceptual modeling, which is a form of fact-oriented data
modeling.
The game distinguishes between two roles: the facilitator, typically a skilled
modeler/analyst who initiates and leads the game, and one or more participants,
typically people with good domain knowledge but not necessarily with any
background in systems thinking or modeling. In our prototype, we work with only
one participant. The game as presented thus supports a collaboration between
facilitator and participant only. However, by adding a multi-participant layer to
the game, it is quite simple to extend the dialogue to a collaboration between
multiple participants (as well as the facilitator): they propose, discuss and
improve an answer before (and after) it is entered as a statement in the main
dialogue. This mechanism has been successfully explored and demonstrated in
(Hoppenbrouwers & Rouwette, 2012).
The top node in the hierarchical decomposition of our game procedure is the
game as a whole. One focused modeling session will typically be done by playing
the game once. The game is divided into phases. A phase represents a distinct
part of the modeling procedure, with a distinct conceptualization goal. For
example, in our prototype we split the FCO‐IM elicitation procedure into two.
43
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
The example game covers only the first phase (“conceptualization”): identifying
and explicitly formulating the domain concepts and relations (words, phrases)
sought for, within the conceptual frame (meta-model) of the FCO-IM method.
The second phase, discarded in this paper, concerns the systematic elicitation of
constraints on populations of the model. The FCO-IM procedure requires the
gathering of example sentences (‘facts’) used in recurrent communication patterns
in the domain. These examples are then rephrased at a higher level of abstraction
(thus going from instance level to ‘fact type’ level). The elementary type-level
phrases so created are the basis for a formal structure (model) that can also be
represented diagrammatically, showing the related concepts and relations
(language elements) used in the domain: its ‘information grammar’ (Bakema et
al., 2002).
Covering a phase iteration from start to end is called a round; a round is one
instance of the activities belonging to a phase. In our example, an attempt at fully
charting one phrase (objects and the relation(s) between them), covering one
element of the domain description (called a fact type), constitutes one round. The
structure of the phase allows for some freedom of action within a round, so
rounds do not have to be played out identical to one another. The end of a round
is a decision whether to start a new round (because the result is still incomplete or
otherwise not satisfactory) or end the phase. The rules clearly describe how to
proceed at this point to force a decision about ending the round. Importantly, at
any point in the game the facilitator may decide to revisit completed concepts for
amendments. These ad hoc flow decisions can override the standard flow.
Each phase of the game is subdivided in a number of steps. Steps are small
separate sets of related activities within a round that are more operationally
described than phases and rounds. Going through one iteration of a step is called a
turn. Multiple turns can be taken to finish a step.
A mission list is created at the start of the game and continuously updated
throughout the game. It plays a vital part in keeping focus and helps the facilitator
make decisions. The mission list consists of a top level goal (the main goal of the
session) and sub-goals. The facilitator has full control over the mission list. For
each concept which emerges during elicitation, a number of sub-goals are created
and then pursued, systematically asking questions related to the concept (based on
the method’s meta-model). The current conceptualization goal is highlighted and
finished goals are crossed off. The mission list (or a summary thereof) can also be
viewed by the participant. Below we show an example of the mission list in mid
game. Strikethrough items are goals accomplished; the highlighted concept is the
one focused on in the current round. The various sub-goals are achieved through
the various FoCons in the steps of the round. Space prevents us from explaining
the method specific modeling terms used in the example; for more on this, see
(Bakema et al., 2002).
44
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
• Create FCO-IM model of “student registration” domain
o Concept “Course” [+]
o Concept “Student” [-]
- Generate 4 examples of “Student”
- Generate elementary fact
- Elicit identifier
- Generate LTL-FTE for repository
- Generate OTL-FTE for repository
- OPTIONAL: identify uniqueness constraint (UC)
- OPTIONAL: identify totality constraint (TC)
- Draw part of the Information Grammar Diagram
- Validate drawn Information Grammar Diagram and repository
information
The flow of the game is directed by decisions made by the game facilitator.
Some decisions can be made by applying clear-cut, discretely decidable rules, like
“if only one unfinished concept goal remains on the mission list, select this goal
and move to step 2.” Sometimes, however, a more intelligent involvement of the
facilitator is required. For example, it can be decided to skip a repeated and
possibly annoying validation step, at some risk (for example: “is this phrase
correct in the domain: follows ”). In such cases, the rules may
offer suggestions (“only skip a validation if you feel fully confident that further
validation is not necessary”) but leave the decision to the facilitator.
The standard activities of which a step consists are: FoCon, game procedure
and decision. FoCon dialogue rules to a certain degree regulate and support the
actual facilitator-participant interaction within the game: the focused question-
and-answer part. We divided the prototype phase into three steps based on three
FoCons identified in the original FCO-IM procedure: “Generate Concepts”,
“Qualify Concepts”, and “Validate Information Grammar Diagram (IGD)”.
‘Game procedures’ concern administrative background work done by the
facilitator, that in advanced digital implementations of the game could be partly
or fully automated. For example, the updating of the mission list is such game
procedure, as is the drawing of an IGD. Decisions are concern the flow of the
game as explained above.
The components as discussed shape the flow of the game, which is
unpredictable (within limits). The rules specify the details, as explained above.
Flexibility is important to deal with unexpected situations and allow for ad hoc
iterations. We provide defaults which can be followed by novice information
analysts who are unsure how to proceed or react. With this mechanism, we avoid
the bogging down of the procedure. The flow rules guide the facilitator. The only
flow rule for the domain expert is: “follow the lead of the facilitator”.
45
In: Nolte, A., Prilla, M., Rittgen, P. and Oppl, S.: Proceedings of the International Workshop
on Models and their Role in Collaboration at the ECSCW 2013 (MoRoCo 2013)
Questions and answers are at the heart of the game. The facilitator will try to
elicit the content by systematically (but not too rigidly!) asking questions to the
participant. The questions structure the conversational part of the game. Each
FoCon comes with a dedicated repertoire of question and answer templates. As
explained in the first section, some of these are highly focused, others very
generic. The facilitator may give an example answer to help the domain expert
conceive and formulate a correctly formed answer (S. Hoppenbrouwers, 2012). It
is not mandatory to use every question available in a turn. Some examples of
predefined questions in step 2 (phase 1) of the game are the following:
• Could you give a meaningful name for this