Skip to content
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

Closed
wants to merge 6 commits into from

Conversation

epiqueras
Copy link
Contributor

Make the block editor real-time collaborative.

@epiqueras epiqueras added [Status] In Progress Tracking issues with work in progress [Feature] Real-time Collaboration Phase 3 of the Gutenberg roadmap around real-time collaboration [Type] Experimental Experimental feature or API. labels Jun 13, 2020
@epiqueras epiqueras self-assigned this Jun 13, 2020
@github-actions
Copy link

github-actions bot commented Jun 13, 2020

Size Change: -669 B (0%)

Total Size: 1.19 MB

Filename Size Change
build/a11y/index.js 1.14 kB -1 B
build/api-fetch/index.js 3.4 kB -1 B
build/autop/index.js 2.83 kB -2 B (0%)
build/block-directory/index.js 7.27 kB +50 B (0%)
build/block-editor/index.js 106 kB +21 B (0%)
build/block-library/index.js 129 kB -109 B (0%)
build/block-serialization-default-parser/index.js 1.88 kB -4 B (0%)
build/block-serialization-spec-parser/index.js 3.1 kB -1 B
build/blocks/index.js 48.1 kB +8 B (0%)
build/components/index.js 195 kB -86 B (0%)
build/compose/index.js 9.31 kB -2 B (0%)
build/core-data/index.js 11.4 kB -2 B (0%)
build/data-controls/index.js 1.29 kB +4 B (0%)
build/data/index.js 8.45 kB +3 B (0%)
build/dom-ready/index.js 569 B +1 B
build/dom/index.js 3.17 kB +1 B
build/edit-navigation/index.js 8.26 kB +5 B (0%)
build/edit-post/index.js 302 kB -82 B (0%)
build/edit-site/index.js 16.6 kB -23 B (0%)
build/edit-widgets/index.js 9.33 kB +1 B
build/editor/index.js 44.9 kB +100 B (0%)
build/editor/style-rtl.css 4.41 kB +140 B (3%)
build/editor/style.css 4.41 kB +140 B (3%)
build/format-library/index.js 7.72 kB -1 B
build/hooks/index.js 2.13 kB +3 B (0%)
build/i18n/index.js 3.56 kB -1 B
build/is-shallow-equal/index.js 711 B +1 B
build/keycodes/index.js 1.94 kB +2 B (0%)
build/list-reusable-blocks/index.js 3.12 kB +1 B
build/media-utils/index.js 5.29 kB +1 B
build/notices/index.js 1.79 kB -1 B
build/nux/index.js 3.4 kB -2 B (0%)
build/plugins/index.js 2.56 kB +1 B
build/primitives/index.js 1.49 kB -10 B (0%)
build/rich-text/index.js 14 kB -814 B (5%)
build/server-side-render/index.js 2.67 kB -8 B (0%)
build/viewport/index.js 1.85 kB -1 B
build/warning/index.js 1.14 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/annotations/index.js 3.62 kB 0 B
build/blob/index.js 620 B 0 B
build/block-collab/add-block-selections-rtl.css 263 B 0 B
build/block-collab/add-block-selections.css 263 B 0 B
build/block-collab/index.js 56.4 kB 0 B
build/block-directory/style-rtl.css 892 B 0 B
build/block-directory/style.css 892 B 0 B
build/block-editor/style-rtl.css 12.1 kB 0 B
build/block-editor/style.css 12.1 kB 0 B
build/block-library/editor-rtl.css 7.88 kB 0 B
build/block-library/editor.css 7.89 kB 0 B
build/block-library/style-rtl.css 7.96 kB 0 B
build/block-library/style.css 7.96 kB 0 B
build/block-library/theme-rtl.css 684 B 0 B
build/block-library/theme.css 686 B 0 B
build/components/style-rtl.css 19.5 kB 0 B
build/components/style.css 19.5 kB 0 B
build/date/index.js 5.47 kB 0 B
build/deprecated/index.js 772 B 0 B
build/edit-navigation/style-rtl.css 975 B 0 B
build/edit-navigation/style.css 974 B 0 B
build/edit-post/style-rtl.css 5.6 kB 0 B
build/edit-post/style.css 5.6 kB 0 B
build/edit-site/style-rtl.css 2.96 kB 0 B
build/edit-site/style.css 2.96 kB 0 B
build/edit-widgets/style-rtl.css 2.4 kB 0 B
build/edit-widgets/style.css 2.4 kB 0 B
build/editor/editor-styles-rtl.css 423 B 0 B
build/editor/editor-styles.css 423 B 0 B
build/element/index.js 4.64 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/html-entities/index.js 622 B 0 B
build/keyboard-shortcuts/index.js 2.51 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.28 kB 0 B
build/url/index.js 4.06 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

@epiqueras
Copy link
Contributor Author

gif

@epiqueras
Copy link
Contributor Author

gif

@epiqueras
Copy link
Contributor Author

cc @dmonad @mtias @shaunandrews @MichaelArestad @pablohoneyhoney

@MichaelArestad
Copy link
Contributor

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:

  • What options does the package come with?
  • Could the cursor be labeled on hover/focus to indicate who is editing?
  • Could each user get assigned a unique cursor color?
  • Could we show each of the users currently looking at the page? (perhaps as avatars somewhere to be designed)

