MASTER Obsidian's Powerful METADATA MENU Plugin - Step by Step

Summary

This video script offers an in-depth tutorial on the 'Metadata Menu' plugin for Obsidian, guiding users through its powerful features for managing note metadata. It covers plugin setup, field types, file classes, and practical demonstrations. The script details the process of creating a new vault, installing plugins, and customizing settings for optimal use. It also explores creating classes for different note types, leveraging lookups for dynamic field values, and integrating with the Obsidian Canvas for a visual workflow. The aim is to enhance frontmatter consistency and efficiency in note organization.

Takeaways

• 📚 The 'Metadata Menu' plugin for Obsidian is a powerful tool for managing note metadata, offering a range of functionalities including context menu items for modifying front-matter and inline fields.
• 🛠️ The plugin requires initial setup, including installing both the 'Metadata Menu' and 'Dataview' plugins, and configuring settings to ensure proper functionality.
• 🔍 The 'Metadata Menu' provides options for field indexing, context menu customization, and various exclusions to tailor the plugin to the user's needs.
• 📝 It supports 18 different field types, each with specific settings that allow for a high degree of customization in how notes are organized and interacted with.
• 🔗 The plugin works with 'fileClasses', which are used to define default fields and settings for different types of notes, enhancing consistency across various note types.
• 📑 File classes can be organized hierarchically, allowing for inheritance of fields and settings from parent classes to child classes.
• 🔄 The plugin includes the ability to create fields that update automatically based on the note's position on the Obsidian Canvas, synchronizing visual organization with metadata.
• 🔑 Auto-completion is available for fields, providing a list of existing values to choose from, which can improve frontmatter consistency.
• 📈 The 'Metadata Menu' plugin can define preset types and values for fields, streamlining the process of adding consistent metadata across multiple notes.
• 🎨 The plugin allows for customization of the context menu, including the option to show all available field options or summarize them under a single menu item.
• 🔍 Users can define global presets for certain fields, and even set up lookup queries to dynamically populate field values from other notes or sources.

Q & A

What is the 'Metadata Menu' plugin and what does it do?

The 'Metadata Menu' plugin for Obsidian is a powerful tool that provides context menu items for notes to modify front-matter and inline fields. It allows users to define preset types and values and offers auto-completion for higher frontmatter consistency.

How can the 'Metadata Menu' plugin be installed in a new vault?

To install the 'Metadata Menu' plugin, navigate to 'Settings', then 'Community plugins', and turn off the restricted mode. Click on 'Browse', search for the 'Metadata Menu' plugin, and click 'Install' and 'Enable'. You will also need to install the 'Dataview' plugin as it is a dependency.

What are the initial steps to configure the 'Metadata Menu' plugin?

After installing the 'Metadata Menu' and 'Dataview' plugins, you need to enable JavaScript execution in the 'Dataview' settings. Then, in the 'Metadata Menu' settings, you can define indexing preferences, context menu options, and various exclusions.

What are 'file classes' in the context of the 'Metadata Menu' plugin?

'File classes' in the 'Metadata Menu' plugin are used for defining default fields, options, and field settings per class. They help in organizing notes based on their types, such as articles, book summaries, projects, etc.

How can you define a new field in the 'Metadata Menu' plugin?

You can define a new field in the 'Metadata Menu' plugin by going to the plugin settings or via a 'file class note'. Each field is defined by a name, a type, and type-specific options.

What is the purpose of the 'Dataview' plugin in relation to 'Metadata Menu'?

The 'Dataview' plugin is a dependency for the 'Metadata Menu' plugin. It enables functionalities like lookup queries, which can be used to dynamically populate fields based on queries that return specific data from your notes.

How does the plugin handle different field types such as dates, numbers, and links?

The plugin supports various field types, each with specific options. For dates, it allows date picking and formatting; for numbers, it provides step increments and range limits; and for links, it enables single or multiple document links with options for aliases and sorting.

What is the advantage of using 'lookups' for defining field values?

Using 'lookups' for defining field values allows for a more dynamic and maintainable way of managing options for fields. Changes made in the lookup note are automatically reflected across all notes using that lookup, eliminating the need to manually update each instance.

How can the 'Metadata Menu' plugin be combined with the Obsidian Canvas?

The 'Metadata Menu' plugin can be combined with the Obsidian Canvas to manage notes and their metadata visually. By dragging notes around on the canvas, their 'cPhase' and 'cStatus' fields can be updated, reflecting the workflow and progress.

What are the steps to update a note's frontmatter based on its position in the Obsidian Canvas?

To update a note's frontmatter based on its position in the Canvas, you need to define fields with the type 'updates with groups in canvas' or 'updates with links in canvas'. Then, map these fields to specific canvas groups or links, and move the notes to the desired positions to trigger the updates.

How can you create a class hierarchy in the 'Metadata Menu' plugin?

You can create a class hierarchy by defining a parent class for a new class. The child class will inherit fields from the parent class, and you can add or exclude specific fields as needed. This helps in maintaining consistency across different types of notes.

Outlines

00:00

📗 Introduction to the 'Metadata Menu' Plugin

This paragraph introduces the 'Metadata Menu' plugin for Obsidian, highlighting its powerful capabilities and the extensive information covered in the video. The speaker outlines the structure of the video, which includes an overview, setup instructions, basics of field types and settings, file classes explanation, and practical demonstrations. The importance of installing both the 'Metadata Menu' and 'Dataview' plugins is emphasized, along with initial setup steps such as turning off restricted mode, browsing for plugins, and enabling JavaScript execution for proper functionality.

05:01

🔧 Configuring 'Metadata Menu' Settings and Field Types

