WikiConveration Final Report

1. Introduction

The Environment and Discovery Collaboratory (EDC) is a socio-technical collaborative design environment that exploits face-to-face interactions among domain experts and other interested participants to facilitate the design of solutions to complex ill-formed problems in the context of urban and transportation planning (Arias, 2000). In its most recent incarnation, the EDC is an embedded computational system with three physical elements: a monitor that serves as a informational reflection space, a flat table top that is “aware” of objects that has been placed upon it, and a set of wooden objects with embedded transmitters that allow the system to distinguish among a limited set of unique pieces. In the context of regional transportation planning, the EDC supports the exploration of group problem solving (and social creativity) through the interaction amongst communities of practice, represented by transportation planning experts, and communities of interests, represented by other interested parties, by encouraging the articulation of tacit knowledge and problem framing through boundary objects that bridge the perspectives of communities of practice and interest (Arias, 2000; Fischer, 2005).

2. Problem Statement

In it current incarnation the EDC requires participants to be co-located and their interactions to be focused around the computationally embedded table. This synchronous interaction structure limits participants to those that can easily fit around the physical table who are within easy reach of manipulative objects. Would it be possible to increase the number of participants, the type and level of tacit knowledge, and the number of different perspectives by extending the EDC to support asynchronous interaction? What are some of the strategies that would help the EDC to support asynchronous interaction? How would these strategies be implemented?

From initial conversations with potential users, we find that adding information to a reflection space is a common task that is not supported well by the EDC or other collaborative systems. As a first step, we created an initial prototype of commenting capability (in the form of discussion or annotation) that would enable authors of a joint document to provide localized comments and feedback. This capability would help users to collaborate with each other across time and geography by enabling them to add contextual information that would have been implicitly available if they were interacting face-to-face. These contextual information would help those not at a meeting to interpret the information against the backdrop of a larger task (such as community design).

We used the EDC as specific context of our investigation into asynchronous interaction approach. However, we have used MediaWiki as a platform for prototyping due its ease of implementation (see our implementation section later in this paper).

3. Rationale

The EDC, like many other system designed to support collaboration, is based on the idea that learning and problem solving is a social process where the result of many minds working in coordination is better than one. These systems often provide different level of support for both synchronous and asynchronous interaction. Systems that support synchronous interactions promote social awareness among participants by providing chat or instant message capabilities (such as SubEthaEdit). Systems that support asynchronous interactions provide social awareness through a bulletin board or discussion format. Microsoft Word, for example, provides a limited form of collaborative support through a serial review model where a user can send a document to other users and receive proposed text alterations and comments.

Collaborative systems may choose to implement one, or both, of these methods depending on the context of the tasks and the type of interaction that need to be supported. We believe that the area of asynchronous interaction support, particularly in the context of joint document production, is a promising area for investigation to support learning and group problem solving since it has the potential for increasing participation across many collaborative systems such as the EDC, a community-generated free encyclopedia (Wikipedia), or an online system to encourage middle and high school students to learn about the science behind disaster news.

4. Related Theory

However, what are the benefit of supporting asynchronous interaction? The theories of distributed cognition provide strong arguments for supporting asynchronous collaboration.

4.1. Distributed Cognition and the EDC

The theory of distributed cognition argues that cognition and cognitive processes is defined by individuals, the interaction between them, the resources provided by their environment, and the functional relationships between all of these elements. Individual distributed cognitive processes may span and coordinate amongst individuals, social groups, internal mental representations, memory, external objects imbued with information, and time (Hollan, 2000).
Thus, learning and problem solving occurs in the context of asynchronous social and environmental interactions.

A related, but philosophically different theory of learning called situation cognition, views learning not only as a process of shared cognition but primarily as a “process of becoming a member of a sustained community of practice” (Lave, 1991). Thus learning is a process of identify formation and community acculturation. As a result, communities of practice possess common knowledge, views, accepted norms of behaviors, and tools that are not easily accessible to outsiders (Arias, 2000). Transportation and urban planners belong to a community of practice that uses specific domain concepts not easily accessible to outsiders.

The EDC is used the frameworks of distributed and situated cognition to bridge the symmetry of ignorance of the communities involved (Arias, 2000). It also facilities collaboration by externalizing revealed tacit knowledge and place them in the reflection space. These artifacts are accessible to all participants and may spark further discussion and negotiation (Arias, 2000). However, since the EDC currently only supports face-to-face interaction, generated artifacts may not reflect the knowledge and concerns of individuals not at the planning meeting.

4.2. Providing Context

