Hacker News Reader

Comment by codingdave | Hacker News Reader

The problem I ran into when I had to do this on a prior project wasn't the algorithm for worrying about individual characters. It was dealing with how to manage people highlighting entire paragraphs or documents, and pasting over them with new content, at the same time as the other editor(s) had been changing things.

Ultimately, while there were algorithmic answers to just about any scenario, we ended up just declaring a business answer instead - the editor only would let you into edit mode one paragraph at a time, and you locked that paragraph while you were in it. We found that almost nobody was actually editing the exact same paragraph at the same time anyway... they were working in different parts of the documents. So not only did that resolve all possible copy/paste insanity, the algorithm became brain-dead simple -- when you update or leave the paragraph, send those changes to everyone else's editor.

View on HN

Back when SubEthaEdit was new, I was a writer on a comedy show. Many afternoons, our team of 4 to 6 writers would get into something like a competitive I-can-finish-you-joke-before-you-do edit war. I don't remember ever again being paid for having that much fun.

But that only worked before SubEthaEdit worked absolutely flawlessly with anything we threw at it. You'd have two people editing the same word, yet it never occurred to anybody that we weren't actually all playing with the same piece of clay.

(Moral of the story: "nobody would ever want to that" is a self-fulfilling prophecy)

That formula should be extend to involve a live audience each having a tomato launching siege engine at the bottom of the window. From the audience perspective the tomato is flying away, from the to be comedian perspective they are flying towards his screen obscuring his vision proportionally.

Then add a gradual set of laugh samples to represent the number of observers who pressed the "yes, that was funny" button. For the jokes with the highest powerlevel animal sounds should be mixed in.

Lets call the invention The Funny Royal.

Yes, you are correct - I meant nobody in my specific user community. There certainly are other audiences who would edit documents differently than my authors did....

Yup, I just wrote an article [1] about just this. Simultaneous co-editing doesn't work unless the UX includes the appropriate cues to avoid this sort of thing. There are astoundingly few good examples of good (much less great!) real-time coediting UXes. This is the primary reason why we added first-class support for these cues so that it's not so damn hard!

[1] https://convergencelabs.com/blog/2017/09/what-makes-for-a-gr...

Agreed. My first UX attempt was to simply put a list of the current editors on a document in the upper-right corner, and highlight the field or paragraph being edited by each person. It worked well enough, but this was also a limited scale audience - just a few dozen legal document authors. A larger scale app might require more, but it met the need we had.

Could you elaborate on the kind of bad UX you've encountered, and what solutions can be used to fix them? I can't think of anything that a simple cursor position indicator (and maybe a selection indicator - though that could get messy if the selection is large) doesn't solve.

That's how Wikimedia does it and it doesn't need all the fancy concurrent editing logic.

MediaWiki locks the whole article (or just a section if the user happens to explicitly choose so), and has no way of doing conflict resolution. It only detects it.

Actually, the way MediaWiki works was what inspired me to better study the problems of version control and concurrent editing in the first place.

But as codingdave said, there are actual person-level issues with editing the same text together, and it happens rarely anyway.

Quip does it this way and I find it pretty frustrating. YMMV.

Reply on news.ycombinator.com