Plain Text, Date, and Checkbox Fields: The Tana Fields Series #2
Continuing our Tana Feilds Series, this edition deconstructs Field types: Plain Text, Checkbox, and Date types - what they are and the best use cases. Future editions will deconstruct other field types, such as Options and Date field types.
Thank you for your continued support. I'm on a mission to help the less tech-savvy community enjoy Tana's power. Your questions help me do that and are always welcome. Post questions in SLACK DM me in SLACK (here’s a Slack invite), in our exclusive Substack subscribers-only Chat (including free subscribers), or Twitter.
TABLE OF CONTENTS for
2024.02.06.v#14.web.268.7.0
Field Types Covered in this edition:
Plain Text Fields
Use Cases
Configuration Options
Beginner Gotchas
Date Fields
Use Cases
Configuration Options
Beginner Gotchas
Checkbox Fields
Use Cases
Configuration Options
Beginner Gotchas
PLAIN TEXT FIELDS
Although Plain Text Field is the first choice on the Field Type Option dropdown, it really should be your last choice.
Plain Text Fields hold any type of information you want: just text, numbers, dates, tagged or not tagged info, — anything.
It’s your last choice because the other options field types enable other functionality you don’t get with Plain Text.
First, see if one of the other field types fits your needs, and if they don’t — then use the type Plain Text Field.
🌟 USE CASES FOR PLAIN TEXT FIELDS 🌟
When you don’t need to search on the field’s value.
Use PLAIN TEXT FIELDS when the field value is information you probably won’t search for in the future. That’s not to say you won’t be able to search on a PLAIN TEXT FIELD value, but it’s not very efficient or intuitive (you may need to use regex to get the expected results)
When your values are not alike or repetitious.
If your field values all represent a group of similar things, then PLAIN TEXT FIELDS is NOT the best choice. But if they are NOT alike, then PLAIN TEXT FIELD is the way to go.
In our #book example, you might have a field named “NOTES.” Notes could be anything - it might be a date, the ISBN, comments to yourself, actual notes, or even an image, thus representing values like this that are NOT alike and best suited for PLAIN TEXT FIELDS.
However, the values for Fields such as author, genre, or title — ARE ALIKE (as every book has those, and you might want to search on them); thus, Plain Text Fields would NOT be a good choice for those kinds of Fields.
Note that homogeneous (or ALIKE field values) does not mean the SAME data, but just the same type of data (like the values are all authors, or all genres, etc.) Thus, Plain Text Fields would NOT be the BEST fit for homogeneous values (although it would technically work).When your values do not need data validation.
Because the Plain Text field type allows for anything, it does not validate what is entered. Note that Tana does keep you from entering data that does not fit the field type - it just lets you know it doesn’t match. So, the term “validate” is a bit of a misnomer.
Nothing more than just another NODE
The value of a Plain Text Field is really nothing more than just another node. Just like if you type a node on your DAILY page without a supertag - it’s just a Plain Text node.
🛠️Configuration Options for Plain Text Fields 🛠️
The configuration settings discussed in the previous article apply to Plain Text Fields. Those settings include Required, Hide Field, Used In, and Actions.
Another option, Auto Initialize, comes up after you choose Plain Text Field. Initialize means to automatically fill the field based on the selected parameters. For Plain Text Fields, there is only one option to either turn on or off. If you turn Auto Initialize on, Tana will automatically fill the field with the value from the same field above it in the hierarchy.
In the example below, we use our #book example again. We’ve got an excerpt from the book (at the bottom). After we read that excerpt, we took notes on it (#thought tag). Later, when we see that note, we want to be able to track it back to its source, so we include in the title, author, and rating of the book from which it came. And since we don’t want to retype all that, we use the initialization options.
Let’s track through the logic of this option: Initialize to Value from Ancestor with this field.
In this example, we are using the field Rating which is a Plain Field. The Auto-Initialize setting is turned ON. So Tana —
#1 - first looks at the field name Rating,
#2 - then goes up (ancestor) the outline (aka hierarchy) to find the same field Rating, takes the value from that field (which is 1), and
#3 - enters that value into the value for the lower Rating field.
⚡️Beginner Gotchas on Plain Text Fields⚡️
One thing that can be confusing for beginners is that Search Queries use PLAIN TEXT nodes as SEARCH OPERATORS and FIELD VALUES. These types of PLAIN TEXT nodes have specific functionality assigned to them in a Search/Queries that PLAIN TEXT FIELDS do not.
When using Auto Initialize to Value from Ancestor with this field. Be sure to use the exact same field. Remember, there can be two fields named the same. If you use two different fields that have the same name - it won’t work. One way to determine if you are using the same field is to open the Field Configuration screen (click on its icon) and temporarily add any character after the field name. You should see the other field name in your example change as well. If you don’t - it’s a different field. You can now delete the added character.
Auto Initialize to Value from Ancestor with this field only works the very first time the tag is added to the node. If you add a value to the ancestor node AFTER you tag the lower node - it won’t work. Or if you have existing nodes, you’ve tagged #thought (aka instances) and then decide to turn on auto-initialize - it won’t update those prior nodes tagged #thought.
A way to get around this is to untag those prior nodes and retag them - then, it will auto-initialize. Untagging it is safe to do, you won’t lose any data you previously entered.
DATE FIELD TYPE
Date field types represent a date that connects to your Day node. The value in a Date field is called a Date Object in Tana terms. And the only reason that matters is that a Date Object is NOT the same as your Daily Node (aka day tag). They are related - a Date Object (a reference to a date entered as shown below) is shown in the reference section on your Daily node.
To enter the date, you have the following options:
Press the space bar OR the calendar icon to the far right of the node - and the date picker will pop up, as shown below.
Enter the ‘@’ symbol, followed by natural language such as “today,” “tomorrow,” “yesterday,” “in five days,” “week 5,” “next week,” “next month,” “next quarter,” “next Wed” (or Thurs, Fri, etc.). You can also include times such as “5:00 pm next Wednesday.”
Enter the ‘@’ symbol followed by a date format such as 3/5/2025 or 06/04/27 - Press Enter when the date appears in the popup.
If you enter the date without the ‘@’ symbol, such as 3/5/2025, then insert the ‘@’ symbol at the beginning of the date and right arrow over until you get to the date in the popup. As you move over the date with the right arrow, it will choose month, then move to month and day, and when you get to the end, show you the whole date.
CMD k > insert date or insert date and time - select the date option desired
To choose just the year and/or month, delete the ‘day’ or ‘month’ by clicking on the “x” in the upper right area of the day or month box. Note that deleting the month will also delete the day and leave you with the year only. Deleting the day will leave you with the year and month. There is no option to delete the year.
These options (year only or month and year, can be used for planning purposes). You can click on the Monthly Node for February and see all its references.
🌟 COMMON USE FOR DATE FIELDS 🌟
To view nodes on a calendar: Using the Date field lets you view a group of nodes on a calendar based on those dates.
The search below shows all ‘todo’ using the view option ‘calendar’
To see references in the Daily node (as shown previously)
To search on specific dates, date ranges, and calculated dates- Using dates in searches is very powerful and flexible. Below are a few examples of how to use dates in your searches.
Search using a Date with Less Than
Search for nodes between two dates.
Use the Greater Than (GT) and Less Than (LT) search expressions to create a search between two dates.
Search with Relative Date
You can enter a date or natural language dates such as Today, Tomorrow, or Next Wednesday.
Search with PARENT and Calculated DATE
This search would be on a Daily node. PARENT refers to the date on the Daily node. PARENT +8 says the date of the Daily node plus eight days.
🛠️ Configuration Options for Dates 🛠️
The configuration settings discussed in the previous article apply to Date Fields. Those settings include Required, Hide Field, Used In, and Actions.
There are three Auto-Initialize options for Date fields:
To the current date - which, no surprise, enters the current date into the Date field value. The node does NOT have to be on the Day node for this to work. It can be anywhere.
To date of ancestor day node - this option requires the node to be on a Day Node for it to work. It will look at the date on the Day node where the node exists (in this case, our node tagged #thought) and enter that date. Note this doesn’t have to be the current Day node; it can be a past or future Day node, and it will enter the data of that Day node, regardless of the current date.
To value from ancestor with this field - this is the same as the Plain Field above.
⚡️Beginner Gotchas on Dates ⚡️
Don’t enter a date in the format of 3/5/2023 or 6/6/27 without using the ‘@’ symbol. Tana does not recognize that as a Tana-date and it will not link that node to your Day node (thus, missing out on a cool Tana feature).
When choosing a date from the popup list (when using the ‘@’ symbol), be sure to pick a node with the date calendar Icon on it, as shown below. Otherwise, it is NOT a Tana-date.
The same gotcha as noted in Plain fields regarding using the same field in both locations when using Auto-Initialize from value of ancestor with same field.
Checkbox Field Type
A ‘Checkbox’ field automatically inserts a box for its value. It can be checked or unchecked in instances.
A checkbox field used in an instance:
To do a search using this Checkbox field, list the field, and if you’re searching for nodes with the box checked (checked = yes), then the search looks like this:
🌟 COMMON USE FOR DATE FIELDS 🌟
Use the Checkbox field anytime you want a yes/no value: checked or unchecked. It could be used to identify items reviewed, read or not read, processed or not, and so on.
🛠️Configuration Options for Checkbox Fields🛠️
The configuration settings discussed in the previous article apply to Checkbox Fields. Those settings include Required, Hide Field, Used In, and Actions.
A Checkbox field, like a Plain field, has only one Auto-initialize option: To value from an ancestor with this field. And works the same way.
⚡️Beginner Gotchas on Checkbox Fields⚡️
Don’t confuse these Checkbox field types with a “checkbox” node created using CMD>Enter that creates a system-recognized ‘todo.’ A checkbox field does NOT create a ‘todo’ - just a box you can check or uncheck.
A search for all #todo, like the one below, will NOT bring up the node that includes the Checkbox field. The node “Movavi Screen Recorder,” with the checkbox field, did NOT appear in the results.
This enables you to use the Checkbox field more like a checklist rather than a task.
When choosing a Date field for a search or a Date field to be added to a SuperTag, be sure to select your own field and DO NOT select a system’s date field. These system date fields were created in the early Tana days, and their function is limited and cannot be used with LT, GT, or Relative date operators. Thus, system date fields should be avoided. They still exist to support older uses.
The same gotcha as noted in Plain fields regarding using the same field in both locations when using Auto-Intialize from value of ancestor with same field.
WRAP UP
That finishes our deconstruction of the Plain Text, Date, and Checkbox fields.
Future editions of the Tana Field Series will cover the following:
Field Types:
Options
Instance
Number
User
URL
eMail
Building Title from Fields
I'm not an expert at Tana, nor do I work for them.
As a passionate volunteer and avid user,
I research these deconstructions to help me learn,
but I write them to help you learn from my mistakes.
I've done my utmost to ensure the accuracy of this information,
including extensive testing and review
by other Tana users more experienced than I am.
That said, I'm human.
I sometimes get it wrong
(please don't tell my husband I admitted that ☺️).
If you find an error or have questions- please comment below,
use my exclusive Substack subscribers-only Chat (including free subscribers),
or DM me in SLACK or Twitter
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.
Tana development has so far catered to the tech-savvy, early adopters, but I’m here to change that. Please do not be intimidated by Slack posts. I fear many newcomers are not asking beginner questions because the technical wizards are geeking out about the newest features, and maybe some of you find that intimidating! (I know I did!)
Let me say this - I have your back 🤝.
P.S. I value your trust. I will NEVER share your email address.
Thanks Dee for the detailed series you create. I know that I can refer to them to get precise examples when I'm stuck and this is exactly what this one did today!