23 May
2019
23 May
'19
4 p.m.
On Thu, May 23, 2019 at 12:10 PM Simon Urli <simon.urli(a)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.
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/linescolo…
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:
>
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”.
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
<vincent(a)massol.net>
wrote:
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
> On 23 May 2019, at 09:43, Simon Urli <simon.urli(a)xwiki.com> wrote:
>
>
>
> On 23/05/2019 09:31, Vincent Massol wrote:
>>> On 23 May 2019, at 09:25, Simon Urli <simon.urli(a)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.
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”:
>>>>> Hi Simon,
>>>>>
>>>>>> On 22 May 2019, at 10:45, Simon Urli <simon.urli(a)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.urli(a)xwiki.com
>>>>>>> More about us at http://www.xwiki.com
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> simon.urli(a)xwiki.com
>>>> More about us at http://www.xwiki.com
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> simon.urli(a)xwiki.com
>> More about us at http://www.xwiki.com