Not sure how "unique" this model is; for example Claris Works was built out of an even more powerful block model (they called them frames) back in the late 1980s:<p>> We came up with a frame-based approach. Most of the functionality particular to the various application types was packaged up into "frames": word processing frames, graphics frames, etc. These frames were then used as building blocks to make documents of the appropriate types, in a unified programming framework. E.g., a word processing document was essentially a bunch of text frames, one per page, linked together. (Doing this neatly was a big challenge - many subsequent efforts at building a component-based architecture (e.g. OpenDoc) have failed to take into account the top-level user interface requirements.) The result was that not only was most of the code shared across the document types, but the application was also truly integrated - the frames could be embedded in each other. E.g., you could plop a spreadsheet frame right into your word processing document. Text objects in a graphics document had a full-featured word processing engine behind them. The database form editor used the built-in graphics environment. Etc.<p>> One related cool thing we had was a "shared graphical context" mechanism: sometimes, stuff would wind up being displayed in multiple frames at once. E.g., maybe you're dragging an object across a page break in a document with multiple pages (like this). We developed a general architecture for displaying actions live in multiple contexts. Of course, a lot of this kind of stuff is old hat today, but it was new and exciting in 1989. Some creative programming was required to do these things efficiently on the hardware of the time.<p>> There were some cool features that didn't make it into the shipping product. For example, originally spreadsheet formulas were much more powerful: you could relate, e.g., graphical object positions and document properties to spreadsheet cells. So you could have the result of a calculation move objects around graphically, or vice-versa. (Further work in this direction led to a novel constraint-based programming paradigm called MOOSE, which I may resurrect some day...)<p>(From <a href="http://groups.csail.mit.edu/mac/users/bob/clarisworks.php#onourown" rel="nofollow">http://groups.csail.mit.edu/mac/users/bob/clarisworks.php#on...</a> )<p>I've been kicking around the idea of writing a CRDT-based editor using this model.
I've not used notion before and this is a great write up...<p>Having built my own private-ish collaborative editor/note/todo/sharing/pm tool back in 2012 (that uses indent level permissions) I don't see how you could have a non "block" implementation?<p>I also don't see how they are having so much performance difficulty moving up the inheritance tree at the client level?<p>Does anyone else who has worked on these kinds of problems take a different approach? This being HN and a space I develop in I am actively curious if any other architecture are in use generally?<p>Are there approaches outside of blocks for tools with this level of granularity?<p>Really cool of Notion to share these kinds of "inside ball" deep dives.
Notion is clearly a feat of engineering. The first time that you modify a link name, and it is automatically modified in all others connected users whether it is in the menu, inside a document or wherever it is. You are just impressed. You can also drag and drop links from a document to a menu.<p>I'm just worried that so much engineering complexity is going to make things slow to move. We will see in a few years if that was a good idea or not
Salesforce and JIRA both did something similar: their underlying database schema is very generic, basically keys and values, allowing arbitrary logical schemas to be defined at runtime. Yet in both cases, they ended up not really taking advantage of this flexibility. The logical schema of both systems is a very ordinary relational schema that could have been implemented directly on the database, with much better performance. I wonder if the Notion developers made a serious attempt to build on top of a more conventional structured schema, and found it really was unworkable?
Been working with multiple document API's recently for my start-up. It's been a real challenge to understand how different document stores compare -- Confluence uses undocumented XML markup that "mostly" mirrors HTML, Google Docs gives you sometimes semantically-incorrect HTML with lots of inline styles, Slack has its own funny Markdown, etc. Then there's Notion blocks. I had to write my own HTML-to-Notion block parser, but I think I prefer working with it over everything else because structured data is just easier.
One interesting gotcha: if you want to completely overwrite a page you currently have to remove every content block one at a time, and then add each new line one at a time. This is using their undocumented API, but the new API doesn't even offer deleting content yet. I'm eager to switch over but it may be a while...
This is a great explainer on how and why Notion is so powerful, and certainly helps explain why it doesn't feel like the fastest tool (because it's inherently more complicated and more powerful than most).<p>I've tried using it for personal notes but it's speed and lack of offline prevented me from migrating to it. But I think it's the best choice for any organization that needs a collaborative docuement/wiki/Confluence-esque tool.<p>Not to mention that I think it has the best default fonts, spacing, and general aesthetic of any tool I can think of.
Notion clicked for me when I realised that everything is a "page with some attributes". Blocks are interesting at the engineering level, but as a user I found I was normally thinking at the level of pages.<p>Each page is some content (optional) with a set of arbitrary attributes of different types, e.g. date, string, number etc. When you create a table and populate it, you are creating a set of pages all of whom have the same attributes and the table is just a view of those pages. You can then create a calendar that's a different way of presenting those same pages. You can also deal with those pages directly and put content in, and reference them from elsewhere.<p>It's a really simple data model, and it's pretty flexible. We built all our processes on Notion initially and then moved them off when they got to an appropriate scale. I'm glad the API exist now, because then that approach can be incremental rather than a wholesale move.
All the ways of displaying things - tables, calendars etc. are just displaying collections of pages.
As author of a Notion browser extension,
"everything is block" concept made it significantly easy to understand the notion doc structure and tweak the UI to add multiple customisations on top of it. For instance showing a fixed static ToC, etc.<p><a href="https://gourav.io/notion-boost" rel="nofollow">https://gourav.io/notion-boost</a>
I think the power of Notion became apparent to me when I created a Page, accidentally changed it to some other type, then ctrl+z-ed it back to a Page, with all its contents intact. Seriously impressive. I wish search wasn't so crap though.
Notion is great for about a month, then the glacial performance and forced-hierarchical structure really start to grate. But by that time you’ve already bought it
Notion is cool but I went back to trello because its so damn slow. The ios app would refresh all the time and fail to sync. The web app was generally buggy.
It's always nice to learn how tools implement this. Especially interesting to me, because I am currently working on a similar tool, although more focused on the plain text aspect (think Markdown + widgets). I am facing slightly different challenges because widgets have to live in a plain text context. For instance, having a widget (say interactive diagram) as part of a Markdown blockquote. On the other hand I don't have to deal with nested blocks (yet), because regular Markdown elements are just text (with fancy styling though). Another challenge is something like $a+b=c$ where it is shown as rendered LaTeX when the user's caret is not touching that part of the document. Also, contenteditable is hard.
Is there a reason why you did not use rdf for representation and some rdf aware encoding like jsonld for serialization?<p>Would be significantly easier for others to work with, could easily query it with SPARQL.
I used a similar approach when working on an editor/notes taker in Flash. Worked quite nicely but even back (early 2000s) then it wasn't really a new idea.
Great write up.<p>I have a requirement to allow users to create adhoc tables within a web application. I was wohoe beat to represent this on database. Any thoughts?
you start a blog post with Engelbart, Nelson & Kay and you have my attention. At last someone who understands where the whole field of digital HID was started.
I liked the part where they talked about the blocks with the blocks and the block blocks and how they all block together.<p>I thought the reference to field pioneers was a bit much, I wouldn’t have the blocks to do that with a straight face. I wish these app makers (see also Figma, AirTable) would refrain from making their self-aggrandizing “we’re bringing computing to the masses”; what a load of blocks. What you’re doing is creating a product (another silo in waiting) serving a market that presently is interested. This block model is also not unique (see WordPress and Drupal): Notion may be refining some of that in a more seamless experience, but this is a different kind of statement. Perhaps “we added collaboration to blocks” would be a possible claim for uniqueness.<p>Aside from this, I found the technical decisions interesting and worth a read.
I tried notion several times and gave up. It is not as good as excel or google sheet. I want the data table view to be as powerful and efficient as google sheet or excel plus other notion views. Right now, it is very difficult to even style the the cells with different colors. I think it will be much better for existing google sheet to add other notion functions. Don't know why google stops innovating.