Open tzugen opened 1 year ago
What exactly do you mean with conflict? As the message suggests, changes were done outside of the editor, and you see the document as it was loaded, and how it is currently. I would not call it a bug at all, but room for improvement. Also, a sudden reload of the file can lead to confusion (jumping cursors) and undesired changes, potentially unnoticed, when you were about to type, right when the reload happened.
cc @nextcloud/designers for UX impact
What exactly do you mean with conflict? As the message suggests, changes were done outside of the editor, and you see the document as it was loaded, and how it is currently. I would not call it a bug at all, but room for improvement. Also, a sudden reload of the file can lead to confusion (jumping cursors) and undesired changes, potentially unnoticed, when you were about to type, right when the reload happened.
With Conflict I am referring to the technical term that is commonly used when a common document A is modified by two parties B and C and the changes need to be consolidated into a new state. There are types of changes that cannot be automatically resolved and need human intervention.
But when a document is modified only by one Party, its a linear history and that should not create a conflict (or a confusing warning for the users).
And I don't think the point that the content could change under your eyes is really valid, because this can already happen when someone else is modifying the document using a different browser instance. (and this is actually a great feature because it allows collaborative editing)
I did not have a look in how far the server requests differ when the document is edited in another browser VS. In the Desktop app. But one possible strategy would be that the when the document changes the server send a DIFF instead of the full file and if that DIFF can be cleanly applied it is applied like any other streamed change. Only if that DIFF cannot be applied without conflicts, then and only then this warning should be shown. I would estimate that using this strategy this interrupting error message could be reduced by 50-90% depending on the type of work flow the users have.
But there is no need to reinvent the wheel there. All these issues are relatively common and have been solved for example in the git program that also this repository is using...
Not exactly, as you are aware when someone else is having the document open in text, and you also see the guest's cursor position.
this really looks to me as a bug :
when you share the .md file in nextcloud, in some way the text app make it visible online, which is great, but if i modify it with any other app than the online text editor (and maybe the markdown editor ? i didn't try, didn't enabled this app) it will go crazy, the changes do not show untill i connect to my account and validate that there is no conflict, and the desktop nextcloud app cannot sync the document anymore, creating a multitude of conflict messages
so this problem prevents me to modify my document outside the online text app, hence : bug
that's weird from an ux point of view : this document is a md document in my folders, i should be abble to modify it offline without conflict since i'm the ony one doing so
Not exactly, as you are aware when someone else is having the document open in text, and you also see the guest's cursor position.
Yes, thats right. I guess that it won't be possible to implement this if a change is coming from external.
this really looks to me as a bug :
when you share the .md file in nextcloud, in some way the text app make it visible online, which is great, but if i modify it with any other app than the online text editor (and maybe the markdown editor ? i didn't try, didn't enabled this app) it will go crazy, the changes do not show untill i connect to my account and validate that there is no conflict, and the desktop nextcloud app cannot sync the document anymore, creating a multitude of conflict messages
so this problem prevents me to modify my document outside the online text app, hence : bug
that's weird from an ux point of view : this document is a md document in my folders, i should be abble to modify it offline without conflict since i'm the ony one doing so
Thanks for putting it in different words, not sure if I explained it so good before..
https://github.com/nextcloud/text/blob/c967d0127151da5a64b770778c097a52e8b3c69a/lib/Service/ApiService.php#LL245C1-L252C5 On a cursory look this seems to be part of the problem. If I understand it right, the client will call Sync regularly, even if nothing changed in the browser (fine), but then the sync will trigger an unconditional call to autoSave, which will fail, because there is a newer file outside. But this call to autosave is not needed if no changes were done.
As discussed internally today, we'd like to stress that this behaviour right now is by design, so changes to this are indeed improvements, and we also agree with the sentiment here. When implementing the change, and text does reload the document without user interaction in the scenario outlined, there must be also some sort of visual feedball/notifier for the users to be not surprised by sudden changed. It could be a popup notification for instance.
allright, i respect your position and all the great work you do, but there is something weird here : if i want to share a link to a .md document, which is a basic nextcloud feature (sharing links to documents), even if i don't want it to be preview in the browser, even if i don't want to use the text app on this file, i cannot : as soon as i share the document the text app is automatically involved (i need to verify that), and the document will not be updated when i change it locally, plus it will create multitude of conflicts messages in my local nextcloud desktop app, and break a standard nextcloud feature
my only option here (i need to verify that on my computer later) is to disable the text app alltogether. otherwise it prevents me from using and sharing .md files. unless i can tell it not to 'take care' of one specific file ? that would be a bad workaround still, but feasable
i don't see how it is not a bug : i install the text app and then another feature (sharing and syncing a .md file) is broken
or did i not understood something here ? i have to take into account the fact that my server is poorly configured ;)
I would argue that this behaviour is still a bug. Uploading a text file (webif or webdav) is no issue. Text file is displayed correctly in Nextcloud (without any changes to the file). e.g.
Line 1
Line 2
Line 3
Changing that file ouside of text (e.g. adding a Line 4
, leads to following message in text:
Whereas the 'latest version' is actually the outdated version and the saved version is the latest version. Confusing!
Nevertheless, if choosing 'saved version', the formatting of the file breaks!
Line 1 Line 2 Line 3 Line 4
This can't be the desired design/behaviour. Please reconsider marking this as a bug! Thanks!
changes were done outside of the editor, and you see the document as it was loaded
Oh woah, but why didn't it load the most recent server-side version first? I'm confused what "current" means in this context.
Whereas the 'latest version' is actually the outdated version and the saved version is the latest version. Confusing!
+1.
In English the left side says "Use current version" and "Use the saved version". The one on the right seems to usually be the safe choice.
Also, is this a dup of #2388 ?
Related: https://help.nextcloud.com/t/text-document-current-vs-saved-version/151600
To me this "feature" sounds like a "simple" workaround to avoid a more complex solution. Did a customer request this "feature"? ;-) I get the feeling that a feature is being forced on all users because someone who pays for Nextcloud wants an edge case covered. Similar to how some marketing guy at GitHub thought it was more important to highlight the sign-up link instead of the log-in link. Because apparently people want to open a new account every day, but rarely log in with it again afterwards ;-)
I also think conflict management should take place during saving and not afterwards when a file is reopened. Also, in 99% of cases, when I click save, I want those changes to be applied, and not, have to decide, in some cases a few weeks later, whether I want to undo the changes I made. I also often use the text app to quickly open a temporary note on another device, and in that case it's very annoying to have to confirm a promt first. Not to mention that the promt is confusing, and it has happened to me several times that I have accidentally undone my changes.
I have reproduced this 'bug'. It is not a 'feature', it breaks 'file sharing' and replaces it with some sort of 'versioned publishing'.
I'm also struggling with this. Here's my scenario, which I think other people (at least those who edit text files locally on their computer) are experiencing:
Now, when opening the public-facing share link in a browser, I expect to see those changes which were synced. Instead, unexpectedly, it shows the old version of my file.
In order to resolve this, I must open the file using Text
via the website or mobile client, and select the right-most option to keep/apply my changes.
This makes some sense for the users who only use the browser and only make edits there, but for the rest of us who use local editors and sync our changes, it feels like very unintuitive or even broken behavior- to be forced to resolve a conflict that doesn't exist in the first place. I really don't want to disable Text
altogether- that's a really unfortunate workaround, because it's a fantastic app.
I'm really not sure how this could be properly fixed, as the conflict/resolution behavior is really helpful in the right scenario. Providing an option to disable the behavior wouldn't be a bad place to start for now, though, if that's possible.
everytime I access a text file in browser or android-app that has been saved on pc and synced I get this. Super annoying. How to explain this to my less technical users? How can this not be a bug? Should users read through the entire file to eventually find the changes, then remember which one is the newer file and finally click on the button on the right every time (unnecessarily since there is no conflict) and think "this is not a bug would be an enhancement to just work as expected ??
I'm struggling with the same issues as others have explained, e.g. https://github.com/nextcloud/text/issues/4078#issue-1683831899
A couple of things with the UX on the situation I'd like to point out:
What is the meaning of this message? I can see a point in "The document has been changed outside of the editor, you need to decide which version you want to keep using the buttons below.". But the part about "The changes cannot be applied."; Why can't they be applied, I didn't change the text in the file I'm looking at. What can I do about it? Is there an issue with the editor that I should contact support about? (I don't necessarily want an answer to these questions, but I'd like to express what a user may think when being met by the messages coming from Text/Notes)
This section is much more obvious as it shows the differences between the files and the buttons are located in a way that it's intuitive enough that there's little confusion as to what the result would be. But I do agree that the wording is confusing. I'm not a native English speaker so I can't suggest something rock solid, but perhaps "Use old version" | "Use new version" would make it less confusing?
There's a very similar, if not identical, issue in the Notes app git: https://github.com/nextcloud/notes/issues/1083
29.0.3 without any office suite. Still there is issue.
When I create .txt file on synced dir, put 1
inside, open that in webui and close, then I put in 2
via local notepad, wait for sync in desktop app or force the update, and reopen file in webui i still have 1
for longer time until it show me which version I want to pick the one with 1
or 2
.
Also, Is I reopen locally file with 2
and just hit save, now when opening it via webui it ask me if I want 2
version or 2
version (current vs saved).
Steps:
What happens
What should have happen: Detect that there was a change from outside and that the document in the cpollaborative editor was not changed in the meantime and just put the new document into the view.