[seumars]

Although the tech behind Figma is nothing but impressive I find that the biggest downside to current collaborative tools is that they're expected to be used collaboratively at all times.

I would say that no more than 10% of the time I spend on Figma is for collaborating with other people in short brainstorming sessions, team workshops, etc. The other 90% is spent by myself working and polishing said prototypes, but still having to deal with the loading times, server hiccups, and so on.

An "offline mode" of sorts would also be a silly feature to expect since their entire stack is built around collaboration. Seems like a difficult balance.

[joeycodes]

Although there is not an officially-supported fully-offline mode, Figma does spend a significant amount of effort preserving changes made offline if the server disconnects and the tab is closed or crashes. Additionally, pushing out a newer version of the file format from N to N+1 requires a delicate dance between client and server to reload the file, upgrade the stashed changes, and merge. These and many other edge cases are handled as invisibly as possible to the user. A really fun edge case is if user A spends an entire weekend offline working furiously populating some page of a document, user B wonders why there's a seemingly empty page in the document and deletes it, user A comes back online and tries to apply changes to a parent node that no longer exists....

Disclosure: I used to work on some of this when I was at Figma.

[karaterobot]

Weird, I've used Figma pretty much every work day for four years, and only had a couple of server hiccups I can recall. No lost data, just an error message that went away pretty quickly. I've had my Mac crash more often than Figma.

With the Adobe purchase, I'm confident that'll change though!

[DANmode]

https://www.pcmag.com/news/doj-expected-to-block-adobes-20-b...

https://www.reuters.com/markets/deals/adobes-deal-acquire-fi...

All smoke?

[Cthulhu_]

I think instead of calling it collaboratively vs 'offline' is to use the terms reactive vs transactional; reactive means every change is instantly visible everywhere (think changing a configuration in MacOS), transactional is that you have to hit a save button (think file editors, Windows configuration).

I do think you have to be fully in on either one or the other. But collaborative tools are more difficult to do as transactional; that works with version control, but then it's up to the user to deal with conflicts. With reactive applications you have to deal with asynchronous whatnots and eventual consistency, although there's plenty of algorithms and technologies out there to handle that.

[thesuitonym]

At the end of the day, any software really has to choose what to prioritize. You can't have good online collaboration unless you design the tool around that--or I suppose if the documents folks are working on are incredibly simple.

Think of it like Excel and Google Sheets. Excel was designed for offline first, but Google Sheets always had online editing as a first-class citizen. Excel today has actually surprisingly great collaboration features, but it's sometimes buggy, and things don't always work the way you might expect. By contrast, Google Sheets is designed from the ground up to be online, and while you can save a file for offline editing, it doesn't actually put anything useful on your disk. Even if you have Google Drive, you just get a .gsheets file that is essentially a link the the document.

I guess where I'm going is, you just have to choose your battles. Be good at one thing, rather than mediocre at both.

[josephg]

I’ve been working on collaborative editing for the past decade or so. There’s no technical reason you can’t have both aspects work well. Eg, although git doesn’t support real-time collaborative editing, there’s no problem coming online and offline while working with git. Crdt based approaches should work online / offline just as well.

It may take extra development time though. The trade off of development time is real.

[cscheid]

Take a look at https://automerge.org/ and the stack those folks are building. You're exactly right that it's a difficult balance (specifically the trick is proving commutativity for the domain-specific data of your application). But automerge (and then https://github.com/inkandswitch/peritext) show it's at least possible. Good stuff.

[ax0ar]

It's still a trade-off many designers happily accept given the fact that it took so much longer to open Adobe's products and dealing with their sluggish programs.

You may argue and say why compare with Adobe? You would be right in that case, but it has been the gold standard in design for many years and set expectations on how design applications behave.

[crabmusket]

This is a big factor in the push towards CRDTs I reckon. They work offline-first, but allow both synchronous and asynchronous collaboration.

One of my formative early tech jobs was implementing a realtime whiteboard on top of WebRTC and CRDTs ca. 2015. It was incredible how easy it was to build new functionality, once the infrastructure was in place to "just replicate the scene at all times".

[rkangel]

Unfortunately collaborative software that works well is extremely hard. It needs to be their from the very foundation of what you're building.

[QuantumG]

It's a good idea.

[collsni]

Found the sucker