The data model behind Notion's flexibility
Not sure how &quot;unique&quot; 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>&gt; We came up with a frame-based approach. Most of the functionality particular to the various application types was packaged up into &quot;frames&quot;: 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>&gt; One related cool thing we had was a &quot;shared graphical context&quot; mechanism: sometimes, stuff would wind up being displayed in multiple frames at once. E.g., maybe you&#x27;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>&gt; There were some cool features that didn&#x27;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:&#x2F;&#x2F;groups.csail.mit.edu&#x2F;mac&#x2F;users&#x2F;bob&#x2F;clarisworks.php#onourown" rel="nofollow">http:&#x2F;&#x2F;groups.csail.mit.edu&#x2F;mac&#x2F;users&#x2F;bob&#x2F;clarisworks.php#on...</a> )<p>I&#x27;ve been kicking around the idea of writing a CRDT-based editor using this model.