Bringing collaborative editing to any application

Three years ago, we decided to face the challenge of making real-time, multi-user collaborative writing available for every software out there. That idea kicked off the development of CKEditor 5 and many other solutions now known as the CKEditor Ecosystem.

In this article I give a quick overview of the problem we aim to solve, the solutions we developed for that purpose and how to approach collaborative editing in your application.

# Background

Writing, especially in a professional environment, is an activity that usually passes through the following distinct phases, among others:

• Phase 1: Well… writing. This is the phase where the author is (or the authors are!) focused on thinking, researching and finally, typing. It’s an act of artistic expression with the intent to communicate. Yes, crafting a well written piece of content is an art, even if we are talking about a financial summary.
• Phase 2: Review and feedback. Here we want to work with our peers on refining the content, legal review, proofreading and consulting with others for opinion and feedback. It may take us back to phase 1.
• Phase 3: Media insertion. If not already made by the author, other professionals can get involved in the creation, selection and inclusion of media material, like images and videos.
• Phase 4: Publishing. The content may pass through a series of final approvals and may be finally released to its audience.

Although the above may miss many other activities and phases around content creation, my point is to underline that creating content is a collaborative task.

# The status of things

The workflow described above led to the creation of software that could help in performing such tasks better. At the same time, the web became the main channel for publishing content and team collaboration. As a result, web apps started introducing collaboration and workflow features.

Still, people needed solutions which were more agile and effective. In the early ages, MS Word popularized features for commenting and reviewing. Following that, Google Docs brought it to the web, alongside an effective way for users to interact in real-time.

These solutions remained a standard for more than a decade. We’ve recently been seeing other big names joining the web scenario with similar proposals, like Microsoft Office 365 and Dropbox Paper.

But note that we’re seeing only big names joining the party. One of the main reasons for that may be because creating technology and infrastructure for such software is extremely complex and expensive (we can confirm this). Companies didn’t thus have a better option than adapting to what’s available out there.

The above added more inconvenient phases to the content creation workflow, bringing overhead just because of “technicalities”:

• Authors and reviewers collaborate in a third-party application.
• Once finalized, the content must be moved (copy & paste) to the publishing platform (e.g. CMS).
• Content must be fixed and readapted to the target platform, because of incompatibilities of features or unexpected results of the paste operation.
• Media must be recreated because of differences in the platforms and to better perform in the multi-devices world we live in.
• The original author and collaborators must review the content again.
• If further changes are needed, they must be done in both platforms now, creating confusion.
• Final approvals must be performed again.

There are additional implications that affect other professionals and even the publishing applications:

• Users must be trained in using many different platforms.
• All platforms need to be maintained.
• Content and history stay outside the application.
• Users need to leave the application, which is undesired both for the user and the application provider.
• Money is wasted on several solutions instead of being invested in a single complete one.
• Precious time is wasted and timing is affected.
• Risk of miscommunication is higher.

In few words, the current situation is sub-optimal. Still, not having a better alternative gave people the feeling that the situation is “under control” (air quoting).

# Our goal

Our goal sounds simple: mitigate all the above pains by making it possible for any application to provide and manage the full collaborative editing experience, without sending their customers to third parties.

Yes, we don’t want to bring yet another Google Docs clone — a website where one can share documents. We want to provide tools for the developers to easily bring that collaboration experience right inside their applications (or even create their own Google Docs clones, if they feel like it).

# The solution

When our team sat to define the future of CKEditor back in 2014, we understood that we would have to face a much bigger challenge than just working on CKEditor 5. Collaboration is much more than only the text editor itself — it requires more features than simply writing and it needs a complex server-side solution to connect users.

Our decision was to design and develop three products, each one fulfilling one of the different requirements:

• CKEditor 5: A brand new editor, with the necessary architecture for collaborative editing.
• Letters: A drop-in component to easily include a complete collaborative editing solution inside any application.
• CKEditor Cloud Services: Among other services, it offers the server-side infrastructure for collaboration in the format of a virtually zero configuration cloud solution.

# CKEditor Cloud Services

To better understand how to bring collaboration into an application, let’s start talking about a critical piece of infrastructure that is transparent (as it should be) to the eyes of end users: the server-side of it.

A real-time collaborative writing solution in some senses acts like a messaging system. We have several users working on documents and their changes must be transported from one user to the other. There must be a central place that keeps track of such users, groups them over documents and transports messages between them. All this must also be fast, secure and highly available.

To eliminate the burden of developing, deploying and maintaining such a critical solution, we have created the CKEditor Cloud Services, which, among other things, provide collaboration services targeted to CKEditor 5. It’s a Software as a Service solution, which means that it’s enough to subscribe to it and a powerful and efficient infrastructure will be immediately available to the application.