const instanceKey = `${ id }|${ password }`;
if ( ! instances[ instanceKey ] ) {
const yDoc = new yjs.Doc();
const yDocPeers = yDoc.getMap( 'peers' );
Copy link

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

Copy link
Contributor Author

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly!

@dmonad
Copy link

dmonad commented Jun 18, 2020

This is awesome! 😍

This PR seems far more evolved than my PR. Should we close #18357 ?

@shaunandrews
Copy link
Contributor

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:

image

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:

image

Or, we could list editors somewhere else in Gutenberg's UI and use shapes along with color to help indicate who's doing what:

image

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?

@MichaelArestad
Copy link
Contributor

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.

@shaunandrews +1 The sidebar seems like a logical and familiar place for comments.

It would be nice to attach names to the indicators

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?

@epiqueras
Copy link
Contributor Author

What options does the package come with?

Right now, just "toggles" for enabling block syncing with peers, block selections and block comments as separate modules.

Could the cursor be labeled on hover/focus to indicate who is editing?

Definitely

Could each user get assigned a unique cursor color?

Yeah

Could we show each of the users currently looking at the page? (perhaps as avatars somewhere to be designed)

Yeah

This PR seems far more evolved than my PR. Should we close #18357 ?

Sure

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:

Yeah, I like that more too, this was just a faster way to test things.

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.

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.

I think the names might be better in genera, as theres no need to refer to the legend to know who's who.

Agreed

Perhaps we can fade-out the indicators if someone hasn't made changes after 30+ seconds?

Sure

maybe just showing the first 2-3 avatars in the top bar. If there are more, collapse the rest into a popover?

Yeah, like GDocs.

@enriquesanchez
Copy link
Contributor

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:

Screen Shot 2020-06-18 at 12 34 21

@mtias
Copy link
Member

mtias commented Jun 19, 2020

Instead, maybe there's a new Comment tool in the Tool menu:

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.

@jasmussen
Copy link
Contributor

@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.

@shaunandrews
Copy link
Contributor

is that you can show a list of avatars in the top toolbar

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.

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'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.

@jasmussen
Copy link
Contributor

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.

@chrisvanpatten
Copy link
Contributor

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.

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.

@epiqueras
Copy link
Contributor Author

Screen Shot 2020-06-22 at 7 03 14 PM

I added colors hashed from the user IDs and started showing the user's name on the margin of the document.

How do we feel about merging this experiment for other people to contribute?

@jasmussen
Copy link
Contributor

jasmussen commented Jun 23, 2020

How do we feel about merging this experiment for other people to contribute?

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.

@LionsAd
Copy link

LionsAd commented Jun 24, 2020

Nice work

Base automatically changed from master to trunk March 1, 2021 15:43
@retzion
Copy link

retzion commented Sep 1, 2021

I have not seen anything new on the add/wordpress-block-collab branch in over a year. What is the status? Will Gutenberg get collaboration support anytime soon? Thanks!

@anamwp
Copy link

anamwp commented Mar 28, 2022

This is very interesting.
Anyone working on this add/wordpress-block-collab branch.
I have not seen any progress since Sep 2021.
Anyone know any update regarding the progress of this branch ?
Me along with my team are ready to contribute to this PR and we have checked this.
Multi user functionality is not working for us.
Does this PR supported for this ?
Thanks.

@sinanisler
Copy link

I tried to build this branch but the build failed.
anyone can share the build version please ?
thanks

@sinanisler
Copy link

ok i managed to make a build. insntalled plugin.

enabled the experimental feature
image

but editor still behaves like normal wp editor. didn't allow multiuser editing same time.

did I miss a step or something?

@sinanisler
Copy link

looks like there was a dev server for websocket and it is offline now. :)

@prajapatisagar
Copy link
Contributor

Hi team,

I've reviewed the PR, and here are my findings:

Working fine with the old version:

  • Real-Time collaboration works on a single browser and with a single user.
  • Borders and the user's current type position are functioning as expected.
  • Inline comments are working correctly.

However, there are some issues that need to be addressed before we can merge this PR:

  • The code in this PR was developed using class components, but we have since moved to function components in the latest Gutenberg block. To make this PR compatible, we need to resolve the conflict and convert the code to support function-based components.
  • The default YJS WebSocket ("wss://signaling.yjs.dev/","wss://y-webrtc-signaling-eu.herokuapp.com/","wss://y-webrtc-signaling-us.herokuapp.com/") is no longer working. We should create our own y-js socket and add it here.
  • The PR only works in a single browser and is not compatible when we open it in different browsers (Guest or Incognito). We need to ensure the code works across all browsers.
  • The current implementation only supports a single user, and it locks posts while another person is editing, displaying the "This post is already being edited" modal. To enhance the user experience, we need to check if real-time collaboration is enabled and avoid displaying the modal in such cases.
  • The node version used is 12. We should update the code to be compatible with node versions 14 or 16.

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

@youknowriad
Copy link
Contributor

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.

@youknowriad youknowriad deleted the add/wordpress-block-collab branch July 19, 2023 11:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Real-time Collaboration Phase 3 of the Gutenberg roadmap around real-time collaboration [Status] In Progress Tracking issues with work in progress [Type] Experimental Experimental feature or API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.