Unification of tags and pages

[dawn pilot]

The post is too long for Discord, so the full version is found here: https://discuss.logseq.com/t/tags-vs-pages-in-the-new-logseq-db-a-missed-chance-for-unification

TL;DR

• In old Logseq, [[page]] and #tag behaved the same, which made tags feel redundant.
• In Logseq DB, tags and pages are split — tags are property values, pages are documents — but they still look and act half-merged.
• Problems: tags are writable but can’t have aliases, tags and pages share the same namespace (causing conflicts), and capitalisation hacks are needed to separate hubs from tags.
• This creates confusion: sometimes a tag looks like a page, but doesn’t behave like one.
• A unified model — where pages automatically function as tags and tag views are just special page queries — would avoid this inconsistency and give users the best of both worlds.

✨ Closing thought: If tags weren’t writable, I’d be nudged into using pages as hubs and tags as pure metadata, which would be cleaner. If pages had tag-like DB views, I’d only need one concept. But right now, we’re stuck in an awkward in-between: tags and pages overlap, yet neither fully replaces the other.

[smoky socket]

Side note, tags were not writable at some point, and many requested to make them so.

A tag is a page that has views in the top section.

A tag can have an alias, but it is just not obvious. The UX is not great. You have to create a page first, add the alias, then convert it to a tag

I am not super convinced that all pages should be tags. I will ponder on this one a bit.

[stoic iron]

Thank you, you clearly put the finger something that makes me uneasy with the DB version... And more generally, it feels like the main paradigms are not finalized and I kinda hoped it would be before devs moved to RTC/mobile, because at the moment it feels like a sand castle.