# CKEditor 5

I’ve already extensively discussed what CKEditor 5 is about, therefore I’ll comment on the pieces that touch collaboration only. The things to keep in mind are:

• CKEditor 5 runs on top of a custom data model — a pure JavaScript implementation.
• Changes to the data model are done by operations, exclusively.
• Such operations can be transported to other clients and correctly merged with operations produced by other users through Operational Transformation (OT).

The final architecture is certainly much more complex and extensive than the list above, but this is the base for what is needed to enable real-time collaborative writing.

Once all of the above was available, we were able to connect it with the CKEditor Cloud Services and end up with a solution that’s very simple to integrate. In other words, anyone using the CKEditor 5 Framework to create their own editors would be able to easily connect users over the same piece of content by just adding a plugin to their editor.

Please note that creating a comprehensive collaboration solution is much more complex. Other than the editor itself, the application must take care of tracking and displaying the list of users, bring the UI that displays the users moving over the content, design other related features (e.g. commenting), and much more.

# Letters

Since building a real-time collaborative editing solution is so complex, we invested in creating an out-of-the-box component that brings all the pieces and features together. A drop-in solution, built on top of CKEditor 5, that allows any application to provide this very advanced feature with minimal integration effort. We named it Letters.

Our goal is to enable the writing experience of established publishing platforms like Medium with the collaborative features of applications like Google Docs, ultimately making it possible to have it inside applications.

Letters brings the following to developers and end users:

• A unified UI that:
  • Contains the edited text, split between Title and Body.
  • Provides a clean user experience where users can focus on writing.
  • Supports easy drag-and-drop of images, powered by the CKEditor Cloud Services.
  • Displays the position and selection of other users.
  • Automatically merges changes made by other users.
  • Allows users to add comments to images or selected parts of the text.
  • Enables discussion threads with other users using comments.
  • Tracks all connected users, displaying their names and avatars.
• A simple to integrate API:
  • Secure, based on modern best practices.
  • Documents are stored in the application itself, not in the cloud.
  • The user base is taken from the application as well. No registration required.
  • Designed for OEM licensing.
• A solution that will evolve in time on quality and features.

Letters makes introducing collaborative editing to an application as easy as this:

1. Decide where to integrate Letters in the application.
2. Create a secure account in the CKEditor Cloud Services.
3. Include Letters in the application and integrate it with the CKEditor Cloud Services.

Couldn’t be easier. In fact, if it could be easier, I’m sure we would make it that way.

# The critical part: your application

We have all the pieces of software needed to bring real-time text editing collaboration into your application. Now what? That’s a very important question, which can be mistakenly answered way too fast.

One of the ways to approach this is by deciding the “obvious”: let’s replace the text editor that we have in our application with Letters (or a custom CKEditor 5) and we’re done, right? Not really.

Most of the UI, UX and workflows inside applications have been created within the scope of single user interactions. For example, a user opens a form, makes changes to content and hits the “save” button. There’s no knowledge of other users opening the same document at the same time. This leads to either conflict when saving changes or to sub-optimal solutions like “locking” the content from editing. This workflow must change when real-time multi-user interaction is expected.

Take applications like Google Docs or Dropbox Paper as examples. They don’t have “save” buttons. Changes are immediately saved as they happen. This makes sense, because otherwise users would be saving the document while others are still working on it. This would lead to unfinished changes or even temporary content being taken as the final one.

Therefore, bringing real-time collaborative writing into you application means designing it as a whole to make it fit that purpose. It should introduce different ways of editing and dedicated workflows for publishing. Creative and smart decisions must be taken and software must be designed and developed. Then, at some point, Letters or CKEditor 5 will come into play, but only as a part of a bigger plan.

# What’s next?

To start, I would strongly recommend playing with the Letters demo on the CKEditor Ecosystem website.

We are working to stabilize and bring more features to both Letters and CKEditor 5. At this stage it is extremely important for us to have quality feedback. We would also love to hear about your use cases and help design your software in the best possible way, so be sure to contact us.

You can read more on the topic of collaboration in our blog posts:

• CKEditor helps: Collaborative policy in government
• The keys for an optimal digital employee experience
• CKEditor 5 Collaboration Features v17.0.0 with new comments API
• 5 best collaborative writing strategies for 2022
• Collaboration journey of CKEditor 5 - What were we up to
• Data compression in real-time collaboration
• 7 reasons why your LMS needs a better and collaborative WYSIWYG editor
• Lessons learned from creating a rich-text editor with real-time collaboration