It is a tradition in the School of Information Systems and Technology at Claremont Graduate University that a student who has recently passed the IST screening exam should give advice to those who have yet to take it in the form of a workshop.

I passed my exam in January 2009, and I’ve chosen to do it this year.   Specifically, between 2pm and 3:30pm tomorrow (Jun 20) in Burkle 24 on the CGU campus.

For all those who are attending (and for those who couldn’t), here are my slides and a ZIP file of all the notes and diagrams I made for myself as I studied for my own exam.

• Slides: 2009-IST-Screening-Exam-Workshop
• A ZIP file of my study notes.
• My posts on my experience.

Team wikis (also referred to in the literature as “corporate wikis” or “enterprise wikis”) are another type.  These are wikis used within the context of an organization for collaboration and coordination.   Where Wikipedia’s pages are highly stereotyped (being one of only a few types — encyclopedia entries, pages describing wikipedia policies, user pages or help pages), team wikis are used for many varied purposes, among them project management, workflow management, issue tracking, ad-hoc collaboration, knowledge management, tech support, e-learning, and communities of practice [Majchrzak et. al. 2006, p. 100].   Where Wikipedia has tens or hundreds of thousands of contributors and millions of readers all of whom have little or no personal connection, team wikis user bases are far smaller — on the order of ten contributors and tens of readers [Majchrzak et. al. 2006, p. 101] — and are all known to one another outside the context of the wiki.  Team wikis are also smaller, containing hundreds to a few thousand pages rather than the several million pages that Wikipedia now contains.   Finally, where the purpose of Wikipedia is to be a knowledge reference that converges to provide more accuracy and coverage as more people contribute, team wikis are evolving artifacts-in-use which continuously adapt to support changing team practices and goals and thus never converge to a completed state.

References

1. A. Majchrzak, C. Wagner, and D. Yates, “Corporate wiki users: results of a survey,” in WikiSym’06: Proceedings of the international symposium on Symposium on Wikis, 2006, pp. 99-104.

Stage 1: Understand the collaboration context.

What is the nature of the goals that will be fulfilled via the system, and what tasks will be performed to achieve those goals?   What kind of collaboration will be going on: mostly tightly coupled, mostly loosely coupled, or generally mixed-focus?  What is the nature of the group that will use the system?  How big is the group, and what kind of people are in it?  Do the people in the group know each other outside the system?  Are they collocated and thus have face-to-face interaction in addition to that in the workspace, or do they interact solely through the system?

Stage 2: Assess and define awareness information lacks and limitations.

This means identifying which types of awareness (personal, informal, social, group-structural, workspace) should be supported (see Types of Awareness) and what kind of information will be needed by the participants in the collaboration to support those types. Use the context from Stage 1 to drive this assessment.

Stage 3: Assess available and potentially available information sources.

Decide whether they can be transformed into the kind of awareness information that was identified in Stage 2.   These information sources should be fed via passive information gathering rather than active solicitation of users’ input (Dourish and Bellotti 1992).   Potential sources are those that are not currently available, but could be if we altered our groupware design to gather the relevant information.

Stage 4: Design the awareness display within the workspace to supply the necessary awareness information.

Choose appropriate metaphors to represent the information (Gutwin and Greenberg 2002), and present the awareness information within the shared workspace alongside the shared object, so that users can see the information and object concurrently, and find the information most relevant to the object, and also to make information available as and when needed as a context for individual activities (Dourish and Bellotti 1992).

Stage 5: Implement the design and evaluate the effectiveness of the awareness display.

Conduct empirical studies of the enhancement to evaluate effectiveness.  Possibly go back to Stage 1 through several iterations.

References

1. P. Dourish and V. Bellotti, “Awareness and coordination in shared workspaces,” in CSCW ‘92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, 1992, pp. 107-114.
2. C. Gutwin and S. Greenberg, “A descriptive framework of workspace awareness for real-time groupware,” Computer Supported Cooperative Work (CSCW), vol. 11, pp. 411-446, 2002.

Awareness of existing content

