Wikis are well-known for supporting collaborative writing. They are focusing on asynchronous collaboration. Today, synchronous text editing in the web is supported by several tools and approaches. However, this possibility is still missing in wikis. Based on a prototype implementation, this paper presents design considerations for a wiki integrating synchronous collaborative editing as a special kind of hypertext authoring.
• Human-centered computing → Collaborative and social computing systems and tools; Wiki; Synchronous editors • Human-centered computing → Interaction paradigms; Hypertext / hypermedia; collaborative interaction
Wikis1 support asynchronous collaborative editing of web pages. The first wiki was invented by Ward Cunningham in 1995 [6][15]. It was called “WikiWikiWeb” as a substitute for quick web (“wikiwiki” is a Hawaiian word for “quick”) [5]. The application scenario was editing and sharing software engineering design patterns. Design patterns aim at reusing object-oriented design structures, i.e. descriptions of communicating objects, interfaces, and classes to solve a general object-oriented design problem in a particular context [10]. Both, design patterns and wikis, have originally been developed as agile forms of technology following a simple reusable system [6]. The wiki idea was to provide a website, which allows users to quickly and easily share, modify, and improve information in a knowledge base collaboratively [15].
Today, wikis are not only used for best practice patterns in software engineering, but also for sharing experiences in several other domains, such as in project management or IT service management. Storytelling is, amongst others, a very important knowledge management instrument supporting the understanding and sharing of experiences. The most famous wiki is the online encyclopedia Wikipedia [6]. It is based on the Wikimedia technology2. There are currently 286 active Wikipedia instances based on different languages. In total, there are presently more than 42 million articles [19] and the number is increasing strongly. However, if multiple users edit the same page at the same time, this causes an edit conflict [20]. The user saving the text at a later point in time than others needs to merge the changes manually. This can be error-prone. Through the versioning of wiki pages, errors can be resolved later, but this can cause much work.
Synchronous collaborative editing is a special case, but in the context of edit conflicts it might be very helpful. Today, synchronous text editing in the web is supported by several tools and approaches. However, this possibility is still missing in wikis, even though it can help supporting the agile idea of self-organizing teams.
In the following, this paper presents related work, a proof of concept implementation of a synchronous collaborative wiki, and first usage feedback. Afterwards, it focuses on design considerations for such a wiki. The paper ends with conclusions and future work.
Copyright held by the author(s). 2 https://www.wikimedia.org/ 2
Hypertext authoring has been worked on in several directions. In the context of a personal authoring environment, NoteCards [13] is an important approach, for example. In NoteCards, notes are represented as cards holding text and images, and being interconnected with typed links. Fileboxes are a kind of composite notes useful to organize large collections of notecards. In parallel, HyperCard [11] came up as a simpler hypertext authoring tool for users of Mac computers. Ward Cunningham was involved in the development of HyperCard. It influenced his first wiki project [5].
In gIBIS [3], hypertext networks based on the Issue-Based Information System (IBIS) approach can be created asynchronously in a group. IBIS is an argumentation-based approach focusing on problem solving. Cooperative hypermedia approaches, such as in [16], focus on collaborative structuring – both asynchronously as well as synchronously with fine-grained notifications of other users’ interactions. In the context of hypertext narrative there is Tinderbox [2], for example. Tinderbox is a tool for making, analyzing, and sharing notes focusing on spatial hypertext, informal semantics, and web collage. Hypertext notes can be published on the web.
The real-time editors Etherpad3 and Google docs4 support
web-based synchronous collaborative text editing based on
operational transformations as replication and concurrency
control mechanism [
In [17], patterns for the design of computer-mediated interaction between humans are described focusing on reusable best practices. One pattern is called “Shared Editing” and focuses on the provision of an editor, with which users can manipulate shared artifacts simultaneously. Studies, such as in [18], focus on investigating user behavior during real-time collaboration. It shows that there are also differences in cultures. For example, in the context of slide sharing, U.S. participants preferred individual navigation through the slides, while Japanese participants wished there was a moderator. 3 http://etherpad.org/ 4 https://docs.google.com/ 5 https://github.com/share/ShareJS/ 3
As a proof of concept, a wiki providing synchronous collaborative text editing has been implemented [7]. Figure 1 shows a screen dump of the current prototype. Articles, i.e. wiki pages, can be selected, edited, newly created, or deleted. Presence awareness is provided, i.e. user names currently editing one and the same article are visualized. In addition, editing awareness is provided through the visualization of remote cursors.
For integrating synchronous collaborative editing
possibilities, we have used ShareJS. The ShareJS server
uses operational transformations [
TogetherJS12 is another JavaScript library, which supports collaborative text editing. In addition, it already supports shared cursors and integrates a text chat as well as an audio chat via WebRCT13. In our prototype, the communication features of TogetherJS have been integrated. While ShareJS synchronizes JavaScript models, TogetherJS integrates directly through the DOM (Document Object Model)14. 6 https://github.com/ajaxorg/ace/ 7 https://www.meteor.com/ 8 https://nodejs.org/ 9 https://www.mongodb.com/ 10 https://codemirror.net/ 11 https://tools.ietf.org/html/rfc7763/ 12 https://togetherjs.com/ 13 https://webrtc.org/ 14 https://www.w3.org/DOM/ 3.2
We did a first evaluation with a group of students using Groupware Observational User Testing [12]. With this evaluation method, evaluators observe users performing collaborative tasks in a laboratory setting. Problems are monitored and users are asked to think aloud about what they are doing. In addition, we have asked about feedback through a final questionnaire. The students were distributed in different rooms and were asked to edit several web pages – similar to articles in Wikipedia. Mostly, they have used the chat to communicate and coordinate themselves. The audio chat did not work properly on all browsers. Communication is very important in synchronous collaboration settings. As a result, the prototype system basically illustrates the advantages of integrating synchronous editing in wikis using operational transformations. Conflict situations and complex merging efforts can be avoided. However, this first evaluation also identified some drawbacks of our prototype system: For using the communication tool, the users needed to manage a session by themselves, i.e. to invite the other users whereas the shared editing was coupled automatically.
Not all integrated editors included the visualization of remote cursors. The cursors are important awareness instruments. Without remote cursors, the users did not know immediately where the others were editing. Students, who did not know the markdown syntax well, needed a lot of time to search and write according to the syntax. For them, the synchronous collaboration helped to learn the language.
In a few cases the response time of the editor was considered slow. 4
In this section, we will look at and discuss design considerations from two perspectives, which are detailed in the following subsections: Collaborative writing strategies as well as Groupware and hypermedia design issues 4.1
There are five well-known collaborative writing strategies [14].
Firstly, a single author might write on behalf of a team. In this case, from the technical point of view collaborative authoring features can be reduced to sharing the results. In sequential single writing, the shared document is passed from one author to the next one, after the author has written her or his part of the document. For this strategy, traditional wikis are already well-suited as edit conflicts cannot occur.
In parallel writing, authors work on their part of the document at the same time, respectively. This can be managed with a traditional wiki assigning each group member a separate starting wiki page. However, if parallel writing does not mean separate sections, but different roles in the authoring process, such as author, editor, or reviewer, then edit conflicts might occur (dependent on the work process).
In reactive writing, a document is created in real-time without substantial preplanning. It is also known as joint writing, consensus writing, or reflective writing. Authors react to each other’s changes or additions, e.g. by creating new sections or changing existing ones. In reactive writing, a high level of consensus is needed and can be developed. Version control is more complex and synchronous collaborative writing is necessary.
Finally, in mixed mode two or more of the collaborative writing strategies are combined so that synchronous collaborative writing can avoid edit conflicts and support consensus.
According to well-known Groupware experiences, such as in [9], it is important to think about awareness features – features that make visible other users and other users’ interactions, such as presence awareness and shared cursors. Also, in asynchronous collaboration, awareness features are important, e.g. to show which relevant wiki pages have been updated since the last login.
Another important issue is floor control. Shall authors be able to write simultaneously or is there a moderator or a predefined process passing the floor to the different authors? In our proof of concept implementation, we give authors, editing the same page at the same time, simultaneous writing possibilities. In this way, reactive writing is possible so that consensus can be built and editing conflicts can be avoided.
Session control is another issue to consider. Do authors need to invite others? In our prototype system, all authors, editing the same page at the same time, are automatically in a shared editing session. It could also be useful to ask writers, with which writing strategy they would like to continue. In this context, a voting mechanism can be helpful. A shared session should also establish a communication channel automatically.
A joint editing session can either be planned or take place by chance. In any case, it is helpful to provide support for latecomers, i.e. people joining later than others. Can they understand what happened? In our prototype system, they can scroll through the document and see what has been edited. In addition, versioning support is usually useful. Furthermore, dedicated latecomer functionality might be helpful, such as recording and playing the session history. Another issue are customized views. In our prototype, we have integrated three different editors, but the authors see and work on the same text. In addition, they can scroll individually. In this context, it needs to be decided which parts of the shared data need to be coupled – the text or the text and the navigation? Or can this be customized? It is also interesting to think about the integration of WYSIWYG editors as not all authors want to use markup languages.
Finally, are there any privacy concerns that need to be considered? Usually, it is important to give users control over which information gets shared and what remains private.
According to Halasz’ seven issues for hypermedia systems [13], versioning is an important feature to maintain and manipulate a history of changes. Wikis already incorporate versioning support. When integrating synchronous collaborative writing, one needs to differentiate versions necessary for concurrency control from document versions, which the authors would like to submit. Here, it might also be useful to integrate decision support to help authors to decide when to submit a new joint version. Alternatively, the system could be able to submit sections of a wiki page separately as new versions.
Regarding collaborative work, Halasz points out that a high degree of concurrent work is important. From the viewpoint of the collaborative writing strategies, this is the case with reactive writing. In asynchronous collaboration, locking mechanisms shall be fine grained. Synchronous collaborative editing capabilities complement this view. 5
We have motivated the integration of synchronous collaborative editing capabilities in wikis and presented a proof of concept implementation. Based on this, we have described first usage feedback and design considerations for this special kind of hypertext authoring.
Currently, we are exploring further JavaScript libraries for this hypertext authoring purpose to improve the prototype implementation.
In our future work, we would like to make a user study among Wikipedia authors to get more feedback and requirements regarding synchronous editing in wikis.
J. Rubart, J.M. Haake, D.A. Titze, and W. Wang. 2001. Organizing Shared Enterprise Workspaces Using Component-Based Cooperative Hypermedia. In Proceedings of Hypertext’01, ACM Press.
T. Schümmer, and S. Lukosch. Patterns for Computer-Mediated Interaction. John Wiley & Sons. 2007.