The speaker delves into the configuration settings of the 'Metadata Menu' plugin, explaining options for indexing fields, customizing the context menu, and setting up exclusions. Auto-completion and field indexing status display are discussed, along with global presets for fields. The paragraph also covers the creation of a 'Classes' folder for organizing vault components and setting up a 'fileClass' field with global fileClass settings. The variety of field types supported by the plugin is introduced, with demonstrations of creating fields like input, list single, list multiple, cycle value list, and checkbox fields.

10:01

📝 Exploring Advanced Field Types and Their Applications

This section continues the exploration of field types, showcasing link fields for single and multiple documents, date fields with formatting and navigation options, and number fields with step increments. The paragraph also introduces a lookup query field, a formula field for calculations, and canvas-related fields. The speaker creates a 'Demo' class file to demonstrate adding various field types, including object fields for organizing complex data like meeting participants with attributes and logistics details.

15:03

🌐 Practical Demonstration of Field Types in Action

The speaker provides a practical demonstration of the field types in a new note called 'Field Demo'. The process of adding fields to the frontmatter through the class association and the functionality of each field type, such as input fields, date pickers, link fields, and object lists, are shown. The dynamic nature of fields, like the formula field updating based on number field changes, is also highlighted. The paragraph concludes with a look at how to manually add fields and values in source view versus using the reading view for easier input.

20:05

🔄 Setup and Utilization of Lookup Queries for Field Values

The paragraph explains how to set up a lookup query for a field, using a specific example where pages with the 'article' tag are queried. The importance of having a 'parent' field in target notes for the lookup to work is emphasized. The speaker demonstrates adding a 'parent' field to 'LookupDemo1' and 'LookupDemo2' notes and shows how the lookup query field in the 'Field Demo' note populates with these notes once linked.

25:06

📑 Understanding File Classes and Their Structure

The concept of 'file classes' in the 'Metadata Menu' plugin is explained, detailing how they are used to define default fields and options for different types of notes. The speaker guides through creating a general 'All' class for common fields applicable to all notes and setting it as the global file class. The process of creating subclasses, like 'Project', and inheriting fields from parent classes is also covered. The paragraph concludes with a discussion on using Dataview queries to dynamically populate list fields in classes.

30:06

🎨 Customizing Classes and Implementing Class Hierarchies

This paragraph focuses on customizing classes by adding specific fields, such as 'phase', 'status', and 'priority' for a 'Project' class. The speaker also demonstrates creating a subclass 'Article' under 'Project', inheriting and excluding fields as needed. The use of 'lookups' for maintaining list field values is introduced, with a practical example of creating a 'project phase' lookup note. The benefits of this approach for maintaining consistency and minimizing administrative effort are highlighted.

35:08

🖼️ Integrating 'Metadata Menu' with Obsidian Canvas for Workflow Visualization

The speaker discusses the integration of the 'Metadata Menu' plugin with the Obsidian Canvas, describing how to set up a canvas to visualize and manage the workflow of articles. The process of defining swim lanes for different phases and statuses, and preparing the 'article' class with new fields 'cPhase' and 'cStatus' is explained. The functionality of updating note frontmatter based on their position in the canvas groups is demonstrated, showcasing how moving notes updates their phase and status.

🔗 Updating Frontmatter with Canvas Links and Concluding the Deep Dive

The final paragraph covers the creation of fields that update based on links made between notes on the canvas, such as 'previous chapter' and 'next chapter'. The speaker shows how drawing arrows between articles on the canvas updates these fields, reflecting the sequence of the articles. The paragraph concludes the deep dive into the 'Metadata Menu' plugin, inviting feedback and suggestions for future video topics.

Keywords

💡Metadata Menu Plugin

The 'Metadata Menu' plugin is a powerful tool in Obsidian that allows users to modify front-matter and inline fields with context menu items. It is central to the video's theme as it is the main subject being discussed and demonstrated. The script mentions its capabilities such as defining preset types and values, and providing auto-completion for frontmatter consistency.

💡Frontmatter

Frontmatter in the context of the video refers to the block of metadata at the beginning of a note in Obsidian. It is a key concept because the Metadata Menu plugin interacts with this section to add and modify fields. The script discusses how the plugin can be used to streamline the process of adding and managing frontmatter.

💡Field Types

Field types are the different kinds of data inputs that can be included in the frontmatter of a note. The script explains that the Metadata Menu plugin supports 18 different field types, each with its own specific options and uses, which is crucial for customizing the metadata structure of notes.

💡File Classes

File classes in the video are a way to categorize and manage notes with specific metadata settings in Obsidian. They are a core concept because they allow for the grouping of notes and the application of consistent metadata structures, as demonstrated when creating a 'Project' class and an 'Article' subclass.

💡Dataview Plugin

The Dataview plugin is a companion to the Metadata Menu plugin and is required for its full functionality. It is mentioned in the script as a necessary step in the setup process, highlighting its importance in enabling certain features of the Metadata Menu plugin.

💡Auto-completion

Auto-completion is a feature of the Metadata Menu plugin that suggests existing values when entering data into the frontmatter. It is an important aspect of the plugin's functionality, as it helps maintain consistency and efficiency in data entry, as discussed in the script.

💡Inheritance

In the context of the video, inheritance refers to how subclasses in the file class hierarchy can inherit fields from their parent classes. This is demonstrated when creating the 'article' class, which inherits fields from the 'project' and 'All' classes, streamlining the process of setting up new classes.

💡Canvas

The Canvas in Obsidian is a core plugin that allows for visual organization and workflow management. The script describes how the Metadata Menu plugin can be combined with the Canvas to update note metadata based on the position of notes within the canvas, creating a dynamic and interactive note management system.

💡Lookups

