On 8 November 2014 22:01, Brian Wolff bawolff@gmail.com 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.