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.
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
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 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.rwthaachen.de/Publications/CEUR-WS/Vol-777/. Selected papers from the workshop
will also be published in a special issue of the International Journal for
eCollaboration
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.
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.
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, 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 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. Cooperation on Models and Models for Cooperation Tom Gross, Christoph Beckmann Human-Computer Interaction Group, University of Bamberg, Germany (<fistname>.<lastname>(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.
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.’
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 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.
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 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.
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 ‘preestablished 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. 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 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 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.
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 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.
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.
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 reflection 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 reasonable segments on which a step-by-step consideration can be based, and for prompting the participants to ensure a systematic reflection.
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
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
requires 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
interactions and visualizing there outcome may prove as very time consuming
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
In summary, the goals of the STWT are: Combining various perspectives, when considering the segments under several 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
In the following we want to discuss and propose how the STWT-oriented collaboration 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.
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 cardinality depending on how many participants have indicated the relationship. At
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
Citizen Service Number (Elicits an identifier for a concept) • How do you distinguish between <object>s in your communication? (Auxiliary question for eliciting an identifier for a concept) • Can there be two <object>s with the same <identifier>? (Validates the uniqueness of an identifier)
The question and answer mechanism can be implemented using some basic software. Main inspiration and example for such software is the Interloc system for generic dialogue games (Ravenscroft & McAlister, 2006). Central to this enhanced chat system is the use of ‘openers’, as explained in the first section. Additional rules are the following.
1. A participant and facilitator alike can only speak when it is their turn to speak (i.e. turn taking is enforced). Experiences with Interloc have confirmed that this is a highly desired feature in a structured chat.
2. Relevant categorized elements (words, phrases) in the answers are marked (in the prototype: by hand, by the facilitator) so they can be easily recognized and traced by both human players and the system. Such items, once identified, can be added to the mission list, planning further question asking about them. As mentioned, the items are typically related to the meta-model of the modeling language underlying the game, but may also represent intermediate concepts (‘half products’) in the process towards a target conceptualization. For example, an elicited instance-level object (“John Doe”) will still have to be categorized and named, and will be used as input for the elicitation of an object type concept (“Student”).
3. In addition to offering a dedicated repertoire of question and answer patterns for each FoCon, a context-sensitive mechanism is added that limits the availability of questions and answers for every consecutive chat entry within the FoCon (i.e. each conversational move). This mechanism is role differentiated, meaning that depending on the context (step, previous move) a move within the FoCon (for example, asking one question or giving one answer) is offered only to either the facilitator or the participant. Through the mechanism, ‘question flow’ is constrained, which turned out to work nicely. However, the flow rules can also be left void, allowing an unrestricted open FoCon flow based on a set of available questions and answers without a constrained temporal ordering or role-specific availability.
4. The interface for choosing openers first offers a choice between some briefly described question or answer options. Only after a choice is made, a matching text template is offered which can be altered at will by the player. This includes the tagging of specific items that make them machine recognizable. For example, at a particular point in step 2, one of the options for a facilitator move is “Ask for distinctive object identifier”. Choosing this option provides the template (already listed above) “How do you distinguish between <object>s in your communication?”. The facilitator can then fill in the <object> slot, effectively entering the move “How do you distinguish between distinguish Students in your communication?” in the FoCon dialogue. Next, one of the moves offered to the Participant is “Give the identifier asked for”. If chosen, the template plus example offered are “<object>s are distinguished by …. (For example: Cars are distinguished by Licence Numbers).
In an advanced version, it should be possible to make some parts of the template freely adjustable, and some not adjustable. This can be augmented by partially automated tagging.
Conclusion and future directions
The synthesis of two prototypes, also extending previous and less guided experiments (Hoppenbrouwers & Rouwette, 2012), have served well in creating operational and clearly structured setups for advanced, specialized collaborative dialogue games. The next step will be to create a robust, user friendly and generically usable digital environment combining the best features of the various prototypes. As in any software development project, there will no doubt be new challenges and insights as we continue our effort to provide user friendly support for guided/structured conversations in collaborative modeling. In addition, we aim to include links with visualizations and verbalizations mirroring the concepts put forward in the conversation, thus completing the connection with more traditional, diagram-based forms of modeling. Finally, we continue our effort to include ‘groupware’ and group facilitation features in our dialogue games.
proach for Lay User Modeling Alexander Nolte, Michael Prilla Information and Technology Management, Institute for Applied Work Science, Ruhr University of Bochum; {nolte|prilla}@iaw.rub.de Abstract. Approaches of collaborative modeling and model usage aim to increase the participation of stakeholders in modeling, but either still require experts support or are bound to certain phases of the model lifecycle: This makes it hard to compose an overall concept of collaborative model usage and development. In this paper, we argue that we need concepts to engage users without modeling capabilities into self-directed, usermanaged processes of using and working on models. We present a corresponding model lifecycle as well as suitable interaction and participation modes, using examples from our ongoing work on integrating lay-users into model usage and development. We analyze this work and present open issues to be discussed by the community.
Process models are common tools in modern organization. Most approaches of
using them for analysis, specification and guidance in organizations have been
developed and designed for expert users, that is, people trained in process
analysis, modeling or model usage. Recent work has amended that this does not
involve stakeholders in a way that encourages them to become active model users
themselves
The (ongoing) work we present here aims at taking these approaches one step
further, towards the support of self-directed, user-managed collaborative usage
and development, which can be performed by users without expertise in modeling
as most collaborative modeling solutions still rely on expert support
There are a lot of approaches and tools for collaborative modeling and model
usage that include participants other than modeling experts. They vary from
approaches requiring (expert) facilitation to self-directed modeling and model usage
Content collection: An important part of model development is gathering information about the process. This includes process steps (activities) as well as roles carrying them out and resources used by them. Table 1 shows a variety of expert-driven approaches methods and tools supporting this phase, while there is a lack of self-directed, user-managed approaches. Non-expert users need to be supported to gather model content – some expert-driven modeling approaches even skip this phase, merging it with the following one.
Model prototyping: Building on the content collected before, this phase is intended to create a process shape and to allocate the content (activity steps, actors etc.) to it, thus aiming at creating a first representation of the process. This proves to be challenging for people without modeling expertise, as it requires a translation from mental models to model language. While most approaches supporting this phase rely on expert support, some allow for self-directed alignment of process content through e.g. clustering. This cannot be expected to result in a fullfledged process model it is a first step in model prototyping. The challenge thus is how interaction with models and modeling tools can be designed to allow users without deep modeling knowledge to create a useful model prototype.
Design and negotiation: This phase aims at creating a process model out of the previously developed prototype that all participants can agree on and that includes the necessary details for implementation (either within the organization or by support of tools). This process might be difficult, as differing views about certain process steps may be present that have to be negotiated and represented in the model. Therefore, most approaches supporting this phase use some kind of expert facilitation. There are however approaches such as voting that may serve as a support for negotiation and allow for participants to become actively involved.
Usage: After completing the model different stakeholders (e.g., workers, management, developers) can use it to guide work, transfer knowledge or use it as a reference for tool implementation. This usage may raise questions about the content or details of the model and it might impose high cognitive and time efforts because of the complexity that models may have. As there is not always a facilitator present to describe the model in an adequate abstraction or to answer questions on details, in self-directed modeling The challenge is to enable people to work with models without this support.
Refinement: Similar to BPM lifecycles, the refinement phase of model usage and development aims at integrating experiences from practice and measurements taken on the performance of the process into a process model thus revising and improving it. While there are approaches that relate lacking performance to steps in models and thus allow focused improvement of these parts, for more informal feedback of stakeholders or self-directed reflection of processes currently hardly any approaches are available. If modeling is to be done by users in a self-sustained manner, this phase needs to be supported, as otherwise models will soon either become outdated or will show an idealized view instead of real work processes.
Regarding these challenges, the questions arise (1) whether we can support these phases of model development and usage in a way that enables self-directed model interaction for stakeholders others than experts and (2) how support for these phases can be created and smoothly connected to the respective other phases in order to support the whole lifecycle. In what follows, we relate our work to the lifecycle and identify open issues and questions to be tackled by future research.
Based upon the previously described model lifecycle we will now describe our
approaches to integrate lay users into them. Besides these proposals, future
research needs to clarify the role of expert facilitation in the phases.
respect to their position within a process sequence and also assign roles to the
respective activities that are involved in conducting these activities
We presented a participatory model lifecycle and its respective phases. We also showed current support and issues for self-directed non-modeling expert participation within these phases. While it became apparent that phases like content collection and model prototyping are supported in a promising way, others still lack proper support for process stakeholders to become active in model development and usage. Especially phases like design and negotiation and usage still rely on experts. For design and negotiation we are currently planning to makes use of milestones as scaffolds thus supporting process rather than content related clustering. Using approaches such as Kanban and Gantt diagrams for project planning that are known to process participants might also be beneficial. Our future work will focus on discussing current issues thus aiming at enhancing existing support for non-modeling experts developing and using models throughout the model lifecycle. Furthermore we are aiming at seamlessly intertwining these phases thus creating an approach that ties them closer together. Andersen, and Richardson, (1997): 'Scripts for group model building', System Dynamics Review, 13 2, pp. 107–129.
Cherubini, Venolia, DeLine, and Ko, (2007): 'Let’s go to the whiteboard: how and why software developers use drawings', Proceedings of the SIGCHI conference on Human factors in computing systems pp. 557–566.
Dumas, La Rosa, Mendling, and Reijers, (2013): Fundamentals of Business Process Management,
Springer.
W. van Stokkum1, P. Heiner1, S.J.B.A. Hoppenbrouwers2 and H. Mulder3 1Everest B.V., ‘s Hertogenbosch, the Netherlands w.van.stokkum@everest.nl p.heiner@everest.nl 2HAN University of Applied Sciences, Arnhem, the Netherlands stijn.hoppenbrouwers@han.nl 3Antwerp Management School (AMS), Antwerp, Belgium hans.mulder@viagroep.nl Abstract. In this paper we discuss background considerations, domain properties, and some design principles for collaborative modeling environments combining the Business Rule Management approach and the Collaborative Modeling approach. The context focused on is that of translating law texts to operational processes and systems for implementing those laws in the public sector. The process of operationalizing law is very difficult to tackle: a diversity of stakeholders have to be involved to reach consensus on semantics, goals and business service design. We consider collaboration techniques crucial in order to create the required broad basis of acceptance regarding operational policies and their formulation. Collaboration techniques also enhance the efficiency and transparency of the process. We discuss the new role of collaboration in relation to the governance processes of the organizations. We illustrate a design case by describing an environment we are developing. We reflect on some lessons learned, concluding that adopting collaborative modeling techniques alone is not enough. Explorations show that additionally, rules and mechanisms are needed to structure and facilitate the group decision making process.
This paper was written in context of an ongoing development project aiming to create a collaborative modeling environment developed to support Dutch governmental organizations in implementing legislation into their operational processes. Though we do sketch the current prototype environment and some design principles, the paper mostly concerns generic considerations about collaborative aspects in this application domain and its consequences for “law execution support systems”.
In the process of business rule creation and management, a variety of stakeholders (legal experts, business management, business architects, IT-experts) work together in order to translate legislation into usable specifications for operational business processes, including specifications for business rule driven IT-systems. In the Netherlands, as well as in various other countries with a thoroughly digitized governmental and public sector, such processes can be observed to exist in many domains (e.g. tax, customs, subsidies, permits, defense) and across a number of governmental organizations.
This process is commonly recognized as being very complex. Legislation is not directly usable in operational situations (typically, law execution by public service organizations). Terms and phrases used in legislation documents often contain pragmatic mismatches and contradictions because of the different contexts in which they are used.
Also, legislation tends to describe WHAT a policy should be, but not HOW it should be implemented by the variety of organizations that have to deal with it. Frequently the legislator deliberately leaves definitions and criteria vague, in order to let exact and definitive criteria arise in practice. In short: substantial a dditional policy making is needed to design business services and operational business rules that can be handled in everyday work processes.
Current methods for ‘translating’ legislation into operational rules (though perhaps ‘developing’ would be a more accurate word here) typically have their origin in Business Rule Management practices. This discipline traditionally approaches the translation quite rationally, for example (Wyner, Engers, & Bahreini, 2010). The normal approach is to rewrite sources (legislation documents) directly into some sort of formal logic, in a format that can be logically validated and is suitable for further translation into executable rules that can be handled by business rule engines and other rule-based systems.
However, the actual translation process in practice can hardly be classified as
being “rational” in the discrete and deterministic sense. Interpreting legisla tion and
the design of business services, thus implementing legislation, involves input of a
variety of stakeholders. All stakeholders act according to their own perspectives
and goals and use their own ‘domain specific language’. Traditional methods tend
to ignore these aspects. They regard them as being the concern and responsibility of
the “super IT-analyst”, who has to consult all stakeholders involved and unify their
views and formulations. Such super analysts are very hard to find in real life,
which causes a scalability issue within the organization. While the speed of
implementation power increases dramatically due to the introduction of modern
business process management platforms, analysis and design become the new
bottlenecks
Ignoring collaboration factors during the formulation of operational policies also introduces another serious issue. The business policies that will be implemented often only include the input of a limited set of stakeholders. In many cases, only a legal expert is consulted and legislation is rationally converted into some kind of logic. The resulting working instructions and systems often do not meet the views and practices of the knowledge workers that have to deal with real life cases. As a result, they feel unsafe because decisions are made that cannot be motivated or that do not take into account the situational context of cases in real life. In short, lack of a common base of understanding has negative effects l ike the leaving of valuable employees (not willing to adopt the policy made), customer unfriendly behavior (“the system is always right”; “computer says no”) or fraud and sabotage (manipulating real life data/facts in order to reach a desired outcome, or simply ignoring systems and policy), causing erroneous and inconsistent behavior of the organization’s services.
In order to fulfill the need for collaboration in law-based business rule creation and management, a modeling environment is being developed combining traditional business rule management techniques with those used in collaboration environments
Commonly known collaboration techniques (chat, shared annotation of documents, discussions, forum, mentioning, case management) are used to optimize the process of working together and making shared decisions. Collaborative techniques as in, for example, (de Vreede & Briggs, 2005; Kolfschoten, Briggs, de Vreede, Jacobs, & Appelman, 2006) turn out to be a crucial factor to tackle the issues in collaborative rule management experienced today
With the help of collaborative modeling techniques, a large group of people can be involved in shared decision making. By facilitating an online workspace, people will no longer be dependent on each other’s agendas. Asynchronous work reduces the need to physically meet during design and group decision making. A substantial larger number of people directly or indirectly can be involved.
When working in an environment deploying collaboration techniques, questions, answers and arguments in discussion are systematically logged so they can be shared and responded to at a later moment. This also allows for detection (not necessarily automatically!) whether people are arguing from the same perspective or not, which can help prevent misunderstandings and mistakes rooted in deviant interpretation.
Sharing knowledge is no longer limited to a point to point interchange between individuals. When reusing the model elements in multiple products and services, decisions and semantics will automatically be reused too. The possibility of reusing the outcome of the ‘translation process’, including the underlying group conversation, is essential for implementing consistent and correct behavior of organizational services. For the government, this means consistent and reliable behavior towards citizens and companies.
In our modeling environment and domain, in addition to the common application of collaboration ,computer supported collaboration did get another very important, and unexpected new role. It has been integrated with the governance processes of the organization.
The business rules (operational policies) created in the process are implemented in a business rule system. This system is able to automatically reason over these rules so it can automatically decide whether e.g. citizens or companies are entitled to receive subsidy or are allowed to receive a residential permit. Even the amount of tax citizens have to pay are calculated automatically. For the organization it is crucial to be able to explain why a decision is made. Although a direct link to relevant legislation sources at first hand seems sufficient, exact explanation can only be based on the design decisions made when formulating the operational policy. So when the system generates explanation it actively uses the arguments behind the discussions when formulating the business rules, in order to really provide 100% transparency in decision making. Without computer supported work this could never be realizable because these arguments never were systematically logged.
Lawyers use these outcome of collaboration processes results when judging official complaints being filed. They even use them when preparing the lawsuits.
The prototype environment in development enables various stakeholders in developing multiple interconnected models in parallel: a model concerning the requirements formulated by the legislator in the law documents, a model with a design of the business services that will be implemented by the governmental organization in order to “bring” the law’s business rules to relevant citizens and/or companies, and a model containing the design of the operational business process, and a model containing the implementation of these business processes within the organization. The different stakeholders involved in creating these models can work together in parallel and use each other’s input. Collaboration techniques help them to discuss about the design and to reach consensus about contradicting opinions and concerns. Because each stakeholder have its own “language and abilities to handle abstract models”, the environment emphatically respects the variety of stakeholders. Therefore, stakeholder specific ‘views’ or ‘design studios’ are developed.
The studio for legal experts rules, legal rights, obligations, procedures and so on. It will also enable visual modeling of the hidden structures that specify how decisions or calculations should be made.
During creation of a law, the proposed law text may change many times. The system will act on automatically sent change alerts. It will intelligently compare the text of newer versions, will visualize changes made and will transfer the unchanged parts of the model from the old version to the new version. Besides comparison, active support is available for determining the impact of changes on the design specification already available, and on operational processes and systems. The business service design studio for business architects Besides the view for the legal expert, a view is created for the business architect responsible for determining and designing the organization’s business services. This view uses its own sources (documents), but will also use model elements being created by the other stakeholders, like the legal expert. However, these model elements will be presented in the domain specific language of the business architect. For example, the model element “legal right of a citizen” will be represented as a “deontic modality” to the legal expert whereas it will be represented as a potential “business event” toward the business architect, and so on. By translating the model elements in line with one ‘mental model’ to those in line with that of another type of stakeholder, stakeholders with different backgrounds and languages still can work on one interlinked and consistent, hidden overall model.
In the future, additional views will be added for the other stakeholder types involved, such as IT-analysts, information architects, managers of data administrations, and so on.
Enable collaborative shared decision making A set of collaborative techniques are combined in an online workspace that is available in and across all “stakeholder views”. It will allow modelers as well as more indirectly involved stakeholders to engage in various forms of digitally mediated, dedicated conversation: discuss, react on each other’s arguments and opinions, and so on.
In our explorative designs and evaluations it became clear that exclusively adopting collaborative modeling techniques to share ideas and information is not sufficient. When designing the business service and its products another important stakeholder comes in sight: the customer, being a citizen or an professional organization that will be confronted with the services and products based on legislation. Important decisions have to be made such as: “who is our target group exactly?”, “what is the profile of our customer?”, “which criteria should be met in order to entitle individuals within this target area to the products made available by law, like subsidies?”, “which questions should we ask? We cannot always use the terms used in the legislation text, because people might not be able to answer them due to the high level of abstraction.
In order to reach an optimal design, serious games, like for instance a “mystery game” can play an important role. In the mystery game a set of “mysterious” stakeholders (panel members) are trying to ask with a minimal set of questions enough information of the mystery customer in order to find out whether he/she is entitled for getting e.g. a subsidy. Of course each stakeholder use the law and internal policies to formulate the questions. The resulting profile and dialog leads to customer friendly design decisions.
In our explorative designs and evaluations, the collaboration techniques supporting and structuring such conversation turned out to be a crucial success factor in tackling most issues experienced in the field today. As discussed, they help to gather a solid basis of understanding between all stakeholders. They help to improve efficiency in decision making. They offer the possibility to share knowledge between individuals and they help to implement transparent business processes. Although these positive aspects will not come as a surprise for the community of computer supported collaborative work, they are completely new terrain for the business rule management community however.
The new role of collaboration in governance will have impact on the organization and tools developed to support the collaborative process. First of all a direct reference should be created between discussions and the business rules that are being produced. Also it is necessary to select w hich discussions may be used for the governance process. E.g. is it desirable to include the names of the stakeholders involved in the formulation of the business rule or should this be anonymous or accessible for special lawyers only? This will be an important issue for further study.
Important additional success factors may be found in further refinement of the basic techniques by means of additional visualization, games and facilitation support.
There is no effective discussion without a clear understanding of the problem. Visualization of developed policy is crucial to evaluate the effectiveness and impact of the business rules formulated.
As discussed, serious games are considered to be an additional means of enhancing the outcome for a problem. Game elements combined with effective visualization can help stakeholders discover the best operational business policy together. Rules of play can also help guide problems collaborative solving processes and conceptualization. In addition, game elements can help motivate participants and make goals and progress more visible and manageable.
Besides diverging techniques like sharing ideas and opinions there is a str ong need for converging techniques in order to make actual decisions one can base further action on. In short, there is need for facilitation. Explorative investigations in collaborative modeling setups, in the case project but also, for example (Hoppenbrouwers & Rouwette, 2012), showed that rules are needed to structure and facilitate the group decision making process. Many of these rules deal with social factors like handling different levels of experience and power positions between stakeholders involved. Facilitation is a skill and this capability is often scarcely available within organizations. Because of the continuous process of translating large scale legislation into specifications, an important next step is to investigate whether it is feasible to add computer aided facilitation techniques to the platform, in order to meet the crucial needed scalability.
de Vreede, G. J., & Briggs, R. O. (2005). Collaboration Engineering: Designing Repeatable Processes for High-Value Collaborative Tasks. Proceedings of the 38th Hawaii International Conference on System Sciences (HICSS38). Big Island, HI, USA: IEEE Computer Society.
Hoppenbrouwers, S., & Rouwette, E. (2012). A Dialogue Game for Analysing Group Model Building: Framing Collaborative Modelling and its Facilitation. International Journal of Organisational Design and
Engineering, special issue on Collaborative Modeling, 2(1), 19-40.
Hoppenbrouwers, S., Schotten, B., & Lucas, P. J. F. (2010). Towards Games for Knowledge Acquisition and Modeling. International Journal of Gaming and Computer-Mediated Simulations, Special issue on AI and Games, 2(4), 48-66.
Kolfschoten, G., Briggs, R., de Vreede, G. J., Jacobs, P., & Appelman, J. (2006). A conceptual foundation of the thinkLet concept for Collaboration Engineering. International Journal of Human-Computer Studies, 64, 611-621.
Wyner, A., Engers, T. v., & Bahreini, K. (2010). From Policy-Making Statements to First-Order Logic. Electronic Government and the Information Systems Perspective (pp. 47-61): Springer. Using natural user interfaces for collaborative process modelling in virtual environments Erik Poppe, Jan Recker, Daniel Johnson, Ross Brown Queensland University of Technology, Australia Abstract. Modelling business processes for analysis or redesign usually requires the collaboration of many stakeholders. These stakeholders may be spread across locations or even companies, making co-located collaboration costly and difficult to organize. Modern process modelling technologies support remote collaboration but lack support for visual cues used in co-located collaboration. Previously we presented a prototype 3D virtual world process modelling tool that supports a number of visual cues 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 made the tool difficult to use for novice users. We now present an evolved version of the technology that addresses these issues by providing natural user interfaces for non-verbal communication, navigation and model manipulation.
Introduction
Virtual worlds have received continuous attention in industry and research for purposes of
training and remote collaboration
In previous work we have explored the use of virtual worlds for remote collaborative
process modelling
In our ongoing experiments on the use of virtual worlds for collaborative modelling, we often note that relatively inexperienced users find using a mouse and keyboard to navigate the virtual environment difficult, in turn impeding their ability to focus on the task at hand – process model creation, analysis or manipulation.
Prototype
We have previously presented a prototype process modelling tool (Figure 1) that uses a
virtual environment and avatars to enable visual cues such as pointing and gesturing to
facilitate communication between remote collaborators
We address the first issue by tracking the posture of the user with a consumer depth camera and applying this posture to the avatar in real-time. This approach enables the use of gestures such as waving, gesticulation, and head nods and shakes, without having to navigate menus or remember buttons. Furthermore, this input method allows for gestures that have not been predefined or subtle variations of typical gestures.
Second, we have implemented a feature for model manipulation via touch input. Instead of having to use a mouse to edit the process model, the user can touch the process model on the screen to create, move, scale or delete elements.
A final issue of using a virtual world compared to other modelling tools is navigation. The 3D view requires users to navigate their virtual bodies in the virtual space, both for 1 A demonstration video of the prototype can be seen at: http://www.youtube.com/watch?v=nvfoBfWpxKU communication purposes and for viewing all parts of the model. This navigation requires movement along 3-axes and rotation around 2-3 axes and is commonly achieved using a combination of a mouse for rotation and multiple keyboard keys for movement. In our experience, this is confusing for users with limited experience with virtual environments. We therefore implemented head-tracking for camera control. The user can now turn her head to either side, up or down, to have the view turn that way and move his head forward, backwards, sideways, up or down to move the camera in the according direction.
Between these input methods, the keyboard is now required only for labelling model elements. Also, we have reduced the number of keys the user needs to remember to a bare minimum. These interfaces should now enable users to focus on the task of collaborative modelling instead of handling input devices.
Acknowledgments We have presented a prototype virtual world that uses natural user interfaces to minimize usability issues for users that are unfamiliar with virtual worlds. In our ongoing work we are executing experimental tests to examine (a) whether this interface indeed facilitates the use of the tool by novice users, and (b) how collaborative modelling processes are enacted by users The contributions by Erik Poppe to this research have been supported by the Smart Services CRC in Australia
References