Lookups are a method of defining values for list fields in the Metadata Menu plugin by referencing notes that contain the value lists. The script explains how to use lookups to maintain and update list field values in a more manageable way, such as using a 'project phase' lookup note.

💡Swim Lanes

Swim lanes in the context of the Canvas plugin are sections that represent different stages or categories of work. The script describes creating swim lanes for statuses and phases, which are used to visually organize notes and update their metadata based on their position within these lanes.

💡Templates

Templates in Obsidian are pre-defined structures for notes that can include specific frontmatter and content. Although not explicitly detailed in the script, they are implied as a tool for maintaining consistency in notes, especially when used in conjunction with the Metadata Menu plugin and file classes.

Highlights

The 'Metadata Menu' plugin for Obsidian offers powerful features for managing note metadata.

The video provides an in-depth tutorial on using the 'Metadata Menu' plugin, including setup and practical demonstrations.

To get started with the plugin, users must disable restricted mode and install both 'Metadata Menu' and 'Dataview' plugins.

Settings allow customization of indexing scope and context menu display options for better performance and user experience.

Auto-completion for frontmatter fields enhances consistency and ease of use within notes.

The plugin supports 18 different field types, each with specific options and capabilities.

Field types include input fields, list selections, checkboxes, number fields, link fields, and date fields, among others.

Users can define global presets for certain fields to maintain consistency across multiple notes.

The 'fileClass' feature organizes notes by types, applying specific fields and settings to each class.

Creating a class hierarchy allows for inheriting fields from parent classes to streamline note organization.

The 'Metadata Menu' plugin integrates with Obsidian's Canvas plugin to visually manage and update notes' metadata.

Swim lanes on the canvas represent different phases and statuses, updating notes' frontmatter when moved.

The tutorial demonstrates creating a workflow for managing articles or blog posts using the plugin's capabilities.

Lookup queries can dynamically populate fields from a note, simplifying maintenance of list fields.

Object fields allow for complex data structures, such as tracking participants in a meeting with roles and companies.

The video concludes with practical demonstrations of the plugin's features in action, showcasing its capabilities for note management.

The 'Metadata Menu' plugin enhances Obsidian's functionality, providing a robust system for metadata management and workflow visualization.

Transcripts

The "Metadata Menu"

plugin is quite powerful,

so this video contains

a lot of information.

To make it easier for you, I added more

chapters than usual.

Depending on what you're interested in,

you should be able to

easily jump around between them.

Having said that, if you

don't know the plugin at all,

I suggest watching the chapters in order.

I structured them to

cover five main parts.

First, an overview.

What does the plugin actually do?

Second, the setup.

This covers plugin

installation and settings.

Third, some basics.

Here, we learn about

the available field types

and their settings.

Fourth, the file classes.

The plugin works with

so-called "fileClasses",

and here we explore what

they are and what they do.

And fifth, practical demos.

This is where we put

all of the above together.

I prepared a few showcases

to illustrate the plugin's

capabilities on its

own and in combination

with the Obsidian canvas.

As each of these parts

has various chapters,

you may want to grab a

snack and a beverage.

This is going to be a long ride.

In the official

documentation, the link to which

I left in the description, it says

that the plugin gives us

context menu items for notes

to modify front-matter and inline fields.

It can define preset types and values,

and we get auto-completion for higher

frontmatter consistency.

Sounds great.

But there are a few things we need

to do before we can

reap all these benefits.

For this video, I will

use a completely new vault

so you can see what you

need exactly to make this work.

After creating a new vault,

we have to go to "Settings",

navigate to "Community plugins", and turn

off the restricted mode.

This allows us to

install community plugins

by clicking on "Browse", searching for the

"Metadata Menu" plugin,

and clicking "Install" and "Enable".

Right away, we get information message

that we also need to

install the "Dataview" plugin.

So we just repeat these

steps, searching for it,

installing, and

enabling it in the same way.

Before we go to the

"Metadata Menu" settings,

we need to check those

of the "Dataview" plugin.

In order to work properly, we need

to enable the second and third option

to allow the execution

of JavaScript and inline

JavaScript queries.

With that done, we can move on to the

"Metadata Menu" settings.

The first option is to

define whether the plugin shall

index only fields in the frontmatter

or also inline fields

anywhere in our notes.

By default, this is set to full note,

but this could have a

negative performance impact.

So if you experience those, you might

want to change it to frontmatter only.

Then we can choose whether

or not a note's context menu

shall show all the

available field options

or, to keep the context menu shorter,

to summarize them under a single menu

item called "Field Options".

Let me quickly jump over to my main vault

and show you the difference.

I currently have this option turned off.

So when I right-click on

a note, the context menu

will show me the "field options" entry.

And after clicking it, I get

a list of available options.

If I turn the option on and

right-click on the same note,

the context menu will include

all these options right away.

This makes it longer, but

also saves you one click.

Personally, I prefer

to have it turned off.

The next four options let

us define various exclusions.

We can tell the plugin to ignore certain

folders, extensions,

file name patterns, or

fields across the vault.

By default, nothing is excluded, and you

can adjust those as you see fit.

The autocomplete option does exactly

what it sounds like.

If turned on, the plugin

will suggest existing values

for you to choose from when entering them

into your frontmatter.

If you turn it off, this

will not happen, of course.

If you want to keep an eye

on the field indexing status,

you can activate the

display of a small icon

in Obsidian's status toolbar.

You can also choose how a set of multiple

values for a property

shall be displayed.

The options are "Array" and "Indented List".

The last option under Global Settings

is pretty straightforward and lets

you define the first day of the week.

By default, and for me, it is Monday,

but you can change it to Sunday.

In the next section, we

can define global presets

