Will repository deposit interfaces support collaborative authoring?

Support for collaborative authoring would appear to be a natural consequence of work done in DepositMO, but is not something that has been addressed directly so far. In other words, we can talk about principles rather than practice, and we don’t have test data to back up any assertions we might wish to make on this point. So in this post we will consider expectations for collaborative authoring by looking at services that already support it.

The question was prompted recently when Stuart Lewis, SWORD Community Manager, invited us to contribute to a series of deposit use cases being coordinated by SWORD together with SONEX. We submitted a short use case on desktop to repository deposit, but Stuart posed another intriguing but harder to answer case on support for collaborative authoring.

One place to look might be Dropbox, since we have already profiled that service and compared it with DepositMO, noting again the distinction that this and other cloud services provide facility for storage and content management rather than, as repositories do, for publication and access. As we found then, this distinction has consequences for the ability to support certain services, and that might also apply to collaborative authoring.

Coincidentally, ReadWriteWeb just highlighted Chatbox, an application that supports collaboration in Dropbox. Chatbox adds the ability to leave comments on, or chat in real-time about, particular files and folders, and everything is stored in Dropbox.

That RWW article also refers to other document collaboration services, Box and Huddle, as well as, in this respect, the venerable Google Docs, the exemplar that Stuart mentioned in his original enquiry. Another service often cited in this and many other contexts is Microsoft Sharepoint, but this supports sharing within an organisation and is harder to set up for use outside an organisation’s computing firewalls than many cloud services.

Looking at these services there appear to be two primary requirements for collaboration: recording and presenting conversations about the object of the collaboration, and tying that conversation to the object. According to RWW again, Google has identified the common document collaboration problem: how to manage comments and conversations around a document.

Chatbox aside, it seems that efforts to tie comments to the document can lose the chronology and immediacy of the conversation, while solutions to that problem often end up detaching the conversation from the document. Google’s approach is to make its new comments system work “like a conversation thread on a Facebook, complete with @replies. When someone is tagged in a conversation, they will receive an e-mail notification. The user can then either click-through to the document, or simply respond to the e-mail. All the conversation is captured and stored in Google Docs with the document.”

RWW notes that Box does something similar with its discussion tools. On its site Box describes its collaboration feature like this: Create an online workspace where you can share project files, manage files with version history, add comments, assign tasks, or create new content.

Huddle‘s promotion of its collaboration feature emphasises more conventional concerns of security and access control: “Using Huddle, relevant people, inside and outside of your organization, can access all content relating to a project or campaign in a secure online environment. Apply granular permissions and control who can and cannot view specific information.”

I have used Google Docs to coauthor documents in realtime, but without the comment features now mooted. Otherwise my approach to collaborating on documents where I am lead author has been typically to circulate the document, usually by email, to wait for comments and update the document accordingly. It seems this approach is somewhat behind the curve in terms of modern document coauthoring, and behind the expectations of users of leading cloud services. If these requirements are reflected by repository users, then repositories have some catching up to do. DepositMO is further away from this form of support for collaborative authoring than I had thought when first responding to Stuart’s prompt.

Salvation may lie with SWORD v2 again, as it has with our efforts to increase the functionality of repository deposit. Colleagues have been putting the case to apply the Google Docs model in the next version of SWORD, and their arguments have been heard, at least as far as testing is concerned. Such an approach suggests the possibility at least of mimicking the approach of Google Docs to collaborative authoring.

SWORD is simply a technical specification for a Web service, however. As always, user-facing services and interfaces, whether for deposit or collaborative authoring, need to follow if we are to exploit changes to the specification.