Intro to Tana FIELDS: Tana Fields Series #1
Today, we start a series on Deconstructing Tana Fields: Options, Plain, Instance, Date? Which field type do you use and why? Does it matter? If so, when?
This first edition discusses what a field is, how to add a field, whether to move a field to the schema or not, how to use a field outside a SuperTag, and a sideline bonus on a node’s reference section. Plus, it covers options in the Field Configuration screen that all FIELD TYPES have in common. Future editions will deconstruct each field type.
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: 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.02.v#13.web.274.12.3
Introduction to Tana Fields
What is a FIELD?
Defining FIELD Components
How can FIELDS be used?
A FIELD or SuperTag?
Is-A
Has-A
Adding a FIELD
To Schema or not to Schema
How to Move to the Schema
Using FIELDS Without a SuperTag
FIELD Types
Field Configurations Screen
Options relating to all field types
What is a field?
In the simplest terms, a FIELD is just another type of node. So, all the rules that apply to a node also apply to a FIELD.
What so special about a FIELD then?
A Tana Field holds information about something else. The “something else” in TANA is a supertag. Thus, a FIELD holds information ABOUT a SUPERTAG.
So if, for example, your supertag is about #book, then your TANA FIELDS will provide information about the book, such as the book title, the author, the date it was published, and any other information you choose to collect. Another word for this information is “metadata,” which, in layman’s terms, means data about data OR, in this case, FIELDS are data about your book.
As you’ll see, fields are NOT just a way to store information. They can add power and flexibility to your Tana workflows.
Defining Field Components
A FIELD is made up of four components-
FIELD NAME - the first thing you select when adding a field
FIELD TYPE - as defined within your field configuration, shown below
FIELD VALUE - is the value entered for the field in each “instance” of your supertag. Thus, in your #book supertag, any specific book such as “Living a Good Life” is an INSTANCE of that #book supertag.
FIELD DEFINITION - is where all the information, including its NAME and TYPE (and more), is stored in TANA. As a beginner, you won’t need access to the FIELD DEFINITION.
** The word “Instance” is also used as a FIELD TYPE; the two are closely related. Instance Field Types are deconstructed in another edition.
How can FIELDS be used?
We’ve discussed some ways FIELDS are used, but let's summarize those and add more.
FIELDS can be used to define data about your SuperTag or Node.
The rest of this article discusses how to FIELDS in your SuperTag or Node.FIELDS can be used as a search criteria in a Query
The search below looks for all nodes tagged #book, AND the STATUS FIELD has to be set to “To Read”
This next search looks for all nodes tagged #book, where the STATUS FIELD is blank (has no value).
FIELDS can be used as columns when in Table View (and rows are your SuperTag instances). To set a Query (search) or ANY node to table view: CMD/CTRL k > Show as Table
FIELDS can be used to GROUP by option when in List or Card View
FIELDS can be used as SORT options in various View Options
FIELDS can be used as a FILTER in View Options
FIELDS can be used as a way to make the right node, appear at the right time, in the right place.
Using a field outside a supertag for nodes you don’t know what to tag yet is a great way to bubble up notes when and where needed. See the section below, “Using Fields without a SuperTag".
A Field or SuperTag
It’s said by many a Tana pro that,
SuperTags have an “IS-A” relationship, and
FIELDS have a “HAS-A” relationship,
and, somehow, knowing that is supposed to clear up the confusion on whether to use a SuperTag or FIELD. 🤷♀️
IS-A RELATIONSHIP
What the hell is an “IS-A” relationship?
When we talk about "IS-A," we're saying that one thing (“To Kill a Mockingbird”) is a specific kind of another thing (like a book). This helps us understand how things are grouped together and how some things are more specific versions of other things.
“To Kill a Mockingbird” IS-A book — thus, a Supertag #book would be used.
The above is also an instance of the book supertag. An instance can also be considered a more specific version of the SuperTag. “To Kill a Mockingbird” is a specific #book; as is “The Great Gatsby” or “Catcher in the Rye” or any other specific book.
I often think of a SuperTag as a one-to-many relationship — one #book SuperTag to many individual books (aka instances).
HAS-A RELATIONSHIP
Okay then, what’s a HAS-A relationship?
When we talk about “HAS-A,” we are saying a thing has or contains other things. It's a way of describing relationships between two groups.
A node or SuperTag is the “container” that HAS items, called FIELDS, in it. Regarding your #book SuperTag - a book HAS an author (FIELD), a book has a genre (FIELD), and a book HAS a publisher (FIELD).
I often think of FIELD as a many-to-one relationship - many FIELDS belong to ONE SuperTag.
So this IS-A / HAS-A method is foolproof?
The method is almost foolproof when you’re just starting out. However, it’s not 100%. The context of these items also plays a part. You might find, as I have, that some items can be an IS-A and a HAS-A, depending on how you look at it. For example, above, we settled on a #book SuperTag. But for a set of books called a VOLUME, a Volumn HAS-A Book.
Aarrgg, I’m confused again! 😡
Don’t be confused. You'll do just fine for a long time, sticking with the IS-A and Has-A methods. Just like most things in life, it’s more of a guideline than a rule. So don’t get too hung up about it
Adding a FIELD
Typically, FIELDS are added when you’re in a SUPERTAG configuration. [Note: see also Using Fields NOT in a SuperTag below.]
To enter a field in a supertag in the box above, you have a few options, all of which accomplish the same thing:
/ to create
On January 16, 2024, the Tana Team announced the NEW “/ to create” functionality. You can now create a field (and many other things) using the SLASH COMMAND. By entering a “/” - a popup presents items you can create, including a FIELD. Hover over the FIELD option, and the FIELD Types appear.
“>” to enter a field
Use the “>” character to tell Tana you’re entering a field. Enter a “>” symbol, then your field name. This option allows you to enter a new field or select an existing field from the popup list as you type. For new fields, it defaults to a PLAIN TEXT FIELD (which you can change in the field configuration screen—see below).
Click the “New Field” button,
Clicking the NEW FIELD button drops down a selection box of the FIELD TYPES (each TYPE deconstructed in a future edition). Select a type, then a field name, or select an existing field from the pop-up box.
Insert Existing Field button
You can choose the “Insert Existing Field” button (found next to the “New Field” button). I don’t recommend using this button. I have found the drop-down selections are not always complete.
To Schema or not to Schema
Every node in Tana has a home. That home is USUALLY where the node is created: the daily page, a parent node, within a supertag, library, or schema. All Supertags (the actual tag themselves, not an instance where you used the tag on a node) will appear in your SCHEMA even if they don’t LIVE there (Schema will reflect a reference to supertags that don’t live there).
TANA FIELDS also live where you enter them—UNLESS you move them.
So why move them?
You may want to MOVE a field for various reasons:
If you think you’ll use this SAME field in other supertags, you should move the field to your SCHEMA. This will give it “preference” in search results when you’re looking for that field. And if I had a crystal ball, I’d say moving it to the schema for use on multiple tags might be even more significant in the future.
Now, if you use a field in multiple supertags and did not move it when you first created it, it LIVES in the first supertag where it was created. Now, down the road, you decide you don’t want your supertag XYZ, so you delete that SuperTag.
Unbeknownst to most beginners, any field created in that tag will also be deleted. And if you used it in another supertag, you’ll see the dreaded trash can in that SuperTag and all instances in which you used those two SuperTags!If you want to make it harder to delete. Moving a field to the schema makes it less likely you’ll delete the field by mistake (such as in #2 above).
So my recommendation is to move fields to the schema unless you absolutely KNOW you’ll never use them in any other supertag.
HOW TO MOVE to the SCHEMA
There are several ways to move a FIELD to the schema, but the easiest way is from the FIELD CONFIGURATION screen.
Click on the FIELD icon to open the FIELD CONFIGURATION screen
At the bottom of the FIELD CONFIGURATION, select “Move to Schema”
Get in this habit while you’re in the FIELD CONFIGURATION screen.
MOVE to SCHEMA via the FIELD Configuration Screen
Using Fields Without a SuperTag
I mentioned above that fields were “typically” used in SuperTags but don’t have to be. A FIELD can be added to any node!
PKMs are arguably known for two things: connections and retrieval. We all know SuperTags and References create connections, as do FIELDs.
FIELDs can also assist in retrieval. What good is a note if you can’t find it, right? But do you want to add a SuperTag to every node? But how will you find it later if you don’t add a tag? How will the note appear when needed?
Using FIELDS outside of a Supertag can help.
You can type the “>” or “/” and add a field anywhere,
on any node,
NOT just inside a Supertag.
For example, you enter a totally random thought on your Daily Page. You’re unsure how to tag it or if it even warrants a tag. Consider adding a FIELD to it.
Indented under that node, you could add a field (using the “>” or “/” technique). Say the FIELD NAME is “Relates to” and as it’s FIELD VALUE you enter a date. No SuperTag, just a FIELD. With that, you’ll see it in the REFERENCE section on that day’s DAILY PAGE, or perhaps a project name so you’ll see it the next time you bring up the project, or maybe a coworker name, so the next time you talk with them, you’ll see your note. Voila! The note appears when you need it (even if you don’t remember it!) - on that day, in that project, or in that person's node.
As a beginner, using FIELDS outside of SuperTags is underused, but if you grasp this concept, it will open up opportunities in the future.
Field Types
After you enter the field on the SuperTag Configuration screen, you can CONFIGURE the FIELD by clicking on the field’s ICON to bring up the FIELD CONFIGURATION screen.
The power of fields is found in FIELD TYPES, the first thing you choose when setting up a field in the FIELD CONFIGURATION screen.
Click on the box labeled “Field Types” to see the list of types. You’ll notice they are the same as when you were in the TAG CONFIGURATION screen if you clicked the “New Field” Button.
Future editions in The Tana Fields Series will deconstruct each field type.
FIELD CONFIGURATION Options Relating to All Field Types
Some of the field configuration options are specific to a field type. Those will be discussed in future issues. Here, we will cover options that are available for all field types.
The common options include:
REQUIRED - default OFF
Tana never REQUIRES any field, even if this option is turned ON. This option name is a bit of a misnomer. If this option is turned ON - it gently reminds you (so gently, you’re likely to miss it!) that this field is required. It does this by placing a “?” at the end of the field, and if you hover over that “?” it will tell you the field should have a value. But if you don’t put anything in it, Tana assumes that’s what you want and won’t force anything upon you.
HIDE FIELD - default Never
Sometimes, SuperTags have an abundance of fields. Some of which you need all the time, and others only occasionally. This is where the “hide field” comes in. If ON, it will minimize the field and place it at the top of the tag when entering a tagged node.
In the example below, the FIELD Rating is marked ALWAYS HIDE, so you see it at the top (minimized) when entering an instance.
Instead of showing “Rating” below “Status,” the hidden option shows it minimized at the top of the tag template.
There are several options related to HIDDEN. These are:
Never (default value)
It will never hide the field unless you change this to one of the options below. Said another way, it will ALWAYS show the field when you expand the Supertag in an instance. NEVER = ALWAYS SHOW
When empty
The field will be hidden if there is no value in the field. Note that the value must be blank. This option can be used on fields you don’t use often but want on the tag when needed. Set it to “When Empty,” and it will stay hidden until you need it and show thereafter when a value is present.
When not empty
The field will be hidden if there is anything in the field, including the default value. So, if the field has a value, it will be hidden.
When value is default
The field will be hidden if its value is the default set in the SuperTag. This lets you see the field only if its value is other than the default value.
Always
The field will always be hidden regardless of its value (blank, filled, or default). Some folks use ALWAY hide because they don’t want to see a list of fields; they prefer to open them only when needed to keep the clutter down.
USED IN
The USED IN option on the FIELD CONFIGURATION screen tells you the number of nodes this FIELD is used (i.e., the instances) and in how many Supertags. This information is often used when deleting a field and helps you avoid the dreaded trash can 🗑️! We’ll be covering How to Delete a field later in the series.
ACTIONS
The ACTION option is used to either DELETE the node or, as a shortcut to MOVE TO SCHEMA. (See section above “To Schema or Not to Schema”)
ADVANCED
Advanced features are beyond the scope of this article, but stay tuned!
WRAP UP
Future editions of the Tana Field Types will cover the following:
Options Fields
Instance Fields
Date Fields
Number Fields
User Fields
URL Fields
eMail Fields
Checkbox Fields
Building Title from Fields
This brings us to the end of this issue. Stay tuned for more in the Tana Fields Series.
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.
precious advice. Finally I understood the importance of fields in Schema. I never know if to recycle the same field but ideally I would like to. The thing is that I've done it wrong at the start and now I need to do some cleanup!