Prevent name collisions between Tag pages and regular Pages

[candid brook]

What happens now:

• I have #Meeting (a tag page)
• In CMD-K I type “Meeting” → first list item says: Configure tag — Create page called “Meeting”
• Press Enter → a regular page “Meeting” is created
• Now there are two “Meeting” nodes (Tag + Page). I can’t convert one into the other because the name is already taken

Why this is confusing:

• Mixed verbs in CMD-K (“configure tag” vs “create page”)
• Two pages with the same visible name
• Convert to Tag on the Page and Convert Tag to Page on the Tag are blocked because the other already exists

Imho this name collision should not be possible. If #Meeting exists, creating "Meeting" as a page should be blocked or CMD-K should ask me what I want to do (eg. offer a list item to configure properties of #Meeting, another list item to 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. I

Are there any workflows where having both a Tag and a Page with the exact same name is useful? Because if not i think guarding against collision also helps make the “pages as documents, tags as collections/classes” model more understandable to new users.

[proud cloud]

The CMD-K behavior seems like a bug to me, and should probably be reported as one.

But that leaves the wider issue of whether such conflicts should be possible? I think it might be solvable by the UI (1) asking if the user really wants to do it, and (2) renaming the tag "meeting" to "#meeting" whenever it appears, so that the two options are clearly differentiated. Right now the # is hidden in some contexts, which is fine if there is no conflict. But there will be less of a problem if the tag meeting is clearly #meeting and not "# meeting" as it is often displayed. Similarly, I suggest having a (P)meeting for properties that have a name overlap with pages or tags.

And if you convert meeting the tag into meeting the page and there is already a page, it should offer to let you either rename it or merge it.

[candid brook]

good point re: bug, will bring it to github. and yeah i agree, a small dialog that confirms user intent (or offers renaming and merging) would probably help a lot…

from a visual perspective i would be a bit sad to have the icon in the list items be replaced/duplicated with a text # or P … but i'm biased in this regard as i worked on CMD K

[proud cloud]

Or it could simply force renaming and offer a default suggestion, such as "meeting (tag)"... I don't know what would be better. My sense is that the system is not confused- it knows the difference between Meeting #tag and Meeting #page, but they can look the same to the user in some parts of the UI, so it is just to make it clearer to the user.

[candid brook]

no you're right, that the system is not confused… it is clearly made to be able to handle the name collisions by using UUIDs as you can see in this video… maybe it's not such a problem after all.

i think in the select dropdown when you type [[Meeting]] the icons make it pretty clear … maybe there could be a small text behind "Meeting" in each row, that says "Page", "Tag", "Property"

[candid brook]

https://github.com/logseq/db-test/issues/583 Bug is reported

[proud cloud]

This is useful. There are two things to fix.

1. Make the cmd-k panel clearer by adding text
2. Implement the same icons we see in cmd-k in the block itself when there are name conflicts, so they don't all look like [[meeting]].

And 3, allow renaming/merging when converting a tag to a page or vice-versa.

[candid brook]

that's a good idea to add the icon inline to the [[…]]!

[candid brook]

Quick mockup of UI Improvement 1 + 2 🙂

[merry lantern]

This looks good, clean and clear

[merry lantern]

I almost want a special character to create properties.
#meeting for tag
Meeting for page
&Meeting for property

From Cmd+k

[candid brook]

That would be cool! but do you often create properties from CMD+K? I don't recall ever doing that in my DB usage…

[merry lantern]

Frankly, rarely. But for consistency it would be great. Some properties triggers are only available via shortcut.

I think cmd+k should be an entry point for all actions

[candid brook]

True! We're getting closer and closer to the old vision of making CMD+K a true omnibox for searching and creating. If the team polishes the transitions between these different states a bit more (always same size - maybe a back button if one moves from "Create tag" list item to Tag configuration) it will feel super fluid…

Related, a little bit more consistency between these dropdown menus (select/comboboxes/property editing) and the app will feel on another level imho… i always wonder why the [[]] select looks different than the node embed select (one has icons and the other not but therefore taller list items).

[merry lantern]

The ux consistency needs to be in other areas like db graph vs Md graph icon.
Some actions are via keyboard, other via mouse event and then there is the action bar. I should log a separate feedback…

[green stratus]

Are there any workflows where having both a Tag and a Page with the exact same name is useful?

When I thought about this, I had an idea that it could be useful for collaborations. In my local database, I am interested in avoiding ambiguous names. But in a shared space, collisions are unavoidable (anyone who has worked in a corporate Notion database will agree, I think).