Explain the problem as you see it
I'd like to have a more emoji-focused series of Supertags and Fields so as to not take up as much visual space with text characters (which can clutter the screen). I already have a long-standing and pre-established system of emojis. Example: represents "Tasks" and all tasks gets that emoji applied. It's impossible to search for emojis quickly when filling applying a Tag (it requires pulling up Raycast and searching, which is inefficient), but it's easy to search for the word "Tasks."
Right now I have a hacky solution for this that involves CSS replacing supertag text with what's found in the description (a single emoji). It works well enough, but a native solution (especially also for Fields) would be ideal.
Why is this a problem for you?
Again a desire for a cleaner aesthetic that is more emoji/graphic/icon oriented than text oriented.
For fields especially, the way they're displayed makes it really challenging to use Tana in a "thin" window, often pushing the content of the fields underneath the name of the field. If instead the Field names were all emojis or icons, that first column could be quite thin, leaving more room for the Field's content. And while you currently can set Fields up with emojis, it then becomes very hard to search for and re-use them.
Suggest a solution
Add the following new top-level field (next to Name and Description) for all Tags and Fields: Emoji or Icon.
Emojis are preferred since they're universal, but it would also be nice to support other icon libraries like Font Awesome icons for folx that want a monochrome aesthetic. Separate the Emojis and Icons by source and then by category, allow the toggling on and off of different libraries, and include a search feature for this pop-up (that uses the same Emoji descriptions as found in Raycast, and the same Font Awesome descriptors as found on their website).
Thanks!
3 Comments
Alternatively, simply have the CMD+K > Add Tags > list also search the Descriptions of the Tags, then we could set Emojis as the name of the tag but still search by way of their Descriptions.
I agree. Relatedly, it would be a huuuge quality of life improvement to have a "icon" node field (in the same vein as how you can add a banner image).
For now one can put an emoji at the beginning of any node but it's not really the same (esp vs. having a set of drawn, colorable icons). I think it would be a small change that would give a comparably large improvement in the look-and-feel of Tana.
Although I'm 100% pro-Tana, I think this is something that Notion has done well and (other than a few other Markdown formatt-y things like headings) is the main reason why pages and tables in Notion sometimes look "prettier".
RE Adam's initial point, it would be really cool as well if supertags could have an icon field too, and the icon gets prepended (or otherwise shown somehow) to any node with that tag. I love that supertags can optionally have colors, and I think they should also optionally have icons. Again, I know you can sort of accomplish this with "build title from fields" but it isn't quite the same and I think having the aesthetic of a nice icon set would go a long way.
Have you tried this? https://tanacommunity.slack.com/archives/C02DP78UXHP/p1726144439882029
Hi all, I am not sure if it's actually a bug, but it FEELS like a :ladybug:
Workflow Setup
Outcome
Now, what I don't get is in which order the options are presented when I select the values. They seem to be in a complete random order. As you can see, they clearly don't represent "usage" (frequency).
Painpoint
:thinking_face: How can I fix that?
Thank you! :hugging_face: