On Mon, May 27, 2019 at 5:25 PM Eduard Moraru <[email protected]> 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? > Simple users that are using the WYSIWYG editor are not using the wiki syntax directly. It's scary enough for them to see the changes (in the History tab for instance) on wiki syntax. You now want them to fix a merge conflict in wiki syntax? I feel it's too much. > > 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. > I don't agree. I think we should use a different **notification** message than "Saved". I think it's useful to know that a merge was needed, even if one could be done automatically. > > 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 you're referring to the diffs, then yes, we don't have visual diffs ATM (on HTML) and even if we had, a visual diff might hide some changes and thus I don't think it would be suited for a merge conflict resolution. But showing the wiki syntax diff and giving the (simple) user some action buttons is definitely easier (for they) than to ask them to fix the merge conflict by editing the wiki syntax directly. Thanks, Marius > > 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) < > [email protected]> > wrote: > > > On Thu, May 23, 2019 at 6:33 PM Simon Urli <[email protected]> wrote: > > > > > > > > > > > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote: > > > > On Thu, May 23, 2019 at 12:10 PM Simon Urli <[email protected]> > > > 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 <[email protected]> > wrote: > > > >>>> > > > >>>> > > > >>>> > > > >>>> On 23/05/2019 09:31, Vincent Massol wrote: > > > >>>>>> On 23 May 2019, at 09:25, Simon Urli <[email protected]> > > 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 < > > > [email protected]> > > > >> wrote: > > > >>>>>>>> Hi Simon, > > > >>>>>>>> > > > >>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <[email protected]> > > > 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 > > > >>>>>>>>> [email protected] > > > >>>>>>>>> More about us at http://www.xwiki.com > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>> > > > >>>>>> -- > > > >>>>>> Simon Urli > > > >>>>>> Software Engineer at XWiki SAS > > > >>>>>> [email protected] > > > >>>>>> More about us at http://www.xwiki.com > > > >>>> > > > >>>> -- > > > >>>> Simon Urli > > > >>>> Software Engineer at XWiki SAS > > > >>>> [email protected] > > > >>>> More about us at http://www.xwiki.com > > > >>> > > > >> > > > >> -- > > > >> Simon Urli > > > >> Software Engineer at XWiki SAS > > > >> [email protected] > > > >> More about us at http://www.xwiki.com > > > >> > > > > > > -- > > > Simon Urli > > > Software Engineer at XWiki SAS > > > [email protected] > > > More about us at http://www.xwiki.com > > > > > >
