I just saw this video on Twitter https://twitter.com/ednico_/status/1722320992255521104
I think using hashtags for ‘instances’ in the same way that Tana uses supertags is going to confuse a lot of people who aren’t familiar with Tana, and will also impact compatability with other Markdown editors (e.g. Obsidian)
Is it not better to use a unique symbol? maybe the @ sign?
Looks to me as if an actual page is being used to define the properties on 
That seems even more confusing tbh.
Would I then have a bunch of pages that simply define a properties list?
I agree it should be something separate, for both clarity and compatibility
I like the concept of powertags but think the tags should actually be a type of template. Then the template property text gets rendered by the template function with the context of the block/page.
Defining it on the Tags page is ok I think, if they are prefixed for example, or even better, the page only has a property with the template name to use.
I totally agree and when I tried Tana I was super-confused by “supertags” because for me tags and a classes are very different concepts. There is no reason to “take inspiration” from Tana here.
In my opinion classes should be implemented using a special property for both pages and blocks:
I Am A Page
class:: [[Foo]] [[Bar]]
- I am a block
class:: [[Foo]] [[Bar]]
This way we should also be able to view classes as a column in table queries.
This implementation describes itself and even users who don’t know the concept of classes will have a way to refer to the feature when searching the documentation or asking other users for help.
What would happen if we use the hashtags instead? I can see how in the future users will refer to them in creative ways like “those tags with properties”, “properties templates” and so on.
CC @futurized
I agree, it does seem like properties are the way to go to achieve the best implementation.
However, I do think that using a special symbol to instantiate an object within a class is supernifty.
e.g.
It makes it super simple to enter information quickly.
And the idea that Tana has with supertag ‘pages’ where there are already pre-existing user-defined queries is super handy.
Can you please explain what you mean? I don’t remember this from my test of Tana some time ago.
Also did you try the DB version from a deployment on the Web like this one?
@alex0 When you click on a supertag, you are now taken to the supertag ‘page’, rather than the configuration menu.
You can configure a number of different views for all the supertagged nodes. Very nifty.
I haven’t actually tried a DB deployment. Didn’t realise it was available.
In Logseq tags are pages (also in the DB version) and of course you can place queries in them. So I guess what Tana does in addition is allowing the user to setup the same queries for all the tags? In that case, have you tried the contextual sidebar?
You can add properties to blocks using “Add property” slash-command. Pages have buttons under the title to add properties. From there you can also setup a “properties template” for each class. Pages and blocks tagged with a class will get that template. When assigning a class with # you can toggle “Turn this block into a page” and what you get is something like a page embedded. Very nice because it’s what I already do manually in my graph.
No, you still have to setup the queries on each tag, but it feels easier to setup than having to build the queries in Logseq.
That contextual sidebar looks cool. I think the challenge is having UI elements that are standard and that are easy for the average user to pick up, which is something that Tana is working hard to implement.
@alex0
The DB version demo doesn’t work for me
I try to use the add properties command but nothing happens.
What do I do wrong?
They copied Tana in the end…