Interested individuals not present at a collaborative planning meeting may want access to information and documents produced and the decision agreed upon. They may also want to contribute additional information, correct inaccurate facts, and critique agreements that resulted. Given the complexity of the collaborative process, it is very difficult to capture the richness of the collaborative situation so that individuals not at the meeting can understand its context. Context can be defined as “information that can be used to characterize the situation of entities (i.e. whether a person, place, or object) that is considered relevant to the interaction; … and is typically the location, identity, and state of people, groups, and computational and physical objects (Fischer, 2004).” Even if participants place information in the EDC’s reflection space, it can be very difficult to understand without contextual information. Likewise, when off-site participants add information to the reflection space it may very difficult to understand without contextual information (Fischer, 2004).

5. Method

We used the task-centered user interface design method as a guide for understanding user needs and tasks that need to be supported by the asynchronous features of a collaborative system (Lewis, 1993). As a first step we interviewed four potential users with different background and experiences (see project site for user profiles and interview notes). From these interviews we created a list of design priorities. From this list of design priorities we selected those related to joint document production and use those as guiding principles for our proposed design.

For the prototype implementation we used mediaWiki, the open source software that supports Wikipedia, and create extensions to implement our meta conversation capability (see our implementation section).

6. Design Priorities

The interviews conducted reveal the following design priorities:

• what-you-see-is-what-you-get (WYSIWYG) approach to wiki markup: Users mentioned that in the context of a wiki, using special markup notations to edit a page and then saving the page to view its final appearance often disrupt their work processes. Specifically, the time it take to save a page and return to the edit page removed them from the ongoing discussion and users loose both information and context during this time. In addition, users must spend time and effort to re-establish the context of the ongoing discussion. Finally, users also noted that most of the applications they currently use, whether web-based or not, have adopted a WYSIWIG approach and that is their preferred method of markup.

• document creation workflow mismatch: Users indicate that when they collaborate with each other users to create a joint document, they often default to using Microsoft Word even though it offers limited collaboration features because Microsoft Word has become the common platform for document production in many work and learning environments. As a result, users often use Word at the expense of a wiki to jointly produce document. However, when they use Word, users find that it does not support some of the desired collaboration features. For example, documents can only be viewed and commented upon serially; thus, users need to open and review multiple versions of same document to consider the feedback of the entire review team.

• social awareness cues: First, when creating or editing document with other people, users would like to see comments localized to a sentence in a document. They find that systems that group comments together at the end of the main document (such as a weblog) often forces them to spend extra time and mental effort to match comments to the portion of the documents that the comments addresses. Second, users find that additional identify cues such as the name of the poster, when the comment was posted, and additional background information may provide additional context in which to interpret the comment.

• comment search / filtering (contextual information management): Users would also like to be able to filter the display of the comments (such as display only the comments made by Scotty since Tuesday).

7. Design Description and Rationale

We propose to enhance a collaborative system’s ability to support asynchronous interactions by incorporating localized threaded comments into the body of a jointly produced document and provide related contextual information.

7.1 Definition of a Wiki and Background

A wiki is a very open-ended web application that serves as a framework for adding and editing content collaboratively. The overriding concept is that any user that can view content and can also easy and immediately edit that content. Other common traits include the ability to easily create a link to a page from any other page simply by knowing that page's name, the ability to create a new page by simply creating a link to it, and then navigating to it, and the use of a very simple markup language to provide formatting, which only provides a fraction of the formatting capabilities of HTML or CSS. Also central to the wiki concept is the concept of version control - any changes to any page are recorded, noting who made what changes and when the change was made. This allows any user to see the history of a page, including the differences between any two versions, and if necessary, undo certain undesired or malicious changes (Wikipedia, 2005).

The term "wiki" originated from the first ever wiki, the Portland Pattern Repository created by Ward Cunningham to discuss pattern languages, which was also called the WikiWikiWeb. The name WikiWikiWeb stems from the Hawaiian term "wiki wiki", meaning "quick" or "super-fast". This attempts to capture the intent of all wikis to make any operation lightweight and quick for the user.

In the Design, Learning, and Collaboration course, we have used a particular piece of wiki software called Swiki, which is simply a wiki written in the programming language Squeak. It shares all of the common wiki concepts: any user can edit any page, links are easy to create, pages are created by linking to them, there is a simple formatting markup language, and there is version control. Swiki also provides useful features such as versioned file uploads, which is becoming more common amoung wiki software, but is by no means universal.

7.2 Design Decisions

Stemming from our interviews with users, it was very clear that not only did conversations within the wiki need to be contextualized within the document they were discussing, but the context needed to be fine grained, down as far as the sentence or word level. Our prototype concept was to represent a given conversation thread as a "conversation bubble", similar to the dialogue bubble seen in newspaper comic strips (see screen shots below). The tail of these conversation bubbles would point to the part of the document the conversation was discussing. The conversation bubbles could be inserted by the user into the page.

Also, it was determined early on that it was very important to be able to hide and show each conversation thread independently. Thus, we used the concept of small conversation bubble icons to indicate to the user that there was a conversation there. By clicking on the icon, the user could choose to expand or contract the full conversation bubble.



Converstation thread collapsed