Han and Kim 2005: This paper describes a context sensitive navigation sidebar that presents parent pages, child pages and sibling pages of the current page with the idea that this should give people more idea of where they are in the wiki.  They claim that it encourages deeper hierarchical structures (6 levels deep vs 3 levels deep) and more linking from page to page.   They defined sibling pages by looking at pages that the parent page linked to.  They had some kind of relevance measure based on linkage of pages which would determine what pages should be listed as siblings.

Hirsch et. al. 2009:  Visual Wiki adds an independent node-edge graph layer on top of a wiki which links related pages and allows an overview of the knowledge in the system that can be navigated.   The paper describes three attempts to make this work.   The first attempt concerned building a node-edge graph automatically from a semantic wiki, while the second and third attempts used traditional textual wikis, with the graph layer being manually maintained independently from the text layer.  All implementations violate one of my core goals: don’t make more work for people by either requiring either one to make semantic linkages, or maintain the graph manually.

Ding et. al. 2007: The authors created a visualization (”CherryTree”) of a wiki used for sharing project proposals which grouped proposals sited at the same research lab together.  In each group, the visualization showed the people owned projects at that lab, and showed what projects they were leads of, and how recently the project pages had been updated.  They were able to do this because they incorporated information from outside the wiki: data from the corporate directory.   They determined project leads by looking at revision histories of the project pages and finding the people who edited the pages the most.  The visualization could also show number of visitors per project, number of editors and connections between projects (a project has a connection if it has shared editors).  A user could mouse over a project to get more information about it.  This work is, however, intended for a very specific use: wikis that house project proposals.  It was also tailored pretty tightly to how the wiki was used in at IBM, and to the organizational structure of IBM.

Espiritu et. al. 2006: In this wiki augmentation (“ENWiC”), a spider crawls the wiki and builds topic maps based on hyperlinks between pages, and uses emphasized text elements (such as headers) as key terms for the content page.  It then uses TouchGraph to display the topic maps as node-edge graphs and offers a user interface that allows users to hand modify the automatically detected topic maps.  It almost satisfies one of my requirements: and it augments an existing wiki without necessarily requiring users to do extra work.  To make it truly useful, they probably do need to do extra work in adjusting and annotating the graph.  It also depends on having a reasonable number of inter-page links, and differentiated header text. The task is also specifically on learning — being able to answer questions based on information to be found in the wiki.  Is that what I intend with awareness of existing content?

Reinhold 2006: A wiki trail is a directed graph of pages followed by a user through the wiki (Reinhold 2006, p. 49).  It can include reversal of path (A -> B -> A) and cycles (Reinhold 2006, pp. 49-50).  Such trails interrelate the pages traversed in a meaningful way (perhaps only meaningful to the user).  The system augments an existing wiki by tracking users as they traverse pages, generating trails from that tracking data and then augmenting the user interface of the wiki with trail visualization which shows where, when one is on a page, other people tended to come from and go to from that page.  They specifically want to augment existing wiki structure and navigation by extending existing wiki software (Reinhold 2006, p. 49).  They want to “reduce manual maintenance in favor of automatic or semi-automatic aids to increase productivity and efficiency” (Reinhold 2006, p. 50)

Ullmann and Kay 2007: The authors created a graphviz driven node link map of wiki pages to give an overview of the wiki and its use.  They colored the nodes by date of last edit, and encoded the relative number of visits to a page in font size.  They linked the nodes by hyperlinks.   They also encoded information about which tickets were related to which page (the platform was Trac, and the subject of the wiki was support for a software development project).   Hovering over one of the nodes gives more information about the node.  The visualization was generated on demand, and so always contained the most recent information.  The results from interviews with users showed that while it worked well with small wikis (around 30 pages), with larger wikis, the visualization became unusable (too much to look through).

Tagging or semantic wikis: Singh et. al. 2007, Giereth and Ertl 2008, Aumeuller 2005.  These all cause the user to have to go in and annotate pages or sections of pages with either freeform tags or RDF annotations.

Awareness of activity

