I actually think this hyper-granular realtime collaboration like in Google docs is slightly overrated.
I think it’s ok to have more a git-like workflow where feedback and changes happen over cycles. As a programmer, I don’t give a shit about your working directory. I do care, however, about your commits :)
All I’m saying is this CRDT craze isn’t always necessary or even appropriate for many products. It adds a lot of technical complexity, especially for a small shop.
Realtime collab apps tend to kill their competitors without realtime collab. See Figma: slightly worse UX and performance compared to Sketch, easily killed Sketch. How did Notion penetrate the competitive docs/wiki market? Much more collaborative than the incumbent Confluence (now confluence is iterating on realtime collab to remain relevant).
Realtime is becoming table stakes in any online collab system. I think code is the exception, not the rule, because it’s 100x more brittle than prose or pixels that need to convey approximate meaning to humans.
You can implement realtime without using CRDT/OT, Notion is paragraph-by-paragraph last write wins, no fancy algo, but mostly good enough to remain competitive.
We used jira for live incident handling back in 2015 at a young company. It was horrendous. Multiple people would add roughly the same update at the same time. It wasn't until they refreshed jira that they'd see the duplicates. This led people to constantly refresh jira both before and after adding a comment. I still remember two people adding the same comment, refreshing together and both deleting their own comments after refreshing and seeing the duplicate. (Found this out after the incident during one of those "what could have gone better?" conversations). We switched very quickly to using Google Docs for documenting the live incident and simply attached that doc to the jira ticket at the end. It sucked badly and made a lot of people hate jira.
As soon as Slack became a thing at our company we immediately switched to using it for realtime incident updates, because Google Docs was unsuitable for a bunch of other reasons. And we wrote some automation around creating a jira ticket, creating a slack channel using the ticket name, and updating the jira ticket with a link to the ongoing incident). At the end of an incident when the jira ticket got moved to "resolved" the slack channel would get archived. Extremely simple and effective.
You are absolutely right. I am in the minority, no doubt. My POV is that standard corporate realtime collaboration is generally a waste of time, personally. Or at the very least, the results always reek of design-by-committee - inconsistencies and compromises. This is independent of tech, and I would say the same about the 2000s white boarding and mindmapping. Sometimes, there are cases where it works, like an 1:1 session with someone you can really vibe with. But even in those cases, it’s usually better with single-control (ie only one person editing at a time).
I’m perfectly fine talking about work on a high level, but when it gets too gritty it’s usually better to sit down in quiet and solve the problem or improve the design on your own. (Needless to say, I did not exactly thrive in a corporate environment.)
So to me realtime collab can be very neat, but it’s not a common enough use-case to be a dealbreaker. That said, there’s tremendous value in being able to easily view, comment, duplicate, copy the latest version that others publish, in read-only mode. Perhaps the success of Figma etc is partly also because of that?
> I actually think this hyper-granular realtime collaboration like in Google docs is slightly overrated.
I have to disagree. It's absolutely necessary for a lot of workflows, especially when people are collaborating on a doc in real time during a meeting (super super common), or when you've got 10 reviewers of a doc all leaving their feedback in comments, and comments responding to comments, over the course of the same hour.
The model of clean commits works well for code. It doesn't work well at all for business team documents that are in-progress.
Heh I’m glad that there’s disagreement. I think I was even surprised myself coming to this conclusion.
> It's absolutely necessary for a lot of workflows, especially when people are collaborating on a doc in real time during a meeting
Well yeah you included the solution in the problem description. I’m not convinced of either the shared control, the talking-typing multitasking or even that the artifact should be a document. Assuming the meeting shouldn’t have been an email in the first place.
> when you've got 10 reviewers of a doc all leaving their feedback in comments over the course of the same hour
This one is easier for me to argue concretely. Shared control with 10 people is awful imo. Suggestions with click to accept can make it better (but then you have a notification problem). But what I really dislike is this perpetual state of work in progress. I think a cyclic workflow is better, with drafts and publish and much less back and forth.
In summary, I’d say that the promise of async work (which is good) ended up being sync instead - for the purposes of the human brain. I don’t want to context switch because Bryan fixed a spelling mistake, or see Janice typing out another bullet point right under mine.
I agree. I haven’t yet interviewed a user that views realtime collaboration as something desirable in itself. In my research, user mostly are forced to do this kind of collab because it’s still better than coordinating via side channels such as email or phone. It has lower friction but at a very high usability cost. In contrast it makes people undervalue the importance of a structured plan of execution for projects with a significant number of collaborators. There are practically no polished, in-between, git-like experience in mainstream tools. The outcome of real-time for users is always remembered as messy and frustrating. I don’t even agree with the premise of shared control as being an effective basis for creative or productive process at large, it is useful for brainstorming and exploration in some specific cases, or highly specialized and niche settings like pair programming. IMHO this is super valued by developers and marketers because it’s challenging, cool and it makes for a good pitch. Not rare to see people who conflate digital collaboration with shared control, thinking they’re synonymous – such is the influence of these modern workflows. We can never know how good other collaboration strategies can be if alternative experiences are under-developed and people default to shared control.
> I actually think this hyper-granular realtime collaboration like in Google docs is slightly overrated.
Disagree, with the caveat that I understand how it can feel overrated if you're not using the new ways of remote collaboration that it enables.
The fully-live remote-collaboration UX in tools like Google Docs [1] and Figma is magical because you can get on a video call with people [2] and co-create, in the moment, without having to fumble with all the nonsense of figuring out who's "driving" and who's "navigating."
Since you're all looking at and editing the same doc, everyone can arrange their windows to have a line of faces along the side and the doc in the center. It's actually better than in-person collaboration. There's no haggling over who's got the whiteboard marker, no one sneezing on everyone else, no crowding around to make sure everyone can see the board...
All the extra nonsense drops away, and you get to be just a group of people making something together.
[1]: Notably, Google Sheets uses a much more ham-handed idea of "realtime." A cell appears "locked" while someone else is editing it, and you don't see their work until they hit Enter. So you end up having to sit there like a buffoon while they type, their work invisible to you, and that friction destroys the magic of live collaboration.
[2]: If you don't do much remote work/collaboration with others around the world, then none of this matters — and it's easy to miss the world of possibilities that this feature unlocks.
Has Nino integrated Git into their tools? Editing lines of code over a GitHub diff window makes sense, but I’m not sure how that would work in, say, a spreadsheet: I don’t know if adding a line =21%*G17 below G17 is a good idea; I’d much rather have the changes in the context of a sheet and understand that it’s computing the VAT on top of the total cost.
I think it’s ok to have more a git-like workflow where feedback and changes happen over cycles. As a programmer, I don’t give a shit about your working directory. I do care, however, about your commits :)
All I’m saying is this CRDT craze isn’t always necessary or even appropriate for many products. It adds a lot of technical complexity, especially for a small shop.