How to manage my pages?

For me, the lack of a reasonable framework to manage my pages and remember things is really fun, but I have trouble finding what I want in the clutter of pages.
How do you manage your pages?

1 Like

How do you mean manage?

I use a very specific structure for my pages and thereby also limit them. This goes for pages with actual content. If it’s just used as linked references I usually don’t manage that at all.

Using properties and tags is how they are put into categories if you will. Using those I can then retrieve them again if I need.

The question is generic, so the answers cannot be very specific, but I’m going to give it a try:

  • Managing pages.
    • A manageable page:
      • outlines the specific concept in its title
        • properties are generally more manageable than free text
      • is relatively short
        • excessive info should be elsewhere or in collapsed blocks
    • Most pages should be connected to each-other through meaningful notes that link them together.
      • A meaningful note is one that specifically describes the connection between two conceptually related pages.
        • Therefore it helps each page to be found from within the other.
      • Avoid circumstantial references.
        • They add noise.
        • They can stay unlinked.
      • As long as there is a reasonable path of linked pages in between a starting page and an ending page:
        • No page is ever lost.
        • The surrounding clutter can be ignored.
          • Just like following specific directions to go to a destination on a map, can safely ignore the rest of it.
    • Whenever finding some time, improve the notes.
      • A good note is not taken, it is discovered.
      • That helps one’s memory more than anything.
      • Improving notes includes their:
        • wording
        • structure
        • position
      • This is a skill learned with practice.
  • Finding what is wanted.
    • Start with a common search of some relevant terms.
    • Pick a relevant page in the results.
    • Follow any link that brings closer to what is wanted.
      • Links can be found either:
        • in the notes of the relevant page
          • Some pages are empty of notes, this is normal.
        • in the references at the bottom of the relevant page
    • Whenever getting too many options, use a query to filter them.

Just under the title of each page, I’ve gotten into the habit of adding tags:: [[parent page]].

If you do that, Logseq adds a really nice clickable index table to the parent page. It effectively builds a hierarchy of your pages from the bottom up, and I don’t really have to think hard about filing systems etc.

You can add multiple tags, for example my Hawaii page has tags:: [[places to visit]], [[volcanoes]].

If I can’t think of a good parent page, I’ll normally tag something as ‘index’ (if it’s an important topic like family or health) or ‘inbox’.

1 Like

@mentaloid Good summary, thanks!

This is how I am doing things as well now. It is like traversing your graph step-by-step and coming closer to desired results with each link.

Connections might be enhanced by properties to get nice subject–predicate–object relations between pages (or blocks). For example to express the fact that Bob knows Anna, have a page property knows:: [[Anna]] inside page Bob. The cool thing is, predicates can be searched in the Linked references, as a property reference is also page reference. This way of structuring effectively can resemble ontologies in Logseq and (mostly) got me rid of namespaces to use.

But I think Logseq has two issues here:

  1. Linked references need more filters.
    • If you dump daily work in the journal and use pages for general concepts/relations, it would be great to have a journal filter in Linked references to just see page connections.
    • Provide a way to quickly filter by free-text combined with page references.
  2. No way to execute “ad-hoc queries”
    • We currently need to write content to Markdown files in order to execute queries, which is quite ineffective and error-prone.
    • Instead have some “ad-hoc” tab, that you know from browsers, to execute queries. Or an additional window similar to the external PDF viewer.
    • I probably would use queries much more often, if I wouldn’t have to 1) find some temporary page 2) dump query as content into the markdown file 3) inspect results 4) remove the query again and hope I haven’t accidentally deleted some other content.
1 Like

I agree with the first part of your post (properties, ontologies, namespaces etc.)

Concerning the last part (issues):

  1. There is indeed much room for improvements in filtering references.
  2. This is debatable:
  • On one hand, it feels familiar to have a built-in way for ad-hoc queries.
  • On the other hand, being able to place a query anywhere is very powerful.
  • What if simulating the desired feature by:
    • Using the right sidebar as a special tab.
    • Putting there a dedicated page for all the temporary queries.
    • Something like this?

What about allowing queries in the search bar (Ctrl+k)? I’ve seen some mock-ups on Discord about it having tabs and one of those tabs could be an Advanced Search for complex queries while simple queries should be allowed straight in the search box…

1 Like

I have tried this approach in the past with the hope that Logseq would implement something like Specify and display relations between pages/tags but it didn’t happen yet. So I just adopted manually compiled indexes of pages.

@mentaloid when we discussed the Query Builder I suggested that Linked and Unlinked References sections should just be queries but with a fixed rule referring to the current page that the user can’t edit.

And once the user has finished playing with a Linked Reference section of a page, there could be an option to copy the query syntax and paste it somewhere else.

This would make queries discoverable early by new users.

1 Like

@alex0 Copying the underlying query syntax is nice to have, but its rule doesn’t need to be fixed. A better visual filter would be beneficial:

  • For every user: As a time-saver.
    • Editing queries takes time.
  • For new users: As a learning tool (if equipped with syntax copying).
    • Learning queries is steep.
  • For basic users: As their only way of filtering.
    • There will always be a big percentage of users unwilling to bother with query syntax.

I mean that only one rule is fixed i.e. the reference to the current page. In the mockup from the thread above the fixed rule is the line grayed out here:

This could be an Advanced view. The default view should not be query-oriented. But I’m stopping here, as we are at the wrong thread. I think we agree that better tools can make management less demanding.

Take both then :slight_smile: . Embedded-page queries for a dynamic view of data and queries for quick searches (this is what I meant by “ad-hoc”).

The alternative query approach looks interesting, but probably clutters up the sidebar without an additional tabs plugin. Given context switching seems to be a requirement from many users, some native form of tab implementation like [Partial Done] Add tabbed windows to desktop client / Multiple instances of Logseq would make sense for me.

This actually is quite cool. I included two queries: one gives me a short list of all pages linking to current page. The other shows me all page properties linking to current page to get an overview of page connections.

Pinning pages in the sidebar would be nice…

1 Like

If you mean that when you open the right sidebar there are already some pages opened, there is a an option in config.edn or you can use the plugin Sidebar Preset.

I actually encountered this option today, which seems quite useful here.
What I meant is to have a pinning option similar to pinned tabs in the browser, so the page gets anchored at the top of the sidebar and cannot be accidentally closed.

Ah, that plugin comes closer to what I had in mind. Will have a look at it, thanks.

Have you tried the Tabbed Sidebar plugin? It’s the one featured in these screenshots.

1 Like