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. > > 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. > > 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. > > 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 >
