Here are my thoughts on how to use a wiki page to collaborate on creating a non wiki page let say a powerpoint presentation. I am looking for feedback on this so feel free to add comments.
So let's step through a use case:
Alex (user A) and Barbara (user B) decide to work together on creating a powerpoint presentation, the title of the presentation will be "fooing on bar"
Alex starts off by making a first draft of the presentation (using the Microsoft PowerPoint application) and he saves the file as foobar1.ppt on his hard disk.
He then creates a new page in the wiki and gives it the same title as the presentation ("Fooing on bar"). He writes a bunch of notes and comments about this first draft and then attaches the foobar1.ppt file to the page (which automatically inserts a link at the top of the page).
He then assigns this page to the AlexTodo and the BarbaraTodo categories so that each of them can quickly get an overview on what is still on their todo list.
Barbara gets notified of this new page (either by the daily email on recent changes from the wiki, RSS, by checking her BarbaraTodo category/blog, or by the fact that Alex emails her a link to the newly created page (so NOT the document).
Barbara reads through the comments that Alex posted on the wiki page and then clicks on the link to the file. The file opens up in OpenOffice (Barbara's favourite presentation tool). She makes a bunch of changes and additions and then saves the file as foobar2.ppt on her hard disk.
Barbara then edits the wiki page, and adds some comments at the top of the page on what she has changed and what else Alex needs to look at next. She then attaches foobar2.ppt to the page.
hgjhgjh
At this point Alex is notified (by email, recent changes, RSS ....) that the page was changed and he then reads the new notes, clicks on the top link (which points to foobar2.ppt so version 2), makes some changes, saves as foobar3.ppt, attaches the newest version to the page and adds some comments.
Etc, etc until no more changes are needed. The end result is a page that contains links to ALL versions of the document with the top link pointing to the latest version. Additionally all comments on the previous versions of the document are visible to all who can read the page.
Once the presentation is completed both Alex and Barbara remove the Todo category tag from the page. Here is a sample of the described page in action: fooing on bar
Problems with this approach: (some of which I noticed when I tried to create the sample page)
- Adding comments and attaching the latest version of the file are two steps. If the user gets interupted s/he might do the first and forget about the second step.
- If the editing step takes a while the user might forget to add the newest version and the comments to the page
- The user might make the edits to the document offline (while on a plane for example) so once the edits are completed there is no way to add the comments (while they are still fresh in your mind) nor the newest version to the wiki. The user will just have to remember to do it once s/he gets back online
- There is no way for Alex to know that Barbara is making a change to the document so he might go and himself make a newer version.
- The user might forget to use save-as as a result the file will not get a new name. So even if the file is properly attached to the wiki page the generated link on the page might not point to the latest version of the file (try: add two different files with the same name to a page and see which one you get when you click on it!). Even if the wiki would do a smart thing by always giving the newest file you still want to ability to link to the previous version.
- This requires discipline to always put the newest comments at the top and after the link to the file (or whatever format people agree upon).
Possible alternative to solve (some of) the problems:
instead of editing the wiki page the users can email their comments with the newest file attached into the wiki.
Emailing makes this a one step instead of 2 step procedure. Email also allows the user to make changes while disconnected from the wiki (assuming their email client allows for offline email creation). Email also requires less discipline about what goes where on the page, the wiki will take care of prepending the email and adding a link to the attachment.
Emailing doesn't solve the following problems: users can still forget to email the newest version after editing is done. There still is no way for Alex to know that Barbara is working on the document. The user still needs to use save-as so we get different filenames for different versions. There is also a new problem users have to remember the page name as correctly type it in the subject line. Since the subjec tline becomes the page name (remember?).
For an example of a page in action see fooing on bar by email
What if we get some help from the Socialtext creators?
Lets say that when using the {file: foobar{{}}} formating it not only creates a link to the actual attachment (which when clicked will open up the assigned application (in our example powerpoint or open office) but also a second link that when clicked opens up a Socialtext application (this is of course done by assigning a different MIME type to the link). This Socialtext application (which will have to be one time installed on the client's PC) will do the following:
- it will download the attachment to the users hard disk
- it will start the assigned application (Powerpoint/Open Office)
- Once the application is closed it will check to see if the file was modified
- if the file was modified it opens a window that prompts the user to add comments
- when the comments are entered and the window is closed by the user (click OK to update, click cancel to cancel) the comments are send as an email to the wiki with the modified file attached.
- To make sure the name of the new version of the file is unique the socialtext application renames the file to YYYMMDDHHMMSS-foobar.ppt
This way users can not forget to email the newest version. They will always be prompted to add comments at a time when they are still fresh in their minds. And we don't have to worry about forgetting to use save-as to change the filename.
Now all we are left with is how does Alex know Barbara is editing the presentation? To this i say isn't that what social interaction is all about? After all we are not trying to create a source code control system here. If you need that then use one ;-)
Thoughts on document-centric vs content-centric collaboration
A major challenge for many people is shifting paradigms from a document-centric approach, where the collaboration happens around edits to a document, to a content-centric approach, where collaboration happens around concepts, explanations of concepts and rationales, which eventually are presented as a document. In other words, the document is simply the delivery mechanism for the content, and not the object of the collaboration.
I am interested therefore, in improvements to the way in which Socialtext can turn wiki content into a document. Notice how in the collaboration above the content resides within the document, and the wiki page contains comments about the edits. At some point, this distinction between comments (opinion) and content (facts?) will blur, and the collaboration will become clunkier.
ST is already a better environment for content (change tracking, search, non-linear navigation, hyperlinking) such as text. Where it is not that good is with other kinds of media (like presentations).
So I've suggested some improvements in a comment to How does socialtext compare to Microsoft's sharepoint. On a practical level, maybe linking into Microsoft's web-runtime Office components (you have experienced them if you've opened an Excel document residing on a web server via IE and you have one of the latter Office versions installed)is an avenue worth exploring. Another promising direction would be to make a wiki page one of several "data types" on which you can collaborate, and make different kinds of office formats some of the newer supported types. That may be more viable now that Office has opened up their file formats. The key would be to provide the same type of services (change tracking, search, non-linear navigation, hyperlinking) that wiki pages have to these other data types.
Good stuff, Hans and Sam!
These are the kinds of use cases we're looking forward to addressing in the coming year.
Some people will find the document-centric modality more familiar and comfortable, and as they use it, they'll learn more about the wiki modality, and some will start using that, too.
contributed by Peter Kaminski on Jun 13 9:34pm
Just spitballing here, but in either the two-step (wiki-edit + attach) or the one-step (email) method, someone planning to do serious off-line editing could add a line
> "Checked out for editing 15 June 2005, 2:30pm CDT - expected return 15 June, 7:00pm CDT"
Off course, this is a convention thing, requiring discipline, but there are several such factors in callaborative work that tech cannot solve - at least without much higher expense. Sharepoint does force check-out/check-in discipline.
This application of social text is extremely important to me, and versioning is a problem. Short of incorporating a full controlled versioning system, allowing files (attachments) to have a history in the same way a page has a history would be extremely beneficial.
contributed by Steve Bishop on Jan 6 8:12pm
Peter Kaminski's comment sounds like turning content into documents is a "nice to have," but I think it's critical for my own company. Our products are regulated by FDA, and design history files (full of documents) are required. I mean, we don't have a product if we don't have that DHF. Turning documents into content is a critical feature for my company.
contributed by Mike Ashley on Mar 26 1:42pm
Why not use Zoho.com or Goggle-Presenter and design the presentation in a collaborative way directly instead of deviations with up- and downloads and wiki-comments.
posco
contributed by Johann Poschmaier on Oct 21 8:57am
contributed by seyllerdeb on Dec 9 3:37pm
Hi Deb,
This page, like many on the site, was not actually created by a Socialtext employee. So I wanted to clarify that the customer exchange is 'open' and not all of the content is Socialtext authored / approved. For any particular wiki page, you can look at the Revisions (upper right) to see who actually edited the page.
We try to keep the permissions open in order to encourage participation. Thanks for adding your comments as well!
contributed by John Bauer on Dec 11 1:59pm