Discussion: Unify pages and blocks

Feedback Feature Requests
25

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.

26

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…

27

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
28

Crosslinked bugreports:

29

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
30

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

CC @venture-comp

31

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
32

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

2 Likes
33

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
34

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
35

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
36

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

37

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?

38

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.

39

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

40

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

41

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

42

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.

43

Yes, intention is to just have blocks as atomic thought unit in the user interface.

It starts with the terminology: Instead of tag (which is only optical nature), page, page reference, block, block reference etc, I really would like to just simplify terms to “block” and “block reference” aka link to a block.

Btw: wouldn’t it be a great idea to call this app “Blocks”? Nice and simple to remember. Drifting off here… :wink:

Main points in this request are to remove page-tags, page-property ambiguity and fix the link reference filter (bug reports). It also would be cool to use it as umbrella post for further discussion about general page-block-unification ideas.

@alex0 Option to treat specific blocks as pages reads like you are only proposing changes to the GUI graph widget by displaying blocks with their title:: property. Having read ongoing discussion, I think, you also mean to have block references as first-class citizens in the app in general, don’t you? So querying block references similar to pages now, displaying blocks by ::title as node in the UI graph, etc.

That indeed would be nice - and probably more far-reaching long-term - request. In a first step we could keep status quo, and consider only “root blocks” (former pages) to be queryable and displayable in the UI graph widget.

Also: As logical consequence, wouldn’t that imply, that we could have one syntax [[]] (or (())) instead of two for block references? If everything in UI becomes a block, we don’t need to differentiate between page references [[]] and block references (()) anymore - would appreciate that!

IMO this is an internal implementation detail of how to provide technical IDs for blocks in the storage. I.e. it shouldn’t matter too much from UX point?

Without going into too much detail I would prefer:
All relevant blocks get technical IDs in form of UUIDs (including root blocks aka todays page, which currently have their title as ID). Hence no worries about duplicate titles when referencing blocks.
The first line of a block is its default title, with reference to following comment:

::title could be a replacement for default block title. But I wouldn’t see it as flag for whether to display the block in the UI graph widget. What about a block property display-in-graph: true?

44

I could have made it more clear, but I didn’t mention the graph view but the graph i.e. the structure of pages/tags as a concept.

I don’t see a good reason to change it and at this point there should be a very good one to make such a change.

Maybe a general purpose menu that appears using @, that search through pages, blocks, commands, templates etc and that paste the right syntax would be better.

I don’t like this idea of unifying pages and blocks because they are elements of two very different structures:

  1. Pages are connected together in a graph, there is no hierarchy.
  2. Blocks have a hierachical structure, they are trees and each tree has a page as its root.

We cannot have all blocks as nodes in the graph, I hope it’s clear how much inconvenient it would be…

Here there is why Tana is different:

  • In Tana the nodes are generally short strings, like records of a database. Long paragraphs, though possible, don’t take advantage of Tana.
  • Tana is basically a database with short strings of text as records but those records are also into a tree structure.
  • In Logseq it is common to place whole paragraphs of text in a block.
  • In Logseq there are multiple trees starting from each page.

So, if we want to be able to organize nodes in trees like Tana does, we have to be able to instantiate a node from a block and not only by creating a page.

Instead, if the issue is inconsistencies between pages and blocks when it comes to queries and other features I totally agree that pages and blocks should be treated in a more consistent way in the UI.

But I’m totally against unifying blocks and pages as concepts to enable a more Tana-like approach in an application like Logseq that among the other thing handles long paragraphs of text.

That said, I suggest to close this feature request since it seems confusing and instead focus of two things:

  1. Discuss how to enable a more Tana-like approach, including my proposal of using title:: properties.
  2. Find the inconsistencies between how pages and blocks are handled in the UI and discuss them one by one.
1 Like