Darren Brierton

Explain the problem as you see it

This is related to (complementary to) the idea for a Gantt or timeline view.

Currently it is not really possible in Tana to indicate that some todos may need to be done sequentially, in a particular order.

Why is this a problem for you?

This can make managing even relatively simple todo lists difficult. For example, a student may need to complete a reading assignment before beginning an essay. Obviously the problem becomes much more acute in larger project management contexts.

Suggest a solution

A new semantic function "Dependency of" would provide the first step in encoding this information.

Corresponding new search operator(s) (as COMPONENTS REC is to "Part of") would allow for finding both what something was a dependency of, and what was dependent on it.

If at some point field value functions were introduced we could automatically mark a todo's status as "Blocked" if it had dependences that were not done. Filtering for this in a todo list query (i.e. all todos not done and not blocked) would then allow the list to be autopopulated by dependents as dependencies were marked done, allowing for good sequential task management.

If at some point a timeline or Gannt view was introduced we could automatically adjust start and end times of something when its dependences were adjusted.

Explain the problem as you see it

Just to be clear from the outset, this isn't really a request to embed queries inside other queries, rather it is a request for a certain type of query functionality that, given Tana's current queries, is most readily described in that way.

Sometimes I would like to be able to search for nodes whose field values themselves meet certain criteria, i.e. find some nodes that meet one criteria, and then further filter the results based on the properties of the field values of those nodes.

At other times I might want to search for nodes that meet a criteria, but then return the value of a particular field of those nodes.

Although the two case are different, they strike me as related: in both cases first a set of nodes is queried, and then a second action is taken based on the field values of the first query; in the latter case the field values are themselves returned as the end result of the query; in the former case the query is further refined based on the properties of the field values.

Why is this a problem for you?

This idea was prompted first by two different users on Slack asking within a few days of one another if this functionality was already possible. Both their use cases struck me as quite compelling. Those comprise the first type of case described above. Then I myself realised that I wanted to perform a search that wasn't yet possible. That was the impetus for the second type of case described above.

Type One

Sven Bendel wanted to be able to find only tasks assigned to projects with a certain property. So if you have a #task tag with a >Project field, which is an instance field for tag #project which has a >Status field, he wanted to be able to find only #task instances whose >Project value was a #project instance whose >Status was "Focus".

Jessica Peters-Banton wanted to be able to find tasks whose current status was blocked, but where the blocking task had status done. In other words, find tasks currently marked as blocked which might actually no longer be blocked. If we have a #task tag, with a >Status field and a >Blocked by field (an instance field for #task), then she wanted to be able to search for all #task instances with a >Status of "Blocked" and a >Blocked by value being a #task instance whose status was "Done".

Both use cases strike me as compelling. They seem to be genuinely useful types of search that many users might want to perform. And in both cases they articulated what they wanted to do as embedding another query inside an existing query where a field value would normally be specified. Although I don't believe that would be a good way to actually implement this feature, I think it is telling that that is how users conceptualised what they wanted to do.

Type Two

I have a #book tag with a >Topics field (an instance field for #topic). I generally create instances of this tag when I buy a book, but I don't necessarily read a book the same year I bought it. I also have #reading log tag, where I note on my #day nodes what I read that day, and that tag has a >Book field which is an instance field for #book tag. Let's say I wanted to see what books I read in a certain year, or which topics had preoccupied me. As things stand this is not possible. I can query all the #reading log instances from a particular year, but as each book may have a dozen or more reading logs associated with it that is not a very clean way to quickly see the books that I read, and there doesn't seem to be any way from there to see the topics.

What I'd like to be able to do is to run a query that returned all the #book instances that were the value of a >Book field of a #reading log instance from this year. I'd also like to be able to take this a step further and run a query that returned all the #topic instances that were the value of a >Topic field of a #book instance that was the value of a >Book field of a #reading log instance from this year.

The most natural way to describe these sorts of queries is as queries on queries (on queries), although I want to reiterate that that does not strike me as a good UI.

Suggest a solution

If I could suggest a solution to this I'd be expecting a job offer from Tana!

But for type one case perhaps a WHERE VALUE field value operator might work in conjunction with dot notation:

#task
>Project      WHERE VALUE.Status      Focus

For type two cases, perhaps something like

#book    WHEN VALUE IN    #reading log
                          >Book      VALUE

and

#topic   WHEN VALUE IN    #book
                          >Topic     WHEN VALUE IN      #reading log
                                                        >Book      VALUE.Topic

Obviously none of these suggestions are particularly user friendly, and the implementation of such a feature depends not merely on the back-end capabilities but also a user friendly way of accessing those capabilities. It's clearly a difficult UX and UI problem to solve, but I think there is a clear use case for query features such as these.

Explain the problem as you see it

As currently the Tana desktop app does not have tabs or multiple windows, the existing panels can become a little cramped.

Why is this a problem for you?

