There aren’t any external dependencies, no. The linked PDF is essentially a fairly detailed technical description of how Etherpad does their collaborative editing, which I’ve implemented in the plugin, the guts being here on the frontend, and here on the backend. (The paper does an excellent job of obscuring how simple the implementation actually is, but I couldn’t find a better one, and of course Etherpad’s source has a bunch of other stuff going on, so it’s not the greatest thing to look at for an MVP type implementation).
It’s probably not perfectly to the letter of the algorithm, notably the bits about merging otherwise incompatible diffs, but I kinda found those to be somewhat rare corner cases, which could be pretty easily remedied by the users involved even if it doesn’t follow what should happen exactly. For example, the paper suggests that if two users submit diffs like this at the same time:
when editing collaboratively in the composer, it is not clear how to stop editing. it’s the “minimize the composer panel” button in the top right corner of the composer which in this case makes it go away instead of minimizing. Maybe change the helper text to say “stop editing”. Or add a button where REPLY/cancel normally would be to say STOP EDITING or some such.
it would be helpful to know who has collaboratively edited a particular post, as well as who is currently in there collaboratively editing right now. Could the existing “replying…” feature potentially be utilized for this? e.g, display avatars and “editing…” in the composer and below the post.
it would also be helpful to know who contributed what to the collaboratively edited text. Not sure how to handle this - I liked how etherpad used to let you choose a color for yourself, which would identify your contributions. Google docs lets you see who’s editing and where their cursor is in the doc.
I think the “collaborate” button could be changed to “edit” but using the same icon and helper text… I think it’s clearer and in many cases there may not be more than one person around to edit anyway.
a different and more scalable way to allow/disallow collaboration may be to add the collaborate icon to the post menu, with “start collaborating” (not enabled) and “stop collaborating” (enabled) as options. Only visible to those allowed to start/stop collaboration.
a category setting to enable collaborative editing might be preferable, along the lines of wiki.
I’ve added this (It was a bug that it wasn’t there, heh
I agree with this a lot and will be thinking hard over the next wee while on the best way to implement it; it’s tricky, but essential in my opinion. Displaying cursors feels fragile and crazy to me (I think you have to absolutely position an indicator div based on a cursor position sent over the wire), so I’m currently thinking on the best way to store information in the diff structure about the author of each fragment (which I think should allow Etherpad-style background coloring), while trying to keep it acceptably scalable. The answer to ‘can the existing replying functionality be used’ is no
I’ve done this as well, as well as hiding the ‘edit’ and ‘wiki’ functionality when a document is realtime-editable (I think of this as a per-post replacement for those functions, which are already mutually exclusive)
I disagree with this one; when building features like this I often think of them as ‘analogous’ with some other feature in the core codebase (retort is analogous to ‘like’, for example), and attempt to design the experience to be parallel to that. For this feature, that’s ‘wiki’ (ie, if you’re thinking about doing this to a post, you would probably also consider wiki-fying it), meaning those options want to be together in the interface.
I’d like to do this, but the core codebase isn’t very extensible to adding category settings at the moment (the one for Retort is a pretty hacky workaround that I’d like to avoid repeating), and so would require changes to core - and I’ve had trouble getting core to accept changes to accommodate plugins. So I’m very hesitant to make plugin features which depend on changes to core, because even very low-risk requests get rejected too often.
I’m currently installing it. I will report soon If others already use it though, I’m interested to know as well.
Installation goes well. I tried to create a new topic and turned it into a collaborative editor using the topic menu option in the wrench. It worked. Then I invited my companion to join the topic and edit. But here there’s a bug: as she started editing, the existing content of the pad disappeared. I tried to edit as well, but our edits would cancel each other.
I’ve seen this with early Etherpad Lite where the pointer would flicker as other people would edit, jumping from your line to their line. I guess something similar is happening here, that the pointers are not handled well. @gdpelican did you encounter this bug?
OK, I fixed it for the main instance, but another instance on Multisite cannot have it. I wonder whether it comes from a mistake I made with /shared permissions… I rebuilt all containers, so it should work now.
On the failing instance I get
ActiveRecord::StatementInvalid (PG::UndefinedColumn: ERROR: column "collusion" does not exist
Clearing Active Record cache, this can happen if schema changed while site is running or in a multisite various databases are running different schemas. Consider running rake multisite:migrate.
Hm, I tried making an account on the linked site, but it didn’t work for me; I managed to make one on the site it redirected me to, but clicking ‘login’ on how.zoethical.com gives me this:
I’ll shift the migration around to the official method to see if that clears up the migration error; of course I didn’t test it on a multisite setup. In the meantime you can run the following to get the migration to go:
Alright, I believe I’ve resolved the multi-site migrate issue. The topic you linked me to seems to be working fine @hellekin, although if you grant me TL2 on that instance (or set the trust level setting for Collude to 0), I can play with it a little.