for certain fields.

Let's add a field called "Status".

In the field settings, we

allow only the selection

of a single value from a list.

The list itself we define right here.

It contains only three options.

"To do", "WIP" for "work

in progress", and "done".

If I create a new

note, right-click on it,

and go to "Field

Options", we now have the option

to "Add Missing Fields at the section".

I click on it and choose

to add the missing fields

to the end of the frontmatter.

This adds the status

field that we just defined,

and also lets us pick one of the defined

values for this field.

Under the "fileClass settings", we

prepare the ground for some

of the "Metadata Menu" magic

later on.

First, we need to tell the plugin

where to find our class files.

This folder has to exist,

so let's exit the settings

for a moment and create it.

As this is a new vault, I

do not have any folders yet.

However, it is not my first vault,

and I expect it to grow.

So I want to make sure

that all the things I need

to organize the vault are separated

from my actual notes and content.

This is why I usually create

a folder called "90 Organize".

In there, I add anything I need.

In my main vault, this

includes classes, databases, lookups,

templates, and canvases.

For now, I only create a folder "Classes"

inside the "Organize" folder.

Back in the settings, I can now select

this folder as the path

to our class files.

Next, we can define a name

for the "fileClass" field.

You can leave the default or change it.

As this is how the field

is shown in the frontmatter,

I prefer to call it just "Class".

The global fileClass

setting lets us define one class

that shall be applied to all notes,

even if no class is

specifically defined in the note.

You can use that to define some fields

that you always want on your notes

and to add these fields to legacy notes

that were created before you

started using file classes.

As I don't have any

file classes defined yet,

I leave this empty for now.

Next, we can limit the number of results,

that means pages using a class,

when viewing the "class files settings".

We will see this in a bit.

And the last option here,

let's just decide whether

the plugins dialog window

or modal shall include an

option to select a file class.

In the "Metadata Menu button" section,

we can define a

default icon for the button.

We will come to those a bit later

and decide under which circumstances

the icon shall be displayed.

By default, these are all enabled.

I recommend leaving them as

they are in the beginning.

And then disable those,

which you don't want to see

after having used the plugin for a while.

The last section here lets us

add a query and a file class

that will be applied to

all files matching the query.

When it comes to fields,

we need to understand that each field

is defined by three things,

a name, a type and type-specific options.

Currently, the metadata menu plugin

supports 18 different field types.

Any field can be defined

in the plugin settings,

as shown earlier,

or via a "file class note".

If you define the same

field in both places,

then the file class

note will have priority

over the plugin settings.

I will quickly demo them all

and some of them we will

see in action later on.

All right, I will start

by creating a new class

called "Demo" in my classes folder.

And to this class, we're going to add

all the different fields.

So let's keep everything

else for the time being

and go directly to "Fileclass fields",

hit the "Add Field" button

and start with the first type of field,

which is an input field.

For all these fields, you

have additional options.

You can set a command for the field,

you can define how it should look like

when it's used inline,

meaning inside the node

rather than in the frontmatter.

And of course you can

define or select the field type.

As you can see, we have the whole list

of the 18 types available.

And for an input field, I

just stick with this one.

Next up, we're going to add a field

which lets us pick a

single value from a list.

Let's say this is "list single".

Now, which values I can pick from

is something I can define directly here

in the field settings, or I can use

alternative sources.

They can come from a node

or they can come from a data view query.

For now, we just stick to

defining them in the settings.

I will quickly add

here the values one, two,

and three respectively.

Then we have the option to create a field

that lets us pick

multiple values from a list.

Once again, I will

define the values right here.

The next field type

which is similar to a list

is a cycle value list.

Once again, we select

type, we define the values.

The difference here is

that instead of picking one

or multiple values from the list,

you will have a button in the properties

which lets you cycle through

the values on the said list.

Next field type is very

common, very useful as well.

It's a simple checkbox field

which can hold three

different types of values.

It can accept "true" or

"false", but also a "null" value,

which might be useful for running queries

against it later on.

Then we have the option to

add normal number fields.

These can hold

numbers as one would expect

and can be used for

formulas and calculating things.

Additional options for numbers field

is you can have a step here.

So say five, for example,

this means that once you use it

in your notes, you will

have buttons for increasing or

decreasing the value in this

field by this defined step.

So plus or minus five in my case.

If you want, you can define

a minimum and a maximum value

for the respective field,

but this is of course optional.

Obsidian is all about linking nodes.

So it's not a big

surprise that we can also have

a link field in our class definitions.

In fact, we can have two different ones.

One is for single links, so links to

single documents only.

And in here, we have additional options.

We can use data field queries.

We can also define

aliases, how the link is supposed

to look like when it's displayed.

And we can define the sorting order.

You have examples here,

how to use these things.

So I will just leave

everything as it is by default.

And then we add another

field for multiple links,

which works basically the same way,

but of course allows you

to have more than one link

as a value in the respective field.

Another all time

favorite is a "date" field,

which of course lets you store dates.

Again, additional options here.

You can format the

date in the way you want.

You can pick the option to

insert a link by default.

"link path" can be

defined, but it's optional.

You can define a shift

interval, which once again,

when you're in the

properties, in the dialogue,

you can use buttons

to increase or decrease

any given date by this specific interval.

And you can also have a dynamic field

containing these intervals.

So in my case, it suggests a cycle field

because it's the one with

defined numbers already.

But I will leave this set to none.

The next one is a bit

more than a simple field.

It's one that can hold a lookup query.

So if we go here to lookup query,

then we have first the option to see

we want this field to

be updated automatically,

which I usually turn on.

I have not yet had problems with queries

or performance issues here.

And then we can define the query itself.

In preparation for my showcase later,

