MASTER Obsidian's Powerful METADATA MENU Plugin - Step by Step
Summary
TLDRThis 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
π 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.
π§ 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.
π 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.
π 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.
π 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.
π 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.
π¨ 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.
πΌοΈ 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.
Mindmap
Keywords
π‘Metadata Menu Plugin
π‘Frontmatter
π‘Field Types
π‘File Classes
π‘Dataview Plugin
π‘Auto-completion
π‘Inheritance
π‘Canvas
π‘Lookups
π‘Swim Lanes
π‘Templates
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.
Browse More Related Video
5.0 / 5 (0 votes)