With the auto-save that comes with realtime editing, the Cancel button has become more or less useless. Most of the time it simply takes you back to view mode without discarding anything (because the changes were already auto-saved). So I’m wondering if we still need a Cancel button when editing in realtime, and if we do, what should be its behavior (what useful action can it perform).
Let’s see what options we have:
Remove / hide the Cancel button. If a user wants to discard recent changes they will have to:
either do it manually (tedious)
or use the Undo/Redo feature from the editor, but note that this will revert the changes from other users as well (and it doesn’t work if remote changes keep coming)
or rely on the document history, identifying the version before the realtime session started, but reverting will include changes from other users that were editing at the same time and also revisions created outside the realtime editing session
Change the name and behavior of the Cancel button to discard all the changes done since the realtime session started (by storing the document version number before the realtime session started), but:
this includes changes from multiple users
this also includes changes done outside the realtime session, while the realtime editing was in progress
Add support for using a draft, Realtime: Auto-save original document vs. a draft , in which case we can provide an action to discard the draft. It would discard changes done by other users as well, but at least it won’t include revisions done outside the realtime editing session.
I don’t see a viable way to make the Cancel button discard only the changes done by the current user. The only improvement in this area would be to add support for per-user Undo/Redo history in the editor Loading..., but it’s not going to be easy (hopefully the new WYSIWYG editor supports this).
I guess the answer that make sense with current features is 1.. Then 2 and 3 are kind of new features that we may or may not want to introduce (and may depend on other factors, so hard to answer in that thread).
Hello, after a few months of usage I find the lack of Cancel button quite disturbing.
Realtime edition is not always used (ex: personal usage, or forms) and it happens often to edit a page to finally not changing anything, in this case the only visible action now is to save the page using the Done button, which adds a new version to the history even if no change has been done. I’m not sure we want to promote this behaviour.
Cancel feature on edit tools is quite common and should be available on XWiki. The most baffling is that an advanced user will keep using the old ALT-C shortcut, which actually works. Is there a possibility to have this feature back through a button?
Isn’t then the problem the fact that a new revision is created? We have the same “problem” by the way when editing without realtime synchronization: save creates revisions even if there’s no change, not even the author. I would rather fix this problem instead of adding the Cancel button back. This way the “Done” button can act as a Save when there are changes, or as a Cancel when there are no changes.
Now, you could argue that the client side already knows if the content is dirty, because the toolbar shows the save status (on the right side), and thus it could make the Done button act as a Cancel when there are no changes. As a matter of fact, that is what I initially implemented, but then I realized there are three special cases:
creating a new empty page: in this case, even if the content is not dirty (it’s empty basically), the Done button should still act as a save, in order to create the page
the page is deleted while you are in the editing session: even if you didn’t change the content, the content you have client side is different from what you have in the database (nothing, since the page was deleted)
the page is saved by someone else while you are editing: again, even if you didn’t change the content, it’s different from what you have server-side, so maybe you don’t want to Cancel
For this reason I think it’s best to check server-side if there are changes on save and if there aren’t any then don’t create useless revisions.
I also find the “Done” button to be not very user-friendly. I had a short discussion with Marius in the near past about whether it would be possible to have the old save bar when you’re editing alone (and switch to the new bar when more than 1 person is editing). The switch could be slightly weird (or not, since it’s interesting to know when someone joins editing the doc you’re editing).
Also, maybe “Done” is not the right term and “Exit Edit”, “Leave Edition”, or just “Leave” would be more explicit.
Now, what I don’t like at all is that I used to be in control of whether what I modified when editing a doc was saved or not, and that was great. This feature has got lost and that’s not great. the main use case is: I write some stuff but decide that it’s not a good idea and I don’t want to save my changes. How do I do that easily now? I know that I can find the history and do some diffs or check the dates to see the version I need to rollback to, but it’s not easy and not immediate at all. Note that if I’ve typed stuff over some time, there’ll be several revisions created too, which is another problem that we have when editing with several people but that we also now have when editing alone.
So to sum up, we have 2 issues to fix IMO:
Be able to cancel one’s own changes since the start of the edit session
Be able to not create extra revisions when being alone (ideally, also when with other people by merging revisions when possible, but that’s more complex).
For me, the simplest is maybe to start editing a page alone with the save bar we had before, and then move to the RT save bar when more people start editing. In 99% of cases, you’re editing alone and you’re suffering from the 2 issues listed above, so that’s not good IMO.
I still believe this automatic switch would be weird and lead to a very bad UIX. You have to take into account that the user may be interacting with the toolbar at the moment when someone else is joining / leaving:
you’re editing alone, you focus the version summary input and start typing; someone else is joining, and suddenly you lose the version summary input and what you typed in it…
you’re editing with someone else, you open the “Recent versions” dropdown, and right when you want to click on a version the dropdown disappears because the other user temporarily lost the connection…
You might think we can ask the user before switching the toolbar but:
asking is still distracting the user from their current action
the user may be away from their computer, so the second user would have to:
either wait (annoyed) before joining
or join alone, so with the old toolbar, which takes us back to the initial problem…
You would have the same problem if you were using Google Docs, Confluence or Notion. Do you know any tool that supports realtime editing but keeps it disabled when editing alone?
There is a “Recent versions” dropdown on the realtime toolbar that you can use to see the versions that were saved since you joined the realtime editing session. You can select a version to see how the content looked like in that version. We are missing a revert button, but that shouldn’t be hard to add. With this you would be able to revert without leaving the edit mode.
But be aware that when you revert you might revert other users changes as well. Even if you start editing alone, someone else might join to fix a typo and then leave. It’s not easy to revert only your changes in a realtime editing session…
Again, it’s not easy to do this because others may have updated the content you modified (and left the session afterward). What we can do is to allow you to go back in history, from edit mode, using the “Recent versions” dropdown, but it will revert changes from other users as well.
I don’t see how we could do this without implementing drafts, like Confluence does.
I don’t think this can work. Moreover, all knowledge management tools I know are auto-saving the content. If you have counter examples I’d be more than curious to know how they handle the switch from editing alone without autosave to editing in realtime with auto-save.
Note that I’m also missing the Cancel button, but I think I could get accustomed to this if we:
make the Done button act as a Cancel when there are no changes (server-side)
add support for restoring a given version from the “Recent versions” drop down
99 % I work alone on an article. I do miss an option where I start editing not in realtime editor always. I know I can leave the realtime editor but I do have to make 3 clicks.
I would like to start alone and receive a popup if someone want’s to join.
I do miss the input for the summary. I know it’s there but actually I do have to do clicks to find the summary.
And last: currently I click “Edit” do nothing and click “Done” and there is a new major revision with no change. (XWiki 17.4.4)
I do like the realtime editor but I find it should only be activated if someone want’s to join (or joins without a popup asking for “permission”).
@mflorea: @Simpel has summarized well my opinion too, which is that we’ve regressed in term of usability when editing content. While RT offers new features which could make it acceptable to have some regressions, it’s hard to justify for 99% of the cases when you’re alone and have these usability regressions.
So I think we need to do something: either fix the usability issues for all cases (ie editing alone and editing with several users) or go back to the previous usability when alone.
This would still make it way harder than before to cancel changes. This would mean:
click the clock icon
click the “revert” action
click the arrow next to “Done”
click the “Leave collaboration” option
Confirm the leave in the modal
You then get the non-RT save bar… on which you need to click “Cancel”!
That’s 6 clicks! Vs 1 single click before… Big loss of usability.
More generally the issues I see are:
It’s harder (more clicks) than before to enter summaries
It’s harder (more clicks) than before to cancel (4 clicks vs 1 before)
You get more revisions than before even when you’re alone, making it harder to understand the history afterwards
BTW, by hiding the “summary” field we’re also not pushing users to fill it, and it’s already not something easy to do, this will lead to even less summaries and harder to understand histories.
As a user I’m not prepared to loose all this (items 1) to 3)) for 99% of my edits.
Maybe we could add back a Cancel button that would revert all my changes during the editing session, unless someone else has also made changes to the same content and reverting would cause a conflict. If that’s not possible or too complex for now, we could imagine a Cancel button that would become greyed out as soon as someone else joins the edition (or if we can, as soon as someone’s else content is saved).
Also, from a usability POV, I don’t understand the “Summary changes” under the clock icon vs the “summarize and done” action under “Done”. And from what I understand this will create a new revision, with the entered summary, even if there’s no changes in the content (ie it won’t affect past revisions, in other words, you cannot set/modify summaries on past revisions that happened during the editing session).
That would be a first step and we need it (especially the Done button behavior which I thought we had - but I’ve checked and indeed we always get a revision too much - we need to fix this one urgently IMO). But I still think it comes short on the usability/control we had before.
I think the possibility to use the “Done” button as a way to save or leave when there are no changes would fit well. Technically, what happens currently with ALT-C shortcut?
the other user will not want to wait for your confirmation (you may be away or looking at a different window)
if they start editing without waiting for your confirmation they are actually forcing the edit lock so you, or they, will have to fix a merge conflict on next save
I’m biased here because I don’t use the summary field that much, and from what I can see on the history of pages from xwiki.org it’s not used much there either. I can understand that for users like you or Vincent that often add change summaries, the additional clicks are annoying, but the fact is that the summary field simply can’t stay on the toolbar when you have autosave, and realtime editing requires autosave. With autosave you need to have a separate action to add change summary. When we designed the realtime toolbar we thought this action is not used often so we put it in the dropdown to unclutter the toolbar.
This can and should be fixed. The Done button shouldn’t create useless revisions.
I don’t understand what you want to achieve with these steps. Isn’t this your use case:
you enter realtime editing mode
you make some changes
your changes are autosaved
you want to leave editing discarding the changes you did
For this the steps would be:
open the “Recent Versions” drop down
restore the content from the first version (this action is not yet implemented, but it would simply replace the edited content with the content from the selected version)
click on Done
Still 3 clicks, but the fact is that what you want to do (discard the changes since you started editing) doesn’t work well with the realtime editing use case because other users might have made changes as well, some of which could be on top of your changes. The bottom line is that a Cancel button is dangerous for realtime editing:
it’s not easy (if possible?) to revert only your changes (in all cases)
reverting other users’ changes is not nice
First of all, the Cancel button you are missing is not reverting all your changes during the editing session. It reverts only the changes done since the last save, which I’m sure is confusing for some users, since clicking on Cancel after clicking on Save has no effect other than returning to view mode.
Then, the problem you have is not necessarily with realtime editing but with autosave. You would have the same problem if you enable autosave outside realtime editing. My point of view is that Cancel doesn’t make sense when you have autosave, at least not as a separate action. I’m all for providing a way to quickly restore some previous content state.
The point of the “Summarize Changes” action from the “Recent Versions” dropdown was to allow the user to create a “milestone” revision, explaining what changed since the last “milestone”. It would work better if we were able to collapse / hide from the page history the auto-saved revisions, showing these “milestone” revisions instead.
@vmassol@Simpel my impression is that for users like yourself the best is to have realtime disabled by default, i.e. don’t start a realtime session when editing a page, until you check “Allow realtime collaboration”. We can add a user preference add a wiki preference for this. The question is what should be the default in XWiki Standard. I’ll open a vote for this.
Exactly what I’m looking for. I as a user want a user preference where I can disable the start of a realtime session when starting to edit.
I would like to have a checkbox “Allow realtime collaboration” while editing.
I would like a wiki preference what should be default for all users if not set by the users. I don’t have a personal preference what should be default in XWiki Standard.
@mflorea I think we still need to improve the RT mode and continue to make it the default.
I think there’s a way to solve the cancel issue + the too many revisions one.
What about the following:
I make some changes in RT, a revision is created (autosave)
I make another change and autosave kicks in. However since there was another change done with my user, the code meres the 2 change into a single revision (ie we end up with a singe revision containing the 2 change sets). Ofc this merge stops as soon as a revision is made by someone else, but can resume if again there are contiguous revisions done by a given user.
Also, during the merge of revisions, if the diff is empty, then delete the revision altogether. This would solve the issue of cancelling leaving revisions behind: you make some changes, you undo them (using the WYSIWYG undo feature for ex) and after you click done (or the autosave kicks in), there’s no revision left.
So to sum up, we could implement:
The Done button not adding a revision if there’s no changes done
The revision merge for contiguous changes done by the same user, including the revision deletion if 2 changes negate each other
Then, later, we could discuss implementing other improvements such as:
3) Revert changes in the “Recent Changes” dropdown
4) Add the ability to set a message on a past revision, in the “Recent Changes” dropdown (ie it should show both the revisions and their messages + have a way to set a message). Side note: we could also allow admins or users with PR the ability to change the message for past revisions in the history view in docextra.
Moreover, I’m not sure that clicking undo multiple times (during which other users may introduce other changes) is better than restoring the content in one click from the Recent Versions dropdown.
This won’t solve the issues that you and @Simpel raised:
I don’t think we can have the same amount of clicks with the realtime toolbar, and I don’t know how many clicks are needed to not consider this a regression.
I’d like to explore this more. We do offer the ability to delete revisions so if there’s something dangerous we need to fix it anyway. I don’t want to discard this off-hand.
When you’re in an autosave mode the natural way to remove content is by undoing your changes. Think MS Word for example or any editor that autosaves. That’s clearly (and by far) more natural and simpler than playing with revisions. Ofc if you made a lot of changes that’s another story (and the undo buffer is limited anyway) but that’s not the use case here.
The idea here is that if you made one change and then removed that change, during the same edit session, there shouldn’t be a new revision created.
Note that I still think it would be nice to have 3) but I find it less urgent than implementing the grouping and undoing of revisions.
For the first point no, but I addressed it in point 4) and it’s less important than other points.
For the second point, it’s solved by clicking “Done” and undoing changes if you started writing a few things you decide that you don’t want after all.
Deleting a version just seconds (or more depending on the load/speed) after it’s been created might create quite a mess (or at the very least big stack traces in the log) for asynchronous tasks for which the version is important (indexing tasks like the mentions, cluster event dispatching, replication, etc.).
But for me it just shows that those async tasks don’t take into account the fact that revisions can be removed. They need to be bullet-proofed to take that into account. This can already happen when manually deleting a revisions seconds after you create one.
The problem is not only with async server-side tasks that may process deleted revisions. On the client-side a big problem is that currently version numbers can be reused. This can happen for instance:
Alice starts editing version 2.1
Bob deletes version 2.1, the latest, and 1.1 becomes the new latest version
Bob saves the page, incrementing the version back to 2.1
Alice saves, overwriting Bob’s changes because although Bob’s 2.1 is a different version than Alice’s 2.1, they have the same number, so there is no merge conflict.
Reusing deleted version numbers creates problems also for real-time autosave. After each save we need to propagate the new version number to all the collaborators, so they don’t get a merge conflict on save. But multiple users could trigger the save and the order in which the new versions numbers are propagated is non-deterministic, so we need to decide which is the latest version. We currently compare the version number and use the highest value, which might not be the latest if revisions are deleted server side. I suppose this could be fixed by returning the revision timestamp on the save response, but I think it’s safer to modify the revision store to use a version counter that is not affected by deleted revisions. There might be unexpected side effects though.
But that’s not what is being discussed here… (which was originally about Cancel).