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”.
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.
[Edit] possible workflow to reference a block by its title:
Start a page reference by typing [[
Together with pages also blocks with titles are presented as options
Choose a block with title from the dropdown menu
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.
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.
Stay with this approach and update documentation properly, like in keyboard shortcuts section of Logseq
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
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:
Let the user find the block using @
Instead of pressing Enter to insert a reference to it, the UI indicates that entry has sub-options
The user use up-down arrows to navigate the dropdown menu (like now) and right-left arrows for sub-options
The user press → to see the properties of the selected block and browse them with up-down keys
The user press Enter to select the property and the following syntax appear:
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:
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 . I feel encouraged to start learning Clojure…
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.
pages (which do have an extracted title:: property (filename)
block with title (which do have the explicit title::property)
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.
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:
- title:: Alice
- title:: Title of a book
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.
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?