Conversation thread expanded

All editing happens within the conversation bubble, without reloading the main document. This allows the user to retain mental context, rather than having to suffer the typical coginitive switch from view mode to edit mode and back to view mode that is so common with wikis.

7.3 Implementation Process

We chose to implement a prototype using the wiki system MediaWiki, a popular wiki software package, and the software used to run Wikipedia, the largest wiki on the internet, and the largest open source encylopedia. There were a number of reasons behind this decision. MediaWiki has an extremely active user and developer base: meaning that there is currently active development, and is likely less buggy than more obscure software packages. Also, due to the high level of development activity, there is a fair amount of developer documentation and conversations and decent source code comments; which prove invaluable when attempting to modify an existing software system. Also, we were familiar with the MediaWiki as users, and familiar with PHP and MySQL, the technologies MediaWiki is based on, which limited the learning curve to simply learning the MediaWiki source code itself.

We chose to implement comments as a form of a template. Templates are special pages within MediaWiki which can be inserted into the middle of other pages. Not only that, but templates can have parameters, which are inserted into the content of the template when it is inserted into the body of a page. This allowed us a clean and easy way to the necessary HTML to display a comment into a wiki document, in a clear and consistent fashion.

In addiiton, the template itself creates an iframe, which loads the comment thread itself. This is extremely adventageous, as it allows the comments to be reloaded, without affecting the rest of the page. This is what allows the user to add a new comment on the fly, without a page refresh.

The comments themselves are simply a separate PHP page, which backends into a seperate mysql table in the database. Each thread has a corresponding id, and is also linked by page id. User authentication is performed via the standard media wiki user authentication - if a user is not logged in, their comments show up as anonymous.

7.4 Lessons Learned During Implementation

We learned a number of lessons during the implementation of the prototype. First off, MediaWiki proved to be very robust software, with extremely good UI design concepts, and a very strong technical architecture. In particular, because it is used on extremely high traffic sites, there is much attention paid to efficiency. Caching is used extensively, attempting to minimize the conversion from wiki markup to HTML as much as possible, as this proves to be a somewhat computationally expensive process. Caching proved to be an impediment to debugging at times, as it was not always clear when a cached page was being viewed, versus a newly generated page.

Also, much attention was paid to security during the development of MediaWiki. Thus, the user entry of arbitrary HTML is heavily restricted. This proved to be an issue, as certain elements such as iframes were stripped from the content during the rendering process. We ended up simply adding the necessary tags to the list of "allowed" tags.

8. Relationship To Our Social Collaboration Project

The major challenge for this project and other collaboration system is getting users to adopt and use this capability. Ernie Arias mentioned in his interview that tools don't motivate people, they makes it easy and possible for people to do what they want and intend to do in the first place. We believe that this commenting facility does not standalone; rather, it is one element of a carefully planned system that provides clear social incentive for people to participate. These social incentives may be based on the ideas of gift cultures and social capital (see our Social Collaboration report.

9. Next Steps and Conclusion

A systematic user evaluation of the our initial prototypes and another design iteration (and development) would be the next steps for our project. Due to this project short time frame presented our prototype to one potential user at the end of our interview and received good feedback. We believe that potential capabilities include:

• flexible search capibilities that allows users to filter for comments by specific users, dates, and topics;
• social tagging for comments;
• incorporation of a community-generated reputational system to help user access the validity of comments

Even with a simple limited prototype, we believe that this approach is very promising as a method to better support asynchronous collaboration in variety of context.

10. References

Arias, E. G., Eden, H., Fischer, G., Gorman, A., & Scharff, E. (2000) "Transcending the Individual Human Mind—Creating Shared Understanding through Collaborative Design," ACM Transactions on Computer Human-Interaction, 7(1), pp. 84-113.

Fischer, G., Lemke, A.C., McCall, R., and Morch, A. (1996). Making Argumentation Serve Design. In T. Moran and J. Carrol (eds), Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Inc. Hillsdale, NJ.

Fischer, A., Giaccardi, E., Eden, H., Sugimoto, M., & Ye, Y. (2005). Beyond Binary Choices: Integrating Individual and Social Creativity. International Journal of Human-Computer Studies (IJHCS).

Hollan, J., Hutchins, E., & Kirsch, D. (2000) “Distributed Cognition: Foundation for Human-Computer Interaction Research.” ACM Transactions on Computer-Human Interaction, 7(2), pp. 174-196.

Lave, J. (1991, c. 1996). Situating Learning in Communities of Practice. In Resnick, L. B., Levine, J. M. & Teasley, S. D. (eds). Perspective on Socially Shared Cognition. Washington, DC: American Psychological Association, pp. 63-82.

Lewis, C.and Rieman, J. (1993). Task Centered User Interface Design. Available online at http://hcibib.org/tcuid/

Wikipedia - Wiki. 27 Apr. 2005