Options and Options from Supertag Fields - The Tana Fields Series #3
Continuing our Tana Feilds Series, this edition deconstructs OPTIONS and OPTIONS FROM SUPERTAG fields. Here’s an index of all the articles in The Tana Fields Series.
Thank you for your continued support. I'm on a mission to help the less tech-savvy community enjoy Tana's power. Your questions are always welcome in SLACK (here’s a Slack invite), in our exclusive Substack subscribers-only Chat (including free subscribers), or DM me in SLACK or Twitter.
TABLE OF CONTENTS
2024.02.28 | v#16 | web.283.6.5
Field type: Options
Predetermined Options
Source of Options
A list of References as Source
Search Node as Source
Combined Options
Field Type: Options from Supertag (fka Instance field type)
Configuration for each Options type
Auto-Collect
Auto-Initialize
Use Cases for Options Fields
Beginner Gotchas
Tana Announcements
Tana Resources
Options Fields and Options from SuperTag fields are so similar we will cover them both in this article. Then, in the “Use Case” section, compare and contrast when each is best to use. We will start with Options Fields.
Options Field Type
An Options Fields type enables you to predefined outcomes. Think of options as outcomes in a drop-down of choices you see when entering a value for a field, as shown below for the field “Status.”
You can predetermine these outcomes using two methods: PREDETERMINED OPTIONS and SOURCE OF OPTIONS:
PREDETERMINED
OPTIONS FIELDS allow you to pre-define choices that show in a drop-down list when you enter the FIELD VALUE in a SuperTag INSTANCE. If you’re familiar with the drop-down in a cell in Excel, this is the same concept — choosing from a list of predefined options.
Once “Options” is selected as the Field type - the screen changes, adding a box titled Pre-Determined Options; this is where you add your options.
Below is the example ”Status” field set as an Options field using Predetermined Options entered as “Backlog,” “In Progress,” and “Complete.”
You can enter as many Predetermined Options as you choose. You are not limited to three, as shown.
SOURCE OF OPTIONS
The Source of Options choice allows you to use a search to define the drop-down selections or to identify a Parent Node with all preferred selections.
Let’s use the “Status” field in our #book example again, but this time, mark it as an Options Field and choose the Source of Options instead of the Predetermined Options as we did above.
The technical definition of the Source of Options is a “List of references and search nodes, whose children will become options.” Let’s look at each separately - List of references and a Search Node.
A List of References as a Source of Options
If you reference a Parent node, the children of that node will be your predefined options.
The two references shown in the Source of Options box above are references to the two Parent Nodes shown below. In the example, we have two Parent nodes; you can have as many as you need. These Parent Nodes can be anywhere in your graph.
The drop-down, when entering a value for this Status field, looks like this:
As you can see, the children of both parent nodes are combined and shown as your drop-down choices when entering a value for the Status field.
Search node as a Source of Options
The results of a Search Node, which are its children, can also be your predetermined options. As with Parent Nodes (and technically, a search node IS a parent node), you can have as many as you need. In our example below, we have one search node looking for two different supertags:
Note also the search can be a complex as you need, the results of which will be your predetermined options.
Here’s a view of where those supertags are, but note they can be anywhere in your graph - under a Parent node as shown with #status or randomly placed in your graphs as shown with #alternativeStatus.
Here is what the drop-down looks like when entering a value for the field:
Combined Options
List of References and Search Node Options
You can also combine the use of List of References and Search Node options as shown below.
Here are field configurations using both a Search (find nodes tagged #status) and a Parent reference to the “New Parent showing option.”
Here is an image of the original reference nodes and the list of tagged nodes:
In the above, the nodes tagged #status are all under the same Parent Node - this is not required for a search option. But in the second part, where we use the reference node - it is required for the children to be directly under the referenced Parent node.
Combine Predetermined Options, Source of Options Search, and Source of Option Parent
You can even combine all three methods (or any combination thereof). In the example below, on the right, the field is configured as an Options field with Predetermined options, and the Source of Options includes both a Parent Node reference AND a search node. Drop-down results in an instance field’s value is on the left.
As you can see, the results include all choices defined in the Predetermined Options box and the Sources of Options box.
Before we jump into use cases, let’s talk about Options from Supertag Options field.
Options from Supertag Field Type
Options from Supertag is a separate field type chosen from the field type drop-down. This feature was formally known as the “Instance” field type but was changed to “Options from Supertag” in the February 19, 2024 Tana update, presumably to make its functionality clearer.
Once you select Options from Supertag, another box is shown: SuperTag. In this box, enter the supertag. Tana will use all instances of that supertag as your predetermined options. (Remember, an “Instance” is any node tagged with that supertag).
Note, however, that you can only enter one supertag. If you need more than one, then you need to use the Options field type, with Source of Options being a search node.
The drop-down results, when entering a value for this Status field, looks like this:
🛠️Configuration Options for Options and Options from Supertag fields 🛠️
The configuration settings discussed in the previous article apply to Options Fields. Those settings include Required, Hide Field, Used In, and Actions.
Configuration Options specific to Options and Options from Supertag Fields
OPTIONS field type
When you choose the Options field type, you have some other configuration options:
Auto-Collect Values
Auto Initialize
A high-level overview of Auto-Initialize options is covered below. An in-depth deconstruction of each Auto-InitialIze option is covered in Article #4 of this Tana Field Series.
Index to the complete Tana Field Series
Auto-Collect
For the Options field type, Auto-Collect is a toggle ON or OFF. When ON, if you enter a value for the field that is not listed in the Predetermined or Source of Options areas, it will then add it to your drop-down list going forward.
See #1 below: In the illustration below, in the book at the bottom left, “This Will Be the Day,” the value of “Recommended” was entered for the field “Status.”
However, that value was not part of the Source of Options, which included only Backburner, Backlog, Complete, and In Progress.
See #2 below: Thus, Tana puts that value “Recommended” in the collected values list
See #3 below, AND it shows it in the drop-down list.
Note that if the Auto-collect option is turned OFF, the additional values still get collected; they just don’t show the drop-down results when entering an instance.
Auto-Initialize
Auto-Initilize options enable some automation. Based on your Auto-initialize option, Tana will fill in the field values automatically. This promotes efficiency and consistency across supertag instances.
These options are set at the field level in the field configuration screen.
There are six different Auto-Initialize options, and which ones you see in the confirmation screen depends on which field type you choose, as shown below.
For an in-depth deconstruction of each of the six Auto-initialize options, see Article #4 Auto-initialize in the Tana Field Series.
🌟 USE CASES FOR OPTIONS and OPTIONS FROM SUPERTAGS FIELDS 🌟
As the above examples illustrate, various types of Options fields can be multiple ways to get to the same answer — a drop-down for field values.
🤷♀️ So, if they all result in the same thing, which one do I use and why?
Which one you use and why depends on your workflow, the static vs dynamic nature of your choices, the complexity of your choices fron your graph, and on you.
? That doesn’t help me! When would I use one over the other?
Fair enough. Let’s go over some specific use cases.
Use the Options field type when:
You need a simple list of options
that are specific to a single node or a small group of nodes.
The options are unlikely to change frequently,
or if they do, they are easy to update manually (this may not be working as intended; I have a note into Tana. I’ll keep this article updated when I know more.)
The predetermined options are limited to one supertag
The predetermined options “live” in that Supertag, and thus would not be accessible to other Supertag unless they are referenced. Doing this across unrelated supertags sets up scenarios where deleting a predetermined option will have unintended consequences (think trash cans) across supertags.
Use Options from Supertag field type when:
You require a consistent set of options based on one (and only one) supertag.
This ensures uniformity and reduces the risk of duplicate values.
The options are subject to change,
and you want to update them centrally or ad hoc anywhere in your graph. By using a Supertag on any node, anywhere, your options will be automatically updated for any Options from Supertag fields using that supertag.
You want to take advantage of inheritance properties,
where nodes inheriting from a Supertag can automatically gain the options defined in the Supertag, facilitating easier setup and maintenance. For example, Supertag B extends Supertag A, and you use supertag A as your supertag for Options from Supertag, then your results with include Supertag A and Supertag B. This is one way to get around the “only one” supertag limitation of this option.
Choosing the right approach depends on the scale of your project, the need for consistency across nodes, and how dynamic the options need to be.
Use Tana Field type Options with Predetermined Options when:
The set of options is known and limited. This is ideal for situations where the choices are static and not expected to change over time.
You want to ensure users select only from a specific list of choices without the possibility of adding new options on the fly. This requires the configures flag “Auto-collect” to be OFF.
The context of use is straightforward, and the options can be predefined without needing to reference external or dynamic sources.
Use Options field type with Source of Options when:
The options are dynamic and may change or expand over time. This allows for flexibility and ensures the options list is always up-to-date.
You want to pull options from your graph, making the options list more adaptable and contextually relevant.
You want to pull options from more than one Supertag.
The scenario requires options to be populated based on user input or other nodes' content, allowing for a more customized user experience.
The choice between predetermined options and source of options hinges on the need for flexibility, the expected stability of the options list, and the complexity of your selection criteria.
Use a combination of Options field types with both Predetermined Options and Source of Options when:
There is a core set of options that remain constant but also need the ability to incorporate dynamic options based on changing conditions or inputs. This allows for a stable base with added adaptability.
When categorizing tasks where most categories are predefined, there's a possibility of new data types coming up that don't fit existing categories, necessitating the addition of new options.
In field values where, you want to offer users a list of common choices while also allowing input or suggesting alternatives, thus avoiding the dreaded “other” option.
When managing inventories or databases where most items fall into known categories, and new items might require the creation of new categories or options over time, allowing for flexibility and specificity.
This approach provides for consistency and efficiency while also accommodating growth, unexpected scenarios, and user customization.
⚡️Beginner Gotchas on Option Fields⚡️
Tana only suggests—it doesn’t perform data validation
1. Don’t use a Supertag reference with an Option Field Type
You might be tempted to put a supertag reference as a Source of Options with an Options Field type. This won’t work.
You must use Options from Supertag field type if you want to enter just the Supertag reference.
Note however, you can get the same results with the two methods by using the Search for a tag in the Options field type and a Supertag reference in the Options from Supertag field type and shown below. These two method result in the same predetermined options:
2. Don’t try to use two supertags in an Options from Supertag field.
This was stated in the above, but just to make it perfectly clear - you must use only ONE Supertag when using Options from Supertag. It will allow you to enter two, but Tana will ignore anything entered other than the first one.
3. Auto-Initialize only works first time
If you turn on and Auto-initialize feature, it will not go back through your graph and update anything. It only works immediately after the supertag is added.
There is a workaround for this, and it will be discussed in Article #4 of this Tana Field Series.
In the meantime, you might find this helpful: How auto-initialize works.
3. Beware of deleting a Predetermined option
Predetermined options “live” in the Supertag. Thus, if you delete a predetermined option node (in the Supertag), then all references to that option will show a trash can 🗑️ . That means in every instance where that option was selected will show a trash can.
WRAP UP
Future editions of the Tana Fields Series will deconstruct the following:
Auto-Initialize Deconstruction
Field Types:
Number
User
URL
eMail
Building Title from Fields
For all articles in the Tana Field Series check out the index:
.
Since the last edition, Tana has made the following announcements. Here’s what’s in it for you:
Since Feb 5th here are some announcements that you might have missed and what they mean to your:
1. “Move to Schema” button removed from field configuration screen if not needed.
Announcement: Fields living somewhere under schema (but not as a direct child) will no longer show the button "Move to schema" in field config. You don't need to 'move home' from your bathroom which is in your home 🤦🚽 (Nodes and references)
This makes it much easier to know if a field can be moved or not.
2. Create a field - is not longer shown
Announcement: We no longer show "Create ..." when editing a field, but only use the autocompleter to suggest existing fields. (Fields)
When entering a field, such as prefacing it with a “>,” then its name - Tana, pops up a list of potential fields to choose from.
If you were trying to enter a brand new field, Tana used to have “Create a field” <new name> at the top of the list that you selected to create your new field.
Well, this change makes it smarter. If what you enter doesn’t match the field (partially or in whole), then the popup list goes away, and Tana now knows you want to create a new field.
This change added to efficiency. Be aware, however, that whatever you type after the popup goes away - is a new field.
So if you were trying to type the field name “Status” but instead type “States,” the popup would appear until you type the letter “e,” at which time there are no matches, so it disappears. If you type fast and aren’t paying attention, you might have a new field unintentionally. But this is true with lots of things in life - you have to pay attention, dang it!
3. Miscellaneous Field name and description clean-up.
Announcement: We've cleaned up the system fields a bit, adding descriptions to all of them. They are now under a submenu when doing "Add field". We've also renamed a few: Node -> Node name, Description -> Node description, Owner -> Owner node. All existing setups will continue to work. (Fields)
I’m not really sure which “sub menu” they are referring to here, but I did see the new names and better descriptions in the Query box, Systems field button. To see the new descriptions, you need to hover over the ? to the side.
For those who actually read help hints like this, it should help especially for system fields like “Owner” now called “Owner node” so users clearly understand that the owner is a node not a person.
4. We renamed Calendar to Daily Notes and gave it a node icon. (Dates and calendar nodes)
This one is not related to fields, but still important. This change likely is an effort to help users understand that the Daily page is where you should enter most of your information “tag it and go” and it will show up later when you need it — concept.
You’ll only notice this change from your “root node” or “home node” — that’s the one with your name on it (unless you changed it). In there, it used to show “Calendar” with a, you guessed it, a calendar icon. Now it says “Daily Notes,” and it still has the calendar icon.
If I had to guess and mine you, it’s totally a guess (nothing official from Tana), I’d say they are setting up new things related to the “root node,” but likely a way out.
5. New buttons for date navigation on calendar nodes! Right-click on "Today" to navigate to this week/month/year. (Dates and calendar nodes)
This change cleans up the daily page but does remove easy access to week, month, etc. You now need to “right” click on “today” to get those options. You can use the “< >” icons to the left of “today” to navigate to the previous and next date. Very clean.
6. We've renamed 'Instance' fields to 'Options from Supertag' (Fields)
As mentioned in this article but worth mentioning again - Instance field type is now called Options from supertag. This is supposed to make it less tech jargon and clearer as to its functionality. What do you think?
7. You can now drag and drop to reorder tabs. 🤗 (Views)
One last one, also unrelated to Fields, but a welcome change. When you’re in View Tabs mode on a node, you can now reorder the tabs with a drag and drop.
This brings us to the end of this issue. Additional resources related to topics in this issue are listed below.
NEW TANA Resources
(since the last edition):
Several Resources, some new, some old, but all related to FIELDS. They are from Tana Inc. help docs, Tana Navigators, Tana Ambassadors, and outside Tana creators:
Articles on Medium (some may require membership)
How I’m making training notes in Tana
10 Key Reasons Why Tana Has Become the PKM Game-Changer
Tana Subreddit Posts of Note:
How to summarize your voice notes
From Official Tana documentation
Community resources: Tana for Beginners (2024)
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.