January 28, 2016 at 16:19Well, this day has come: quick collaborative editing in ONLYOFFICE editors
This day still came. We rolled out an updated version of ONLYOFFICE Document Editors 3.6 document editors with fast collaborative editing, as in Google Docs. He was asked, demanded, threatened for a long time, but we were inexorable. Until they surrendered under the pressure of users who want to edit their secret materials, in real time watching what the co-author is gaining.
Next, we will explain why we were so opposed to “fast” co-editing, how our version differs from the similar mode in other online editors and how we are going to solve the undo / redo issue.
When we chose exactly how the joint work with documents in our editors will be implemented, we had no doubt that the “strict” regime was the best option. By working in this way, the user sees the collaborator’s edits only after the collaborator saves the changes.
It is in this editing mode that users can simultaneously edit a multi-page document without interfering with each other. That is, the edits of the user editing the document on the first page will not create any inconvenience for his co-author working on the 20th. In the case of “quick” editing, the first could interfere with the second, since its changes trigger the recount of the pages of the document. In addition, if users write something on different pages, they don’t need to know about the changes that occurred literally at the other end of the document.
Other arguments for a “strict” editing mode :
In general, this approach seemed more productive and universal to us, so the classic co-editing mode in ONLYOFFICE is precisely “strict”. You can learn more about it in our old, but not lost text .
We did not worry about the lack of a quick co-editing mode, but users wanted it. Like our PR department, practicing collaborative creativity in real-time. In general, we gave up and even found the
pros of the "fast" mode :
In the new version of editors, “fast” co-editing mode is set by default. You can return the classic “Strict” one by following a simple scheme: the “File” menu - the “Advanced Settings” tab - “Co-editing mode”. You can switch between modes at any time.
With “strict” editing, the “fragment” of the document fragment that the user is working on is “clamped”. For its co-authors, the object is locked until the user saves his changes. After saving, the object is unlocked until someone again begins to frantically edit it. With "strict" editing, the user saves his edits by hand. In addition, once every ten minutes, the document is automatically saved.
With "quick" editing, the mechanism of work, in fact, does not change. Except that autosave happens more often. 25 times per second, the timer asks for changes and, if they were made, does save. Immediately after saving, the object is unlocked. Thus, it creates the feeling that the edited fragment was not even blocked. In fact, lock existed only 1/25 of a second, and if Flash doesn't type in our editor, then, in general, no one will notice this little trick.
The clamping pattern turned out to be almost perfect for everything except typing and deleting text. In these cases, blocking a paragraph, even the shortest one, caused unpleasant natural phenomena: some letters were simply not typed. Therefore, we had to refuse to block paragraphs when entering and deleting text (in other cases, blocking is still present).
Next, we needed to provide simultaneous input / removal of text from one paragraph for several users. To do this, we needed an algorithm for transforming changes, or, as it is also called, operational transformation. In fact, this algorithm already existed in our editor. In the "strict" editing mode, he was responsible for merging the added / deleted paragraphs in the document. Although at the time of development, we did not even know that we were “inventing” an operational transformation.
The essence of the algorithm is as follows :
Suppose we have a paragraph with the text "Abr" and two users - Number One and Number Two, who want to simultaneously make changes to this text. For example, Number One introduces the letter “x” at the beginning of the word, and Number Two deletes the letter “b”. When merging, you should get a "habr".
For the algorithm, user actions can be written as ins (“x”, 0) (inserting the letter “x” at position zero) and del (1) (deleting at position 1). Let’s try to perform these conversions sequentially, taking into account whose changes are the first to come to the server:
It is clear that the difficulty lies not only in the changes themselves, but also in which of the users managed to send their edits first. The solution to this problem is that user changes that come to the server second need to be converted through changes that come first. In the first case, since deleting at position 1 does not change the insert at position 0, the second change does not change.
In the second case, insertion at position 0 affects the subsequent deletion at position 1, it is converted to deletion at position 2. As a result, after the conversion, we get the following diagram.
According to this principle, all text (and not just text) editors that have collaborative online editing work. However, our version is somewhat different from how everything is arranged in other online editors.
The difference is where the conversion of submitted changes occurs. For other online editors (for example, Google Docs), the server is responsible for the conversion processes. Changes come to him intact: in our case, it is ins ("x", 0) from Number One and del (1) from Number Two. Next, the server converts the received edits and sends them to users. Thus, Number One will get del (2), and Number Two will get ins ("x", 0).
In our scheme, everything will happen differently. Both users will send a request to the server to save their changes. One of them will receive the answer “it is possible”, and the second “it is impossible”. The one who received the “can” will immediately send its changes to the server, which, in turn, will forward them to the second user. The second user will apply these changes and (according to the scheme described above) will convert his own through them. Only after that he will send his converted changes to the server. Then the edits will come to the first user.
The main advantage of our scheme is that we do not load the server - it stores only the list of changes that were made to the document, and a save queue is organized.
We admit right away that we do not yet have undo in the “fast” co-editing mode. Unfortunately, no one has the kind of undo that users would like.
For example, undo editors of Google Docs partially works. Rather, it is intended that users will cancel minor oversights, typos. Attempts to roll back more serious changes can lead to unpredictable consequences.
Suppose one person added a table, and the other began to change it, say, move borders, enter text. Then the first one decided to do undo adding the table. In fact, the table will disappear with everything that the second user did in it. If, for example, he dragged a part of the text from a document into the table, then it will sink into oblivion along with the canceled table. In addition, for such an undo option, it is not possible to make the correct redo in terms of changes made to the document.
The undo / redo scheme in Google Docs does not return the document to its original form, as the user would like, on the contrary, it can make it the way this document has never been.
We are more impressed by the option invented by Microsoft: the user makes his own edits and can roll them back as much as he wants, but only until user number two connects to the editing and makes his own edits. Then undo will work for the second user. Until a third appears. This option seems to us correct from the point of view of editing, so now we are working on the implementation of this scheme in our editors.
However, we are also thinking of adding undo, which would work similar to Google. In our plans, it coexists peacefully with the Microsoft version: while you can do the correct undo / redo, we do it, then try to do undo like in Google Docs.
The ability to switch editing modes is our innovation. Users who are simultaneously working with a document can choose the most comfortable editing method for themselves.
For example, Number One has "strict" mode enabled, and Number Two has "fast" mode. The first blocks objects and saves its changes itself. The second one does not block anything, and it saves automatically. If the former edits an object or a fragment of text, the latter cannot do anything in them. At the same time, the first does not see what the second is doing - let there be a surprise. After saving, Number One will send its changes and accept the changes of Number Two.
If Number Three is connected with “fast” mode, then they and Number Two quietly work in the mode of quick joint editing. At the same time, they do not see and cannot correct the fact that the same introvert Number One blocked it. The latter, by the way, works both undo and redo.
This scheme of work seems logical and convenient to us - it allows users to choose a way to interact with co-authors, depending on the tasks and mood. Switching between modes is possible at any time during editing.
You can try quick collaborative editing in action here .
PS The review mode also appeared in the new version of ONLYOFFICE editors with tracking changes made during document verification. Proposed edits can be accepted or rejected.
PPS Work on editors never stops at all. We always think what would be added and improved. Therefore, there is still much to come.
Next, we will explain why we were so opposed to “fast” co-editing, how our version differs from the similar mode in other online editors and how we are going to solve the undo / redo issue.
Strict vs fast
When we chose exactly how the joint work with documents in our editors will be implemented, we had no doubt that the “strict” regime was the best option. By working in this way, the user sees the collaborator’s edits only after the collaborator saves the changes.
It is in this editing mode that users can simultaneously edit a multi-page document without interfering with each other. That is, the edits of the user editing the document on the first page will not create any inconvenience for his co-author working on the 20th. In the case of “quick” editing, the first could interfere with the second, since its changes trigger the recount of the pages of the document. In addition, if users write something on different pages, they don’t need to know about the changes that occurred literally at the other end of the document.
Other arguments for a “strict” editing mode :
- The absence of distractions in the form of comments by colleagues regarding the changes made and their own changes;
- No conflicts with undo / redo;
- And, of course, the opportunity to correct grammatical and punctuation errors before colleagues break out in a whirlwind of jokes about this.
In general, this approach seemed more productive and universal to us, so the classic co-editing mode in ONLYOFFICE is precisely “strict”. You can learn more about it in our old, but not lost text .
We did not worry about the lack of a quick co-editing mode, but users wanted it. Like our PR department, practicing collaborative creativity in real-time. In general, we gave up and even found the
pros of the "fast" mode :
- Convenience and speed when working with small documents (several pages);
- Entertainment;
- Convenience for the joint development of ideas, for example, brainstorming;
- The ability to quickly make and track the final changes when working together on the final version of the document.
In the new version of editors, “fast” co-editing mode is set by default. You can return the classic “Strict” one by following a simple scheme: the “File” menu - the “Advanced Settings” tab - “Co-editing mode”. You can switch between modes at any time.
How it works
With “strict” editing, the “fragment” of the document fragment that the user is working on is “clamped”. For its co-authors, the object is locked until the user saves his changes. After saving, the object is unlocked until someone again begins to frantically edit it. With "strict" editing, the user saves his edits by hand. In addition, once every ten minutes, the document is automatically saved.
With "quick" editing, the mechanism of work, in fact, does not change. Except that autosave happens more often. 25 times per second, the timer asks for changes and, if they were made, does save. Immediately after saving, the object is unlocked. Thus, it creates the feeling that the edited fragment was not even blocked. In fact, lock existed only 1/25 of a second, and if Flash doesn't type in our editor, then, in general, no one will notice this little trick.
Operational conversion
The clamping pattern turned out to be almost perfect for everything except typing and deleting text. In these cases, blocking a paragraph, even the shortest one, caused unpleasant natural phenomena: some letters were simply not typed. Therefore, we had to refuse to block paragraphs when entering and deleting text (in other cases, blocking is still present).
Next, we needed to provide simultaneous input / removal of text from one paragraph for several users. To do this, we needed an algorithm for transforming changes, or, as it is also called, operational transformation. In fact, this algorithm already existed in our editor. In the "strict" editing mode, he was responsible for merging the added / deleted paragraphs in the document. Although at the time of development, we did not even know that we were “inventing” an operational transformation.
The essence of the algorithm is as follows :
Suppose we have a paragraph with the text "Abr" and two users - Number One and Number Two, who want to simultaneously make changes to this text. For example, Number One introduces the letter “x” at the beginning of the word, and Number Two deletes the letter “b”. When merging, you should get a "habr".
For the algorithm, user actions can be written as ins (“x”, 0) (inserting the letter “x” at position zero) and del (1) (deleting at position 1). Let’s try to perform these conversions sequentially, taking into account whose changes are the first to come to the server:
It is clear that the difficulty lies not only in the changes themselves, but also in which of the users managed to send their edits first. The solution to this problem is that user changes that come to the server second need to be converted through changes that come first. In the first case, since deleting at position 1 does not change the insert at position 0, the second change does not change.
In the second case, insertion at position 0 affects the subsequent deletion at position 1, it is converted to deletion at position 2. As a result, after the conversion, we get the following diagram.
According to this principle, all text (and not just text) editors that have collaborative online editing work. However, our version is somewhat different from how everything is arranged in other online editors.
The main difference
The difference is where the conversion of submitted changes occurs. For other online editors (for example, Google Docs), the server is responsible for the conversion processes. Changes come to him intact: in our case, it is ins ("x", 0) from Number One and del (1) from Number Two. Next, the server converts the received edits and sends them to users. Thus, Number One will get del (2), and Number Two will get ins ("x", 0).
In our scheme, everything will happen differently. Both users will send a request to the server to save their changes. One of them will receive the answer “it is possible”, and the second “it is impossible”. The one who received the “can” will immediately send its changes to the server, which, in turn, will forward them to the second user. The second user will apply these changes and (according to the scheme described above) will convert his own through them. Only after that he will send his converted changes to the server. Then the edits will come to the first user.
The main advantage of our scheme is that we do not load the server - it stores only the list of changes that were made to the document, and a save queue is organized.
Cancel / Return
We admit right away that we do not yet have undo in the “fast” co-editing mode. Unfortunately, no one has the kind of undo that users would like.
For example, undo editors of Google Docs partially works. Rather, it is intended that users will cancel minor oversights, typos. Attempts to roll back more serious changes can lead to unpredictable consequences.
Suppose one person added a table, and the other began to change it, say, move borders, enter text. Then the first one decided to do undo adding the table. In fact, the table will disappear with everything that the second user did in it. If, for example, he dragged a part of the text from a document into the table, then it will sink into oblivion along with the canceled table. In addition, for such an undo option, it is not possible to make the correct redo in terms of changes made to the document.
The undo / redo scheme in Google Docs does not return the document to its original form, as the user would like, on the contrary, it can make it the way this document has never been.
We are more impressed by the option invented by Microsoft: the user makes his own edits and can roll them back as much as he wants, but only until user number two connects to the editing and makes his own edits. Then undo will work for the second user. Until a third appears. This option seems to us correct from the point of view of editing, so now we are working on the implementation of this scheme in our editors.
However, we are also thinking of adding undo, which would work similar to Google. In our plans, it coexists peacefully with the Microsoft version: while you can do the correct undo / redo, we do it, then try to do undo like in Google Docs.
In different modes
The ability to switch editing modes is our innovation. Users who are simultaneously working with a document can choose the most comfortable editing method for themselves.
For example, Number One has "strict" mode enabled, and Number Two has "fast" mode. The first blocks objects and saves its changes itself. The second one does not block anything, and it saves automatically. If the former edits an object or a fragment of text, the latter cannot do anything in them. At the same time, the first does not see what the second is doing - let there be a surprise. After saving, Number One will send its changes and accept the changes of Number Two.
If Number Three is connected with “fast” mode, then they and Number Two quietly work in the mode of quick joint editing. At the same time, they do not see and cannot correct the fact that the same introvert Number One blocked it. The latter, by the way, works both undo and redo.
This scheme of work seems logical and convenient to us - it allows users to choose a way to interact with co-authors, depending on the tasks and mood. Switching between modes is possible at any time during editing.
You can try quick collaborative editing in action here .
PS The review mode also appeared in the new version of ONLYOFFICE editors with tracking changes made during document verification. Proposed edits can be accepted or rejected.
PPS Work on editors never stops at all. We always think what would be added and improved. Therefore, there is still much to come.
