NOTE: This project is decidedly beta at the moment, and I am posting here in order to garner some willing souls to help me test it out and let me know whatās rough and what I should improve next.
Now, users with sufficient trust level (default is 2, configurable in the settings), will be able to click āCollaborateā and get an editor to modify the post in real time.
This looks pretty cool! I had a quick skim of the repo and canāt see any external dependencies - is that correct? It just implements the āEasySyncā algorithm in Discourse?
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 like the fixes - thank you! I can see this being very useful in my community, especially when we are in one of our many webinars or video conference calls and taking notes collaboratively.
Bummer about not being able to replicate the āreplyingā¦ā feature. That way weād know itās worth jumping in to collaborate, and once in collaborating weād know whoās collaborating with us.
Iām currently installing it. I will report soon If others already use it though, Iām interested to know as well.
First Report
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?
Note that when I click āEditā, I get an empty post although the sentence āThis is a collaborative editor.ā is written in the topicās first post.
Let me run rake multisite:migrate since a log is complaining about itā¦
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
and
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.
If others already use it though, Iām interested to know as well.
