search

mui / toolpad

Toolpad: Full stack components and low-code builder for dashboards and internal apps.
https://mui.com/toolpad/
MIT License
1.29k stars 286 forks source link

Real-time collaboration #418

Open oliviertassinari opened 2 years ago

oliviertassinari commented 2 years ago

Duplicates

Latest version

Summary 💡

Make it possible to collaborate on the same page.

Examples 🌈

Motivation 🔦

This is similar to #348 but covers multiple editors. To be honest, seeing Webflow, Retool not having this feature, and how developers work in their own PRs, I doubt this is a feature developer would really want. But who knows, upvotes will tell us.

Janpot commented 2 years ago

I strongly believe most people look the wrong way at what's the benefit of real time collaboration. The big advantage really isn't about working in a document simultaneously. It's about having a single source of truth. About knowing that whenever you open the document, you're looking at the latest version, and having the confidence that when you're editing a document, your changes will be in there for the next person. It's about avoiding branching off and having to maintain multiple versions of the same document. I have bad memories of emailing around versions of excel documents and trying to merge back everybody's changes 🙂 . The fact that I see someone else's cursor move and realtime type is a nice gimmick but most of the time it's not practical working on a document simultaneously.

Retool not having this feature, and how developers work in their own PRs, I doubt this is a feature developer would really want

Tooljet, dynaboard and appsmith have it.

oliviertassinari commented 2 years ago

About knowing that whenever you open the document, you're looking at the latest version

Strong agree with this. Same in the GitHub PRs view that has a websocket to let you know that there is a new commit.

Tooljet, dynaboard and appsmith have it.

I would be careful with what was the rational behind their decision. Maybe they got trapped into the same thinking as of https://medium.com/@christian.dobbert/the-missing-bullet-holes-and-abraham-wald-25e68d7a870f. Maybe it was something among these lines for them: "Retool doesn't have X, let's differentiate by adding X". I think to never do. For us, it should be: "What is a core dimension of the problem that we can make x10 better?".

Janpot commented 2 years ago

Strong agree with this. Same in the GitHub PRs view that has a websocket to let you know that there is a new commit.

Yes, but merging conflicts manually is still a difficult process. the 10x better approach might as well be, "eliminate the possibility for merge conflicts altogether".

The implementations in appsmith and tooljet feel like they're an afterthought. They are indeed bad examples. Maybe we should rather look at google docs vs. word. Or figma vs. sketch? I may be wrong but I have a sense that their realtime nature is a great contributor to their success. Maybe the paradigm is only useful for editing documents?

prakhargupta1 commented 2 years ago

Maybe the paradigm is only useful for editing documents?

I guess so. A design/document has a lower threshold for anyone to contribute, hence collaboration is needed. But the same doesn't apply to building a production app. In the broader view of allowing collaboration. I see 3 options:

  1. Real-time commenting https://github.com/mui/mui-toolpad/issues/416: A user will be able to see others commenting and their pointer moving. Retool doesn't have this. Though it is possible through Cord: https://retool.com/blog/build-together-in-retool-with-cord-comments-and-annotations/
  2. Multi-user editing: Like the present Toolpad, Retool experience, and it is not real-time. https://community.retool.com/t/multiples-users-collaborating-on-the-same-app/3852
  3. Real-time multi-user editing: As discussed above like Figma/Google Docs. If this only for developers then the same purpose can be achieved through Git sync.

Priority wise: 1 > 3, but upvotes to conclude more.