I'm going to add here a query that

should return all the

pages that have a specific tag,

in my case, "article".

We will see this in action in a moment.

But for this to work, these

other nodes, the "target notes",

need to have a defined field inside of

them with a link back

to the main note.

So I will call this field "parent".

And then we will see how it works.

The type of output is

something you can pick,

depending on your preferences.

For me, I will just leave it

as a list of links displayed

in line in the frontmatter.

Earlier, I mentioned the possibility

to create a formula field.

So let's take a look at this one.

Here we can enter a formula that

calculates values which

we have in our frontmatter.

For example, I could say I want to take

the value from the "number"

field, add to it a fixed amount of 10,

and add on top of this whatever value

we have in the "cycle" field.

Once again, I want to make

sure that this gets updated

automatically whenever

there is a change in one

of these fields.

Next, we have three field types that are

related to the canvas.

We have the option to update

a value in our frontmatter

based on links or based

on groups, I'm using there

or based on links to

specific groups in the canvas.

I will show all of those

a bit later in the demo

because for this to work, we actually

need a canvas which I

have not created yet.

So we need to come

back to those a bit later.

However, what we can do already is

we can take a look at the

last four options here, which

are object fields.

I will start with a

"list of object fields".

So let's imagine a use case where I'm

organizing or keeping

track of meetings.

So what I have in

meetings always is "participants".

I will add this.

You can see it's an object list.

And for each of these participants,

I want to track certain information.

For example, I would like to track the

I will call it participant name, "pname".

And here, I then have to select the

parent of this field.

In my case, this is "participants".

I will accept any value

because it's just a text.

And you can see that we

have this little indentation

at the arrow indicating

that the participant name is

a child object of the

participants object list.

So let's add two more.

We have the role of a person.

I should call it "prole" probably.

Again, belongs to participants.

And it's an input field.

And we have the "company".

Participants, input field ...

there you go.

OK, so this was an object

list with child objects.

Now, let's see how it

looks like for a field that

also accept objects but

uses values as fields.

I will call this one "logistics".

We are still in our

meeting mind space, if you like.

Does not have a

parent because it's on top.

All right, then let's

add additional fields

The logistics here.

First of all, we have the "meeting date"

belongs to logistics.

Is of course a date field.

I have no special

formatting or restrictions here.

And we have the "location"

belonging to logistics.

Once again, I should

call this M location.

So I know it's about the

meeting because could be anywhere.

And then I have here the "meeting type".

And this I want like to be a cycle value.

And I will simply say this

could be a "one on one meeting".

It could be a "client meeting".

Or it could be anything else.

Doesn't matter right now.

And the last one I would like to add

is a checkbox field which tells me

whether this is a virtual meeting or not.

Again, part of logistics, rule of rules.

If it's "yes", it's virtual.

If it's "no", it's face-to-face.

OK, now we are still

missing one last type here, which

is a field that accepts a YAML object.

I will show only the YAML one.

The JSON one

works exactly the same way.

But instead of YAML formatted code,

it would accept JSON code.

And I will call this one "other info".

And of course, this is

part of logistics as well.

Let's see how this

looks like in real life.

I will open a new note here.

Put it side by side

with our class definition.

I will call this "Field Demo".

Of course, we don't

see anything right here

because so far it does not really belong

to a class which we can change by right

clicking on the title

and saying "add class to Field Demo".

Currently, we have only one.

So we can pick the "Demo" class.

This is defined here.

We can do the next step

in two different ways.

The first one is to

right-click again on the tab

and say "add missing

fields at section", which

will open a modal where we can say

we would like to add

all the missing fields

at the end of the frontmatter.

So that's one option.

The other one is to left-

click on the class icon.

And then we get this nice little dialogue

where we can also say "add

everything in the frontmatter".

Or we can also add fields individually.

So if we say we have our

input field and this is missing,

we could add it here with one click.

And then we automatically

get asked for value for this.

So I can enter some text here.

And if we go back to our note,

we can see that this is here.

It really depends.

In my case, I would

like to add everything

because I want to show

all the different fields.

And we can simply go through them.

So this is currently our source code

view as you probably noticed.

And of course, I can also

write things in here manually.

But if I switch to the

"reading view" or the "live preview",

then I have all the fields

with a little icon next to them.

First of all, indicating what they are.

And then, of course, I

can simply input my values.

Formula is automatically calculated.

The lookup query is still

empty because we do not yet

have target nodes.

We will see this change in a moment.

For the date, I can

simply pick something here

with the date picker.

I can also use the navigation to move on.

I can insert the date if I want.

And I can clear the field, of course.

I'll leave this as it is for now.

You will see that because of the settings

that we defined here

in the date field, we

activated insert as a link by default.

It is indeed a link.

Talking about links, in

the multiple links field,

we can add links to multiple pages.

And in the single one, we can, of course,

only select one single page.

For the number, we have our depths,

as we defined them

before, plus and minus 5.

But we can also enter anything else

that we would like to have there.

As you will have

noticed, changing the number

also updates the formula field.

So instead of 10, as it

was before, now it's 31.

Checkbox, I suppose, is fairly clear.

You can check it or uncheck it.

For the cycle values,

remember we defined the value 7, 8, 9.

So we can simply click through those.

We have exactly these three values.

And every time it changes,

the formula also updates accordingly.

Then we have our multiple

value selection from lists.

So I can pick the value

4 and 6 in this field.

And of course, the single value selection

only lets you pick one value.

Now, coming to participants.

This is, as we discussed before,

and as you can see here

on the left-hand side,

an object list with specific attributes.

Now, if you click on this

field, I get another dialog.

Currently, there are no entries.

So I can add one.

