1: A node. 2: A field name. 3: A field value.
Examples of types of structured information:
Publishing dates (date format)
E-mail (email format)
Order number (number format)
Task status (options format)
Attendee (supertag instance format)
Comments (plain format)
Types of fields
Every field has two components:
Field definition: The template of the field, which consists of a name and type of field, and its configuration.
Field value: the value of the field, which can be manually input or automatically initialized when applying a supertag.
There are many words for Fields in other contexts, such as Properties, Attributes or Metadata. What's important to understand is that they apply to a node, and become part of describing that node. You can create a named relationship between two supertags (#person is an >Author of #book), formalize what the node is through its properties (a #person has an >Address, #meeting has >Date, #task has a >Status), and use Fields to further define and add supporting information about the thing that the node is representing.
Stand on an empty line and hit >.
You can immediately give it a name. To configure it further, click on the field icon or Cmd/Ctrl + K -> Configure Field
Every time you invoke > and begin typing, you are searching from a list of available fields which you can reuse, or you can create a new field with the exact name by hitting Cmd/Ctrl + Enter.
Creating fields in the supertag configuration: you can add a field by using the [+ Create Field] button, or using > as described above.
Creating fields from the (+) node: Click on it and select [Insert Field]
The place you create a field becomes the primary instance of this field which carries the field definition. This can be anywhere in the graph, including inside Supertag configurations.
If you delete the field definition or its parent, and you used the field in other places, they will now appear with a trash icon alongside the name. This is intentional to prevent old data from being deleted.
To better preserve the Fields you create, move them to the Schema. Field definitions that are owned by the schema also get priority when searching for fields.
In Search nodes: Fields can be used to narrow down on supertag searches like "Find items with supertag #meetings with field Attendees=Jane Doe" or "Find items with supertag #persons with field Role=Developer"
Here's a search for exercises to work back or abs with the equipment available
You can also search for the field itself. Add the field and the system field value SET, or add the field definition through @[field name]. This will return all nodes that carry the field. To see just the node and field, use Table view and hide all columns except for the field you want.
In Table View: When a node with child nodes is shown as a Table, the Fields of the child nodes are shown as columns. Adding a column to a table adds a field to the node. If the table is showing results based on finding a supertag, users will receive a suggestion to incorporate the new field into the supertag definition.
In Cards View: Fields can be displayed as extra information on a card by selecting them through Display. Tip: If you have a field which contains an image, the image will fill the bottom of the card.
| Types | Description |
|---|---|
| Plain | Plain is the most flexible type of field. It acts just as any other place in Tana where you can write anything. Ideal for data that is unlikely to be repeated (e.g. Bug description) or does not need data validation (Options, Dates, Emails, URLs etc.) |
| Options | Options let you provide a preset of options you can select from in a dropdown menu. Pre-determined options allows you to define the options straight in the field configuration. Each node becomes an option. Can be reference nodes. Nested nodes are not visible. Sources of options allows you to pull in one or more nodes whose child nodes you want populating the options list. Nodes can be a mix of different things: created straight in the field configuration, or added as a Reference to a list of static nodes, or a Reference to a Live Query. Auto-collect values is turned on by default on this field type, and will make it so all values you type in during input are collected and shown as options the next time you make an input on another instance of the field. The first input becomes the primary instance of the option; deleting it will cause references to this node to appear with a trash can. Move the primary instance to the Library or elsewhere to avoid this. The collected values can either be the sole options for the field, or they can exist alongside Pre-determined options, and Sources of options. |
| Instance | Instance refers to Supertag instances. Select a supertag in configuration and a dropdown list will be populated based on the instances of that Supertag. Writing in a new value will prompt Tana to suggest that it be tagged with the same supertag. |
| Date | Date fields accept Tana dates that link to the Day node. Press space or use @ to enter date. Right-click on date to change it, or to navigate to the Day node. |
| Number | Number fields are for fields that have just numbers in them. This will give you the ability to do calculations in Tables, and lock a field to a phone number by setting max. or min. value of digits. For example, one might want to make a "rating" field between 1 and 100. |
| User | User fields prompt you to put in a user of the workspace with @, like @Olav Sindre Kriken in the Tana workspace. |
| URL | URL fields store URLs / external links. |
Email fields store email addresses | |
| Checkbox | Checkbox shows the field as a checkbox toggle instead of a field you can write in |
| Name | Description | Title expression |
|---|---|---|
| Description | The description of a node. Add a description in the node config or by hitting Ctrl+i (Mac) or Alt+i (PC) | ${sys:description} |
| Created time | The date and time when the node was created | ${sys:createdAt} |
| Last modified time | The date and time when the node was last modified | ${sys:lastModifiedAt} |
| Last modified by | The user who last made edits to a node | ${sys:lastModifiedBy} |
| Modified by | A list of users who modified the node in the past | ${sys:modifiedBy} |
| Owner | The owner of the node. A node can have many parents, but only one owner. | ${sys:owner} |
| Tags | Supertags applied to the node | |
| Workspace | The workspace a node belongs to | |
| Number of references | Number of times the node is referenced across all available workspaces | |
| Calendar date | Date based on ancestor calendar day the Node/Field is nested under. | ${sys:dateFromDayNode} |
| Done | Whether a node is checked or not (Yes/No) | |
| Done time | The date and time of when the node was checked (only gets set when checking the node, not through done-state mapping) | ${sys:doneTime} |
Wouldn't it be great if Tana could automatically fill out fields for you, so you wouldn't have to? In some cases, that's possible. Fields can auto fill values, so you can specify how their content should be autofilled when a supertag is added to a node.
One of the things that set Tana apart is the ability to attach data about a node directly to it.
In this lesson you'll learn about is-a and has-a – something that will immediately unlock powerful workflows.