-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Collab: New package, a framework for collaborative editing. #23129
Conversation
epiqueras
commented
Jun 13, 2020
Size Change: -669 B (0%) Total Size: 1.19 MB
ℹ️ View Unchanged
|
To test, enable the "Collaborative Editing" experiment. It worked like a charm on the first try with multiple windows open. @epiqueras I have a few questions:
|
const instanceKey = `${ id }|${ password }`; | ||
if ( ! instances[ instanceKey ] ) { | ||
const yDoc = new yjs.Doc(); | ||
const yDocPeers = yDoc.getMap( 'peers' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest using the Awareness protocol instead for showing who is currently working on the document. https://github.com/yjs/y-protocols/
It is a dedicated CRDT for sharing awareness data. The advantage is that it automatically detects when users are offline and that it does not leave any traces in the Yjs document (in the log of changes). You can also have a look at the other editor bindings to see how they make use of the Awareness state. E.g. y-codemirror
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, got it. So I would use setLocalStateField
to set the cursors and getStates
to read them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly!
This is awesome! 😍 This PR seems far more evolved than my PR. Should we close #18357 ? |
Well... this is impressive. The commenting systems is a great addition, and I like that comments are tied to blocks. But I'm not sure having a new button in every block toolbar is the best way to go about it. Instead, maybe there's a new Comment tool in the Tool menu: Though, I do worry a little about ending up with a Comment highlight indicator on every block. Perhaps a plugin-like sidebar would be better? You could open the sidebar, and then it would list all Comments in the document. If you click one, the block highlights in the canvas, and you see the Comment UI floating near it so you can respond. -- It would be nice to attach names to the indicators, and maybe introduce colors; Something like this: Or, we could list editors somewhere else in Gutenberg's UI and use shapes along with color to help indicate who's doing what: I think the names might be better in genera, as theres no need to refer to the legend to know who's who. Perhaps we can fade-out the indicators if someone hasn't made changes after 30+ seconds? |
@shaunandrews +1 The sidebar seems like a logical and familiar place for comments.
Right. That's why I was asking about the colors and names for indicators. It would be good to show names on indicator hover along with avatars/names/colors somewhere else. I'm not sure about them being in the breadcrumbs toolbar. It's so rare, maybe just showing the first 2-3 avatars in the top bar. If there are more, collapse the rest into a popover? |
Right now, just "toggles" for enabling block syncing with peers, block selections and block comments as separate modules.
Definitely
Yeah
Yeah
Sure
Yeah, I like that more too, this was just a faster way to test things.
I think the sidebar and only showing highlights on comment selection can be suitable for resolved comments that need to get out of the way. But, active comments would get lost too easily. It's good to see the active highlights because it reminds people to resolve all comments before publishing. Perhaps, we should only show them while in the "Comment" mode, though, to avoid noising up the editing experience too much. We should still show an active/resolved count somewhere.
Agreed
Sure
Yeah, like GDocs. |
This is really cool 🙌 I agree that having comments on the sidebar would be best. I can see having an additional icon next to 'More tools and options' that opens a comments sidebar. I also think showing user presence should be more prominent and easier to spot. I thought about having them on top floating slightly above the toolbar, considering that need to accommodate for the top toolbar and narrow widths: |
I agree, the tools menu is underutilized. @jasmussen also did some designs for collaborative editing a while ago that might still be relevant, including the avatars on the toolbar. |
Emphasis "a while ago". It's in #3741 and maybe you best not look 🙈 😅 The take-way, if anything, is that you can show a list of avatars in the top toolbar, with a small color band at the bottom, and that same color band is used to indicate the block being edited. I would avoid floating the avatars in the canvas, but instead force the top toolbar (if enabled) to stack. I'd also be careful in choosing a palette of beautiful colors to use for this — I or @pablohoneyhoney can help here. Finally, it's worth trying to use a solid line rather than a dashed one, and showing it not-outside the block but in the same way as focus styles are shown at the moment. |
I'm hesitant to put so much focus on avatars when I expect that most WordPress users won't have one. It seems like focusing on showing their Display or User name along with a color — both shown directly on the canvas — would be the best option.
💯
I'd be fine keeping it consistent with the focus styles, but one concern I have is that with blocks like Image the colored border is very easy to miss. |
Keeping it flush is mostly about the complexity it avoids, which is the complexity we thankfully managed to reduce with G2. You could presumably tinker with the border width — it's okay that it's a different border width (and yes style if we have to), so as to actually shape-distinguish from focus, which it isn't. |
This is definitely true, and I don't disagree, but I do want to note there is an effort to add an avatar upload (separate from Gravatar) to core which has gained some traction, potentially for 5.5. So it might not necessarily be viable now, but could be in the future. |
If we do get this in, one of the first followups should be a PR to refine the "user is editing" border style. Merging and iterating is fine when we remember the iteration step — the dashed line and colors used is the only weak point in an otherwise beautiful PR! I have a bit on my plate, otherwise I'd be happy to help. |
Nice work |
I have not seen anything new on the |
This is very interesting. |
I tried to build this branch but the build failed. |
looks like there was a dev server for websocket and it is offline now. :) |
Hi team, I've reviewed the PR, and here are my findings: Working fine with the old version:
However, there are some issues that need to be addressed before we can merge this PR:
I have a question regarding the implementation using WebSockets. According to the guide (https://make.wordpress.org/core/2023/07/03/real-time-collaboration/), WebRTC doesn't require any extra setup on the server. Do we have any plans on how we're going to handle this? We can start working on resolving the above points to ensure the PR is ready. Your thoughts and feedback on these changes are welcome. Thanks |
Hi @prajapatisagar Thanks for the review there. Actually, the exploration have moved now to this PR #52681 That was a good reminder to close this PR though. |