Sometimes I want to keep a node open while I work on something else. But if that something else includes configuring a supertag and configuring its fields I can just run out of room in a single window to work efficiently.

Suggest a solution

There is a new feature in the latest release (November 2023) of VS Code (another Electron app) which they're calling "floating editor windows".

We are happy to announce that with this release you can move editors out of the main window into their own lightweight windows

They are full-powered editor windows, but lack the other features of the main window such as sidebars, panels, terminal, file browser, etc. It would be sweet if we could detach a Tana panel in a similar way. The detached panel could not itself have panels, and there would be no sidebar.

Explain the problem as you see it

The problem with PARENT and GRANDPARENT is not merely their limited scope but also their fragility, simply changing indentation can break live queries (and that also holds for some requested enhancements like GREATGRANDPARENT or ANCESTOR_1, ANCESTOR_2 etc.).

Why is this a problem for you?

Side menu and tabs allow us to create pleasing UIs in Tana, but my ability to use them is greatly limited if they are to contain live queries. For example, a project template like this

Project A #project
    Dashboard
        Tab 1
            Side menu live query for all tasks related to Project A

is not possible because Project A is beyond the reach of GRANDPARENT.

Suggest a solution

I suggest a new ANCESTOR WITH TAG field value that, like FOR RELATIVE DATE, accepts a single argument, in this case a tag name. This field value would match the closest ancestor node with that tag.

So instead of a live query like this, which cannot have its nesting level changed:

#task
>Project PARENT

you could do

#task
>Project ANCESTOR WITH TAG #project

Explain the problem as you see it

There are specific circumstances in which the Title column in a table is redundant. It would be good to have the option to hide it.

Why is this a problem for you?

Let's say I have a task that repeats frequently, but irregularly, perhaps to pay some vendor, "ACME Manufacturing". Whenever they invoice me I create a reminder "Pay ACME Manufacturing" with fields for due date, amount, invoice number. I want to always use the same title, because in all other view and search nodes it is immediately apparent what it is.

But when I want to search for all instances of this, and see how much I have paid them over a specific amount of time, my table looks like this:

Title                       Due date          Amount
----------------------------------------------------
Pay ACME Manufacturing      Mon, 4 Sept       456
Pay ACME Manufacturing      Wed, 6 Sept       987
Pay ACME Manufacturing      Fri, 8 Sept       678

The first column is wholly redundant in this particular search and takes up a lot of room, but there is no way to hide it.

Suggest a solution

The ability to hide the Title column of tables just like all other columns can be hidden.

Explain the problem as you see it

At the moment FOR RELATIVE DATE is tied to searching in terms of weeks or months, but often I am interested in a time period x days in the past, or x days in the future, regardless of what day of the week it is, or what date of the month it is.

Why is this a problem for you?

1. Search nodes that show (for example) events coming up in the next few days are extremely useful in a #day node.
2. If I am tracking my progress in a recurring activity, an exercise like pushups or squats for example, I may wish to attach a search node to that exercise that shows my last few exercise sessions.

Both those searches are not easy to achieve at the moment, although they strike me as common use cases.

For the forthcoming events I can search for next week with FOR RELATIVE DATE next week, but if it's Monday that won't show me anything for this week. I can instead search for FOR RELATIVE DATE this week OR FOR RELATIVE DATE next week, but if it is Friday that will also show events from the past four days. So I have to instead search for NOT LT FOR RELATIVE DATE today AND (FOR RELATIVE DATE this week OR FOR RELATIVE DATE next week). Not only is this needlessly complex, it still doesn't really show me what I want, as on Monday it shows me what is happening in the next 14 days, and on Sunday it shows me what is happening in the next 7 days.

For the exercise example, it is even harder. Let's say I lift weights, and want to track my progress. I don't want to see every weight-lifting session since I started using Tana, I'm probably just interested in my last few sessions, so I can see what sort of progress I am making. The best it seems I can do though is search for FOR RELATIVE DATE last week OR FOR RELATIVE DATE this week. Assuming that I work out regularly, what I probably want to see is something like the last 28 days.

Suggest a solution

Please add next xx days and last xx days as possible arguments for FOR RELATIVE DATE.

Explain the problem as you see it

It would be nice to be able to do some simple date and time calculations, in particular for durations.

Why is this a problem for you?

Let's say that I'm logging my work on a task by using cmd+k and either "Insert current time" or "Insert current date and time" to record the time I started on a task and the time I finished. It would be incredibly useful to be able to, at the end of the week, calculate the total amount of time I spent on those tasks, and also calculate the amount of time spent on those projects that the tasks were related to.

Suggest a solution

A conception of duration, as a system primitive, calculated automatically from any date field that contains a range (a start and end), and new System Start Date/Time and End Date/Time. Durations stored as seconds (or milliseconds) but displayed as human readable years, weeks, days, hours, minutes and seconds. The ability to sum these values like we already can for ordinary numbers.