We've been getting several inquiries related to document management in Drupal, and occasionally about OpenAtrium, a Drupal distribution we've used as a base for several projects that needed strong group collaboration functionality.

Heerad asks:

How does OpenAtrium handle collaborative editing of documents?

Well, first of all, Drupal (and OpenAtrium) is not a document management system, it's a content management system. Documents can be attached to content, and can leverage Drupal's versioning, permissions, workflow, and search. But generally attachments are edited in other software. And while Drupal does a great job of detecting conflicts when you edit content, it does less to help manage conflicts in attachments.

So my first question becomes, would it make sense to move the content into Drupal, where we have far more ability to manage it, and assemble that content into documents at the end of the process?

Heerad's question goes slightly deeper, though -- he was really asking about managing conflicts, allowing simultaneous editing.

There's basically 4 different ways systems can handle this situation:

  1. Revisions. Save revisions without detection of conflicts. This is how wikis generally work. Person A and Person B both get copies of the document, and both make changes. Person A saves the document back to the system. Person B saves their copy back to the system. Person A's changes are wiped out. This is what Drupal does with documents/attached files. It can be set up to save every single revision, so at any point somebody discovers this, somebody could download each affected version, merge in the changes using the office tools to do that, and post the changes. Sucky workflow, but I do think people have been doing this for decades so it's not that unfamiliar.
  2. Active Locking. This is the classic "library" approach -- you check something out, and only you have access to it (though at least online, others can read it while you are working on it). With this approach, the system only lets you edit a document if you have explicitly checked it out, and nobody else can get a writable copy. The drawback here is that somebody might check something out but not actually be working on it -- and block anybody else wanting to make what might be a small change.
  3. Lazy Locking, conflict detection. Anybody can get a writable copy of the document, but the system will only let you save changes to a document if nobody else changed it before you saved it back to the system, and will warn you that others have made a change. This is what Drupal does with regular content, but not necessarily with documents.
  4. Live editing with multiple editors. This is what is becoming the gold standard -- everybody edits in the same environment, and everybody can see each change that everyone makes. Google Office does this very well, but we're seeing more and more options out there for this. It's still a very tough problem, and not something easy to roll in your own site.

When you're reading the marketing copy for various Software as a Service apps, you might be persuaded that they're all doing Live Editing, but I would ask careful questions about the capabilities, before assuming it actually works the way you want.

Here's a story about OwnCloud implementing collaborative editing - live editing: http://www.zdnet.com/owncloud-documents-to-bring-open-document-format-ed...

... I have actually tested that out, and found it's still too buggy to use in a production environment -- my experience was that it did not successfully store everyone's changes, some were missing when downloading the edited document. Even so, this provides code in the same language/technology stack as Drupal uses, so it provides us code we can port over to Drupal and then resolve the bugs as they are identified.

Another collaborative editing plugin is Etherpad. However, I don't think that generates an office format that can be easily downloaded -- that might be a good solution for editing content in a Drupal page, without necessarily editing a full document.

Recommended approach with OpenAtrium

We still really need to understand who the users are, and what specific goals they would have in collaborating on document editing. Where Drupal and OpenAtrium could be a great solution, and really be an effective collaborative editing platform, might be following the model we did for a global health education group we worked with, which basically broke down what will end up being a large structured document into individual sections, and assembling those into an outline. Each section ends up being its own Drupal "node" or page, which can be edited individually. The document as a whole can be shown in a single page at any time and easily cut/pasted into a word processor for further formatting/cleaning up for publication.

I'm calling this "Document Assembly" and I think it might be a very elegant approach to this. It's not often in practice that two people are editing the same section of a document at the same time, and so there is rarely any conflict. If you're doing the editing directly in the web site instead of "offline" in a word processor, you get the Lazy Locking version of conflict detection built into Drupal. We have tools now that support this assembly, and I'm very interested in developing some real user experience improvements in this area.

Here's a working table of contents of part of an active workplan for that client:

The key thing to making this successful is making sure people are communicating who is working on what.

One simple thing we might change if your needs in this area are to create large structured documents might be to add the "assigned to" field currently used on tasks to document sections. We could provide a simple tool for somebody to flag to anyone interested that they are taking on this item -- and then if somebody else wants to work on it, they can coordinate with the "assigned to" person. This might also help when generating a list of "my document items" and managing that workflow.

OpenAtrium is a great starting place to have a platform you own and control, to help coordinate the activity of groups of people working on separate projects. If you're interested in getting something like this set up for your organization, contact us! We'd love to help.

Share this article with your friends!

Comments (6)

soulfroys

Here, in my work, we made our intranet based on OA (2.000 users), and this module (https://drupal.org/project/content_lock) was the only really helped us create a viable collaborative environment. Unfortunately the module is unsupported due to a security issue the maintainer didn’t fix, but there is a patch on the way (https://drupal.org/node/2238703).

Could You consider the inclusion of this module in OA?

20 May, 2014

Hi,

Thanks for your comment! I haven't used that module. And I'm not a maintainer of OA, so I'm not in a position to get that in. And I don't think it's appropriate to include in OA by default -- but it looks like a great option to make available, and we could certainly deploy this for you, apply the patches, or create new patches as appropriate. It does look like a useful addition for this particular problem.

Let us know if you need assistance!

Cheers,
John

20 May, 2014

John, I have very limited knowledge about all this technical information you share so please bear with me. My in-house web team created a new site for my publication on the Drupal platform. I noticed within days of going live that the site download time is extremely slow and I can correlate the downward trend in page views directly to the launch as I feel readers are not waiting around for the download and click off the site. Is this a problem with Drupal that can be fixed? Thank you, Steve

03 Jun, 2014

Hi, Steve,

I just checked your site, http://www.aircargoworld.com/ , and indeed, it is very very slow to get any data. I don't think this is an issue with Drupal -- I think it's a problem with your hosting environment. It's taking over 10 seconds before any data comes through. I also see you're hosted on a Windows server.

We can certainly move you over to a "virtual private server" that responds much quicker. Most of our sites start out returning the front page in 3 seconds, and on busy sites we can get big boosts out of caching at various levels, get that to arout 0.8 seconds without much effort.

We'll follow up in email, and maybe we can set up a time to talk!

Cheers,
John

03 Jun, 2014

Add new comment

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.