Liccardi et. al. 2008a, Liccardi et. al. 2008b: This paper is specifically about asynchronous collaborative writing on single documents, specifically parallel writing in which participants are assigned separate sections of the end document, and then merge their sections into a coherent whole (Liccardi et. al. 2008a, p. 265-266).   CAWS is a wiki-like system of their own creation.   First, they have four awareness views: one for the user themselves, which shows the documents they’re currently working on; one which shows what other people have done recently; another which allows them to indicate their status (a la iChat) and a page which contains “group awareness information concerning users’ roles, responsibilities, their positions on issues and their status related to goals that they were initially set. ” (Liccardi et. al. 2008am, p. 266).  CAWS also has a document blog and forum to discuss things about the document, a planning feature in which one assigns roles to different participants; typically the owner of the document does this (Liccardi et. al. 2008b, p. 3).  Roles in this case possibly mean “what section do I edit?”  Users can enter estimates as to how long it will take to do their tasks. Finally, users can annotate sections of the document and refer to those annotations in the discussions.  a planning feature in which one assigns roles to different participants; typically the owner of the document does this (Liccardi et. al. 2008b, p. 3).  Roles in this case possibly mean “what section do I edit?”  Users can enter estimates as to how long it will take to do their tasks.

Atzenback and Hicks 2008: Helping people be aware of the community and of their collaboration partners is a good thing.  Such tools also help integrate newcomers into the community more quickly, because it could help them become aware of both the importance of community and also what their role and position in the group is.  Socs is implemented as a standalone browser for Wikipedia, written for OS X in WebKit and other Apple APIs.  It integrates with AddressBook, Mail.app and other Mac apps.  It presents the user with several windows: a browser window in which the article is presented (not necessarily from Wikipedia (Atzenback and Hicks 2008, p. 7); a window listing contributors to the article and how much they contributed; an address book of authors that the user knows; and a 2D map of a social space which shows the people the user knows, but distributed among the 2D space in a structure of the user’s creation.  In that space, those people the user knows and which also edited the article being viewed are highlighted.  The core of Socs is really this social space.  This space provides social reminding and social data mining.  The assumption in this article is that the kind of collaboration in Wikipedia is again that of a group of people making one document, while in a team knowledge base, this is not necessarily the case.   Teams have different goals for their wiki usage than do wikipedia teams.

Suh et. al. 2008: This paper presents an augmentation of Wikipedia which attempts to provide social translucence in an attempt to improve the percieved accountability and trustworthiness of Wikipedia articles.  The tool appears to be a filter for Wikipedia (you view Wikipedia through this other website), and it adds a dashboard to each article and user page.  Above each article which shows (a) a graph of edit activity in the article and its associated “talk” page (b) the list of users with links to their user pages) and (c) a graph for each user showing edit history on the article over time.   On each user page, it shows a similar dashboard, but in this case it shows (a) a graph of the user’s activity over time (b) the list of pages the user has edited (c) graphs for each page showing edit activity on the page over time and (d) a drill down ability which shows each individual edit by the user on a page.  The user page gives an overview of what topics a person is interested in as well as an evolution of those topic areas.

References

