Workflow improvement when creating pages fromexisting content

Feedback
1

I have a feedback I would like to share.
I have been trying to organize my notes in Logseq and I keep stumbling on one thing.
If I have a structure of notes like this:

  • Title
    • content1
    • content2
    • content3

and I create a page out of the title like this:

  • [[Title]]
    • content1
    • content2
    • content3

I would expect the nodes content1-3 to move to the created page. I would also expect the parent node of the page reference to become collapsible. Instead the bullet can be collapsed, however the child nodes belong to the parent node only. This is not necessarily wrong, this is how Logseq works. I understand that. It is logical from the program’s point of view, but the reason I am bringing it up is that from the human point of view it would really simplify the workflow if child nodes moved to the created page of the parent node and the parent node could be collapsed or expanded.

Let me demonstrate:

Let’s say I am making a bunch of notes regarding some subject. At this stage it is logical to keep them together and just work with them in one cluster. They all feel related somehow. Let’s say I am taking notes from a book:

  • content1
  • content2
  • content3
  • content4
  • content5
  • content6
  • content7
  • content8
  • content9

I go back through the notes and write a title describing the note in the simplest possible way. I get a structure like this:

  • Title1
    • content1
    • content2
    • content3
  • Title2
    • content4
    • content5
  • Title3
    • content6
  • Title4
    • content7
    • content8
    • content9

Now I want to make my notes useful for Zettelkasten, so I transfer one title to a separate page, in order to be able to interlink them together easily:

  • [[Title1]]
    • content1
    • content2
    • content3
  • Title2
    • content4
    • content5
  • Title3
    • content6
  • Title4
    • content7
    • content8
    • content9

If the pages automatically took the children of the title I transformed into a page I would be done. Since they don’t work that way I have to make the following steps:

  1. Open the sidebar.
  2. Open the book page in the sidebar.
  3. Open the page of Title1.
  4. Cut the nodes belonging to the [[Title1]] node from the book page.
  5. Paste the nodes to the Title1 page.

If I transfer more than one title to a page, then I have to repeat steps 3-5 for each subsequent title converted to a page. That’s a lot of extra work. I thought about whether there is a reason a page created from a node cannot accept children nodes as content, and I haven’t found any. Nor have I found any reason why a node with a page reference couldn’t be collapsible. There is the case where a page link can be inside a block of text like this:

  • Text Text Text Text [[Page Reference]] Text Text Text Text

In this case it wouldn’t make sense to move anything to the created page, however I believe cases like this are possible to condition out easily.

2

Well… Are you the Complication of Simple Affairs Office director?!

Parent node and childs appear in the Linked References section of the created page. If you wish have them in the body page you could embed or copy it.

Ask yourself where on the page they should be pasted and why. Compare your answer with the logic of the “linked references” section.

Sorry if I was a little harsh.

3

Logseq is gradually integrating blocks and pages into a unified concept, called nodes.

Once that is fully in place, simply nesting already leads to your desired behaviour .

If unsure what I mean, check how Remnote works, for example.

4

I see, that is actually very illuminating, thank you. I failed to consider the work in progress database approach. Actually I stumbled upon it some time back and then forgot.

I haven’t realized, the page approach reflects the necessity to save data in markdown file. Moving to a database model mitigates the need and any node can therefore be connected to any other node without needing a page as a home to be saved to. That is actually a very elegant solution, making logseq more coherent than before. I have a lot to look forward to.

Is there any estimate when the database version will be released to the public? From the link you provided it seems there is still a lot of work to be done, before everything is ready.

1 Like