Also, there is the possibility of having to go though the conflict resolution screen multiple times if, whenever trying to finish it and press save, a new change was done in the background user, generating a conflict with the version you have just resolved. If it's a very popular page that users are constantly editing generally on the same places of the document, this could get a bit annoying the more time you spend in edit mode :)
On Mon, May 27, 2019 at 5:25 PM Eduard Moraru <enygma2...@gmail.com> wrote: > Hi, > > I feel we're over-engineering things a bit, at least for a fist version. > My feeling is that the approach is to go with an UI-first version (the > whole talk about being able to choose "mine" vs "their" versions) and only > then, at a later point, coming back to a text-based version that allows you > to fix the details. Why not go the other way around, in a simpler and > already familiar (to some at least) yet flexible solution of starting with > the text-based version, since we are editing wiki syntax after all? > > IMO, the easiest thing we could do is that, when a save is attempted, a > merge should be attempted first. If no conflict occurs and the merge can be > done automatically, the save should be done on the DB as well and the user > should not perceive anything, thus not affecting his flow. > > Note: I hope we are all on the same page when I say that the merge > conflict resolution should target/work on wiki syntax in the UI as well. > > If, however, conflicts do occur, the save does not go to the DB. Instead: > * If it was a save&continue, the UI should inform the user (popup/bottom > screen notification) that the save failed because of a conflict and offer > the possibility to keep editing or resolve the conflict > * If it was a save&view (or if the user clicked "resolve conflict" after a > failed save&continue), the UI should reload the (wiki) editor with the > entire merged content that will include the conflicts in a way that is (at > least in the first implementation) similar to how git conflicts are > displayed in a file, i.e. clearly marked in the content (where the conflict > starts and ends), showing your version vs the version that is currently on > the server (in the DB). Example (with html, but imagine wiki syntax here > and we could use something better than "HEAD", etc.): > https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png > > An improved version (iteration) of this could then be to use something > like CodeMirror's "merge" addon (since we already use CodeMirror in the > syntax highlighting application). It supports 2-way or 3-way display and > live diff computation between the versions, synchronized scrollbars, and > other neat stuff: https://codemirror.net/demo/merge.html We could decide > if in "our" version we include the user's original version OR if we put > directly the merged version (where the auto-merges are already applied) OR > if we have a button under the user's original version to perform auto-merge > on request, leaving just the remaining conflicts to be handled by the user. > Finally, when save&view is pressed in this mode (note: probably we need to > disable save&continue so that the "conflict resolution" action is "atomic", > i.e. without leaving the content in an unfinished merge state), whatever > the edited version is will overwrite the DB version of the document (i.e. > force with whatever it contains). > > WDYT? > > Thanks, > Eduard > > On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) < > vali...@gmail.com> wrote: > >> On Thu, May 23, 2019 at 6:33 PM Simon Urli <simon.u...@xwiki.com> wrote: >> >> > >> > >> > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote: >> > > On Thu, May 23, 2019 at 12:10 PM Simon Urli <simon.u...@xwiki.com> >> > wrote: >> > > >> > >> So trying to sum up the discussion to see if we all agree. >> > >> >> > >> All the above is in the case of a save conflict: >> > >> >> > >> 1. Default behaviour for all users is to try an automatic merge, and >> to >> > >> display a window conflict resolution in case of merge conflict. The >> > >> conflict resolution is an all-or-nothing based, allowing to choose a >> > >> version over another. >> > >> >> > > >> > > I don't agree about the all-or-nothing, since I would prefer to accept >> > what >> > > we can, warn on conflicts. >> > > We should show a resolution conflict when the conflict is on the same >> > line. >> > > Auto-merge the rest. >> > >> > Apparently I wasn't clear about my "all or nothing" feature. For me it >> > only concern the resolution of the merge conflicts, but the choice made >> > apply to ALL conflict of the document. That's what I meant. >> > >> >> Here it was the confusion, since in my mind, I though we were going line >> by >> line. You said that in the first version we won't have this, but ideal >> implementation it should go like that (and even at the word / character >> level for realtime-editing). >> >> >> > > >> > > >> > >> >> > >> 2. There is an option in the user profile to be able to always see >> the >> > >> diff in case of save conflict, to accept or not the merge, even when >> > >> there's no conflict. >> > >> >> > > >> > > I don't like the option in the profile. IMO we should decide on the >> > > behavior and apply it for all users. Edit is a core feature, conflicts >> > > again are part of this kind of interaction. >> > > >> > >> > So you'd go with a -1 for this option? >> > >> >> We should add a new configuration only if it's needed. Again, I think we >> are introducing a lot of things (parent/child relation, accessibility >> options, etc.) that we never test. We don't reach a conclusion by >> ourselves, so trying to make everyone happy, we are just increasing the >> complexity of selection for the user and for the testers. >> >> >> > > >> > >> >> > >> 3. When a user save with a merge, the notification message displays >> that >> > >> it's a merge save. It means that user clicking on "save&view" might >> miss >> > >> it. >> > >> >> > > >> > > On "Save&View" we can increase the timeout for the notification. >> > > The notification could mention also the magnitude: "Saved. >> Auto-merged 10 >> > > conflicts." >> > > If cannot save, show the conflict modal. >> > > >> > >> > How would you quantify this magnitude? The number of versions between >> > the two saves? What about minor/major versions? It looks a bit fuzzy to >> me. >> > >> >> The magnitude I had in mind applied for the line by line case. If you look >> at the image >> >> https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolor.png >> , 3 lines were successfully merged, while having conflict on 1 line. So we >> were tacking about different things. >> >> >> > >> > About increasing the notif timeout in case of Save&View I'm not >> > convinced: you're suppose to be immediately redirected to the view page >> > in case of Save&View, so making the user wait on a notif doesn't look >> > very nice. >> > >> >> The idea was to redirect the user as soon as possible in the View mode, >> just display the bottom page notification a bit longer (or add a >> notification display for the View step). >> >> Thanks, >> Caty >> >> >> > >> > Simon >> > > >> > >> >> > >> Those are the first three priority points. The following points are >> > >> important too, but might not be finished in 11.5. >> > >> >> > >> 4. If another user saved a document that I'm editing, I have a >> > >> notification in the editor and I can click on it to see the >> > diff/conflicts >> > >> >> > > >> > > This mockup might not help, but is something I had in mind that I >> want to >> > > share: >> > > >> > >> https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolor.png >> > > >> > > Ideally I would like to see real time, if not the exact changes, but >> at >> > > least the lines affected by the current editor. >> > > >> > > Thanks, >> > > Caty >> > > >> > > >> > >> >> > >> 5. The conflict resolution is line-by-line based. >> > >> >> > >> WDYT? >> > >> Simon >> > >> >> > >> On 23/05/2019 10:00, Vincent Massol wrote: >> > >>> >> > >>> >> > >>>> On 23 May 2019, at 09:43, Simon Urli <simon.u...@xwiki.com> wrote: >> > >>>> >> > >>>> >> > >>>> >> > >>>> On 23/05/2019 09:31, Vincent Massol wrote: >> > >>>>>> On 23 May 2019, at 09:25, Simon Urli <simon.u...@xwiki.com> >> wrote: >> > >>>>>> >> > >>>>>> Hi Caty, >> > >>>>>> >> > >>>>>> On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote: >> > >>>>>>> I'm not sure I agree about this profile option. >> > >>>>>>> Indeed we want to make things as simple as possible and having >> > >> conflict >> > >>>>>>> resolutions can be scary, still, there is no way an user could >> take >> > >> this >> > >>>>>>> decision in advance. >> > >>>>>>> Users will want to have control over what they do and at least >> know >> > >>>>>>> something went wrong. We cannot automatically merge, without any >> > >> warning, >> > >>>>>>> since users will immediately see that their work was changed. It >> > >> will be >> > >>>>>>> reported as a bug (in case they notice it) and they will expect >> to >> > >> be able >> > >>>>>>> to recover the work. >> > >>>>>>> I can't think of a case when an user would not care about the >> > >> changes and >> > >>>>>>> the result. >> > >>>>>> >> > >>>>>> Let say that a document has 2 sections, and a user is editing >> > section >> > >> 1, while the other is editing section 2. The merge should work >> properly >> > >> without any conflict. >> > >>>>>> I don't really see the point of asking by default the second >> user if >> > >> he's ok to merge his work on section 1 with what has been saved on >> > section >> > >> 2. >> > >>>>>> On the contrary I feel it could be scary for the basic users to >> see >> > >> this kind of message and it decreases the easiness of using XWiki >> IMO. >> > >>>>>> >> > >>>>>>> Also the options are not clear to me: like 2: automatically >> merge, >> > >> but ask. >> > >>>>>>> Well is automatically or not? >> > >>>>>> >> > >>>>>> It's automatic but as you mentioned just after, in case of >> changes >> > >> are made on the same line there is a conflict that needs to be >> solved. >> > >> That's what I meant by "ask in case of merge conflict". >> > >>>>>> >> > >>>>>> On the contrary option 1 was a fully automatic merge, with a >> > >> predefined strategy to choose one version over another in case of >> > conflict. >> > >>>>>> >> > >>>>>>> We need to ask for resolution only if the changes are on the >> same >> > >> line, >> > >>>>>>> besides this, we should try to automatically merge, but provide >> the >> > >> info to >> > >>>>>>> the user that we did that. Instead of the normal Save message, >> we >> > >> could say >> > >>>>>>> that we performed a Merged Save. And in the history I would >> expect >> > >> to be >> > >>>>>>> able to see what lines were added by what users, just in case >> > >> something >> > >>>>>>> went wrong. We are lucky that we have the Blame view :) >> > >>>>>>> So not sure we need a configurable option in profile. We just >> need >> > to >> > >>>>>>> decide on the 'default' and implement that. We keep adding >> options >> > >> that >> > >>>>>>> only increase the complexity of the product and we never get to >> > test >> > >> all >> > >>>>>>> the possible mixes and configurations. >> > >>>>>>> So what are the use cases when we would need this option in the >> > >> profile? >> > >>>>>> >> > >>>>>> As I said above I personally don't see the point of always >> > displaying >> > >> the merge diff especially for basic users when there's no conflict. >> > Now I >> > >> really think that some users would want that, that's why I proposed >> the >> > >> profile option. >> > >>>>> I agree that option 3 is not great as it gets in the way. Now it >> > could >> > >> be interesting for the user to know it happened. Maybe some fleeting >> > >> notifications at the bottom of the screen or some info added to the >> > commit >> > >> message or some visual info when you’re in edit mode and before you >> > press >> > >> save. >> > >>>> >> > >>>> So in case of "Save&Continue" it's quite easy to change the "Saved" >> > >> notification message by another one. I'm not quite sure how to inform >> > the >> > >> user about the merge if he cliks on "Save&View”. >> > >>> >> > >>> By implementing the part below :) ie by providing this info >> > continuously >> > >> before he clicks any save button. >> > >>> >> > >>>> >> > >>>>> Ideally I’d like that we poll regularly to see if there have been >> > >> changes and display some icon if there are with the ability for the >> > current >> > >> user to click and see the diffs with his version, and if there’s a >> > >> conflict, that a visible message is displayed on the screen (but >> without >> > >> interrupting of his typing). >> > >>> >> > >>> More details: when there’s a conflict, clicking the message/button >> > would >> > >> show the diff and the conflict. >> > >>> >> > >>>>> And when he saves, the merge is done then. >> > >>>> >> > >>>> I like the idea, now would that be enough to inform about the >> > performed >> > >> merge? If we go in that direction I'd need some design proposal for >> the >> > UI >> > >> @Caty :) >> > >>> >> > >>> Yes we need to find where to put that information. >> > >>> >> > >>> BTW, even better, we should ideally also display the icons of the >> users >> > >> who are editing the same doc and/or who have saved content after the >> > >> current user started editing. >> > >>> >> > >>> And we already have a design page for this ;) We called it >> > >> “collaborative editing”: >> > >>> >> > >> >> > >> https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing >> > >>> >> > >>> Thanks >> > >>> -Vincent >> > >>> >> > >>>> >> > >>>> Simon >> > >>>> >> > >>>>> WDYT? >> > >>>>> Thanks >> > >>>>> -Vincent >> > >>>>>> >> > >>>>>> Simon >> > >>>>>>> Thanks, >> > >>>>>>> Caty >> > >>>>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol < >> > vinc...@massol.net> >> > >> wrote: >> > >>>>>>>> Hi Simon, >> > >>>>>>>> >> > >>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <simon.u...@xwiki.com> >> > wrote: >> > >>>>>>>>> >> > >>>>>>>>> Hi everyone, >> > >>>>>>>>> >> > >>>>>>>>> I'm working on the merge on save for the roadmap of 11.5 and I >> > >> need some >> > >>>>>>>> decision to be taken. >> > >>>>>>>>> >> > >>>>>>>>> The main idea of the merge on save, is to try to merge users >> work >> > >> in >> > >>>>>>>> case of save conflict. Knowing that the merge might led to >> merge >> > >> conflict >> > >>>>>>>> in case of edits on the same places. Those merge conflict can >> be >> > >> tackled >> > >>>>>>>> automatically, but a priority will be then given to one version >> > over >> > >>>>>>>> another. >> > >>>>>>>>> >> > >>>>>>>>> I first propose to add an option in user profile, so users >> would >> > >> have >> > >>>>>>>> the possibility to choose between: >> > >>>>>>>>> 1. Always merge automatically the work, even in case of >> merge >> > >> conflict >> > >>>>>>>> >> > >>>>>>>> I don’t understand this part. If there’s a conflict it means it >> > >> cannot be >> > >>>>>>>> merged… So would it do? Take latest version and overwrite >> previous >> > >> version? >> > >>>>>>>> >> > >>>>>>>>> 2. Always merge automatically, but ask what to do in case >> of >> > >> merge >> > >>>>>>>> conflict >> > >>>>>>>>> 3. Always ask what to do in case of save conflict >> > >>>>>>>>> >> > >>>>>>>>> Now the question is: what should be the default option? >> > >>>>>>>> >> > >>>>>>>> Certainly not 1! 2 is really the best to me. >> > >>>>>>>> >> > >>>>>>>> Thanks >> > >>>>>>>> -Vincent >> > >>>>>>>> >> > >>>>>>>>> Option 1 looks like a good fit for decreasing the number of >> > clicks >> > >> to >> > >>>>>>>> do, but I'm a bit afraid that in case of conflict they would >> have >> > >> the same >> > >>>>>>>> feeling as before the warning conflict window: i.e. to loose >> some >> > >> part of >> > >>>>>>>> their work. >> > >>>>>>>>> >> > >>>>>>>>> WDYT? >> > >>>>>>>>> >> > >>>>>>>>> Simon >> > >>>>>>>>> >> > >>>>>>>>> -- >> > >>>>>>>>> Simon Urli >> > >>>>>>>>> Software Engineer at XWiki SAS >> > >>>>>>>>> simon.u...@xwiki.com >> > >>>>>>>>> More about us at http://www.xwiki.com >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>> >> > >>>>>> -- >> > >>>>>> Simon Urli >> > >>>>>> Software Engineer at XWiki SAS >> > >>>>>> simon.u...@xwiki.com >> > >>>>>> More about us at http://www.xwiki.com >> > >>>> >> > >>>> -- >> > >>>> Simon Urli >> > >>>> Software Engineer at XWiki SAS >> > >>>> simon.u...@xwiki.com >> > >>>> More about us at http://www.xwiki.com >> > >>> >> > >> >> > >> -- >> > >> Simon Urli >> > >> Software Engineer at XWiki SAS >> > >> simon.u...@xwiki.com >> > >> More about us at http://www.xwiki.com >> > >> >> > >> > -- >> > Simon Urli >> > Software Engineer at XWiki SAS >> > simon.u...@xwiki.com >> > More about us at http://www.xwiki.com >> > >> >