• D. Aumueller, “SHAWN: Structure helps a wiki navigate,” in Proceedings of the BTW-Workshop WebDB Meets IR, 2005.
• C. Atzenbeck and D. Hicks, “Socs: Increasing social and group awareness for wikis by example of Wikipedia,” in Procceedings of the 2008 International Symposium on Wikis (WikiSym) Porto, Portugal, 2008.
• X. Ding, C. Danis, T. Erickson, and W. Kellogg, “Visualizing an enterprise Wiki,” in CHI ‘07: CHI ‘07 extended abstracts on Human factors in computing systems, San Jose, CA, USA, 2007, pp. 2189-2194.
• C. Espiritu, E. Stroulia, T. Tirapat, and Insticc, “ENWiC: Visualizing wiki semantics as topic maps – An automated topic discovery and visualization tool,” in 8th International Conference on Enterprise Information Systems (ICEIS 2006), Paphos, CYPRUS, 2006, pp. 35-42.
• M. Giereth and T. Ertl, “Visualization enhanced semantic wikis for patent information,” in 12th International Conference Information Visualisation 2008, London, ENGLAND, 2008, pp. 185-190.
• H.-S. Han and H. Kim, “Eyes of a Wiki: Automated Navigation Map,” in Digital Libraries: Implementing Strategies and Sharing Experiences, 2005, pp. 186-193.
• C. Hirsch, J. Hosking, J. Grundy, T. Chaffe, D. MacDonald, and Y. Halytsky, “The Visual Wiki: A New Metaphor for Knowledge Access and Management,” in System Sciences, 2009. HICSS ‘09. 42nd Hawaii International Conference on, 2009, pp. 1-10.
• I. Liccardi, H. C. Davis, and S. White, “CAWS: an awareness based wiki system to improve team collaboration,” in 8th IEEE International Conference on Advanced Learning Technologies, Santander, SPAIN, 2008, pp. 265-267.
• I. Liccardi, H. C. Davis, S. White, and H. S. O. Southampton, “CAWS: Visualizing awareness to improve the effectiveness of co-authoring activities,” Special issue of Collaborative Computing in IEEE Distributed Systems Online, 2008.
• S. Reinhold, “WikiTrails: augmenting Wiki structure for collaborative, interdisciplinary learning,” in WikiSym’06: Proceedings of the international symposium on Symposium on Wikis, 2006, pp. 47-58.
• A. V. Singh, A. Wombacher, and K. Aberer, “Personalized information access in a wiki using structured tagging,” in OTM Confederated International Conference and Workshop, Vilamoura, PORTUGAL, 2007, pp. 427-436.
• B. Suh, E. Chi, A. Kittur, and B. Pendleton, “Lifting the veil: improving accountability and social transparency in Wikipedia with wikidashboard,” in CHI ‘08: Proceeding of the twenty-sixth annual SIGCHI conference on Human factors in computing systems, 2008, pp. 1037-1040.
• A. Ullman and J. Kay, “WikiNavMap: a visualisation to supplement team-based wikis,” in CHI ‘07: CHI ‘07 extended abstracts on Human factors in computing systems, 2007, pp. 2711-2716.

As artifact-in-use, from the time the first page is created in a team wiki, the wiki  is in use as a product: team members access and use the knowledge in the wiki.    While this is going on, the wiki is changing:  pages are added and edited, deleted and moved.   Wiki maintenance and growth must be carefully balanced with the utility people get from its use.

Wikis are always in a state of being finished in some sense, and in another sense, always unfinished.  They evolve and grow over time, and can live for years, possibly outlasting the people who started them.   They can grow to be large, to thousands of pages.  These factors make wikis challenging and costly (in terms of effort) to maintain even while they give benefits in terms of knowledge sharing.

In this way, wikis differ from other groupware which have been used in workspace awareness research.  Much of the prior work in workspace awareness typically concerns short term collaborations which have the goal of producing product at the end of a few hours or days (for example, Dourish and Bellotti 1992, Greenberg et. al. 1996, Gutwin et. al. 1996).  The set of collaborators is constant, they start from a blank slate and produce a finished product, typically a single document.

References

1. P. Dourish and V. Bellotti, “Awareness and coordination in shared workspaces,” in CSCW ‘92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, 1992, pp. 107-114.
2. S. Greenberg, C. Gutwin, and A. Cockburn, “Awareness through fisheye views in relaxed-WYSIWIS groupware,” in GI ‘96: Proceedings of the conference on Graphics interface ‘96, Toronto, Ontario, Canada, 1996, pp. 28-38.
3. C. Gutwin, M. Roseman, and S. Greenberg, “A usability study of awareness widgets in a shared workspace groupware system,” in CSCW ‘96: Proceedings of the 1996 ACM conference on Computer supported cooperative work, 1996, pp. 258-267.

There are, however, two kinds of limitations in the awareness support in current wikis: limitations in the existing mechanisms, and lack of support for some kinds of awareness.

Limitations in the existing mechanisms: activity

Some of the existing wiki mechanisms for awareness of activity — page history lists, recent changes pages, and watch lists — are not as useful as they could be because they require the user to work, sometimes work hard, to gather awareness information.  A collateral result of this is that users may miss activity in the wiki.  In addition, all these mechanisms are ex post facto: one only learns of activity in the workspace after that activity has happened.

