Welcome back to the third installment of the Tana Live Search Series. In this series, we deconstructed elements of Live Search that make your search powerful and flexible: System Operators, System Nodes, System Fields, and Value types. We will discuss what they are, how they work, why you’d use them, and how they differ.
System operators, nodes, fields, and keywords are the cogs in the engine that drive your search. Keywords are deconstructed in the fourth, and final, article of this series before we move on to other fun TANA features.
Tana's terminology can be confusing. One reason is that some terms overlap, while some features have multiple terms to describe them. I'll do my best to help clarify in non-technical terms.
Table of Contents:
2023.06.23.v6.web.192.0.0
Differences
…System Operators
…System Fields
…System Nodes
Differences
Below we look at each SYSTEM OPERATOR, NODE, FIELD, and FIELD value element and breakdown options within each element, how they differ from other elements, and examples of how to use them and why. Some of these elements, although they can be used in a LIVE-SEARCH (Tana Help Center Live Search page), were not intended for search but as DISPLAY or SORT options within VIEW OPTIONs: list, table, card, tabs, and calendar views. Those elements are called out specifically below.
System Operators
System operators are the heart of Boolean logic. Both Operators and Boolean logic were deconstructed in article #2 Live Search Building Blocks and Execution Order.
In Tana, System Operators include (with links to the prior article details):
AND
OR and NOT
LT (less than) GT (greater than)
CHILD_OF
LINKS_TO
OWNED_BY
COMPONENTS_REC
Items to remember:
Operators compare or match two values.
When entering the operator, the case does not matter (use either lower or upper case or any combination)
An operator is a “field” and thus should be prefaced by the ">" symbol before the operator when entering in the search area.
System Operators are a subset of System Fields (discussed below), and as such, are often referred to as System Fields in the documentation, and are noted as System fields in the drop-down selection list when entering them into the search area.
If you forget to use the ">" symbol, Tana will warn you and ask if you want Tana to fix it (say yes!)
Operators come first
Although we “think”
X OR Yin Tana, you ask for
OR (X Y).The operators always come first
Whereas, other System Fields (below) don’t necessarily come first.
There are various ways you can mess up entering an Operator in the search box (and I’ve done them all!). In most cases, Tana will ask to fix it. However, you can do some one-off key combinations by mistake, which can cause you to enter something that LOOKS right but isn't. To avoid this - get in the habit of using the operator buttons in the search box.
System Fields
System fields are TANA-predefined FIELDS that have specific functions. Like SYSTEM OPERATORS, they compare values. But unlike SYSTEM OPERATORS, these SYSTEM FIELDS are generally one of the values compared. Also, unlike OPERATORS, these FIELDS can be used as both a criterion in a Live Search and as a view option selection to DISPLAY or SORT by (in lists, tables, cards, tabs, and calendar views).
In a Live Search, SYSTEM FIELDS are entered as—wait for it… FIELDS 😉; thus, you preface them with the ">" when entering them into the search box. Or if selecting them as a View Option, you will find them in the DISPLAY button drop-down, displayed in PINK:
We deconstruct each SYSTEM FIELD below.
Name
The NAME of the node - everything to the right of the node icon. You would use this SYSTEM FIELD in a search to find a specific node. In practice, though, there are better ways discussed below.
A limitation of using NAME in a search is that you have to enter the entire name of the node exactly. So it’s much more efficient to find the node via the top search bar.
The NAME SYSTEM FIELD is more often used as a DISPLAY or SORT option in one of the VIEW OPTIONS, as shown above.
You have better options to find a node:
Use the Search BAR at the top of your screen and begin typing in a part of the node name
Use an @reference
Enter the name or part of the name as plain text using regex in a search.
REGEX? What the heck is REGEX?
REGEX stands for Regular expression and is not something a beginner needs to worry about if you don’t know what it is already. But it is a valid way to find a node, so it’s included here. That said, there are a few REGEX examples listed in the resource section provided by Odin from Tana. These are very basic REGEX examples that can come in handy, even for a beginner.
Use a search, then use the FILTER option to filter by name.
Description
DESCRIPTION is the info underneath the node’s NAME. The node description is entered via CTRL + i (MAC) or ALT + i (PC).
Descriptions are not just for descriptions! You can use it however you like. In some cases, such as a supertag, the description clarifies and reminds you what that supertag is for. This helps you maintain consistency.
But any node can have a description. So you might use it for a temporary thought, something you want to follow up on, be able to search on, but don’t want to maintain it permanently in the node. Fields, supertags, plain text nodes, query nodes == ANY node can have a description.
In my fiction writing, I use the node’s description when I want to fact-check something, or maybe search for a better word or phrase later. I include “TK” within the descriptions to surface those nodes later.
Then I can use the System Field (be sure to use the SYSTEM field) Description to find those nodes:
When I’ve completed my check - I delete the description.
Note: in the search above I use a slash before and after the “TK” string I’m searching for. This is a very simple form of REGEX mentioned above. You can use it wherever REGEX is allowed in TANA, and it will find your text string anywhere within the field (not just those that begin with TK, but all node that have TK in the DESCRIPTION). For more examples of basic REGEX syntax, see the RESOURCES section at the end of this article.
What ways can you think of to use the DESCRIPTION? Answer below in the comments, please. I’d love to hear your thoughts.
Due Date / Overdue
This DUE DATE System field is independent of a user-defined Due Date field (see Items to Remember below). At one time in Tana's history, DUE DATE used with OVERDUE was the only date test you could do.
Since then, however, Tana has introduced functionality that allows you to compare either the system DUE DATE or your custom DUE DATE to any date, or range of dates, including the use of LT and GT operators. If you do want to use the OVERDUE system field - you must use the DUE DATE system field—it will not look at your custom due date.
So you can use the system DUE DATE field or create your own - just remember to choose the same one when doing a search—they are not interchangeable. You can still use the OVERDUE value also, but you're more likely to use a range of dates or date comparison to get things like - overdue by three days or due today and overdue, etc.
Example of using the SYSTEM DUE DATE combined with OVERDUE:
Note: technically, you don’t have to include the #task requirement in the above search but I consider it a best practice for clarity (just in case you have DUE DATE in another tag you may not want to appear in this search).
Here is an example of a USER DEFINED DUE DATE with RELATIVE DATES*. This search finds all tasks Overdue, Due today, or Due tomorrow, based on your defined Due Date field:
In summary, you’re better off using user-defined fields for DATE and DUE DATE for added flexibility including:
Use auto-initialize
Coordinate colors with other fields
Hide the field
Combine with “FOR RELATIVE DATES” keyword in searches
None of the above can be accomplished when using SYSTEM FIELDs DATE and DUE DATE.
Created time
Every node has a created date and time automatically associated with it in Tana. You don’t see it unless you use DISPLAY when in VIEW OPTIONS: a list, table, tab, card, or calendar. You can select this system field as a SORT in View Options or in a Live Search.
If you want to see what nodes were created TODAY by your team, the search would look like this:
There will be more about the KEYWORDs, such as FOR RELATIVE DATES or PARENT options, in the next (and final!) edition of this Live Search series.
Closely related to this CREATED TIME system field is another KEYWORD: “CREATED in X days”. It has the same basic functionality but it gives you much more flexibility.
As an example, say you went on vacation - and when you get back, you want to see all nodes created in the four days you were gone.
Of course, you can narrow down that search by including a tag (maybe #project to see only projects created) or a specific responsible party.
Last Modified time
Date and time the node was last changed/updated. This can be used as a Live SEARCH KEY or as a DISPLAY item in a table, list, calendar or card view.
Last Modified by
The user who last changed/modified the node. Works the same as LAST MODIFIED TIME above.
Owner
OWNER is not a person but a place in Tana where the node lives. The default owner is where the node was created. You can “MOVE” or CUT and PASTE a node to a different home.
Why do I care where the node “lives”? 🤷♀️
Generally, you don’t—especially as a beginner. But a good understanding of where a node lives can help you understand how best to delete things and minimize the chance of deleting something you didn’t mean to. I’ll be doing a DECONSTRUCTION on deleting in a future article.
Tags
Using the TAG SYSTEM FIELD is equivalent to just entering the Tag. The two examples below are equivalent: search for everything that has the tag: #project
TAGS is another SYSTEM FIELD that is more useful as a SORT, DISPLAY, or FILTER option in a VIEW mode.
One of the more helpful uses of TAGS is to DISPLAY it when in a table view. It will show all tags associated with a node. Not only the tags that show at the end of the node but also any “extended” tags.
Would you like to know more about “extended” tags, what they are, and how and why to use them? If so, let me know in the comments below.
Workspace
You can limit searches to a specific Workspace(s). Note you can add this to your search in two ways:
Enter the workspace name via an “@” reference and your workspace name:
Or, click the WORKSPACE button in the search box, and select the Workspace's name. They appear differently in the search box but function the same.
The two searches appear the same but the workspace name was entered differently.
Number of References
The number of times this node is referenced. It's the tiny number in the right-hand side margin of the node.
This includes every time this node is shown as a result of a search and directly referenced by you. I hope TANA changes that one day because, for me, knowing how many times I referenced it is the important number - not how many times it shows up in a search.
In the example below, the node "Dunning-Kruger" is referenced elsewhere in the graph six times:
Calendar date from day
The daily page where the node currently resides. Remember above, I said OWNER is where the node lives, and by default, this is where the node was created. But you can MOVE or COPY PASTE a node to a new home. Thus, the CALENDAR DATE FROM DAY can differ from the daily page or node where this node was originally created.
Why would you move a node?
Here are some examples of when I might move a node:
I create a node in one workspace and need to move it to another, such as the Tana Community Resource Hub workspace I maintain.
I mistakenly start typing on the day node, thinking it’s on the current day - but it isn’t. So I move it to the current day.
I like to keep all original nodes of my commands together. I feel this helps me not delete something by mistake. So I have a node called “COMMANDS” under which all the commands are categorized and logged. I create a command on a day page (as I originate almost every node), then MOVE it to the COMMAND node.
🤔 hmmm, would you like to know more about the MOVE command? Let me know in the comments.
Done / NOT Done
Indicates a checked checkbox node. Checkbox nodes are created with entered using CMD/CTRL Enter on a node.
This search can be accomplished in two ways:
selecting DONE from the SYSTEM FIELD drop-down in the search box, OR
typing in the KEYWORD plain text field DONE
Here is option 1:
Selecting DONE from the SYSTEM FIELD drop-down, presents DONE as a field and gives you a box for its value. If you check the box, it will result in all nodes that are DONE; if you leave the box unchecked, the search will result in all nodes NOT DONE.
However - note the WARNING BELOW regarding NOT DONE SEARCHES.
Here is option 2:
Note the dot to the right of DONE, indicating it is plain text. It’s actually not ordinary plain text - it’s a PLAIN TEXT KEYWORD which we will deconstruct in the next issue.
You would replace DONE with NOT DONE to get all nodes NOT DONE but beware —
WARNING: searching for NOT DONE nodes may provide very unexpected results. That’s because all nodes are NOT DONE unless they are DONE (have a checkbox AND are checked).
Well, duh. Of course anything NOT DONE excludes DONE.
But wait. I said ALL NODES are NOT DONE unless checked. That means
TANA cannot distinguish a regular node from a checkbox node not checked
TANA thinks they are the same.
So always include another search parameter when performing NOT DONE searches. Commonly, you would include a tag such as #task or #todo - tags to find all tasks or todo’s NOT DONE - then your results will make sense!
Done time
Time the checkbox node was checked. Done time works the same as MODIFIED TIME noted above.
SYSTEM FIELDS Items to remember:
Multiple nodes can have the same name. So be sure to select the "system field" when you want one of these fields. In the example below, my graph has many nodes named "description," but if I want the system field description - I must select the one labeled "system field."
System Nodes
System nodes are TANA predefined VALUEs with specific functionality connected to them. Please note, these are VALUES to a KEY (see KEY:VALUE concept here if you don’t remember). Usually, the key is a specific field name. Unlike normal values, these system nodes are entered at “FIELDS” themselves using the @ symbol — not as plain text fields. Fortunately, TANA has a fail-safe. If you enter as a plain text field, it will ask if you want to fix it — say yes!
System nodes (and their corresponding links in the previous article) include:
DEFINED
NOT DEFINED
SET
NOT SET
Much like operators, system nodes compare.
For example, a search expression that says:
ASSIGNED TO SET
Tana will search for nodes where the field ASSIGNED TO exists AND has a value - any value.
However, the opposite, NOT SET, works much like NOT DONE. NOT SET results in
all nodes that do not include the field ASSIGNED TO, AND
nodes that have the field but no value in the field
To find only nodes where a specific field has no value - you need to include another parameter like #tasks in the example below:
SYSTEM NODES Items to remember:
SET looks for a specified field THAT has a VALUE
NOT SET looks only for nodes WITHOUT a value, regardless if the field exists or not. Thus, any node that does not include the field — would not have a value—and would be included.
The node DEFINED is often confused with SET. DEFINED looks to see if the field is included - regardless of its value. It's just looking to see if the field exists.
In almost all cases where Tana suggests to FIX, you should.
However, when using DEFINED -- you would decline the FIX if you want to see nodes where the field EXISTS (regardless if the field has a value or not). But for beginners, it is unlikely you’ll find much value in using DEFINED. So, Tana assumes you meant to use the system node "SET," as this is a much more common search.System nodes are Tana-defined nodes (defined by the system), and you reference these using the @ symbol (like a reference) and select the existing system node. Do not enter as plain text.
Thank you for your continued support.
I'm on a mission to help the less tech-savvy community enjoy Tana's power. Whether you're a free subscriber or paid (thank you very much for your support!), don't hesitate to post your questions (even if you think they are dumb!) in SLACK, in our exclusive Substack subscribers-only Chat (including free subscribers),
or DM me on SLACK or Twitter.
This brings us to the end of this deconstruction. Next issues we will discuss some basic features beginners must master to experience the power of Tana. Then after that, we will finish up the LIve Search Series: KEYWORD (PARENT, GRANDPARENT, FOR RELATIVE DATE and more).
And don’t forget to participate in our subscribers-only (paid or free) CHAT, where I post occasional TANA Tips, Tools, and Techniques.
https://substack.com/chat/1340510
Tana Announcements that impact you and additional resources are listed below.
TANA TALKS
Here are the TANA announcements made since the last edition, that impact beginners. I’ve also included some SLACK post that are very helpful:
There haven’t been any general update announcements since our last edition that have a bearing on beginners. There has been a lot of update related to BUILDERS, that I won’t rehash here.
Some really great SLACK posts, though.
One, in particular, I’d like to point out. Theo Koopen, a talented and fellow Tana Navigator and author of the SNaCK Zettelkasten Template (and video), started a thread about approaches to Zettelkasten, incorporating AI (or not), and general notetaking topics.
It’s a great conversation, with great screen print examples. I encourage you to dig in. Here is the Slack link to the post. If you need an invite to SLACK, click here.
NEW TANA Resources:
In the most recent Tana Tour, Ev Chapman interviewed Kamara Simpson about her Tana setup and how she uses it. Great interview with examples of using Tana for personal activities.
Great interview with examples of using Tana for personal activities.
akosbalasko on SLACK released an EVERNOTE to TANA converter
- released a helpful tweet about INBOX ZERO. He provides some great COMMAND examples accessible to beginners. Easy to follow, easy to copy, and easy to make your inbox flow better!
Want to send a tweet to your TANA graph? Stian shares some commands combined with your TANA CAPTURE and INBOX that send the tweet URL to TANA, then with COMMANDS - converts the link to a NODE with an appropriate title and children for the rest of the tweet thread. Another very useful application, created by an expert, and accessible to beginners. Just copy and go.
Like to share tweets using the Tana Capture App, but wish you had more than just the URLs in the inbox? Stian has the solution for you! A template that gives you a button to process tweets in your INBOX, fetch the contents, and generate titles and descriptions. Template Video
REGEX Examples from Odin
If you don’t have access yet to Tana, you can sign up for Early Access on the Tana.inc site, then pop over to the Slack Introduce Yourself channel, and well, eh, introduce yourself. The Tana Team will DM you an invite.
Hi Dee. I love how you've organized all of your bespoke commands into one node and I will follow suit. Where does your "Commands" node live? Do you keep it in the sidebar or do you have yet another node (like "Schema") where you keep things like this?