A continuum of functionality and data representation

Recently, while in a discussion in the Anytype alpha testing forum about whether "simple tables" should be supported, along with full database "tables", I had what seems like a potentially interesting idea. I think implementation may have some challenges, and I'm not sure I've described it well below. But this is hopefully enough to get the gist of what I am thinking about and tell me what makes sense and doesn't, what seems workable and maybe not. In short, feedback wanted!

A Continuum or Spectrum of Functionality

The Problem with “Simple” Tables in a Database App

Simple tables - by which I mean boxes and lines primarily for aesthetic purposes - are often very useful. They’re even available in markdown, and have had a place in many of the better editing and - to a lesser extent - note-taking apps to-date. But they have a little bit of a problem in the context of a database-enabled app like Notion or Anytype, which is that one could very easily enter useful info into such a table, initially just to organize it visually, and then later want to move that into a full-blown database, or even just do some calculations or other spreadsheet-like functions with it, even something as simple as dragging columns or rows around.

Converting Tables to Spreadsheets to Databases

This suggests some way to take an existing “simple” table and convert it, either to more of a “spreadsheet”, with e.g. calculation functions, column summaries, drag-drop column arrangement, etc., or even all the way to a full Notion-style Database, where each Row becomes a “Page” or “Object” of some kind. This sort of functionality exists in some form in a few apps, though Notion is not among them since it doesn’t support simple tables. In Notion you can paste in simple table content and it will become a database, at least, but this doesn’t allow you to take advantage of the, well, simplicity of simple tables themselves, and the potentially natural progression to a full database.

In any case, this is also only half of the potential equation, so to speak. It’s nice to be able to get your simple table to become something more powerful. But… what about the desire to take more complex data, like a full database, and represent it more simply? Maybe this is a limited use-case, but it was the seed of my idea: moving between different complexities of representation for information, not just one-way (from simpler to more complex), but both directions, and ideally non-destructively.

The Complexity Continuum

The phrase that came to mind when I realized the potential value of this was "a continuum of functionality or complexity” (or perhaps a “spectrum” rather than “continuum”), involving the ability to in some way move in both directions along it. A capability, or a whole bunch of capabilities, to go from unstructured data, to increasing amounts of structure and functionality, and back again if needed. I think this entire concept is an important meta consideration for the future of knowledge management and insight generation in general, too.

Examples

So for example, let’s say you start with a Simple Table. It has no functionality, no calculations, etc., it is purely aesthetic, and this is fine for a start. This is a useful thing to have. But then let’s say you realize you do want to perform some calculation or other data work on this information in this existing table. Ideally you could then very simple open the controls for the Simple Table Block that holds that data, and Convert it to a “Spreadsheet Block” or “Dynamic Table” or something. You could then do things like Sort, Calculate, and Filter. Then perhaps you eventually decide you now want to actually add lots of information and detail and formalized fields of data (relations) to the bits of info in your table, so again you use block options and convert it to “Table” (or “Set” perhaps) and it automatically creates Objects (pages) for every Row of that Table or Spreadsheet block, and replaces the prior block with an in-line Set view. Now all of your rows link to full pages, and each column becomes a Relation, etc.

Conversely, a non-destructive way to actually take a Table View of a Set (or a Spreadsheet block) and convert it to (or at least view or instantiate it as) a Simple Table could be really interesting and cool as well. I would imagine, due to the loss of significant functionality in the process, that you’d want it to output to a new block so as to be non-destructive. Perhaps it could even be a type of Block Reference for an entire database or view of a database: “Reference as Simple Table”. :thinking:

At a meta level this concept of being able to move along a “spectrum” or “continuum” of functionality while operating on the same/similar core data reminds me of some ideas and capabilities that the Fibery team is thinking about and working on. Initially those are outlined here:

And in ongoing discussion of their upcoming “blocks” functionality:

https://community.fibery.io/t/in-dev-migrate-entity-view-to-blocks/2005

And while I think it is important to think of it in the context of “tables” as I am doing here, it is also important to extend this to thinking about how all content can be used and re-used in such ways (things like block references, transclusion, etc., at the least).

But Why?

Going from simple to more complex seems fairly straightforward, it doesn’t involve “loss” of data, and the biggest challenge is probably just figuring out how to parse the source formatting and sensibly turn it into more and more structured data. Fortunately even simple tables have some clear structure to them, structure that very directly maps all the way to the sophistication of database tables. Notion demonstrates this well. But what about going the other way, from a database back to a simple table? And why would you want to anyway?

I have noticed in my own note-taking that sometimes there is a certain amount of friction to the very presence of the controls that enable more sophisticated formatting, even if I am not using them. I use and enjoy Obsidian for most of my note-taking, in part because it is so simple and “transparent”. If I want to format, I can just type formatting into the text (markdown), this is its own kind of “cluttering” but for me, at least, it does not seem to have the same cognitive load that some other tools’ approach to formatting and the like does.