Dourish and Bellotti (Dourish and Bellotti 1992) say to present the awareness information within the shared workspace alongside the shared object, so that users can see the information and object concurrently, and find the information most relevant to the object, and also to make information available as and when needed as a context for individual activities.  This is not the case with the existing mechanisms.

For the recent history page, the page history for a page and the watch lists the user must purposely navigate away from the pages they may be working on to those pages and then parse the information in order to discover maintain awareness.  This they do in addition to the primary work of maintaining and using the wiki.   Secondly, by default, the recent changes page typically lists only the last several days or last fifty or one hundred changes, and keeps only the last 90 days.  When there are a high volume of changes or when users who do not visit the recent changes page frequently are likely to miss workspace activity.

For the user profiles, users must manually maintain their user profile with accurate information.  This suffers from the inherent problems of informational mechanisms due to both the burden on and the dependency on the posting user (Dourish and Bellotti 1992, p. 109).  Such information is of limited trustworthiness and utility.

Limitations in the existing mechanisms: existing content

For the mechanisms which support awareness of existing content support in wikis — lists of titles, lists of words in titles — the problem is in the amount and quality of information given.   In any but the most simple wikis, the number of pages soon exceeds the capability of users to keep track of, and thus the lists of titles and of words in titles become unusable.   Secondly, page titles may not be good indicators of the content the page contains.  Wiki pages are typically not structured hierarchically (indeed, a flat namespace is one of the wiki design principles) and as the number of pages grows, the availability of reasonable page titles decreases.  At any rate, page titling suffers from some of the same drawbacks of informational awareness mechanisms that Dourish and Bellotti (Dourish and Bellotti 1992) speak of, namely that the user that titled the page may not understand how that title will be interpreted and thus equivocality becomes an issue in discovering existing content from page titles.

Lacks in awareness of activity support in wikis

Existing workspace awareness support mechanisms offer a view of what has changed in the workspace.  What is almost always lacking is information about what has been and is being used in the workspace.   By this I mean the information which can be used to answer the following kinds of questions:

• What pages do people most often look at?
• What pages do particular users look at?
• What pages are not looked at?
• How do most users traverse the wiki?

This kind of information is important for users of the wiki for several reasons.   First, it rewards authorship: if a user contributes to a page and then sees that the page is used, they may be incentivized to contribute to more pages.  Conversely, if people who are not contributing see that people actually do use the content in the wiki, they may be more inclined to contribute.

Second, this information may indicate where to dedicate effort.  If certain pages in the wiki are used, that may indicate that more or more fully described content of that kind may be appreciated.  Conversely, pages which are not used may be revisited to assess whether to improve them, discard them or let them remain.

Third, seeing what pages particular users look at can foster greater knowledge of team members.  If I know what you are interested in, I know more about you and can thus know better how I can collaborate with you or assist you in the  future.

References

1. P. Dourish and V. Bellotti, “Awareness and coordination in shared workspaces,” in CSCW ‘92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, 1992, pp. 107-114.
2. C. Gutwin and S. Greenberg, “A descriptive framework of workspace awareness for real-time groupware,” Computer Supported Cooperative Work (CSCW), vol. 11, pp. 411-446, 2002.

Existing wiki software used in the wild natively offers some awareness mechanisms that offer workspace awareness information.  Some mechanisms offer awareness of what other users in the wiki have been doing, who they are, what they are interested in and what kind of expertise they might have.  Others give users an overview of the extent of the information contained in the wiki, as well as indicators of what parts of the wiki might need work.

Awareness of users and their activity

There are four awareness mechanisms which are built into almost every wiki implementation that support awareness of the the other users of the wiki and their activity: page history lists, a recent changes page, user profile pages and some ability to watch particular pages and be notified of changes.

A page history list is associated with each page in the wiki, and show each change that has been made to the content of the page all the way back to its initial creation.   Users can see when the page was changed, who changed it, and what particular changes to it were done.  The page history lists offer feedthrough type awareness information (Gutwin and Greenberg 2002), particularly group-structural awareness and workspace awareness.  One can get an idea how the page got to be in its current state, who caused it to be in its current state and when.  One can also get an idea of who is invested in the content of the page and who might be experts in the area covered by the page.

