On 8 November 2014 22:01, Brian Wolff <[email protected]> wrote:

> Honestly i dont think anyone's even tried to improve the conflict screen.
> There's probably a lot of low hanging fruit on the usability of edit
> conflicts which could be persued that have nothing to do with the hard,
> real time editing solutions (as cool as those are).
>
> If someone is intrested in trying to improve edit conflicts, id reccomend
> starting with:
> *only showing relavent parts. If your conflict is in a section, and you
> were doing a section edit, dont ask user to resolve entire page (this is
> particularly painful on VP type pages).
>

​Yes, though this is normally triggered because the section isn't called
what it used to be; if you're appending a new section to the end of the
page I think it works fine.​



> Furthermore: find some way to present only the conflicted lines (ie what
> conflict markers show in a source control system) in a user friendly way.
>

​The normal way to solve this UX problem is "three column diff"​, but that
(a) isn't remotely good for mobile interfaces, and (b) adds Yet Another
Interface which may confuse as much as it assists. We'd need a lot of
painful UX research and a huge amount of developer time here, I feel.



> *better conflict resolution algorithms. This would require experimentation,
> but im sure there exists something better for merging natural language
> documents than just shoving it to gnu diff3. Perhaps even just adding a
> newline after every sentence (period) so that it merges on a more fine
> grained level would be appropriate. I imagine there must be papers written
> on this subject we could look to for advice.
>

​This doesn't work for languages without word/sentence/paragraph
separators​, of course, but has some promise.


​There are probably some other improvements we should think about, but this
is a good start.
​
Note that the behaviour
​ for IP editors is probably worse, given the special code paths used for
logged-in editors (the "you can't conflict with yourself" branch) that
aren't open to IPs.

J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

[email protected] | @jdforrester
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to