WYSIWYG systems have their own advantages in terms of distraction, too, so it’s not all about formatting. That’s just one example I’ve noticed personally, and have seen others speak of as well. Controls for blocks in tools like Notion are another good example. Even when you’re just typing a bunch of text you sometimes can get distracted as your writing creates new blocks, etc. The block concept and representation itself becomes a distraction.

I describe all this because I feel the same can be true of representing information in tables. While Notion’s in-line table views have tremendous utility, I often find them “busy” or “cluttered”-looking, distracting even, depending on my intent for the page I am embedding them in. And I think others experience some aspects of this as well. It seems it might indeed be beneficial, at times, to be able to simply represent e.g. a database table in a more stripped down, simple-table-like format.

Now certainly you could have an option to “turn off controls” or enable/disable edit mode, while still maintaining it as a database view, so that’s one approach. But there are two others that to me seem more interesting to think about, even if they’re not the right answer(s). Perhaps they point in an interesting direction.

How it Might Work

Transclude with Options

One newly-revived approach to the need to have data in different places simultaneously, if not different forms, is called “transclusion”. It essentially means showing a single piece of information (text, etc.) in two or more places at once within a system, and generally when you edit it in one place (or the “original” place), it updates that data everywhere it is “transcluded” to. This is a term coined by Ted Nelson, which he implemented in his own “Project Xanadu” hypertext system decades ago, but it has seen a resurgence in recent years with Roam Research, RemNote, and others.

Now consider, if a table of any kind is a sort of “block”, an object that holds structured data, then surely you can transclude this. And in doing so, perhaps you can simply provide options for how you want that data to be represented in the target location. Perhaps this could allow for simply displaying a complex database table as a simple, non-interactive table. So rather than having to worry about dealing with destructive transformation of a source object and complex data into something simpler, you are just making a reference to it wherein you display that data in a different, simpler. This concept arguably has utility and value in other concepts as well, for example the difference between a link to a PDF, a static and non-interactive preview of that PDF (perhaps with a “gallery” view to scroll static pages), or an in-line, interactive view where you can e.g. select text, scroll pages, even annotate, etc. All representing the same source data, but in different ways.

Non-Destructive Object/Block/Type Transformation

Another interesting possibility is hinted at by Notion itself, I believe, which is that (if I understand correctly) you can turn one block type into almost any other without losing data. If the contents of your block maps well to the new block type, it will show up, but even if it doesn’t my understanding is the information in the fields for the block itself are maintained in the back-end. And if you were to transform that block back into the original type, that preserved data would return. Even if that’s not the case, it’s an interesting idea, and one that I think maps neatly to the concept I’m describing.

What if you could take a Database View in Notion and simply turn it into a simple table, non-destructively? It would keep all the database linkage info in the object’s back-end representation, and you could just turn it back into a database view at any time, if you wanted to. Now you might say well, why bother with that when you could just recreate a table view from the source database any time you want to. And yes table views themselves are in a sense a kind of example of what I’m talking about in that they are filtered views of more sophisticated data. But you can express so much complexity and customization in a table view, with filters, visible and non-visible columns, etc, etc. that I think there is value in being able to transform that table into a “simple” view, without editing, and then to transform it back if you ever need to actually edit it again, preserving all the filters, etc. that were in it originally. Recreating those can be non-trivial.


Anyway, that’s the idea, as best I can describe it. I think my example of tables-to-databases may not resonate or click with everyone. But hopefully you can see how this idea can also map to other representational concepts, views, object types, etc. The core of the idea is the ability to move from simple to complex representations and functionality and then back again, or perhaps to not even think of it as going “back” to simple, but merely as different ways of representing the same “object”, “block”, or data. That, if anything, is the important idea here.

Notion just implemented a nice “simple tables” feature that you can convert into full databases ~(but not, I think, the other direction)~~. So this is not surprising, but nice to see.
https://twitter.com/Notionatwork/status/1460385080581443590

Edit: and then I saw this! :grin:
https://twitter.com/gettindabucket/status/1460679296003891203

Edit: So you can go from Simple Table to Database and back to Simple Table. The caveat seems to be that if you add any info that is not compatible with simple tables, any non-text properties, or even if you just add any contents to the pages that are created when you convert to database (they start out blank), then you seem to lose the ability to turn it back into a simple table. Interestingly it does restore formatting that is lost on conversion to a table though! Here it is in action:

I understand why this limit exists, but at least with page contents it seems a bit unnecessarily limited. Pages can have child pages, and database pages are sort of children of a database “page” in Notion, so to my mind you could easily take a database and just convert it to a simple table with the pages and their contents simply becoming sub-pages of that page that now contains the simple table.

I’ll also note that this does not yet demonstrate the idea of instantiating a complex data structure (full database) in a more simplistic representation (simple table), which also potentially solves some of the issues with converting between them. Hopefully Notion or another team implement this.

I’ve just discovered Formable, which appears to be aiming at something rather like the above concepts:
https://formable.tools/
Click through for a really nifty little animation that neatly demonstrates the core concept here (brief snippet below).
formable-visual-metaphor