Well, this day has come: quick joint editing in ONLYOFFICE editors
This day still came. We rolled out an updated version of the ONLYOFFICE Document Editors 3.6 document editors with fast co-editing, like in Google Docs. He has long been asked, demanded, threatened, but we were inexorable. Until then, until you surrendered under the pressure of users who want to edit their secret materials, in real time watching what a collaborator is typing.
Next, we will explain why we were so opposed to “fast” joint editing, how our version differs from the similar mode in other online editors, and how we are going to solve the issue of undo / redo.
When we chose how collaboration with documents in our editors will be implemented, we had no doubt that a “strict” mode is the best option. Working in this way, the user sees the edits of the collaborator only after he has saved the changes.
')
It is with this editing mode that users can simultaneously edit a multi-page document without interfering with each other. That is, editing 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 “fast” editing, the first one could interfere with the second, since its changes trigger the recalculation of the document pages. In addition, if users write something on different pages, they do not need to know about the changes that have occurred literally at the other end of the document.
Other arguments in favor of "strict" editing mode :
In general, this approach seemed to us more productive and universal, therefore the classic co-editing mode in ONLYOFFICE is precisely “strict”. More information about him can be found in our old, but not lost the text .
We did not complex about the lack of a quick co-editing mode, but users wanted it. Like our PR department, practicing co-creation in real-time mode. In general, we gave up and even found
Pros of the "fast" mode :
In the new version of editors, the “fast” mode of joint editing is set by default. You can return the classic “Strict” 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, there is a "clamping" of a fragment of the document that the user is working on. For his collaborators, the object is locked until the user saves his changes. After saving, the object is unlocked, until someone again starts frantically editing it. With "strict" editing, the user saves his edits with his hands. In addition, the document is automatically saved every ten minutes.
With the "fast" editing mechanism of work, in fact, does not change. Except that autosave happens more often. 25 times a second, the timer asks for changes and, if they were made, makes a save. Immediately after saving the object is unlocked. Thus, it seems that the edited fragment was not even blocked. In fact, lock existed for only 1/25 of a second and, if Flash does not type the text in our editor, then in general no one will notice this little trick.
The clamping scheme was almost perfect for everything except typing and deleting text. In these cases, blocking a paragraph, even the shortest, caused unpleasant natural phenomena: some letters were simply not typed. Therefore, we had to abandon the blocking of paragraphs when entering and deleting text (in other cases, the blocking is still present).
Next, we needed to provide simultaneous input / deletion of text from one paragraph for several users. For this we needed an algorithm for transforming changes, or, as it is also called, an 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 "avbr" and two users - Number One and Number Two, who want to simultaneously make changes to this text. For example, Number One inserts the letter “x” at the beginning of the word, and Number Two deletes the letter “c”. When you merge should get "Habr."
For the algorithm, user actions can be written as ins (“x”, 0) (insert the letter “x” in the zero position) and del (1) (delete in position 1). Let's try to consistently perform these transformations, taking into account whose changes will come first to the server:
It can be seen that the complexity lies not only in the changes themselves, but also in who of the users managed to send their edits first. The solution to this problem is that the user changes that come second to the server need to be transformed through the changes that came first. In the first case, since deleting at position 1 does not change the insertion 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 into deletion at position 2. Finally, after conversion, we get the following scheme.
According to this principle, all text (and not just text) editors that have co-editing online work. However, our version is somewhat different from how everything is arranged in other online editors.
The difference is where the conversion of the submitted changes takes place. For other online editors (for example, Google Docs), the server is responsible for the conversion processes. The changes come to him in an untouched form: in our case, these are ins (“x”, 0) from Number One and del (1) from Number Two. Next, the server converts the edits received and sends them to users. Thus, Number One will receive del (2), and Number Two - ins ("x", 0).
In our scheme, everything will happen differently. Both users will send to the server a request to save their changes. One of them will receive the answer “can”, and the second “cannot”. The one to whom it is “possible” will immediately send their changes to the server, which, in turn, will send them to the second user. The second user applies these changes and (according to the scheme described above) converts his own changes through them. Only then will he send his converted changes to the server. Then edits will come to the first user.
The main advantage of our scheme is that we do not load the server - it only stores a list of changes that were made to the document, and a save queue is organized.
We immediately recognize that we do not yet have undo in the mode of “fast” joint editing. Unfortunately, no one has such an undo that users would like.
For example, undo editors Google Docs works partially. Rather, it is designed for the fact that users will cancel minor missteps, typos. Attempts to roll back more serious changes can lead to unpredictable consequences.
Suppose one person added a table, and another began to change it, say, move the boundaries, enter text. Then the first one decided to make an undo table addition. In fact, the table will disappear with everything that the second user did in it. If he, for example, dragged into the table a part of the text from the document, then it will sink into oblivion along with the canceled table. In addition, for this option undo it is impossible 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 with the option invented by Microsoft: the user makes his edits and can roll them back as long as necessary, but only until user number two joins editing and makes his own edits. Then undo will work for the second user. Until the third appears. This option seems to us to be 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 about adding undo, which would work just like Google’s. In our plans, it coexists peacefully with the Microsoft option: as long as you can do the correct undo / redo, we do it, then we try to do the undo as in Google Docs.
The ability to switch edit modes is our innovation. Users who work with the document at the same time can choose the most convenient way to edit.
For example, Number One has “strict” mode enabled, and Number Two has “fast” mode. The first blocks objects and saves its changes by itself. The second does not block anything, and saving it happens automatically. If the first is editing an object or a piece of text, the second can do nothing in them. At the same time, the first one does not see what the second one does - let it be a surprise. After saving, Number One will send its changes and accept the changes to Number Two.
If Number Three is connected with the “fast” mode, then they with Number Two are quietly working in the mode of fast co-editing. At the same time, they do not see and cannot rule what the introvert Number One blocked. The latter, by the way, employs both undo and redo.
This scheme of work seems logical and convenient to us - it allows users to choose the way of interaction with collaborators depending on the tasks and mood. Switching between modes is possible at any time editing.
Try quick collaborative editing in action here .
PS In the new version of the ONLYOFFICE editors, a review mode has also appeared with tracking of changes made during document verification. The proposed edits can be accepted or rejected.
PPS Editors never stop working at all. We always think that this would add and improve. Therefore, there is still a lot of things ahead.
Next, we will explain why we were so opposed to “fast” joint editing, how our version differs from the similar mode in other online editors, and how we are going to solve the issue of undo / redo.
Strict vs fast
When we chose how collaboration with documents in our editors will be implemented, we had no doubt that a “strict” mode is the best option. Working in this way, the user sees the edits of the collaborator only after he has saved the changes.
')
It is with this editing mode that users can simultaneously edit a multi-page document without interfering with each other. That is, editing 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 “fast” editing, the first one could interfere with the second, since its changes trigger the recalculation of the document pages. In addition, if users write something on different pages, they do not need to know about the changes that have occurred literally at the other end of the document.
Other arguments in favor of "strict" editing mode :
- The absence of distracting factors in the form of comments from colleagues regarding the changes made and their own edits;
- No conflicts with undo / redo;
- And, of course, the opportunity to correct grammatical and punctuation errors, before colleagues break out into a whirlwind of jokes about it.
In general, this approach seemed to us more productive and universal, therefore the classic co-editing mode in ONLYOFFICE is precisely “strict”. More information about him can be found in our old, but not lost the text .
We did not complex about the lack of a quick co-editing mode, but users wanted it. Like our PR department, practicing co-creation in real-time mode. In general, we gave up and even found
Pros of the "fast" mode :
- Convenience and speed when working with small documents (several pages);
- Entertainment;
- Convenience for joint development of ideas, such as brainstorming;
- The ability to quickly make and track the final edits when working together on the final version of the document.
In the new version of editors, the “fast” mode of joint editing is set by default. You can return the classic “Strict” by following a simple scheme: the “File” menu - the “Advanced Settings” tab - “Co-editing mode”. You can switch between modes at any time.
How things are arranged
With "strict" editing, there is a "clamping" of a fragment of the document that the user is working on. For his collaborators, the object is locked until the user saves his changes. After saving, the object is unlocked, until someone again starts frantically editing it. With "strict" editing, the user saves his edits with his hands. In addition, the document is automatically saved every ten minutes.
With the "fast" editing mechanism of work, in fact, does not change. Except that autosave happens more often. 25 times a second, the timer asks for changes and, if they were made, makes a save. Immediately after saving the object is unlocked. Thus, it seems that the edited fragment was not even blocked. In fact, lock existed for only 1/25 of a second and, if Flash does not type the text in our editor, then in general no one will notice this little trick.
Operational transformation
The clamping scheme was almost perfect for everything except typing and deleting text. In these cases, blocking a paragraph, even the shortest, caused unpleasant natural phenomena: some letters were simply not typed. Therefore, we had to abandon the blocking of paragraphs when entering and deleting text (in other cases, the blocking is still present).
Next, we needed to provide simultaneous input / deletion of text from one paragraph for several users. For this we needed an algorithm for transforming changes, or, as it is also called, an 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 "avbr" and two users - Number One and Number Two, who want to simultaneously make changes to this text. For example, Number One inserts the letter “x” at the beginning of the word, and Number Two deletes the letter “c”. When you merge should get "Habr."
For the algorithm, user actions can be written as ins (“x”, 0) (insert the letter “x” in the zero position) and del (1) (delete in position 1). Let's try to consistently perform these transformations, taking into account whose changes will come first to the server:
It can be seen that the complexity lies not only in the changes themselves, but also in who of the users managed to send their edits first. The solution to this problem is that the user changes that come second to the server need to be transformed through the changes that came first. In the first case, since deleting at position 1 does not change the insertion 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 into deletion at position 2. Finally, after conversion, we get the following scheme.
According to this principle, all text (and not just text) editors that have co-editing online 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 the submitted changes takes place. For other online editors (for example, Google Docs), the server is responsible for the conversion processes. The changes come to him in an untouched form: in our case, these are ins (“x”, 0) from Number One and del (1) from Number Two. Next, the server converts the edits received and sends them to users. Thus, Number One will receive del (2), and Number Two - ins ("x", 0).
In our scheme, everything will happen differently. Both users will send to the server a request to save their changes. One of them will receive the answer “can”, and the second “cannot”. The one to whom it is “possible” will immediately send their changes to the server, which, in turn, will send them to the second user. The second user applies these changes and (according to the scheme described above) converts his own changes through them. Only then will he send his converted changes to the server. Then edits will come to the first user.
The main advantage of our scheme is that we do not load the server - it only stores a list of changes that were made to the document, and a save queue is organized.
Cancel / return
We immediately recognize that we do not yet have undo in the mode of “fast” joint editing. Unfortunately, no one has such an undo that users would like.
For example, undo editors Google Docs works partially. Rather, it is designed for the fact that users will cancel minor missteps, typos. Attempts to roll back more serious changes can lead to unpredictable consequences.
Suppose one person added a table, and another began to change it, say, move the boundaries, enter text. Then the first one decided to make an undo table addition. In fact, the table will disappear with everything that the second user did in it. If he, for example, dragged into the table a part of the text from the document, then it will sink into oblivion along with the canceled table. In addition, for this option undo it is impossible 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 with the option invented by Microsoft: the user makes his edits and can roll them back as long as necessary, but only until user number two joins editing and makes his own edits. Then undo will work for the second user. Until the third appears. This option seems to us to be 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 about adding undo, which would work just like Google’s. In our plans, it coexists peacefully with the Microsoft option: as long as you can do the correct undo / redo, we do it, then we try to do the undo as in Google Docs.
In different modes
The ability to switch edit modes is our innovation. Users who work with the document at the same time can choose the most convenient way to edit.
For example, Number One has “strict” mode enabled, and Number Two has “fast” mode. The first blocks objects and saves its changes by itself. The second does not block anything, and saving it happens automatically. If the first is editing an object or a piece of text, the second can do nothing in them. At the same time, the first one does not see what the second one does - let it be a surprise. After saving, Number One will send its changes and accept the changes to Number Two.
If Number Three is connected with the “fast” mode, then they with Number Two are quietly working in the mode of fast co-editing. At the same time, they do not see and cannot rule what the introvert Number One blocked. The latter, by the way, employs both undo and redo.
This scheme of work seems logical and convenient to us - it allows users to choose the way of interaction with collaborators depending on the tasks and mood. Switching between modes is possible at any time editing.
Try quick collaborative editing in action here .
PS In the new version of the ONLYOFFICE editors, a review mode has also appeared with tracking of changes made during document verification. The proposed edits can be accepted or rejected.
PPS Editors never stop working at all. We always think that this would add and improve. Therefore, there is still a lot of things ahead.
Source: https://habr.com/ru/post/276101/
All Articles