Discussion: Unify pages and blocks

From a discussion on Discord about Tana’s “everything is a block” approach I think we have some ideas.


Issue: in Logseq pages are at the same time the “root blocks” and nodes in the graph, plus they have additional UIs like filtering references. When we want to create a node, we are forced to create a page and so a new “root block”.

Solution:

  • Treat the title:: property as a special one for blocks.
  • When referencing a block (still using its ID) provide an option to display its title instead of its content so that it looks like a page reference.
  • Provide an option in the graph view (like “display journal pages” that we have now) to also display blocks that have a title:: property and render them as their titles (like pages).
  • Provide the UI needed to fill the gap between pages and blocks, for example filter references of a certain block.

I know that you can already consider the first line of a block as its title but it could get in the way i.e. you may not want every single block to be treated like a node/page. So let’s make it optional by requiring an explicit title:: property.


Thanks @Joe_Smoe for testing Tana and provide useful insights.

What do you think @venture-comp @Didac ?


[Edit] possible workflow to reference a block by its title:

  1. Start a page reference by typing [[

  2. Together with pages also blocks with titles are presented as options

  3. Choose a block with title from the dropdown menu

  4. The block is reference with some kind of syntax, for example:

    - This is a reference to [title::](((1234-5678-90123)))

and rendered like a link to that block but replacing title:: with its actual value:

- This is a reference to Title of the Block.

At the moment you can already create a link to a block with custom text with [text](((ID))) but with the above syntax we wouldn’t need to manually update “text” because it would be dynamically rendered by looking at title:: value.

2 Likes

That sounds really cool! Thanks for the effort @alex0 .

I see one potential issue for newcomers: block-references have always been started by (()) and page references [[]]. Now with the change [[]] is page or block, (()) block-only. It might be harder to remember, which syntax you actually need to use.

Two possibilities:

  1. Stay with this approach and update documentation properly, like in keyboard shortcuts section of Logseq
  2. Change to one main syntax [[]] and keep (()) for backwards-compatibility as block-only

Ad 2) This would be my preference. [[]] might list entries filtered by auto-complete and first prioritized by pages, then blocks with ::title, then ordinary blocks.


Should I still create bug reports for the two described issues in OP

  • #1: Simple queries should look at page-tags too when looking for a reference
  • #2: Fix inconsistencies with link reference filter between page and block

or are they already contained in

?

This is an issue in general, in my opinion Logseq needs an all-encompassing menu (maybe triggered by @ since most people are used to it from social networks) from where you can select everything: pages, blocks, commands, templates etc. Then the right syntax, that being [[]] or (()), appears.

To reference the value of the property of a block, why not:

  1. Let the user find the block using @
  2. Instead of pressing Enter to insert a reference to it, the UI indicates that entry has sub-options
  3. The user use up-down arrows to navigate the dropdown menu (like now) and right-left arrows for sub-options
  4. The user press to see the properties of the selected block and browse them with up-down keys
  5. The user press Enter to select the property and the following syntax appear:

[key::](((ID)))

that since it’s a standard Markdown link it would be rendered as key:: in other editors, but in Logseq, when the block is unfocused, it would be rendered as value, where “value” is the value of the key of the specified block.

This could be useful in many scenarios, not only with title::, for example to render something like status:: Active or counter:: 48.

Same with pages but the syntax used would be:

[key::]([[Title]])


I’d report them because maybe they could be easily fixed soon. About the #2 though, I think it could be obsolete in future since when I explained to the designer the idea to re-use the future query builder UI for those filters he welcomed the idea.

That all are very good ideas, I feel the need they are organized in an updated roadmap.

Also high on my wishlist: “Object types” (don’t know if there is an official term) to express, some block/page is an instance of another reference and inherits all property declarations. Example: [[Person]] has properties age::, name::, [[Author]] has property books:: and extends [[Person]]. [[Don Joe]] is [[Author]], and has properties books:: XY, age: 45, name: Don Joe.

Then being able to render this quickly as table, canban card layout etc. If I remember correctly, these are calleld “Super tags” in Tana.

At least there are enough ideas to spend the $4.1 million effortless :joy:. I feel encouraged to start learning Clojure…

As far as I know the current roadmap include:

  • Sync (currently in beta)
  • Whiteboards (currently in alpha)
  • “Properties 2.0” (initial code in enhance-properties branch, it includes cardinality, type, range and description for properties, it could be preparatory inheriting properties you just asked)
  • Query builder
  • Make the UI/UX more consistent

Yeah it’s what Tana calls “supertags” (bad name and bad idea to use hashtags to assign them, in my opinion).

This is a common concept in Object Oriented Programming, they are called “classes”, the ones that inherit are called “subclasses of” and the inverse relation is “superclass of”.

Different ways to render query results is something the team is interested in too, as far as I can tell.

3 Likes

Crosslinked bugreports:

I principally agree on most of these arguments. Despite being a heavy and dedicated user for a long time now, I’m still having issues discriminating between pages & blocks.

Removing this has the potential to simplify most of the use case scenarios. Not sure what we will lose though? ie: The graph only shows pages…

2 Likes

Here there is my proposal to treat certain blocks as pages:

CC @venture-comp

Thanks for the write-up @alex0.
Personally I would like to see some performance improvements for the graph first, (main reason why I currently use it rarely). It seems to cause high CPU idle load.

1 Like

I agree with this post. Pages should be “just another kind of block” (one that happens to live in its own file).

2 Likes

I think this is exactly not what you want. Now you add another type of ‘block’. If you add the the title:: properties you are in fact creating a third type.

  1. pages (which do have an extracted title:: property (filename)
  2. block with title (which do have the explicit title::property)
  3. block without title (no title:: property at all)

What would be the gain in that except complexity? And yes I read about the ability to have blocks with title in the graph view. Not an extremely big advantage in my book with the possibility we currently already have to create a page from a block and automatically reference it. That is in fact what you want and what you already can do.

I thought the goal was to simplify and make everything work as much the same as can be … lose the tags vs page-tags and properties vs page-properties and the inability to show pagename when searching for properties (at least in simple queries).

For me the title of a page is like a first block in that page and every page can have only 1 first block and 1 only. If that structure would be used in files you in fact have only blocks?

You also mention in this discussion that it is not doable to see the path to blocks that have the same name. But I would really love that. Look at Trilium Notes that have cloned notes that can be shown in multiple places/pages. References does that but I would like to see all path’s for blocks with a certain name.

I am technically not very experienced but in most cases I think less options instead of more is the way to go. Rather a simple setup that can be used complex instead of a complex setup that can be use simple.

Thanks for the discussion … interesting read.

1 Like

At the moment pages are “root blocks”, so they can’t be organized in the structure blocks have thanks to indented lists.

In Logseq you have a network of pages, connected together by references made in their children blocks; in addition each page has a tree of children blocks, so another structure that is not linked to the former.

At the moment if I want to add a node to the network above, I need to create a page i.e. a Markdown file.

I’m saying it would be useful to let us define new nodes of that network using blocks, so that they can be organized hierarchically in a single page using indented lists.

Let’s say I have books and authors but I don’t want a page/Markdown file for each of them; instead I want all of them to be stored in Books.md but still retaining the feature of pages:

Books.md
- title:: Alice
  id:: 1234
   - title:: Title of a book
     author:: ((1234))

as you can see I can organize nodes using an indented list.

The point is not only appearing in Graph View, but also use queries where I can look for “Alice” as author (at the moment queries can’t handle block references; Edit: you can use "((...))" in queries, but I would like if this was better supported, for example in future Query Builder).

This is basically the difference between Tana’s “nodes” and Logseq’s blocks & pages.

1 Like

I also agree with the OP, I think pages and blocks should be more interchangeable. The existence of a “block to page” plugin is a sign of this.

Why not reference pages with ID in the same way as blocks, and use aliases as labels, like in Wikidata?

1 Like

Sorry but this doesn’t make any sense to me. [[wikilinks]] are much better than ((1234-5678-9012-3456-7890)).

But if you change the title of a page, links to that page are broken. With a neutral/persistent ID You do not have to rewrite the anchor links referring to the page, or using a redirection system to keep track of every link text change.

As the original poster said, the filesystem persistence layer is leaking into the UX.

When descriptive titles and references are conflated, page titles seem more suited for standardized keywords and terms, not for title texts subject to change.

In which cases are wikilinks preferable? For editing content in plain text editors?

The point of Wikidata is also that you assign an ID to a concept, then you can describe the concept with labels in multiple languages. This reminded me of the alias feature in Logseq.

In Logseq renaming a page result in an automatic edit of all the pages referencing it, so what are you trying to solve?

Referring to pages/blocks in other graphs?
I think a reference should contain both a persistent ID and a human readable description.

But it’s not what we are discussing here, it would be another huge topic.

If automatic all pages are edited to reflect the change in name of page being referenced that automatic change is an edit while I did not edit that file. So you’re recent changes are incorrect now.