The recent changes page is a single page which gives a global overview of the most current activity within the wiki.   It shows what pages are being worked on, who is working on them, when the changes occurred, and briefly what kind of change was made: create, edit, delete, rename.  There might also be a brief comment about the nature of the change by the author.  The recent changes page can offer informal awareness (if activity has happened recently enough), group-structural awareness and workspace awareness.   One can get an idea of what parts of the workspace are being worked on, who is doing the work, and when those changes occurred.   If one watches the recent changes page enough, one can get and idea of who works on what pages, when they tend to work and possibly what kind of actions they perform (mostly edits?  mostly reorganization?).

Users of most wikis have the opportunity to fill out user profile pages: pages about themselves.  On those pages they can list biographical information and areas of interest, expertise and responsibility.   Profile pages largely offer some social awareness and possibly some group-structural awareness (if we trust the authors to be honest and accurate about their roles within the community).

The ability to watch pages for changes may be implemented by presenting a special page for each user which lists recent changes to pages a user is interested in (MediaWiki) or by having the wiki e-mail the user each time a page they are interested in is changed (MoinMoin).   Watch lists give users workspace awareness for certain parts of the wiki.

Some particular wiki implementations have additional awareness mechanisms.  MediaWiki uses “talk” pages which house an active discussion and history of discussion of activities and decisions supporting authoring of the associated article.   MediaWiki also supports meta-informational markup (called “template messages”) on the content page itself, and this is used in Wikipedia (which is build on MediaWiki) to mark articles as needing particular types of work (“Citation needed”, “Does not meet neutrality standards” ), or as bing in certain states (“Currently being reworked”, “Protected until a dispute can be resolved”), or as being considered for certain actions (“It has been suggested that this article be deleted,” “Should be merged with another article”).  Both these mechanisms give awareness of the potential intention of individuals or of the group with regards to future actions, and can enable prediction of what might occur.

MoinMoin Wiki gives per-page access statistics, which give some indication of how much a page is read.

Awareness of existing content

There are two important aspects of team wikis which causes research on workspace awareness in wikis to differ from that which has been done in other groupware.  First, wikis are long lasting and constantly evolving.  Second, the amount of content in wikis can become large to the extent that even users with long experience with the wiki may not know its full extent.  Therefore, most wikis have some support for automatically listing the contents of a wiki in various ways: a list of all page titles, a list of all the words in the page titles, a list of orphans (pages which no other page links to) and of needed pages (links within existing pages which do not go to other pages).

The list of all pages and of words in all pages offer two ways to browse the wiki, and discover content the user may not be aware of, while the list of orphans and needed pages offer users direction as to what they might work on.

1. Try not to decrease the sense and power of community that successful wikis depend on.  Try rather to increase it.
2. Likewise, try not to decrease the effectiveness of the accountability measures inherent in wiki technology.
3. Try not to increase the cost of making changes to the wiki.

I feel that it is those design principles of simplicity and naturalness which have directly caused the recent success and proliferation of wikis.   In my opinion, much of the prior work in augmenting or changing wiki technology to support different goals  conflicts with one or more of these guidelines, most often it is by increasing the cost of wiki maintenance.   This is especially true of the work among academics to add semantic web support to wikis, which  in every case I’ve seen makes making edits much more laborious and difficult.

One of my primary goals in this work on adding awareness support to team wikis is not ignore these guidelines and thus possibly fundamentally change the way that wikis are used and perceived.

Wiki design principles