And I can see here the name is Jane Doe.

Her role is to be a CEO.

And she works for a

company called "The Champs".

So now we have one

additional participant here.

But, and that's the nice

thing about object lists,

I can add here as many as I want.

So I can put another one.

And we say this one is Joe Doe.

He is a CFO.

And he works for the "Winners".

Now we have two names in here.

And we also see those in our metadata.

And when I switch to source view again,

you have to list it here

underneath the participants field.

All right, so this is

for the object list.

Now we have another one left here

regarding our logistics.

It works similarly, though not the same,

because we have here

just one entry, right?

So each meeting has

just one date, a location.

We have a meeting

type, which you can pick.

I would say this is a client meeting.

Is it virtual?

It's not.

We meet face-to-face.

And other info, here we

can add - in YAML format -

whatever we want.

So we can say person "Jane",

food preference "vegetarian".

Or we can add person

"Joe", food preference "steak".

And if we then go back to our frontmatter,

we once again have here under "other info",

exactly what we put there before.

Here we have all the logistics.

All right, now I still owe you the demo

for the lookup query.

For that, let me

quickly create a new note.

I will call this one lookup demo.

I will add a field for "tags"

and give it the value of "article".

Actually, let me make

this "LookupDemo1".

And then I create another one,

which is basically the same.

We can also have a heading here

and some text, make this a bit nicer.

Okay, if we come back

here to our "Field Demo" note,

we can now see that our

lookup query is still empty.

Why is this?

Because remember if we

go back to the settings,

we said there needs to be a field,

a related field called "parent".

Now let me quickly put

this also to the side here

so we can see all of

these things happening

at the same time.

All right, so what we need now is a field

in our target notes.

So the lookup demo

nodes are our target notes,

whereas our field demo is

our source note or lookup note.

Now here we go and say we entered this

parent field in line

and then we need a link

back to the field demo.

And as soon as I do that,

you can already see

that in the lookup query,

we now have "LookupDemo1".

Let me do the same

here. There you go.

And our lookup query

catches now the second demo note

as well.

And these are

basically all the field types

except for the ones

related to the canvas,

which I'm going to show

in the demo in more detail.

If all this sounds overwhelming and

confusing, don't worry.

Everything will fall in place

once we apply those things in practice.

Now with settings and

field types out of the way,

we can look at these

mysterious "file classes"

I have been mentioning

several times already.

Sorry to interrupt.

I almost forgot, well,

I did forget to quickly

ask you to like the video

and subscribe to the channel.

Assuming you do like it, of course.

But since you're still here,

the odds for that seem to be good.

So in any case, thank you.

I appreciate it.

File classes are a core part of the

"Metadata Menu" plugin.

They are used for

defining default fields, options

and field settings per class.

Okay, but what is a

"class" in this context?

Well, think about the

different types of notes you have

or may have in your vault.

For example, you may have

articles, book summaries,

projects, meeting

notes, recipes, and so on.

With the "Metadata" plugin,

you can define

specific fields and options

that you want to use for each of the

various types or classes.

I suspect you would have different fields

in your frontmatter for a recipe,

then for meeting

minutes or a book review.

These rules and

definitions are defined in

and managed with classes.

Technically, this is done with notes.

So let's go to the

previously created "Classes" folder

and create a new note.

I first want to define a general class,

which I will use for all notes

that do not belong to another class.

It shall contain a few

fields that are always relevant

regardless of the specific note type.

So I create a new note and I call it "All".

Because I created

inside the "Classes" folder,

which we defined in

the settings as the place

where we store our classes,

the plugin automatically

knows that it is a class.

If it does not, you

just may have to close

and reopen your vault.

As you can see,

we automatically get

into the class settings.

Now some of these we know already.

We have been working with the

"Fileclass fields" extensively

in the previous chapter,

but there are two other sections.

There is the "Table view",

which gives you a list of all the notes

belonging to the respective class,

which currently of course is none.

And then we have "Fileclass Settings".

Now before we jump into the

"Fileclass Settings" in detail,

we want to make sure that the "All" Class

is indeed being used every

time a new note is created

and no other class is assigned.

To do so, we go to the "Settings",

"Metadata Menu" Settings,

and "FileClass settings".

And here in the field

that we left empty before,

the "global fileClass",

we can now select our "All" Class.

Once again, doing so will

make sure that any note we create

will belong to the "All" Class initially.

There's another thing that might be

useful in this context.

It's this setting here to

"add a fileclass after create".

If you enable this,

then you will always be prompted

to pick an existing class for a note.

Currently I have it disabled

because I still create notes quite a lot,

which do not need to belong to any class.

But if you're working in a way

that every note

belongs to a specific class,

this is very useful.

All right, so we have

defined our "Global File Class"

and can get out of the settings.

Now let's see how this works.

Let's create two fast fields.

One, we will simply call "tags"

because this is something I always want

to have in my notes.

We'll accept any value of course.

And the second one I will call "Class"

because obviously I need to have a field

for a class as well.

Now the "Class" field would be a list

where I can pick a single value from

because I would like each note

to belong to just one class exactly.

As we saw before,

I can define the values for this list

directly here manually,

or I can use alternative sources.

I can pick sources from a note,

which we will see a bit later,

or I can use a Dataview Query

to return certain items for my list.

In my case, I would like

to use a Dataview Query.

If you don't know

anything about Dataview,

that's totally fine.

You can simply copy paste the query

and simply adapt it to your own needs.

What this one does is it

gives me a list of pages

from a specific folder.

In my case, the "90

Organize/Classes" folder.

Remember, this is where

we keep all the classes

and then just returns the page file name.

So basically this will give me values

for this specific list field

based on all the notes I

