27 May
2019
27 May
'19
5:22 p.m.
Hi Edy, all,
On 27/05/2019 16:25, Eduard Moraru 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.
we all agree on that so far.
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.
I hope too, for me it should work in any editor: WYSIWYG/inline/wiki/etc.
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/…
So for me that is specifically *not* a first version proposal :)
I won't be able to do such work properly in one release, for sure.
Hence my proposal to reuse the work already done with the conflict
window, and to reuse it for the merge conflict window.
Now I agree it's a really good idea and it could be a good direction for
next iterations.
Simon
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)
<valicac(a)gmail.com <mailto:valicac@gmail.com>> wrote:
On Thu, May 23, 2019 at 6:33 PM Simon Urli <simon.urli(a)xwiki.com
<mailto:simon.urli@xwiki.com>> wrote:
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.
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/linescolo…
, 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
I want
to
> > share:
> >
https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolo…
properly
users to see
the same
conflict.
https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing
<simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com>>
would have
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.urli(a)xwiki.com <mailto:simon.urli@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
On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
> On Thu, May 23, 2019 at 12:10 PM Simon Urli
<simon.urli(a)xwiki.com
<mailto:simon.urli@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.
me it
Auto-merge the rest.
Apparently I wasn't clear about my "all or nothing" feature. For 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?
>
>>
>> 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 
>
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 >
> 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.urli(a)xwiki.com
<mailto:simon.urli@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
<mailto:simon.urli@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 >> 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 >> 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
>> 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 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
have been
> 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 >> 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
proposal
for the
> 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 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”:
> >>>
> >>
>>
>> Thanks
>> -Vincent
>>
>>>
>>> Simon
>>>
>>>> WDYT?
>>>> Thanks
>>>> -Vincent
>>>>>
>>>>> Simon
>>>>>> Thanks,
>>>>>> Caty
>>>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <
vincent(a)massol.net <mailto:vincent@massol.net>>
>> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>>> On 22 May 2019, at 10:45, Simon Urli 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 >> 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
<mailto:simon.urli@xwiki.com>
> >>>>>>>>> More about us at http://www.xwiki.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Simon Urli
> >>>>>> Software Engineer at XWiki SAS
> >>>>>> simon.urli(a)xwiki.com
<mailto:simon.urli@xwiki.com>
> >>>>>> More about us at http://www.xwiki.com
> >>>>
> >>>> --
> >>>> Simon Urli
> >>>> Software Engineer at XWiki SAS
> >>>> simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com>
> >>>> More about us at http://www.xwiki.com
> >>>
> >>
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com>
> >> More about us at http://www.xwiki.com
> >>