Darren Brierton

@Matt Rodeghero , Tana is still beta software, you really need to try to follow at least the announcements channel on Slack to follow what is going on. The iOS app is available via Test Flight, i.e. it is not in general release on the app store. The full details are on Slack.

As Odin reminded me today, this is already possible. Just adding a reference to a node in a line on its own in the query builder will limit search results to its descendants.

Hide empty groups toggle in Notion:

As Ready mentioned above, how Workflowy does it is pretty much the exact functionality I had in mind:

https://www.youtube.com/watch?v=zOJvL0Qv1u4&t=223s

LOL. Now I feel bad. I presumed that you used the Workflowy feature. As I said in my original comment, I'm never going to stop using Keynote. But there are times when I just want to say to a couple of my colleagues, "Hey, come over here, I've got an idea for how to fix this!" and a simple no-frills presentation mode in Tana would be perfect for those scenarios.

Ready, you're not going to upvote the idea?

I was just about to create an idea for this myself. I think that this would be a great feature to have. I'm never going to stop using Keynote when I need to do a really fancy presentation with transitions and animations, and complex text formatting, but I can easily envision circumstances where I've got some notes about something already worked out in Tana and I just want to quickly present it to my colleagues.

"View as presentation" or "View as slides" on a node would make that node a fixed title at the top of the screen. Each child node would be an individual slide, with the descendants the contents of the slide. Font size would automatically be increased, the sidebar would be hidden, and one could navigate through the slides using the cursor keys.

Logseq has a plugin called bullet threading which highlights the current node in a very unobtrusive way. It appears to be very popular with Logseq users.

I've added a separate "idea" for dependency management that is closely related to this idea. Consider upvoting it if you upvoted this.

https://ideas.tana.inc/posts/490-new-semantic-function-dependency-of

Another example of someone asking about this on Slack.

Given that the existing Node Filters for commands are based on what is available in queries (live search) in general, it would seem that your idea would be better framed as an idea for extending live queries.

SVG images work now as of web@256.0.2! Thank you.

So, first of all I wanted to say congratulations on this new feature. I imagine it probably works great for many of the most central use cases, and I also imagine that you never intended it to be the final word for all use cases. I also imagine that it might be useful for you to know about concrete use cases where it perhaps does not work quite so well, so in that spirit I thought I'd explain in depth something I am using Tana for.

I do appreciate that this is going to sound extremely niche, and in its specifics it is. But I also think it exemplifies a more general pattern that might be exemplified by people who use diagrams or flow charts to document particular sorts of things — network diagrams or project management flowcharts for example.

Apologies in advance for the length of this post, but I think I need first explain as briefly as I can what it is I am doing. I've been an amateur drummer for decades, and over that time I have amassed a huge collection of exercises, rudiments (short sticking patterns that are like the alphabet for drummers), and rhythms and grooves, mostly jotted down on scraps of paper. These are all short musical phrases, often just a couple of bars long, not sheets and sheets of music. I am slowly engraving them all in Dorico, and exporting as SVGs which I then import into Tana where I tag them and classify them, write notes, and relate them together. Unfortunately, the new image format is not working so well for this.

The first problem is that tag names are displayed on top of the images, often making them hard to read:

Even worse, in cards view for some reason the tag name is repeated, once above the image and once again on top of the image, this time almost completely obscuring the musical notes themselves:

Second, the name is displayed in a muted grey colour, centred beneath the image. I'm sure this works well for captions of images which are like floats in a longer document, but when it is supposed to be the title of something it's actually quite hard to read:

The tag name is far more prominent in the screenshot above than the actual name of the node. This is made worse when a node is expanded:

Here the title, 50 Ways to Leave Your Lover, is almost completely obscured by the image above and the fields below. (And note that again, the tag name obscures part of the music.)

Returning to the screenshot before the one above, the centred layout is odd here. Music is always left-aligned, and it feels really odd for me to read them like that. The enforced centring here is not an insurmountable difficulty, but it makes things harder to read comfortably.

Finally, when you zoom into a node it looks like this:

I'm not quite sure what is constraining the height, as the image is an SVG and so presumably lacks an intrinsic height. As it is, the image is a little small.

It seems to me that the best way around this is for you to add a small number of built-in image layouts, rather than just one. I am not suggesting adding endless user configuration options, I dislike that idea almost as much as you probably do. But a few curated layouts (less than a handful) designed by the Tana design team surely could cover most eventualities. One which left-aligned the image, had the title and tag on the same line, left-aligned also, and which set the title in a brighter colour would work perfectly for me, and I'm sure others too.

Another option might be to have different layouts depending on whether an image was tagged or not.

Thanks for taking the time to read this.

For live queries this exists already:

The problem with search operators such as the ones suggested, and with PARENT and GRANDPARENT, is that they are too fragile, searches that use them break as soon as you change something's indentation.

I'd like to see an ANCESTOR WITH TAG which took one argument (a tag) and matched the nearest ancestor node tagged with that tag. So in the original example

/- Level 1 #book
/-- Level 2 #chapter
/--- Level 3 #topic
/---- Level 4 #paragraph
/----- Level 5 #sentence

a search node nested under level 5 with the following query

ANCESTOR WITH TAG #chapter

would match the level 2 node.