We are building a collaboration tool to bring all the amazing features of Git and GitHub to the world of Microsoft Word. It’s designed for anyone who works on a long lived document with other people: lawyers, journalists, academics, authors, etc..
I come from a software development background and, due to the nature of writing code, we have had to come up with some great tools to collaborate. The main driver behind this is being able to make changes to a document (or in our case a piece of code) without impacting anyone else. Once we are satisfied with our change, we must then merge our work with that of other developers who may have changed the same file simultaneously, to eventually create one cohesive document.
Git and GitHub have enjoyed huge success in our industry, but their platforms are limited to plain text (with no support for the rich formatting offered by Microsoft Word), making them unsuitable for many other industries.
At Simul, we want to bring these incredibly useful features to the humble Word document.
Git has the concept of a “master” branch. This is the source of truth for the document.
Whenever an author makes a change to a document, they do so in their own branch. This prevents their changes from impacting anyone else. Once complete, they will attempt to push their changes to the master version, at which point they will need to perform a merge and carefully resolve any conflicts.
This process continues over and over as authors collaborate. Along the way, tags or checkpoints in the code are marked. These are used to signify a version of the code which has been tested and can be deployed.
There is a lot of overlap here with the authoring process of a Word document. You don’t necessarily want the real-time coauthoring experience offered by Microsoft SharePoint or Google Docs., this can inhibit your ability to determine who is responsible for specific changes to content. Branching offers a much clearer audit trail of changes. Like with code, tags can be added to signify a minor or major version of a document is ready to be published.
GitHub is an interface which sits on top of Git offering additional social features such as comments and raising issues greatly improving collaboration. Simul aims to deliver benefits from both products.
The main limitation with Git is that it only works with plain text (think Windows Notepad). I have seen authors resort to plain text or markdown in order to take advantage of Git, but this means losing all of your rich formatting such as images and fonts. This is usually too much of a sacrifice for companies as formatting needs to be reapplied with each publication, which is very time-consuming and prone to errors.
A second obstacle is that Git is a tool designed by and for very technical users. Most operations are performed via the command line which makes it unsuitable for a general user.
Once a document is created in Simul (this could be a new Word document or an uploaded file) all changes are tracked.
In this example I have uploaded a very original document named “Example Document” which contains the words “The quick brown fox jumps over the lazy dog”. By clicking the “Open in Word” button, Microsoft Word launches and I have replaced the word “dog” with “cat”. Simul will show the following once I save the changes:
There are a few things here which are noteworthy:
This happens regardless of whether “Track Changes” are turned on in the document. Not only does this show the document changing but it guarantees that no other changes were performed on the sly.
Fairly straight forward; but if our friend “James” also made a change at the same time as us (or simply decided to edit a previous version), we would see a new branch created:
The revision tree now shows James has made changes to 0.0.1 which do not include the changes we made to 0.0.2.
If we look at James’ changes, we can see he has change the word “fox” to “wolf”. Note that the sentence still refers to the lazy dog and not cat.
We can also comment on James’ change; ensuring all communications which affect the document are recorded and accessible.
However, we are now in a situation where we have two competing versions of the same document. We can alleviate this by merging our work using the teal panel above.
By merging, a new version is created (0.0.4) which includes both Ben’s and James’ modifications. Each author’s changes will be included as a regular tracked change within Microsoft Word:
The changes can now be accepted or rejected as per normal and we have a single “latest version” for authors to contribute to.
Simul offers a lot more features than demonstrated above. I won’t go into them in detail but if you want to learn more you can read our guide What is Simul?.
Absolutely we need it. A good example of its effectiveness is a group of lawyers from different firms attempting to draft an agreement. This is often a very inefficient collaborative process involving multiple copies being sent via email and the changes having to be manually combined.
Not only does this consume more time but is prone to human error - it is difficult to establish what is the latest version, and once changes are accepted all history is lost. Not to mention authors intentionally trying to insert clauses without being noticed or deceiving a party into agreeing upon the wrong version of a contract.
There are plenty of examples of people struggling with this problem, you can read about them using the links below. But all their solutions require the user to abandon Microsoft Word and work with plain text. At Simul, we are determined to develop a platform which supports you and your preferred authoring tool:
Simul is a free service for a long as you need, we also have paid plans available which include more sophisticated features and greater control over your documents.