Unifying pages and blocks

[jtrakk]

Roam and Athens: Boons and Pitfalls explains how having Pages in the model requires users to make an awkward choice between Pages and Blocks. The article proposes unifying pages and blocks into a single type and explains several advantages it would have.

What do you think about this proposal?

[leogao2]

I personally like this proposal - I've run into issues with deciding which level of abstraction of concepts are to receive a page and which are merely a block (square bracket linking is more convenient, but blocks are more convenient to navigate within a single topic), and by merging blocks and pages, this would be a lot simpler (not to mention this abstraction feels more elegant).

[aaronweewee]

Remnote does this and it simplifies and make things streamlined and reduces one layer of friction, it also makes embedding a lot easier. But from what I can tell, Athens is following the steps of LogSeq and Roam, so I don't think they will do this

[elliotsayes]

Author of the article here :)

I also doubt that Athens will prioritize this until it has feature parity with Roam. But I would point out that the proposed data model behind it is technically compatible with an exact clone of Roam, but would also allow more options in the future. Something to consider @tangjeff0 :P

[tangjeff0]

Haha most of Roam features we don't want actually :)

[jtrakk]

@tangjeff0 Can you elaborate on that, or is it written up somewhere? I've been hoping to switch from Roam to Athens as soon as it's available for my distro, but I'd like to learn more about the intended design differences.

[tangjeff0]

@jtrakk what features are mission-critical from Roam that Athens doesn't have?

[jtrakk]

@tangjeff0 My only experience with Athens is fiddling around in the demo app.

The big things I notice missing in 2 minutes are:

• Paste image from clipboard. Roam uploads and displays it.
• /file upload.
• Sync status indicator. Google Docs, Roam, and Dropbox have a little indicator light that says whether my changes are synced yet. Communicating system status accurately is really important to having confidence that my work is being saved.
• A lightweight query system. (a & b | c) | !f would be fine.
• I sometimes get "parse error" tool-tips appearing in the demo after I mashed the keyboard and typed a bunch of apostrophes. I don't know what it's talking about but Roam doesn't do that.

I can't check easily in the demo but I'd want to make sure that it's robust:

• Roam block actions (create block, move block) are sluggish on a page with a few thousand blocks and it's terrible.
• The search box should stay fast into millions of pages.
• Incremental deploy process with rollback. Deploy first to a small group, then incrementally increase. When you make some changes that break stuff, monitoring should be able to notice changes in the metrics and roll back before deploying to all users.
• Real-world latency monitoring. A few months ago Roam had an update that added a catastrophic-backtracking regex, and it made Roam unusably slow for several days -- not okay for users who consider it their second brain. See how Chromium does real-world performance monitoring.

[tangjeff0]

A few of your listed bullets are available on Electron, not on web demo: sync indicator and image paste.

IMO the 3 most important features Roam popularized were bidirectional links, block references, on top of an outliner. Most of the features many users ask for like /file are not fundamentally new or a different paradigm, just a faster horse -- expected features for a notetaking app. The two bullets you mention that are interesting/different are a lightweight query system and fast search into millions of pages.

In the short-term, we should just improve the core to be very robust and production-grade, as you mention. Stability, no data loss, and performance are the most important principles for a knowledge tool.

That said, there is still a ton of room for innovation at both the interface and data level that no one has really addressed yet. We've really only scratched the surface. The more robust we make this core, the broader and deeper Athens can be as a platform. That's what I'm most excited about!

[zhangxiubo]

I'd second this proposal. From a purest point of view, a page can be modelled as a named block/node.

As an example, when a user types in [[Athens]], a reference (e.g. ((abc123XYZ))) to the block whose "alias" attribute contains the value Athens can be inserted in its place instead; the UI then renders "Athens" as the text of the link.

[zhangxiubo]

The Streams plugin maintains a list of child tiddlers for each parent tiddler (a tiddler is the unified unit of content in Tiddlywiki). Each tiddler also has a parent field, though it's optional. Such data structures are used to implement a outliner in which each "block" is also a tiddler so there is no distinction between "block" and "page".

[zhangxiubo]

Disambiguation is a harder problem that I haven't solved yet. My current strategy is to maintain Wikipedia-style disambiguated names for each topic. There might be a better way though.

[elliotsayes]

@tangjeff0 what approach are you looking to take here? are you wanting to solve a couple of specific problems (instances of UX friction, homonyms)? Or redesign the app model around abstractions that better fit knowledge representation?

[tangjeff0]

@elliotsayes why is it an either/or? We want to want to improve both knowledge representation and UX.

[elliotsayes]

It's a fundamentally different way of approaching the problem, and the solutions you end up with will have different tradeoffs. So far the work done in (accessible) PKMs like Athens is the yellow arrow, starting from a familiar abstraction. The problem we are discovering is that there are inherint issues in this model, that are addressed by layering on bandaids for each one.

It's like trying to make a circle by starting with a square and repeatedly trimming the corners. You'll get closer to a circle, but to base your model on lines makes development tedious, and will never be perfect.

Taking the homonym example - this is a systemic problem in languages. The bandaid might be one of:

1. Namespacing system
2. Alias/disambiguation system

Either will be added complexity for the user, as well as a complication to the underlying app model. And expect to repeat adding complexity as new problems arise when scaling to, broader, deeper, highly interconnected and multiuser graphs.

The other way of approaching the problem would be starting from the left "unfamiliar abstraction" and building the pink arrow to make it more accessible. This way, the application model would perfect match the business problem (representing knowledge), and homonyms etc would only be treated as an interface problem, separate from the underlying model.

But that creates new problems: what is that "perfect model" (Hint: it may not involve text), and how do you bridge the gap ("simplify") back to something usable? Finally, by exposing more of that model to the user their underlying thinking will at some point have to "flick a switch" and adapt to its fundamental abstractions.

My gut feeling is that it could be too soon to try this approach, as there are still a fair amount of "complexity points" available before overwhelming the user, and PKMs haven't yet proven themselves as indispensable tools worth learning new abstractions for. On the other hand I see this decision as fundamental to the philosophical and marketing point-of-difference between Athens and Roam.

Thanks for reading my thesis lol

[jtrakk]

"The data model behind Notion's flexibility" is an interesting explanation of how Notion uses blocks.

[solarkraft]

Agreed. Pages are just thin wrappers around blocks. You can already zoom into blocks and make them essentially like a page.

Unifying the two concepts might also allow for scoping/nesting of pages, which relates to the namespacing issue I keep hitting a lot (e.g. an "Architecture" page for Athens, plus one about designing buildings).

That said some kind of linkability/the UX around pages should be preserved; I found keeping all my notes in a large tree in Workflowy/Dynalist fairly inconvenient, because clicking through the tree structure is a bit cumbersome. I appreciate Athens' quick search feature.

[tangjeff0]

How do you think the nesting of pages would look like for you @solarkraft ? I think I saw that LogSeq has this now

[solarkraft]

My current nesting approach is [[[[Topic]] Sub-topic]] (I was surprised it's possible!), before that it was Topic: Sub-topic. Both are not very convenient to reference and fall apart after a single layer of nesting.
My idea was that, like in programming, references to stuff in the current namespace could have the name omitted.

I never thought of namespacing like nesting pages, but it sounds like it could be a good approach.

But maybe all of this would be moot if the line between pages and blocks was gone, since I frequently find the choice between them difficult (and the choice is never really right).

In the spirit of your list, here's my interpretation:
A page is a block in a global namespace that has some bold text on the top node and is treated a bit differently in search and referencing.