+1 for what @ishgunacar said.

Hadn’t thought of this. Seems obvious in hindsight, and much cleaner.

I’ve been reading this thread and unless I’m misunderstanding something…you can toggle tags on and off in the graph view. The option is in the Filter portion of the menu.

There is a blog post from Tiago Forte on tagging, which among many things covers tags as statuses:

It is lengthy but a very insightful read.

If you’d like to follow Tiago’s journey from not liking tags at all, to liking them a bit more, here is a post from 4 years earlier:

Both are interesting reads.

3 Likes

Hi everyone,

Here’s my thought process for this:

Some tag features:

  • Tags are a shortcut to a search function, but this function is limited. I cannot use regex with them (for example tag:/^#string/), such as tags starting with something or ending with something. In this specific sense, a tag is inferior to a normal search.
  • Tags are weak links between concepts, as there is not a specific page to tie the two concepts together. Sometimes you just want to relate two or more things without creating a page. We should keep that.
  • Tags have a dedicated panel
  • Tags look different in the document

Today I was wondering, should my dates be tags or notes to link to? The concept of daily notes calls for the later, but there are cases where I just want to tag something with a date as to not create a page. So right now I feel like I should be using both tags and notes for my dates, and tags only for when I don’t need the page.

So, a realization came to mind, a link [[]] can become a tag if Obsidian makes three changes:

  1. A key combination, something like Alt + Click that when pressed instead of going to the page, it becomes a search function such as "[[string]]".
  2. An option in the configuration to ask before creating a page with a link click, in case the page does not exist before. This has to be paired with a visual signal to differentiate which links have pages created and which ones don’t. There are many options here, color, adding a pound symbol at the start of the link like #[[string]], etc.
  3. A way to save searches and/or to have links be listed in a separated panel. Similarly to the tag pane.

These three things would make the concept of links [[]] contain the concept of tags # with the added benefit that there would not be restrictions for multi-word tags (no needed to join with -,_, etc.)

Another plus is that there would not be an unnecessary worry if a concept should be a link or a tag, as the link would serve both.

The big con here is that there would be two competing features that overlap with the same use-cases, making things confusing for the users. So there should be a clear path of implementation paired with an option for users to massively reformat notes, in case this comes to fruition (similar to the markdown importer).

Thoughts?

1 Like

What’s being proposed here accounts for what’s been discussed elsewhere:

With a somewhat clear set of features on how to achieve it.

1 Like

This two things for me are positives of tags and pages being separate entities. I actually like that they have a dedicated panel that let’s me know how many of a type of page I have. They also serve as visual queues for me. Can you guess in this note where is my #important tag?

I think having a tag glossary is important, tags can get out of control. I’m curious in which cases doesn’t it make sense to create a page? Also… creating a link doesn’t create the file itself until you click on it, AND it still shows up in the graph as a connection.
Adding a panel that lists all the links in the graph would soon be impossible to navigate.

@argentum

They also serve as visual queues for me.

But this is using custom CSS, right?

In that sense what’s being shown in the screenshot is achievable with internal links too, especially because it has data-href attributes and these also have .internal-link .is-unresolved classes. Which allow for the same result you just showed, and I could argue even better, here’s a demo:

All these are internal links no usual # tags used:

[[tag new unexisting page]] <-- this is a tag without page created

[[tag important]]  <-- this is an important tag, unique color no page created

[[tag important with page]] <-- this is an important tag, unique color with a page

[[Ideas]] <-- existing page, this is not a tag

[[a page but not a tag]] <-- non existing page, not a tag

[[tag existing]] <-- this is an existing tag with a page for descriptions (if anyone likes that)

All tags are multi-word

And here’s how this very page renders:

And the css used is very small:

.internal-link[data-href^="tag "] {
  color: white;
  padding: 1px 8px;
  text-align: center;
  text-decoration: none;
  display: inline-block;
  margin: 1px;
  cursor: pointer;
  border-radius: 14px;
  background-color: var(--text-accent);
  opacity: 1 !important;
}

.internal-link[data-href^="tag "][data-href*="important"] {
  background-color: red;
}

.is-unresolved::before {
  content: "⚠️ " 
}

So the basic structure is there, it’s just missing some considerable steps in order to make it work like a full tag.

In the end the points mentioned above would be still missing given the current behavior of links.

My point is, the links and tags are very close in terms of UX and having links absorb the benefits of the tags, all of them, would provide a better experience.

6 Likes

That’s a fair point! I still think that the separation is good and a “links” pane would be rendered unusable as the vault grows.

It’s still unclear to me on which cases a date doesn’t make sense as a link and does as a tag, and especially now that I’ve seen that you can format links in such a way. Wouldn’t that make links work for you? You could use only links pretty much in the same way by pretending tags don’t exist in obsidian.

This is pretty much what I’m using right now, the problem is I’m not able to quickly search for something the same way a tag works. One feature of tags is that they serve as shortcut for the search function. So the points mentioned above are still fundamentally missing:

  1. A key combination, something like Alt + Click that when pressed instead of going to the page, it becomes a search function such as typing "[[string]]" in the search bar, similar to tag:#string.
  2. An option in the configuration to ask before creating a page with a link click, in case the page does not exist before.
    1. This has to be paired with a visual signal to differentiate which links have pages created and which ones don’t. There are many options here, color, adding a pound symbol at the start of the link like #[[string]], etc. This is addressed with the custom CSS.
  3. A way to save searches and/or to have links be listed in a separate panel. Similarly to the tag pane.

I still think that the separation is good and a “links” pane would be rendered unusable as the vault grows.

I’m not sure how the internals work, but if we are able to build a graph with thousands of notes, I don’t think a searchable list with a number of mentions for each link is too far fetched.

1 Like
  1. Couldn’t you select the text and press ctrl+shift+f?
  2. Since there is a visual distinction you click on a link that is unresolved, and it will create the file? How are you imagining this works if you click but don’t create the file?
    About the styling… You can already do this with is-unresolved can’t you? And I’m no css expert, but wouldn’t you be able to use before:: for this too? It’s not very clear to me if you think something other than the custom css should be added.
  3. You can already star searches!

There are vaults that range anywhere from 200 to 38k notes, I think once you have more than 100 links, finding stuff in that pane is going to be hard or need a lot of scrolling.

These are all UX/UI improvements transformed features that can make the [[page]] work like a tag.

  1. That could be an alternative, for now, but I could see my self (potentially other users) easily miss-clicking and navigating to the page instead of searching, but yes. I still think a key combination is a small UX improvement to add here.
  2. There are two things here, the option to “confirm to create (through link navigation)” and the styling.
    • The styling is easily solved as shown in the demo above.
    • Perhaps there’s a better way, but the config option is an UX improvement similar to what we have as an option on “Confirm to delete”. One can easily create a bunch of blank pages, and the users might not necessarily want that. Especially when the current styling for is-unresolved is simply opacity: 0.5; it’s an easy mistake to make. This is not as related to the tag discussion but it does indeed help to align the tag/link behavior: because clicking a tag does not create a page and a setting like this might impede the creation of undesired pages (which might happen if the devs do decide to go down a similar path)
  3. That’s very useful to know! I wasn’t aware of it. I can easily make some adjustments to my workflow with that. In all honesty, I’m very new to Obsidian, just a couple of days-old user here.

There are vaults that range anywhere from 200 to 38k notes, I think once you have more than 100 links, finding stuff in that pane is going to be hard or need a lot of scrolling.

I see your point, but I do wonder if the people who manage all these notes would be interested to know the top mentioned links and these be shown as a list (that’s what the tag panel practically does). And for the same people who have more than 30k notes, how many tags do they currently have?

1 Like

Thanks, that clarifies a lot of things for me! Being new means you can look at this with fresh eyes, and I think that helps a lot too! I would suggest adding a reminder to come back to this thread in a few weeks (up to you!), and if you feel these improvements are still needed, go ahead and make those #feature-requests for the things you’ve noticed. (Ideally, small-ish so they are self-contained). I don’t think those necessarily have to happen only if #tags end up as [[pages]] and there’s a good chance other people want similar things too.

3 Likes

I suggest why not make #tags those [[pages]], which auto-populate, any mention in a tabular format?
Storing info like time of creation, pages which mentioned it, number of mentions on each page, etc

I don’t understand why’s there fuss around when such feature can be implemented as optional core plugin?
Can anybody explain me?

1 Like

I use [[@tag is page]] for tag and create a page.

2 Likes

As it has been said by @andyfreeland : very nice ideas formulated in this post. Thank you @INoViodiUMNE for bringing this up. And thanks for everyone else for the discussion.

Apart of stating my support for the handling of #tags as [[pages]], I want to mention another reason why this could become extremely useful:

There are many reasons for working and thinking in more than one language. Mine is that I’m a social anthropologist. So, if a tag would behave like a page, I could use aliases for that ‘tag’- and in that way use tags in multiple languages. For instance: #diet (English) would then equal #Ernährung (German) and #alimentation (French). No limits to this.

Of course, I could simulate this behaviour with the workaround mentioned by @INoViodiUMNE - but then I would need to forgive all the functionality which comes with using tags in obsidian (as mentioned by @ishgunacar). This is not nice. So far it is an either-or. I want to be able to add more context to tags, to use them in more than one language and to enjoy all the benefits of tags (as mentioned by @doserved and @Calhistorian) - for instance the possibility to enjoy them providing me with a pick list.

2 Likes

i totally agree with this interpretation. A tag is really a different type of information/relationship holder to a link. There have been a number of occasions when I have initially used a tag and subsequently gone back and changed it to a link. In my use case links indicate a primary relationship between pages that I would want to follow when reviewing my notes while, say, writing an article. A tag however is a very soft link that allows me to quickly search all of my slipbox(es).

By way of example in my vault there is a direct link between ‘The Royal Society’ and ‘Sir Robert Moray’. The former is tagged as a ‘society’ and the latter as ‘person’, ‘philosopher’ etc. If I want a page of links to all entries ‘person’ then I can easily create one using OQL (Obsidian Query Language). This latter approach is how I create most of my MOCS as it is dynamic in that the page is constructed from a fresh search every time I open it.

So yes, I think there is sufficient difference/flexibility as it stands but hey, that’s just my two pennies worth. :slight_smile:

I do agree! Yes, using tags in that way really makes sense.
However, I still want to add aliases to my tags so that I can use them in multiple languages. Or add - when the time comes to convert a tag into a concept and write about it - more context to them. At least a description would be nice… :slight_smile: (But maybe, that refers to a feature request which has been formulated elsewhere?)
But yeah, still thinking about your post. Makes sense and in fact, I use my tags and links in quiete a similar way as you do.

I think this can be a useful addition, as it adds value and doesnt change the way tags are used now.
I just wonder - isnt it basically just an automated version of what is kind of achievable right now with 1. using search for that tag 2. copy the results 3. paste them into a note ?

For those people still looking for this functionality, Tag Wrangler 0.5.0 now supports Tag Pages, which allows you to say “this page is associated with #my/tag” by making the tag an alias of the page. You can then hover preview it from any place it appears, alt-click it to open the tag page, and so on. The places where the tag appears in other notes will be listed in the “unlinked mentions” section of the page’s backlinks.

I created it mainly to be able to have hover-previewed dataview tables about specific tags, but it also serves for being able to use autocompletion of tags for certain concepts without giving up the ability to have a page for them.

(Btw, you can alias multiple tags to the same page, but they will still show as separate tags in the tags pane, despite sharing the same destination page.)

5 Likes