Many things are not in the UI and your ability to do them depends on heavily following discord (e.g the alias trick for tags, the deleting node from library, .... and it's unclear if these things will be supported, or not, in the futur).

Still it look like logseq DB will be incredible, and there are very nice features and innovatives concept, I'm sure it will settle. And probably the purpose of the alpha was to garner this kind of feedback as well

[jovial marten]

I feel you. One of the things I really really like about Logseq MD is that I don’t have to think „is this a page or a tag, do I use hashtags or wikilinks?“

[misty field]

My 5 cents. I was also confused with this thing when I first tried DB. I found the OP's post and shouted "This!". But a few days after, I realized that for me personally, it is not a big issue anymore. With the DB version, I create way fewer pages: almost all metadata is covered with tags and properties.

I am still not sure how it will go for me, but it is quite possible that I won't use ⁠[[pages]] at all in DB. And that is kind of an answer to the question "should I create a page or a tag here?"

[cobalt vector]

I actually love the way that Tana does it which is that tags are metadata and nodes contain content

[mortal heron]

I can think of at least one use case where you wouldn't want a page to automatically be treated as a tag. I have several topics that I created an actual page for like "Ubuntu Troubleshooting Changes". I put specific notes on the page describing a problem that arose and what I did to fix it. But I also have a "Linux" tab that I would run as a query below the dedicated page content so that all of the blocks I've tagged "Linux" also show up on the page, which is things like common commands that I use enough to need but not enough to remember the syntax off the top of my head. I wouldn't want "Ubuntu Troubleshooting Changes" to be a tag because it's not intended as an open-ended topic for linking disparate blocks.

[visual nebula]

THIS!! I was trying out the DB version recently and found out about this big change from the MD version, and I was very disappointed.
I don't really understand what is the logic/use case behind the separation of these two.

Both pages and tags are essentially the same thing from use case perspective: Collection of related pieces of information/objects/nodes at one place.
We add tags/page links at a node because we want this piece of information/node to be visible in that tag or page.
Why create two different ways to achieve the same thing?

And I cannot think of a single reason/use case this separation is required to fulfill. What's wrong in giving pages the same UI tags have? I would love to hear from someone who thinks this separation is needed for their use case.

This separation is problematic because It adds unnecessary friction. When I am writing at a node and I want to this node to be visible at another place too, I have to check whether that place is a tag or page, then use # or [[]] syntax accordingly.

Currently these are the differences between page and tag, and their existence feel for just the sake of it (and I hope they are removed eventually and pages are given the capabilities of tags as well):

1. The default view of references in pages is list view (and they are displayed at the bottom of the page) whereas the default view of references in tags is table view (and they are displayed at the top of the page).
2. Tags can also be given aliases but these aliases are not displayed below the tag's page title like the normal page.
3. And ofc: # and [[]] syntax difference for referencing.
4. Extend like properties and properties inheritance to the node cannot be used for normal pages.

[tiny nova]

I’m in favor of keeping tags and pages separate. For me, tags are metadata templates and pages are documents. In MD I used tags like #towatch and #toread for inboxing. In DB I turned them into #Read and #Watch with simple status properties (Inbox → Reading/Watching → Read/Watched). That structure works well, and I like seeing the table fill on the #Read or #Watch tag page.

But when I’m writing, I want a clean page, not a collections hub (table view). You wanted to hear some real use cases: For me it's writing essays, feature specs for product work, or design briefs. All of those i want to read like standalone documents. I might tag these pages, for example with #Document (which allows me to cycle through Draft → Review → Publish status). Then it shows up on the #Document tag page without changing how the page itself feels.

I’m genuinely curious about the strong push for unification in this thread. If you’re against the split, how are you using tag pages and the DB model day to day? What exactly breaks for you with real examples or screenshots?

To me the model makes sense. Imho what needs work is UX and onboarding:

• Add a "Tag this as…" button in the page header next to "Add icon" and "Set property".
• Add an "Add alias" at the same spot.
• The first time someone creates a tag, show a short explainer that links to a handbook article.

But all in all I’d keep the #Tag and [[Page]] split. For me it maps to real workflows and keeps my writing space clean while making data collection pages easy.

[visual nebula]

Yeah, I agree with you! Your point is: Currently in a tag page, references view (the table which bothers you) is visible even if that tag hasn't been used anywhere. And in a normal page, references view is only visible if that page has been linked somewhere else in the graph.

If we make this that in a tag page too, the references view will be visible only if that tag has been used elsewhere, then you should be fine, right?

[tiny nova]

Regarding your point 1:

• Tag pages show a collection table in the main content at the top.
• Both tags and normal pages still have Linked references below the main content in list view.
• Normal pages don’t get the collection table in the main content, they only show the linked references section at the bottom.

So it isn’t “tags = table at top, pages = list at bottom” as a single either/or. Tags add a collection table on the page, and both page types still have the standard linked references underneath.

[tiny nova]

i think that's a misunderstanding: the table on tag pages does not bother me. I actually want it to always be visible, even when the tag has 0 items, because the empty state lets you hit "+ New" and add the first item quickly.

i'm basically arguing that i like the current model and don't think unification of both page types would be good 🙂

[visual nebula]

Currently there are two kinds of pages: "tag pages" and "Normal Pages" (which both differ in behavior in few aspects).
What this thread topic has proposed that remove differences in those aspects.
Hypothetically, let's assume that is achieved and all the pages now behave like "tag pages".

Then your workflow will face this UI issue: Many a times, you will require pages which doesn't have an empty table visible at the top. This will now no longer be possible to achieve.

[tiny nova]

ah yes that‘s right. I got a bit confused when you said „References view“ – because as i pointed out in the Screenshots #Tag pages still have „Linked References“ section too (below the tag table). But yeah in case of a unification that table would be annoying when i‘m writing an essay.

[visual nebula]

Ok, that's one valid reason. 👍

[tiny nova]

I think the collection table works a bit different than „Linked references“ because the tag table only shows every tagged object once - in „Linked references“ it could be displayed multiple times. But i get the confusion between the two because they use similar query/view switching UI elements.

[visual nebula]

By the way, a Workaround solution that I will try tomorrow (hoping that will solve my concerns/issues regarding this division of tags and pages) (now I am going to sleep😇 ):
I will only use tags in my graph and never create a normal page.

I will see how that goes and why that can/cannot be solution to my concerns and then update here.

[tiny nova]

yeah curious to hear about your reports! Good night

Looking through my "All Pages" I notice that i also like to use pages for people ( [[John Doe #Person]]) and companies ( [[Northframe #Company]])… For books/articles i tend to use blocks…

[ocean flame]

While I dont completely agree Tags and Pages should be merged, I can see why it might be beneficial. However I believe that the 2 ways of "linking" are a separate matter, and its actually an extremely useful functionality. If Pages disappear and only Tags remain, I wouldnt want all my pages that link to a Tag to inherit the Properties of that Tag, because sometimes I only want to link to that page.

For example, lets say I have a tag called Recipes, and it has "Time to make it" and "Ingredients". Lets say that at some point I want to write something about Recipes in general, so I might add a block to Todays journal that says "I should add more [[Recipes]]". This is obviously not the same as "I should add more #Recipes", since in the last case, this block would be considered a new recipe (and have Time to make it and Ingredients as properties), which obviously doesnt make sense

[jovial marten]

I‘m not using the DB version 🙂
Not a fan of the tags table on top of the page either.

I feel the DB version is much more designed for people who want structured data (properties, choosing a „type“, complex inheritance) — and in the process we loose some fluidity.

[tiny nova]

Ah I see, but have you had a chance to play around with it more seriously?

And yeah the DB version is definitely more about structured data, but I think the ambition of the redesign is to keep peaceful outlining at the core and just make data collection more casually accessible and reliable. I'm obviously biased though as ex-contributor 🙈 With some distance i do realize that the presentation of the new functionality is still quite nerdy… hence why i think some focus on the onboarding to the new mental models is needed.

Do you collect any metadata in the MD version with the key:: value property syntax?

[tiny nova]

Totally agree on keeping the two link actions separated as they are.
[[Recipes]] = talk about the concept > adds it to the Linked References
#Recipes = classify this node as a recipe and inherit its properties > adds it to the tag table as new unique object

Both linking and tagging are useful and should stay distinct and predictable.

[brazen rivet]

for what it's worth, I naturally got the same general workflow as @tiny nova when using DB for the first time. Note that i didn't use logseq MD prior to using logseq DB.

For me tags are for categories. Tag #Person is to characterize a block or a page that is a person. But i don't want the individual person itself (let's say John Smith) to be a tag, I want it to be a blank page in which i will write info about that person.

And i want a tag page #Person with a table containing all Persons in my graph, arranged however i want. I most probably wont put anything other than the default table in that tag page.

Same general idea with books, films, projects or even broad subjects. For example I got a page [[Anarchy]] that is a #theme that i use as a property on my films and books. And that i can populate with writings or ideas or info about anarchy as a political subject. But i wouldn't want a tag #anarchy, because that is not a type of object (i don't know how to say it better).

So for me the distinction between #tag and [[page]] is quite clear and for now I'm using it both for different things. If the two are merged i will need to re-think my workflow quite a bit or put more work in re-creating this distinction (with templates for example)

[tiny nova]

So we've several concrete workflow examples that benefit from keeping #Tag and [[Page]] separate:

• Type/class vs instance/object: #Person, #Company, #Book, #Project, #Theme, #Recipe as categories; pages like [[John Doe #Person]] or [[Northframe #Company]] as the things you actually take notes on. #1428704340448776334 message
• Clean writing surfaces: regular pages stay visually simple for documents without need of a collection table on top (essays, feature specs, design briefs). #1428704340448776334 message
• Inline intent: [[…]] just adds a linked reference to a tag or page, no instance is created; #… classifies the current block, creating a unique entry in that tag’s collection #1428704340448776334 message

Given these real use cases, I’d love to hear from those who suggested or voted for this unification feature request: can you share concrete cases (descriptions or screenshots) where merging tags and pages would make your day-to-day work in the DB version simpler? I’m genuinely curious about examples in practice, not just theory.

[buoyant sonnet]

I entirely agree with @tiny nova on this.

I think that one problem might come from people who used #tags extensively in MD and then imported those to DB as NewTags. I recommend NOT doing this, as they do very different things in each version of the app. (You can opt to convert some or all #tags to [[pages]] on import.)

As @tiny nova said, NewTags should really be reserved for items you want to have collections of. I use it for #contacts but I wouldn't make a particular contact page (e.g. "Jane Doe") into a NewTag. Once you understand this, the distinction makes sense and the workflows that come from it are much easier to understand.

What is needed is (a) a better import UI for MD users, and (b) better onboarding for people using NewTags for the first time.

(I think it would also be helpful to not call MD tags and DB NewTags by the same name, which is why I use "NewTags.")

Some of the discussion here might help: https://discuss.logseq.com/t/introducing-newtags-with-examples/32310/18

[tiny nova]

Actually I just ran into a case that made sense to me why some people might want "unification" or at least tighter name handling:

1. I already had #Meeting (tag page)
2. In CMD-K I typed "Meeting". The first item read Configure tag — Create page called "Meeting"
3. Pressed enter → a regular page Meeting was created
4. Now I have two Meeting page nodes (one a tag page, the other a regular page) … I can’t Convert to Tag on the regular page or Convert Tag to Page on the tag, since the other already exists

Imho this name collision should not be possible. If #Meeting exists, creating Meeting as a page should be blocked or ask me what I want to do (eg. maybe configure properties of #Meeting, maybe turn tag page into regular page). Same the other way around. Also maybe there should be Convert to Tag / Convert to Page toggle in the header of every page type, not just hidden behind the three dot menu.

But now I'm curious if anyone has a real workflow where having both page types with the exact same name helps.

[buoyant sonnet]

I agree, but I think this should be a separate feature request. That way we can discuss how to deal with the problem in a new thread. (I think it might be solvable with UI tweaks...)

[misty field]

I am not sure if I can reproduce this on test.logseq.com. Do you use an updated desktop app? Last week, several similar bugs caused by collisions were fixed.

[jovial marten]

That's actually a good example. I think that in MD, Logseq did a pretty good job of hiding a lot of complexity from users. The explanation for choosing between wikilinks vs tags was: Use whatever you like, you will get the same results. You don't have to think about it. Similarly with namespaces: Yes, it is clumsy to edit namespaces, but it's easy to understand. In DB there are two new interfaces (inheritance property and the library) to deal with.

i didn't really have time to try the DB for real work, it may very well be that my worries are just that

[tiny nova]

i was able to do this in my main graph and test graph on test.logseq.com (which should have the latest bug fixes)

[tiny nova]

That's fair! At it's core it's probably really just two different notetaking styles, as you said in your previous comment. For me the benefits outweigh the new complexities, but I get the other perspective as well.

[tiny nova]

I'll try set one up later

[dawn pilot]

(Part 1/4)
Thanks everyone for the thoughtful examples - they've helped me crystallize where the friction in my own workflow actually comes from. This is gonna be a long one, but hopefully sheds a lot more clarity.

I'm not arguing for merging tags and pages blindly. I am arguing that the current model introduces accidental complexity and that the system could be simplified intelligently, without breaking any of the workflows you've shared.

1. Tags behave too much like pages - but without the full capabilities of pages

Tags can:

• be written on at the top
• be linked using [[...]]
• appear in search, the graph, Recent, page lists

But they cannot:

• have aliases
• avoid namespace collisions
• behave consistently like fully capable pages

This "90% unified / 10% different" model is where my friction comes from. It results in tags feeling like incomplete pages, not clean metadata types.

2. Tags currently act as better hubs than pages - and that nudges me into misusing them

Right now a tag page:

• automatically gives me a structured table of items

A regular page:

• only gives me backlinks at the bottom

So when I want an overview of something, the tag view is the better tool.

Before the DB version, I would create a page and use its backlinks as a hub. Now the incentives are reversed - the tag view is the more powerful default hub, so I start using tags just to get that hub, even if I don't want the tag to serve as a class/type.

This creates conceptual blur.

(Part 2/4)

3. The UI reinforces the confusion rather than clarifying the model

Tags appear everywhere pages appear:

• Search
• Graph
• Recent
• Autocomplete
• All Pages lists

This makes tags feel interchangeable with pages.

Because tag pages are writable, I naturally start treating them like pages. And because pages lack the automatic table view, I often prefer tags as hubs or grouping tools.

A clearer UI distinction would help:

• Search/Recent/Graph should prioritize pages
• Tags/structured types should live in a dedicated Tag/Type Library (the equivalent of Pages → Library)
• Opening a tag should feel distinct from opening a page
• Pages should be the main work surface
• I should go to the page hub to get an overview of a type's collection, not to the tag page

This would prevent ending up "in the wrong place" as easily as today.

4. Namespace collisions reveal a deeper model‑consistency issue

Examples:

• #Meeting vs [[Meeting]]
• #career vs [[Career]]

These should not be allowed to become two separate entities. Today they force awkward capitalization hacks and inconsistent behavior. If tags and pages are supposedly distinct ideas, they shouldn't collide in names or require capitalisation hacks to coexist. This is not a schema issue - it's a UX consistency issue.

5. I like the class→instance model - but tags are not clean classes yet

The model many of you described makes perfect sense to me:

• #Person → type/class
• [[John Doe #Person]] → instance/document

But currently tags are:

• half class (structured table, metadata, type-like behavior)
• half page (writable, linkable, visible everywhere)

This blurring makes the mental model harder than necessary.

What I'd prefer:

• Pages = documents/instances (writing, hubs, aliases, queries)
• Tags = classes/types (structured, table-driven, not writing surfaces)

And for the UI to reflect this clean separation.

(Part 3/4)

6. Why I originally talked about "unifying" tags and pages

My real wish is: A single, unified way to assign and maintain structured properties across pages.

In old Logseq:

• properties had to be repeated manually on every page
• nothing unified pages of the same "type"

With DB Logseq, tags are supposed to fill this role - effectively acting like abstract pages/classes.

But right now the tag concept:

• behaves partially like a page
• behaves partially like a type
• isn't clearly a first‑class "class system"
• overlaps heavily with pages in UI
• lacks page features like aliases and naming control

So instead of simplifying the mental model, tags introduce a second concept that overlaps heavily with the first.

This is why I initially talked about unifying tags and pages: not to flatten everything, but because I want one consistent system for managing structure and metadata across pages, not two overlapping ones.

Call them tags, classes, abstract pages - I don't mind. What matters is conceptual clarity.

7. What I'm actually advocating is intentional clarity

• Keep [[Page]] for writing, conceptual hubs, navigation
• Make "tag = class/type" explicit and clean - used for classification
• Give tags the capabilities they need (aliases, merging, no name collisions)
• Give pages optional structured views
• Provide a dedicated Tag/Type Library separate from Pages
• Stop showing tags everywhere pages show
• Make sure each concept has an intentional, consistent role

This is not about reducing functionality - it's about reducing accidental complexity.

(Part 4/4)

8. Why this matters to me in practice

Right now:

• tags feel like pages missing features
• pages feel like tags missing features
• tags appear everywhere pages appear
• tags are the better hubs by default
• I'm nudged toward using tags as pages
• namespace collisions cause confusion
• maintaining structured properties still feels harder than necessary

I want to work in pages all day, and use tags purely as structured types - but the current UI and behavior make that surprisingly hard.

---

If helpful I can share screenshots from my graph to show where this ambiguity bites, but the core idea is: I'm not advocating for flattening tags and pages - I'm advocating for a clearer, more intentional model where each concept has a distinct purpose and the UI reinforces it rather than blurring it.

[tiny nova]

Phew that was a long one indeed 😮‍💨🤖 it seems to me you switched from arguing for a unification of tags and pages to a clear distinction between tags and pages. Sometimes a picture speaks more than a thousand words, so it would be helpful if you included some screenshot examples from your graph to ground this discussion in real workflow issues.

Btw tags can have aliases

Also i don't know where tags don't "behave consistently like fully capable pages"

and on regular pages, you can turn the "Linked references" into a table view if that is what makes the tag pages feel so hub-like to you

I think Logseq's flexibility is one of its most powerful assets, so I don't really see the downside of tags being visually and functionally similar to pages. I do agree tho, that a dedicated Tag overview that we can navigate to from the left sidebar wouldn't hurt, similar to this view in Tana.

[buoyant sonnet]

There is the #tag page. I added a "tag-type" property and group them by that, so I can filter out "logseq tags" from "workflow tags" and "topic tags" ...

[tiny nova]

that's a cool approach

yeah maybe that #Tag page should just be pushed to the "Navigations" elements in the left sidebar

same with the Library page btw!

[buoyant sonnet]

The UI of the Library page could use some work...

[tiny nova]

maybe that's why it's so hidden 😄

[smoky socket]

I have #tag added as favorites at the moment

[dawn pilot]

Thanks for reading - it did take a while to compile on my side too 😅
I’ll put together some screenshots when I have time, though they’ll mostly just illustrate the issues I’ve already described in text.

I don’t think I’ve “switched” positions. I hoped it was clear from my reasoning - and especially from my closing remark in the original post:

Closing thought: If tags weren’t writable, I’d be nudged into using pages as hubs and tags as pure metadata, which would be cleaner. If pages had tag-like DB views, I’d only need one concept. But right now, we’re stuck in an awkward in-between: tags and pages overlap, yet neither fully replaces the other.

It’s never been a black-and-white issue for me. I’m pointing out some problems (which others seem to experience too) and trying to articulate them. If I were able to present a fully fleshed-out final solution, I’d probably be on the Logseq team - or building my own “Seqlog”… 😄

My core point is this: Tags behave too much like pages and not enough like pages at the same time.
That’s the blurred edge I’m trying to highlight.

So either:

• unify → one concept serving two purposes, or
• clarify → two concepts with clean and intentional boundaries

Both approaches would solve the problem.

Hopefully I’ve made my points clearer now. It felt like the headline of my post was taken very literally instead of looking at the underlying issue: how to address this overlap without dumbing anything down or assuming it’s just “user error.” My intention was to spark the question: “How could what we have today be expressed through one concept (pages) instead of two overlapping concepts (pages vs tags)?”

So, based on everyone’s replies, it seemed easier to communicate the problem using the language of pages and tags. And as I mentioned initially, a clear separation here would also solve the issues I’ve been having.

[runic ocean]

I much prefer just having everything is a block idea. That way I don't have to think about if I want something to be a block or a page. I really like the way that Tana does it. Any node/block can be a page if you zoom in i.e full screenn

[ocean flame]

I think most people dont adhere to this workflow, since most of the times one has a somewhat clear distinction between Titles and Content, so its nice to have Pages to provide this structure to your data

[misty field]

It works not only for Tana but also for Workflowy, a pretty popular app that fits general user needs. I mean its userbase is something like 10x what Tana or Logseq has.

Distinctions between the title and the content make sense in many cases. But that does not mean the app should force the user to have titles where the app thinks it's better.

[ocean flame]

In what way do you feel Logseq "forces" you to "have titles where the app thinks it's better "?

[misty field]

I’m not saying it does. Well, it does, but in super niche situations, so I do not care much: like [here](#db-chat message). Or with journaling (since journal items are pages).

What I’m trying to say is that having everything as a block can be a more flexible workflow compared to applications where users have to create titles. Like, Workflowy is more flexible in this sense than Obsidian.

[tiny nova]

but isn't everything in Logseq DB a node? And it just offers the affordance to promote a node to a page view, by tagging it as #Page? Ideally we're also allowed to tag any node with #Tag or #Property

[misty field]

Right and i love it. But also there are pages that can't be "demoted" to nodes, at least not easily. It is true for both examples of "forced" pages I've mentioned.

[tiny nova]

That's valid! We need a "Convert to block" option here…

[misty field]

I think it’s a bit more complex than just not having a UI button. For instance, where should the «demoted» journal page be placed as a node? The Workflowy answer is that it should be at the home page. However, not all Logseq users have a «home page» (only those who’ve disabled journaling).

So, we sometimes run into conflicts between our old MD ideology (where pages were more important) and the new DB workflow. I could mention more examples of this «curse of backward compatibility,» but it would be totally off-topic.

[tiny nova]

haha they obviously should be placed in node nirvana 😄

In Tana they seem to automatically be placed on Today's journal

[misty field]

I'm afraid it is more like node "Orphanage" — the place for pages that have never been nodes with parents. I am really sorry for this joke.

[tiny nova]

fair that you don't have a full solution yet, but this is a feature-request channel and so to me the ask feels a bit too vague. Most threads here come from concrete pain in certain workflows, with a clear, contained change people want (so a relatively small scope).

DB has been in the works for ~2 years and the “tags for collections, pages for documents” model has been there from the start… Also there was precedent that this UX works (see competitor Tana), so it feels a bit late to scrap it and have only one concept.

I can see the case for clearer separation and small UX tweaks. Imho it's always a tradeoff with flexibility, which some alpha users seem to like too. If you have some ideas, maybe you could break them into single, concreate feature requests so it's easier to discuss and vote

[tiny nova]

honestly the metaphor isn't far-fetched 😅 i think an "Orphans" view could really be useful… Maybe call it "Inbox" instead. But it would work as a holding area for thesed demoted pages/nodes without parent. And with a "Move to…" action they could be "adopted" into the right place.

[misty field]

Getting the "/move to..." command could be our first step torwards Orphange Inbox.

[tiny nova]

it should work via CMD K too

[smoky socket]

Atom

[tiny nova]

as term for these nodes you mean?

[smoky socket]

Yes. Or “disconnected node” since we commonly use “node”

[tiny nova]

I guess "atom" rolls more easily off the tongue, but "disconnected node" feels more fitting…

Detached node or unparented node could also be options?

the "orphan" term is already used in the Graph View

but not sure if sounds insensitive to native speakers?

[misty field]

Yeah, it's common tech term. Like orphan packages in brew, etc. I mean, "master branch" was also a tech term. But unlike it orphans were not abandoned. (sorry again).

[tiny nova]

i see! since the outliner uses a lot of family metaphors (parent, child, siblings) it does make sense to me stay in that metaphorical space for nodes without parents… but maybe "unparented" would sound less harsh in English as well as translations.

[dawn pilot]

Of course, I just have only been able to properly try it after I found out it was possible to download through Github builds.

I did understand the db-feedback to be for feedback. Otherwise I'd suggest a renaming to 'feature requests' for a better UX experience there too 😄

Maybe I'm still presenting my case badly 😅 I'm really not trying to start a revolution and scrap two years of hard work. Honestly, I feel like it's the last 10-30% and we would be there.

I've also tried Tana and there there is a clean separation. It's not like I can just add text, images and what not to a Supertag and treat it like a regular node. Instead it's a clear concept, a collection, adding it's meta properties to every entry in the collection.

💡 I wrote in my original post that a clearer separation could also be achieved,

If tags weren’t writable, I’d be nudged into using pages as hubs and tags as pure metadata, which would be cleaner.
..that to me is a clear suggestion.
Maybe I've lost the overview, but I don't see why this would be a bad idea.

In Notion I feel I only have one concept "block", which is able to either just remain like that or be elevated with properties yielding powerful collections (database) feature.

That's why it to me feels like both paths are feasible in order to achieve a clearer distinction between a regular node and a 'collection' concept.

[visual nebula]

Sorry for the late reply, I got extremely busy with work this week and couldn’t test things earlier.
While testing the DB graph today, I discovered the “convert to tag” option that appears when searching inside a block using #. This is fantastic because it lets me convert regular pages into tag pages on the fly. With this feature, my workflow of using only the # syntax for all page references (I only use # in my Markdown graph and have never used [[ ]]; even for journals I use date-tags to form a collection of everything I did that day) ** can be implemented even with maintaining the pages and tags divide**, just that feature should get improved in this way: https://discord.com/channels/725182569297215569/1439251625062563911

If this happens, then I am all good with the current pages vs tags divide.

[visual nebula]

I don't agree with @dawn pilot suggestion of deepening the divide between tags and pages by making tags not writable. That would be disastrous for my workflow.

[tiny nova]

you're right, sorry if my last message sounded gatekeep-y about this channel. and yes, in Tana tag pages aren’t writable.

since this thread has branched into a lot of ideas, could you maybe make a separate db-feedback post just for “make tag pages non-writable”? that way we can vote on that single smaller scope change and discuss pros/cons in our workflows.

if i remember correctly tags weren’t writable in early DB builds and it was added later, which suggests some users were asking for the flexibility. in the end the Logseq team will have to weigh input from both sides of the tradeoff: clarity (non-writable tags might make the conceptual model cleaner) vs. flexibility (writable tags let some workflows keep notes/context on the tag page).

[smoky socket]

I was waiting to see if someone remembered that it was NOT editable, leading to a feedback, then the team made it editable 🙂
Now the opposite is being asked

[tiny nova]

noice, that convert to tag works well for your workflow!

[smoky socket]

But yes, this conversation has been great. Break them out as seperate feedback as suggested by @tiny nova to allow upvoting

[tiny nova]

hehe, glad i wasn't imagining this. and yeah user desires are complex

even tho i'm on team flexibility in this tradeoff i mentioned, I just checked all my tag pages, and in over a year of regularly using Logseq DB, I've never added notes to them…

[tiny nova]

if a separate thread is created about making tag pages non-writable, it would be great if you could share your workflows (maybe even with screenshots if that's possible), to add to the discussion!

[misty field]

Apparently it already works:
Cmd + K -> Move blocks to... does the job. Also, there is the Cmd + Shift + M shortcut.

[smoky socket]

A practical example of using the tag page: This subscription tracker calculates subscription properties using the query function.
This creates a self-contained subscription tracker system.