To arrive at those guidelines, I went back to what Ward Cunningham said were the design principles that drove his creation of wiki technology in the first place.   Here they are in their entirety (all design goals copied directly from http://c2.com/cgi/wiki?WikiDesignPrinciples):

• Open. Should a page be found to be incomplete or poorly organized, any reader can edit it as they see ?t.
• Organic/co-evolution. The structure of the site is expected to grow and evolve with the community that uses it.
• Incremental. It must be both possible and useful to cite unwritten pages.
• Observable. Activity within the site can be watched and reviewed by any other visitor.
• Convergent. Ambiguity and duplication can be removed by finding and citing similar or related content.
• Mundane/undistracted. A small number of conventions provide all necessary formatting.
• Universal. The mechanisms of editing and organizing are the same as those of writing so that any writer is automatically and editor and organizer.
• Tolerant. All input will produce output even when the output is not likely to be that desired.
• Overt/concrete. The formatted and printed output will suggest the input required to reproduce it.
• Unified vocabulary. Page names will be drawn from a ?at space so that no additional context is required to interpret them.
• Precise. Pages will be titled with sufficient precision to avoid most name clashes, typically by forming noun phrases.

I summarize these as follows:

If we make pages visible to all in the community, show how they have evolved over time and also who changed them and when, then give people in the community the freedom to edit any page while making editing and organizing the wiki as low cost to the greatest number of people as we can, the content in the wiki will increase in scope and quantity over time.

I distill that even further into three themes:

• Community: the wiki is a community resource, and social ties within the community bind people to the common purpose of making the wiki better.
• Accountability: changes are done in public, in front of the community, and attributable to individual authors.  Knowing this should lead authors to try harder to do good work, and hopefully reduce incidence of intentionally poor or counterproductive work.
• Low cost: changing the wiki does not cost people much in terms of overhead.  If the activities associated with maintaining the wiki (changing a page or reorganizing it or reverting a page to fix vandalism) do not cost an author much, they will be more likely to actually do the work.  Or there will be, at least, less disincentive to do the work.

Currently, these problems can be ameliorated only through manual work by team members, which takes time away from both contributing to and using the wiki, and from from the actual role the team fulfills in their organization.   If shared by all team members, this work requires its own cooperation and coordination mechanisms.   If team members are assigned specific maintenance roles, this causes knowledge acquisition bottlenecks.

Thus, the problem is to augmenting current wiki software with automatic awareness mechanisms which will alleviate the above problems while doing so without compromising the core wiki design principles (Cunningham 2008).

Background

Over the past five or so years, wikis have become increasingly used as informal (”conversational” (Wagner 2006)) knowledge repositories, especially for small to medium sized teams (Klein and Smith 2008, Majchrzak et. al. 2006).  These team wikis offer typical benefits of more formal knowledge management systems while the lowering barriers to entry and reducing knowledge acquisition bottlenecks common to those more formal systems.  The core wiki design principles (Cunningham 2008) are what enable this.

Team wikis are maintained collaboratively by all members of the team.  Domain experts write pages in the wiki in their areas of expertise in order to help the rest of the team or to record team knowledge and other content.   This helps team knowledge sharing, coordination and collaboration and single and double loop learning (Majchrzak et. al. 2006).

There are two problems with wikis however:

• Lack of awareness of activity. Getting teams to adopt wikis and use them to share their knowledge and help coordinate team activities is not easy.  One thing that helps encourage most or all team members to use and contribute to the team wiki is the knowledge that their fellows are also doing so (in that pages are being created and edited) and using it (in that people are accessing the pages and potentially using the knowledge — this is especially true for one’s own pages).   Furthermore, team members can duplicate effort because they don’t realize that other people are working on the same kinds of things they are.   So this is about the awareness of activity.  Awareness of use is valuable from both a team morale and giving perspective, and from a management perspective (if management can see that only one person maintains the wiki, they can take steps to encourage more use).
• Lack of awareness of existing content in the wiki. The domain experts are typically not information architects, and as such, wikis tend to grow organically and chaotically.  As wikis grow in size, content gets lost because its creation in the wiki is not communicated to or noticed by other team members.  This can, in turn, cause duplication of effort because an author creating a new page may not realize that a similar page already exists.  Finally, if a page has been lost in this way, it will fail to become linked to other, related knowledge, decreasing the overall usefulness of the wiki.

Addressing awareness of activity, most wiki software have features built into them which attempt to rectify this kind of awareness: a RecentChanges page, a page subscription mechanism (notifying the user when a page has been updated), and various automatic lists of extant pages, but these have proved ineffective in practice.

For awareness of existing content, some wiki proponents and some have proposed wiki maintenance roles and processes (WikiPatterns 2009) for team members so that the load of architecting the content in the wiki doesn’t fall to one person (creating a knowledge acquisition bottleneck).  People in these roles create organize and clean up content, creating page hierarchies and linking related content.   This also has proved hard to implement because (a) such activity takes time away from the direct business purpose of the team, (b) it takes time away from actually capturing and updating content in the wiki, (c) it requires a special skillset (information architecting) that team members for the most part are unlikely to have, (d) it requires coordination and collaboration.   These qualities make such activity highly susceptible to many of the failure modes of humans (Cockburn 2002) — people make mistakes, people are inconsistent, people prefer to fail conservatively, and people are creatures of habit.

References

1. A. Cockburn. Agile Software Development. Addison-Wesley, Boston, 2002.
2. W. Cunningham, “Design principles of wiki: how can so little do so much?,” in WikiSym ‘06: Proceedings of the 2006 international symposium on Wikis, Odense, Denmark, 2006, pp. 13-14.
3. Klein, R. and Smith, M. (2008). Pursuing the peak of excellence: Wiki as a knowledge base. In SIGUCCS ‘08: Proceedings of the 36th annual ACM SIGUCCS conference on User services conference, pages 167-172, New York, NY, USA. ACM.
4. Majchrzak, A., Wagner, C., and Yates, D. (2006). Corporate wiki users: results of a survey. In WikiSym’06: Proceedings of the international symposium on Symposium on Wikis, pages 99-104, New York, NY, USA. ACM Press.
5. Wagner, C. (2006). Breaking the knowledge acquisition bottleneck through conversational knowledge management. Information Resources Management Journal, 19(1):70-83.
6. http://www.wikipatterns.com/, Retrieved Feb 21, 2009.

• What is the nature of the goals that will be fulfilled via the system, and what tasks will be performed to achieve those goals?
• What kind of collaboration will be going on: mostly tightly coupled, mostly loosely coupled, or generally mixed-focus?
• What is the nature of the group that will use the system?  How big is the group, and what kind of people are in it?  Do the people in the group know each other outside the system?  Are they collocated and thus have face-to-face interaction in addition to that in the workspace, or do they interact solely through the system?
• What kind of awareness information is necessary to support the tasks and goals given the nature of the group?
• What kind of data is available to the system (through either active or passive gathering) that can be transformed into awareness information?  Dourish and Bellotti (Dourish and Bellotti 1992) say that awareness information should be passively gathered from the normal activities of the group, rather than actively solicited from users.   They claim that active, informational mechanisms are inherently problematic (e.g. subversion or CVS commit logs) because of both the burden on and the dependency on the posting user (Dourish and Bellotti 1992, p. 109).  First, the posting user gets no personal benefit from the update and actually has to do extra work in addition to the work of actually producing the work product.  Secondly, the posting user determines what information to convey and (in some cases) how to convey it.   The posting user has little incentive (beyond social pressure) to provide accurate, detailed, timely and comprehensible information, and at any rate provides only what they think is appropriate, which may not be what others need.   Thus such information is of limited trustworthiness and utility.
• How will the data be represented: situated within the workspace, or separate from it; in literal form or symbolic form?  Gutwin and Greenberg say that the situated-literal approach is “the closest approximation of how awareness information appears in the real world, and is the only one that allows people to use their existing skills with the mechanisms of feedthrough, consequential communication and gestural communication” (Gutwin and Greenberg 2002, p. 30).
• What metaphors can we use to best represent the specific kinds of awareness information we want to present? Gutwin and Greenberg give a sampling of what had been done prior to 2002 (Gutwin and Greenberg, pp. 31-33).
• When and where within the interface will each kind of awareness information be presented?  Dourish and Bellotti say (Dourish and Bellotti 1992) to present the awareness information within the shared workspace alongside the shared object, so that users can see the information and object concurrently, and find the information most relevant to the object, and also to make information available as and when needed as a context for individual activities.  Allow users to see other’s work and actions as they occur and where they occur.

References

1. P. Dourish and V. Bellotti, “Awareness and coordination in shared workspaces,” in CSCW ‘92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, 1992, pp. 107-114.
2. C. Gutwin and S. Greenberg, “A descriptive framework of workspace awareness for real-time groupware,” Computer Supported Cooperative Work (CSCW), vol. 11, pp. 411-446, 2002.