Microsoft Loop brings back Google Wave?(techcrunch.com) |
Microsoft Loop brings back Google Wave?(techcrunch.com) |
I used the publicly available fluid preview for a while and it is miles better using word for any kind of collaboration. I have since gone back to using Word for collaboration and I despise it. I feel like pulling hairs off my scalp.
I would say it is a competent new tool that gives you everything that notion did, while leveraging the kind of integration microsoft already goes well. The improvement is particularly noticeable not just because the product is good, but because what it replaces (word online) was so incredibly bad.
Disclosure - I would put a disclosure about my employer here, but don't want to be seen publicly bad mouthing another actively maintained product by my company.
IIRC wasn't it only "doomed" because it was such a resource hog people could barely use it? From what I remember the people who could get it working loved it.
> Loop components, “atomic units of productivity”
OLE! But for the web! Seriously anyone else remember when OLE was a thing and you could drop a print shop pro banner in Word, click it, and print shop pro toolbars would appear? (I think it was print shop pro, if not some similar bit of software, its been 25 years so my memory isn't perfect on this exact point!)
> Google Wave was clearly ahead of its time.
So were the million other attempts to do this over the years, but hopefully the experience will get incrementally better with each go at it our industry tries.
This is how progress happens, one step at a time. Learn from the past and make brand new mistakes that the next team gets to learn from.
The few of my friends that got in early couldn't do anything because there were so few others, and everyone else just forgot about it months later after the hype died down.
No idea why they keep doing this.
Limited invites can create buzz, Facebook did it well by inviting entire universities at once, that got around the problem of "no one else you know is on it."
Inviting purely random people to a collaborative system? Eh, not such a good idea!
"This is neat!"
"Yeah!"
"Wave!"
"That was cool."
"Yeah."
"K. Bye."
Nowadays you have Webpack and React and Node and all that stuff where you rarely get to be coding but most of the time you're spending at managing all those tools.
It also was a privacy nightmare. IMO it was just a test from Google to see how reliably this would work, I doubt they had the intention to let it run as a product.
But I really loved it.
Hell they tried remote RPC stuff and what, 30 years later protobufs comes along and everyone declare's Google's library to be LOL amazing.
TBF I've used both COM and protobufs (in the same team!!!) and and protobufs was 100x easier to work with.
But still, some of the those old ideas of MS were really good, just IMHO they were limited by the languages of the time. Programming in raw C or 90s C++ was hard enough as is, trying to add entire new technologies on top of that, eh, not nice.
And of course back then all software releases were big bang versions every 3 or 4 years and you to support all previous versions basically forever, so yeah, difficult limitations to create new technologies under.
Lots of good lessons to be learned though!
Their vision is that developers are creating these "smart objects" which you can then put in various places. You can have them in Teams discussion, Loop, Outlook email client etc. The contents is synced between users in real-time. Instead of passing links to various applications where the work is performed, you bring the work to (for example) Teams.
I think the more interesting aspect is the extreme coauthoring; it looks like the underlying tech is open source as well which is pretty interesting for a lot of applications: https://github.com/microsoft/FluidFramework
Notion doesn't have the multi-cursor live coauthoring feature though; that's new.
Do you know if the Fluid Framework is built on top of CRDTs?
Particularly, I'm interested in understanding customizability of Fluid components, integration with React, and any concerns about Azure service lock-in.
[1] "The Fluid Framework is a library for building distributed, real-time collaborative web applications using JavaScript or TypeScript." https://github.com/microsoft/FluidFramework
Notion, Airtable, and Coda always knew they'd have to deal with this at some point.
Still, the team has to be disciplined, or else Wave quickly became chaotic.
Sure this is wave. Sure this is notion.(which isn't the grandiose lightbulk product fans of it seem to think it is, not to mention its significance way overblown... you think Microsoft cares what hipster-designer/dev doc collab party you're in?)
The collaboration on any kind of docs/work is just natural and expected progression now. Anyone else just find this not that exciting?
But it's people. And it's tools. And it takes time for them to adapt and grow and old habits die hard.
Microsoft has taken 10 years to get to the point where its userbase may be ready for realtime collab apps that bring together multiple types of docs. We're talking about a userbase, and an age, where there is still tons of doc emailing and filename-ver-2-Copy.doc going on. Yes, lots of us have moved on from that thanks to perhaps more niche openness to new editing and sharing methods, Notion-heads, Figma jams, etc. But MS is just getting there now and who knows if customers will even end up using it since they've got other ways to collab in and out of the ecosystem on different scales.
But again, meh -- not that exciting. Just tools.
All in all I think Discord is better than either of them but I'll take Teams over Slack any day.
It's worth pointing out that Microsoft has let its OneNote product wither on the vine in recent years, ceding use cases and market share to competitors like Evernote, Bear, Craft, and even Obsidian. People have been asking for Markdown support and the ability to insert code blocks in OneNote for years; maybe Loop will end up being the de facto replacement and contain those features.
Someone actually took the time to write that doc page instead of implementing a basic editor feature...
[0] https://support.microsoft.com/en-us/office/find-and-replace-...
I'm still somewhat annoyed that major email providers don't support proper threading. I wonder why. Is it because email is supposed to be "easy" and threads are cognitively "hard"?
It was trying to be Reddit, Slashdot, HN, etc... a threaded forum post, instead of hypertext you could markup, annotate, or edit.
The fact that it is completely free and open source, tells you that it is a straight 'extinguish' which was rare but now they have gone and done just that (Again).
This is what 'extinguish' looks like with the new Microsoft.
Comparing anything that is not federated with Wave sounds odd to me.
Also, federated seems like the least important wave feature that people talk about.
The real time aspects, on the other hand, were pretty amazing at the time. From todays perspective the reverse might be true ;-)
It's a shockingly shameless clone of Notion.
As for the Wave comparisons, it's more of a technical comparison of the Fluid framework and Wave's real-time collaboration data model/editor, right?
It's kinda mindblowing that in $CURRENT_YEAR we're able to do run beautiful-looking ray-traced video games on a home console that costs a few hundred dollars, but when I launch Microsoft Word on a several-thousand-dollar MacBook Pro it takes over 8 seconds from a cold start (just timed it right now).
We've all just accepted that 8 seconds is an acceptable time to wait to type some words into a computer.
Great, can't wait to automate my cursor to look awake in meetings while being resting away from the computer.
The note taker takes the note, while other people queue up the topics to talk about next.
I'm not suggesting this is the best way to take the meeting note and I'm happy to hear about the alternatives, but it is reasonably usable.
It doesn't look gorgeous either. People wouldn't like to distract the meeting through the doc, which is projected to the large screen in front of everyone.
It works OK.
(Source: I was co-author of the original Google Docs implementation aka Writely; had some visibility into later iterations. I left Google in 2010 but have some idea of what went on subsequently.)
A year later they released Google Wave and Google Docs also got collaborative editing at some point.
Even then, Etherpad was not the first collaborative editor. It was just the first (to my knowledge) online one but I believe desktop ones existed for years.
And of course, the principle used behind collaborative editing (operational transform) is from at least 1989.
CRDT is the newer game in town now and it may replace OT entirely.
As a third party observer, I take it they both Google Wave and the collaborative editing in GSuite derive from Etherpad, and Etherpad itself is built upon the academic papers that predate it. If that is the case, while I’m sure some code may have migrated over, Google Wave “died” but Etherpad lives on.
Sure they took some of the pieces and reused them in other products, but Wave definitely died.
Now the only email is the one that gives the link to the online document.
GSuite might have some code from Wave, but collaborative editing came from existing implementations.
Google does this with a lot of their stuff, it seems, too. Google Glass, for example, spread into so much of Android and further: Ok Google for the Assistant came from Ok Glass; the timeline made its way into Google Now and eventually into Assistant again; heck, you can see the beginnings of Material Design in the Glass UI. Google makes a ton of experimental products only to axe them swiftly and put their remains into new products.
Comparatively, I'm much more excited about Automerge https://github.com/automerge/automerge, which promises much friendlier developer ergonomics as simple as:
doc1 = Automerge.change(doc1, 'Mark card as done', doc => {
doc.cards[0].done = true
})
https://fluidframework.com/docs/faq/#can-the-fluid-framework...
I think you have to consider your use case. If you want to build pure online collaboration tool it is fine. But if you want to build something that supports offline collaboration it seems not to be ready yet:
> Clients do have to be connected to the Fluid service. Fluid can tolerate brief network outages and continue operating but eventually the promise of being able to merge local changes weakens. We are investigating ways to improve this using other merging techniques designed to reason over large deltas but no final solution is in place today.
However, what I do like about their approach that they support multiple modern front-end frameworks from React to Vue to Web Components.
Straight from the README, but maybe there are other limitations:
"This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services. Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship."
That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is MIT licensed [0] and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage.
I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. Other open source backends[1] aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem.
[0]: https://github.com/microsoft/FluidFramework/blob/main/LICENS...
[1]: https://fluidframework.com/docs/deployment/service-options/
The key part here is the second sentence "Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines.". But there can be other such limitations also, just hidden somewhere else.
Sometimes I wonder how we got out of that era alive.
I can imagine someone could build a multiplayer game on this thing (though I doubt that's what MS designed for).
The tech for appjet was primarily Javascript server-side, and I believe it used GWT for Java->Javascript client-side. This was seen as very odd to many inside Google, as javascript on the server was a new concept back then, and a far cry from the "officially supported" languages for development at Google.
While the initial launch of Wave went ~okay, the product itself had massive scalability issues. The Appjet/Etherpad team was then aqui-hired and quickly relocated to Australia. While one would think they were acquired for the similarities between Wave and Etherpad, they were instead tasked with "fixing" the javascript server-side performance situation. This made sense to management as appjet had been pioneering the concept since before Node was a thing.
In the end this wasn't a great outcome for the acquired team, but is typical of the aqui-hiring Google does.
Doc and sheets later added comments and realtime collaborative editing, but it was all reimplemented and never directly lifted from Wave's implementation.