Most recent edit on 2005-03-16 21:28:21 by LynnCherny
Additions:
Comments by LynnCherny
I also found this fascinating, and tantalizing! As a corporate user of wikis over the years, I've almost despaired of them on so many fronts -- the very nature of wikis means that they evolve in sometimes unfortunate, almost cancerous shapes; it's often the case in a "healthy" wiki world with many contributers that no one can find anything, no one can easily track changes over time, and the pages thus become tough to use as reliable internal reference documents for anything. At least that's been my experience in software development where we've often used them for brainstorming or documenting of design ideas. (I end up re-affirming my belief in the role of information architects every time I visit a wiki nowdays.)
Your addition of the task fields could help to focus the purpose and goal of many a wandering wiki page! But it could also be very peculiar applied inside the kind of brainstorming wikis I've seen during design phases. I wouldn't necessarily expect a sensible to-do item to exist in a fluid content which anyone can modify -- as the to-do context changes, so does the task, potentially. Now, in a more controlled editing environment, where the context is not fluid and the tasks are easily defined and unlikely to mutate, your feature would be extremely useful. Your example fit the bill nicely for this type of context.
So -- the genre of wiki page probably determines how useful the feature is. Proscribed roles and responsibilities and processes, inside a content that's not expected to be re-architected daily or move out from under the reader, make for a good context for your feature. But the opportunity for frustration for both assigners and assignees of tasks inside a constantly mutating information context seems quite high to me. External social control over the misuse of such a feature might be sufficient inside a corporate environment, though.
LynnCherny
Edited on 2005-03-15 20:36:12 by DerekHansen
Additions:
Abstract
Wikis provide a powerful method of creating and managing hypertext documents. In this paper we address the question of whether the wiki collaborative construction paradigm can be applied to workflows and business processes. We introduce a new prototype web application, Kontiki, in which traditional wiki structure is augmented with a few simple, new primitives: fields, assignments, and dependencies. We also discuss other recent efforts to use wiki-style interaction for the creation of complex, structured content.
Comments by DerekHansen
Summary
As wiki’s have become more widely used, organizations have begun to recognize some of the potential benefits of allowing relatively seamless integration of reading and editing of web documents. The original idea behind a wiki (often referred to as the ‘wiki way’) was to keep it extremely simple. However, as wiki’s have begun to be used in more contexts it has become apparent that additional features are needed to supplement the original feature-set. The shear number of open source communities and companies (e.g., Jotspot, Social Text) that create feature-packed wiki engines is evidence that there is both room for improvement and something worth exploring.
This article by Wattenberg and Feinberg discusses a prototype wiki system called Kontiki designed to facilitate workflows and business processes. Specifically, it allows users to:
- easily create fields (with values including free text, true/false, or registered users)
- assign these fields to registered users (or other fields holding a user’s name) so that they become tasks
- make fields dependent upon other fields
Furthermore, it is designed to show a list of the user’s outstanding tasks in a separate frame from the content.
Specific Comments
I was very interested in the simple, yet provocative idea of creating fields that can be assigned to individuals and then assuring that those individuals can easily track the fields assigned to them. The paper focuses on how this can be used to help with business processes, but additional usage scenarios likely exist. As I see it, the primary situations where Kontiki would be useful are ones that:
- include many people’s involvement (e.g., collaboration)
- are improved when multiple people edit both the content and structure
- are fairly well defined
The primary usage scenario discussed in the paper is an organization hiring process, which seems to be a nice fit. To a lesser extent, the paper also discusses the possibility of collaborative document editing. The one concern I have with collaborative document editing is that typical wiki’s do not have well developed concurrency control systems, so if more than one person is editing a page at a given time problems arise. Additional usage scenarios that you may want to consider are training procedures, career development plans, or even travel procedures.
The idea of making fields dependent upon other fields is a bit troublesome in a situation where anyone can edit the document (and therefore may not know what dependencies exist). I would worry about individuals creating circular dependencies and breaking links to dependencies without knowing it. To limit these types of problems you could help make these dependencies visible in some way, include error messages that explain when potential problems may arise, or only allow a few trusted individuals to create and break these dependencies.
On a more macro level, when you start looking at usage data it will become more apparent how many people edit these documents and in what ways. My hunch is that in many situations there will only be one or two individuals that will edit the wiki, in which case a wiki (where everyone can edit the document) may not be necessary.
One final idea. I really like the idea of the group of users actually creating a To Do list for any one individual based upon their editing of the document. In a way, it is like allowing my colleagues to add items to my sticky pad To Do list on my desk. What’s more, other people can easily see what I have done or still have to do on my list. I have two suggestions that you may want to think about in regard to this. First, time is often of major importance when looking at To Do lists. You may want to think about how time can be integrated into the system (e.g., allow deadlines to be assigned to fields). Second, there may be some benefits of having an entire workgroup use a Wiki to keep a public and editable To Do list for all of their work-related activities. This would require a different set of features and is certainly a different (but complementary) research project, but I think it could be very fruitful and it would open up many additional possibilities.
Related links:
http://www.socialtext.com/∞
http://www.jot.com/∞
http://www.twiki.org/∞
DerekHansen
[Please insert additional comments in this section followed by your WikiName]
Deletions:
[Please insert comments in this section followed by your WikiName]
Edited on 2005-01-31 16:10:47 by DerekHansen
Additions:
[Please insert comments in this section followed by your WikiName]
Deletions:
Oldest known version of this page was edited on 2005-01-31 16:01:49 by DerekHansen []
Page view:
Martin Wattenberg, Jonathan Feinberg, (2005)
Kontiki: A Wiki for People and Processes