have in this specific folder.

All right, so these are the things

I always want to have in any new note.

Now let's see what happens

when I create a new note.

I will call it "Note1".

We immediately see this

belongs to the "All" class

because of this little icon up here,

which is the same as the one

defined for the class itself.

Now, as we have seen before,

if I click on this icon,

I will see which fields are missing.

I can add them all to the

frontmatter and there you go.

Now here we can say

this is "All" and for tags,

we can put whatever we want.

Okay, having defined a

general class for all the notes,

I still owe you the details

for the "Fileclass settings".

So let's take a look at those.

First item here is simply a value

that you can define as you wish

for the maximum number of rows

you get returned in the "Table view".

Remember we saw the "Table view" before,

it was empty because we had no notes

belonging to this class.

Now we have "Note1" and

it shows up as it should.

The second option is "map with tag".

So what this does is it

binds tags with the class name.

So we can activate this.

And then any notes that have a tag

that matches our

class name, in this case "All",

will automatically be seen

and assigned to this respective class.

If you don't want this to

be based on the file name,

you can actually define

specific tag names right here.

So instead of using the file name,

you can say, I want all the

notes with the tag "article"

to be treated as a

member of this specific class.

If you don't want to do it with tags,

you can also do it with file paths.

So you can say

everything in a specific folder

shall be part of this

class and with bookmark groups.

I don't have any

bookmark groups, but if I did,

they would show up here

and you can use them as well.

Now, you will have noticed

that I skipped the "button icon".

The button icon is simply the definition

of which icon should be displayed

for notes belonging to a specific class.

By default, this is a clipboard icon,

but we can change this.

In order to know what

icons you can use there,

I suggest going to the

website, "lucide.dev".

Simply look for all the

icons, search for one.

I will take note here.

You can then simply

click this little code,

copy it over to Obsidian,

enter it here, and the note will appear.

If you save these

changes, then you will see

that all the notes

that belong to this class

are automatically updated as well.

These last two settings here help us

with organizing our classes.

We can create a kind of tree structure

where we have top classes like "All",

and then specific subclasses helping us

to organize our frontmatter for the

different note types.

So for example, I

could add a new class here,

which I call "Project".

And if I go to project settings,

I can first change the icon, for example,

and we can then say the parent class

for the project class should be "All".

What this does, is by default inheriting

all the fields that we have

defined for the "All" class.

So our "tags" and "class"

fields, which we defined in "All",

will automatically be used for project

class notes as well.

Of course, if I don't want to do this,

I can say I want to

exclude certain fields,

which you can then

pick from this list here.

For the time being,

let's just use it as it is.

And we have our first two

levels of our class hierarchy

with "All" and "Project" underneath.

Of course, not every class needs to be

part of the hierarchy.

If we look at our "Demo" class,

we can see there is no parent defined,

which is totally fine.

Congratulations, you made it

through the relatively

dry, theoretical part.

If you skipped it, feel

free to use the detailed chapters

to go back and look up

anything that seems unclear

during the following practical demos.

In this section, I

will not spend much time

on explaining the logic

and mechanisms anymore.

First, we will see how

all this works on its own.

That means without

needing any other plugins.

And then I'm going to

walk you through a use case

of writing articles or blog posts,

using the Obsidian Canvas

to organize the workflow

and the related notes.

I believe this is easy to understand.

Anything you see here

can of course be applied

to other topics and areas as well.

Let's go back to the

previously created class note

for "Project".

We already defined the custom icon

and we assigned the "All"

note as our parent file class.

Now let's add some file class fields.

There is "phase", which is a

list of the values: backlog,

research, write, review,

published and outdated.

Then I have a field called "status",

which is again a list

field with the values: to do,

in progress, done,

blocked, on hold and canceled.

And I want to have a

field called "priority"

with the options of: low, medium and high.

These are all select fields.

And for now I defined the

permitted values manually,

directly in the settings.

I do not need to define

the "class" and "tags" field

because we inherit those already

from the "All" parent class.

I can now create the note "Project1".

I assign the class to it

and add the related fields.

Because we can have

different types of projects,

we can and perhaps should create a class

per project type.

I will quickly create an "article" class

with the "project" class as its parent.

So you can see how we

slowly build a sort of tree

out of our classes.

This class inherits

the "class" and "tags" fields

from the "All" class.

And it also gets the "phase",

"status", and "priority" fields

from the "project" class.

However, it also has

some specific fields,

which I will add now.

First, there is "author",

which is a normal input field,

letting me enter any text I want.

And then I want to add a date

field for the publish date,

which I call "published".

By using the parent file class,

we just created a structure like this,

which helps us to minimize the

administrative effort

for classes and

maximize the frontmatter quality

and consistency across our notes.

But what if we don't want to inherit

exactly the same fields

that are in our parent class?

Well, if we want to remove

a parent field completely,

we can simply do so in

the "Fileclass settings"

under "excluded fields".

For example, we could

remove the "status" field

from our "article" class.

If we want to keep the field,

but have different values for it,

we can add it again with the same name

and customize the values.

Here, I just copied the "phase" field

from the "project"

class to my "article" class.

Then I add the phase "rejected" to it.

Going back to our article note,

we can now see the new phase is

in the list of available options too,

while the values in the

project note remain unchanged.

One more thing to make this easier:

You will recall that I defined the values

for each list field manually.

As this is a nightmare to maintain,

I practically never do this in real life.

Instead, I work with "lookups".

Here is how that works

and where the dedicated "Organize" folder

comes in very handy.

The "phase" field for our

project class is a good example.

I want to replace these

manually defined values

with a lookup.

As you can see,

we can change the values source type

to "values from a note".

But first, we need to create this note.

