Ask Freelock: Collaborative Editing in OpenAtrium and Drupal?

By John Locke on May 20, 2014

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.

Comments

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

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

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

Add new comment

The content of this field is kept private and will not be shown publicly.

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <blockquote cite> <cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h1> <h2 id> <h3 id> <h4 id> <h5 id> <p> <br> <img src alt height width>
  • Lines and paragraphs break automatically.

Drupal Canvas — Block HTML (locked)

  • Allowed HTML tags: <strong> <em> <u> <a href> <p> <br> <ul> <ol> <li>

Drupal Canvas — Inline HTML (locked)

  • Allowed HTML tags: <strong> <em> <u> <a href>

More Like This

Group module, friendly URLs, Pathauto, PURL, Drupal, Group Purl
🕑Sep 22, 2025 🖋John Locke 💬0

Use Group Purl on your Group site!

One big missing part of the Group module is setting up friendly URLs that contain the group in the path for group content. You can't set this up in Pathauto -- the tokens are too limited to handle this correctly.

Drupal, table sorting, data management, content reporting, HTML tables
🕑Jan 28, 2025 🖋John Locke 💬0

Ask Freelock: Sortable tables?

Kevin asks,

Is there a Drupal Add On or Widget that would allow users to sort tables as they're displayed on the website?

Hi, Kevin,

Several options here:

Cliff person smile Drupal  jousting
🕑Jan 17, 2025 🖋John Locke 💬0

Drupal CMS: Making the easy stuff easy

In the past couple days I've gotten two different questions regarding building functionality out in WordPress. This seems a bit...weird with timing, given that Drupal CMS just launched three days ago!

Three people wearing colorful masquerade masks, smiling under festive lights.
🕑Jan 14, 2025 🖋John Locke 💬0

🕵️‍♂️ Privacy for website owners, and introducing 💧 Drupal CMS

January 2025

Happy New Year!

This month we're doing a deep dive into privacy. Privacy for website owners, privacy for you, privacy for the world. To cap it all off, we have a special Privacy Tune-up offer to make sure your privacy policy is accurate and covering your assets...

And if that's not enough, it's a big week for Drupal -- see below for why!

Construction cranes against a blue sky
🕑Oct 29, 2019 🖋Nick Kelly 💬0

Don't Play Whack-a-mole on Prod!

If you’re making improvements to your sites, even as simple as pushing updates, you’re going to be changing things around. Inevitably, you’ll break something. Wouldn’t you like to find that out before the production site goes down from the “improvements”?