So I go back to my "Organize" folder

and create a new

folder there called "lookups".

In there, we create a note

and call it "project phase".

Then we add one value

per line to that note.

Back in the field settings,

we now change the source

type to "values from a note"

and then select this note "project phase".

Back in the "Project1" note,

we can still select the value for the

phase field as before.

But if I now add a new

phase to the lookup note,

this change will

automatically be reflected

and the new value will be

available to pick from the list.

This is much faster and easier

than going to the field settings.

So you can see with a bit of planning,

you can build a flexible set of classes

and if needed, a class hierarchy

that - in combination with templates -

will help you to keep your

notes frontmatter consistent.

For the second use case,

we will combine the functionality

of the "Metadata Menu" plugin

with one of Obsidian's

core plugins: the Canvas.

This combination will

let you manage your notes

and their metadata by simply

dragging them around on a canvas.

It will also let you establish a workflow

and visualize your work progress.

I use this approach for

managing my Obsidian videos

and a digital garden that I publish

via Obsidian to my website.

Moving notes around on this canvas will

update their status.

For example, currently

all the notes are published.

If I were to move one

into a different box or group

and update my digital garden,

this note would

automatically be unpublished too.

Okay, we are back in my sandbox.

The first thing to do is

to create a new canvas.

I will call it "MDM Canvas demo".

I want to use the canvas

to visualize my workflow

and where each of my

articles is in that workflow.

I also want it to update the respective

article's frontmatter

for its "phase" and "status"

depending on where it is on the canvas.

To do so, I create

horizontal swim lanes for the status.

In my case, they are

for backlog, in progress,

done, canceled and on hold.

But you can put whatever

suits your needs, of course.

Then I add vertical

swim lanes for the phase.

I will use research,

writing, review, published,

and outdated.

If I arrange these swim lanes nicely,

it will give us a grid

or a matrix, if you like.

These swim lanes are

what canvas calls "groups".

We need to remember

that for the next step.

Now let's prepare the "article" class

for working with canvas.

For that, I add two new

fields called "cPhase" and "cStatus",

to differentiate them from

the previously defined ones.

For both fields, I define the field type

to be "updates with groups in canvas".

Then I need to tell the

field which canvas to look for.

We now have a logical

connection from our note "Article1"

to the "article" class and to our canvas.

Next, I need to add a new note.

I will add a card first

and call it "Article2".

Once I have my ideas collected as cards,

I start converting them into files

with the same respective name.

When I open such a file in a new tab

and make sure that I am in "source mode",

we can see that there is

no frontmatter at all,

but that the file

belongs to the "All" class,

indicated by the icon next to its name.

Now we can right click on the note title.

We remove the "All" class

and the note's icon changes

to that of the "article" class.

If we click on that icon,

we can select

individual fields to be added

to our frontmatter or add all the

missing ones in one go.

We also see our class

hierarchy starting with "All",

via "project" to "article", and

can decide to only add the fields

that come directly with

each of these classes.

I do so.

And in our fron matter, we now see "tags",

"phase", "status", "published", and "author".

If I now move the note on the canvas

to the intersection of

"backlog" and "research",

its frontmatter gets

updated automatically.

Oh, but hold the phone!

We now have both values in each field.

That's not what we want.

So we need to tell the

class which swim lanes

or canvas groups map to which field.

Let me delete these fields

from the frontmatter again

and go to the "article"

class "field settings"

and look at the "cPhase" field first.

At the bottom of the dialogue,

we can define that the

field shall be populated based

on canvas groups identified by

colors or by the group names.

If each of your groups

has a different color,

you can use those of course.

In my case, I have three

phases with the same color

and even one phase and

one status group are red -

so, have the same color.

This means, colors are

not going to work for me.

Instead, I will define the group names,

adding each of the phase names here.

Then I do the same for

the "cStatus" field.

Of course, this needs

to be done only once,

but if you add new phases or statuses,

you would have to update these values.

Let's go back to our note

to see the frontmatter.

If I now move the note on the canvas,

both fields get updated correctly.

The same principle

applies when we are updating

front matterfields based on links,

we do on the canvas between items

rather than the groups they belong to.

Here I opened the three

article notes I prepared earlier.

And as you can see,

"Article3" already contains

frontmatter for "cStatus" and "cPhase",

based on the steps we did just before.

Now I'm going to drag

"Article1" and "Article2"

on my canvas as well.

As soon as I do that, of course,

the frontmatter for

"cStatus" and "cPhase"

gets updated in both notes as well.

What I would like to do

now, is to show the sequence

of these articles.

So I go to the "Fileclass

fields" and add two new fields.

One for previous chapter

and the second one for next chapter.

For both fields, I

chose the field type "updates

with links in canvas".

For the field "previous

chapter", we choose incoming

because we want to

track from which chapter

or from which note on the canvas,

an arrow or a

connection is pointing towards

the respective note. For

the field "next chapter",

it's of course, the other way around.

If I now draw an arrow from

"Article1" to "Article2"

on my canvas, you

will see that both notes

get updated accordingly.

And of course, the

same is true when I do it

from "Article2" to "Article3".

Of course, I can still move the notes

around on our canvas.

As long as they stay

within the different groups,

the frontmatter of these

notes is going to be updated

accordingly and even when I

move it to different groups,

the frontmatter information

for previous and next chapter

based on the links that

we created, not the groups,

is not going to change.

This concludes another deep dive

into one of Obsidian's

more complex plugins.

Let me know in the

comments what you liked

or did not like about the video.

And if you have any

requests for one of the next ones,

drop them there too.

I'd rather make videos about topics

people are interested in

than what I think they might like.

And that's it for today.

Thanks for watching

and see you next time.