I’m excited to share a preview of the upcoming Obsidian Typing v1.0. This iteration represents a comprehensive reenvisioning and reengineering of its predecessor, designed to offer enhanced robustness and versatility.
What is Obsidian Typing?
Obsidian Typing allows you to define specific types of notes for group-based customizations. By associating a note type with a name and folder, all notes within that folder adopt this type. New notes of this type are automatically directed to the designated folder.
Here are some of the features:
Configuration as Code: Utilize the Obsidian Typing Language (OTL) to intuitively and powerfully configure and categorize notes.
Field Types: Ensure a consistent structure across notes by precisely defining field names and types for each note type.
Headers & Footers: Eliminate repetitive templates with autogenerated content that gets added during render-time.
Interactive Links: Upgrade your links by turning them into custom React components.
Name Prefixes: Establish consistent naming conventions.
How can I use it?
To spark ideas for potential personal applications, here’s a brief glimpse into what you could achieve with Obsidian Typing:
Databases: Catalog movies, books, or papers by creating types with specific fields. Make addition of new entries a breeze.
Study Organization: Organize your study materials with note types for courses, lessons, and assignments. Keep track of everything and add context with headers and footers.
Habit Tracking: Design a system to track daily habits. Log your progress and get recommendations on what to tackle next.
Work Management: Create interconnected systems that bridge Issues, Projects, Meetings, Colleague, and other note types. See the bigger picture by connecting meeting attendees to meetings or issues to projects.
Custom Knowledge Systems: Customize Obsidian to your unique needs. Be it crafting semantic wikis, charting ancestries, or undertaking other specialized projects.
Why Release the Documentation First?
I believe in the power of community feedback. Hence, before progressing to the final development stages:
Feedback: Before finalizing the plugin, your insights and suggestions would be invaluable. Understanding your requirements and perspectives can guide the plugin’s final adjustments.
Demand Gauge: It’s essential to gauge the interest and demand for such a tool, which in turn motivates and steers the direction of the development process.
Can you tell how it differs from Metadata Menu? I think Metadata Menu doesn’t prevent fields having forbidden values. Maybe this plugin tackles this problem among many other things.
As said many people before me, there are specific database programs to accomplish similar things as managing metadata in Obsidian. We should all ask if a serious effort is needed to enhance database capabilities in Obsidian. What do we get from that effort and how it will change and benefit our existing database-like-oriented needs.
Thanks. I am planning to publish the first prerelease version in the next several days, and the BRAT installation instructions will be added by then. The review for the public marketplace will take some time, so I don’t anticipate it being available there any earlier than in the next two weeks. As for the second question, I’ll focus on written documentation as the first priority, but I will also consider adding some video demonstrations.
Indeed, some features of Obsidian Typing might overlap with existing tools like Metadata Menu and the recently introduced Properties in core Obsidian. Discovering the latter, in fact, motivated me to expedite my release. While these tools might share functionalities, the UX often stands out as the distinguishing factor.
I hold Metadata Menu in high regard; it’s a robust plugin. I was unaware, until now, that it introduces abstractions like file classes — which closely align with what I term as note types in Obsidian Typing. Moreover, it even supports file class inheritance, as I have understood. I began developing Obsidian Typing in 2021, and given the dynamic nature of the plugin ecosystem, it’s no surprise that some functionalities became standard in other plugins over time. I’ll ensure future documentation includes distinctions in a section like “What Obsidian Typing Is Not.”
Addressing your question about field management: the UX and UI are notably distinct in their approach. Metadata Menu offers a UI-centric method, whereas Obsidian Typing draws inspiration from programming concepts, treating note types akin to classes and notes as instances. This approach feels more intuitive when defining through code, though I understand and appreciate that UX preferences vary. When creating or modifying typed notes in Obsidian Typing, you are doing it via convenient and keyboard-friendly prompts (autogenerated from type definitions). I’m not currently aware if Metadata Menu offers a similar feature, but I’ll look into it. Regarding field validation, Obsidian Typing ensures consistency with the defined schema when edits are made via our prompts.
However, field management isn’t the sole focus of Obsidian Typing. I’m sure the community will realize its broader potential with time. While my promotional skills still leave much to be desired, I believe the plugin’s distinct features — from custom headers/footers and enhanced links to note type inheritance and powerful scripting environment — will resonate with many users. Once the core is released, I’ll focus on showcasing its capabilities with type packages for real-world use cases.
Have you tried out the new Properties View core plugin? I hope you’ve been in contact with Obsidian team because I don’t know how that would work with this new core plugin. Apparently, it doesn’t support hierarchy and it will try to rewrite the YAML value, so I don’t know if it will be in conflict with your plugin?
Thanks a lot for making this plugin. I’m very excited to try it out once it’s approved on the community plugin marketplace (I’m a noob so I need to wait for documentation and walkthrough too).
The functionality of Typing is currently orthogonal to what the Properties offer. In terms of the representation of fields in the note content, Properties saves them in the frontmatter, while Typing operates on inline fields, following the Dataview standard. I may integrate support for frontmatter fields in the future. However, as long as the format aligns with the specification, I don’t foresee any conflicts.
Having read the documentation, I’m really excited to try this plugin! My use case is to catalogue sewing patterns, my fabric stash, and sewing projects. I have a system developed using Notion for this which is heavily reliant on linked data tables, filters and formulas, so that e.g. if I’m planning to sew something, I can immediately see which fabrics and notions I have in sufficient quantity that are suitable to the project — without needing to physically root around in the fabric storage boxes.
I’ve been patiently waiting for the Obsidian ecosystem to mature to the point where I could feasibly migrate my “digital sewing room” from Notion to Obsidian without spending too much time on it. I’m hoping that Obsidian Typing will help make this possible.
I am not a software developer, so feeling a bit daunted by how technical the setup may prove to be. But willing to learn! Thank you so much for writing such clear and comprehensive documentation before releasing the plugin… It often is the case that a good plugin is let down by its documentation, so your approach is refreshing!
There are some requirements that i have thar I’m not sure if this plugin could fulfil.
I want to be presented with a form with validation when I create new entry (AKA note) of specific type
I want custom render only sections on notes based on their type. For example a button to create a new note of the current type or to see some metadata with a custom view in the footer, without that being part of the note
Easily adding/modifying content to sections of the note directly from reading view
Absolutely, when you define field types for a specific note type, the plugin generates a prompt (or a form) with the relevant fields and their associated pickers. For instance, if you define a field as rating: Number[min=1, max=5], the plugin ensures only valid inputs within that range. The same principle applies to other field types. If you specify a field such as link: Note["Type1", "Type2"], only notes of types Type1 and Type2 will be accepted for the link field. You can find an illustrative example of the prompt UI and the corresponding schema on the documentation’s landing page.
Headers and footers, whether defined in markdown or JavaScript, are not part of the note content. They’re configured on a per-type basis and can be inherited. So, if you aim to inject a custom metadata view or a button, it’s entirely feasible with this plugin.
I apologize if I misunderstood your third point. Typically, the reading view doesn’t allow modifications to the note content. Headers and footers, since they are injected and not stored in the content, cannot be modified either. However, if you’re referring to interactions with these elements, their interactivity depends on your definitions. They can be set up to modify metadata within the current note or other notes based on specific interactions. For modifications to headers and footers themselves, these elements are updated in real time as you adjust the .otl and related js files, allowing you to see the changes almost instantaneously. Still, I sense there might be another aspect you’re referencing. Please do clarify if that’s the case.
I want to give you a quick answer to this, and will expand on details later.
Imagine that I have a restaurant type. I want a button in the header that, when clicked executes a script/template whatever that adds a row to the log of visits. Will something like that be possible?
Thanks to @cameron for this awesome walkthrough, I am definitely adding it to my Quick Start page!
Unfortunately, for some reason I was not able to comment under the video, so I’ll leave my comments here.
About the issues highlighted in the video:
Icon: Everything was done correctly when enabling icon fonts in the settings, it’s just that I specified a FontAwesome Pro icon there, while only Free ones can be downloaded in the plugin.
Adding items to lists: This isn’t documented yet, but adding items to a list can be achieved by pressing Cmd+Enter (or Ctrl+Enter for Windows users).
Number pickers: I confess, I haven’t refined this feature much yet. At the moment, it serves a similar function to the Choice pickers, mainly to restrict the set of numbers you can input. I’m planning on offering a variety of number pickers in the future, more flexible to cover more use cases (like sliders, radio buttons, etc.).
Schema reloading: This is a known issue, and I’ve received feedback on it. For now, the workaround is to simply reload Obsidian.
Note content: It’s strange that it was inactive. It is designed as a lightweight markdown editor with basic formatting features and smarter list/task support. I’ll investigate what might be causing this issue.
It’s by far not perfect yet, but it wouldn’t be Beta otherwise. Anyway, the core is mostly done, so now I can focus on smaller features, bugs and overall usability.
Thank you @cameron for the detailed walkthrough and for documenting your initial experience! Your insights not only assist me in identifying potential issues but in the first place provide others with a deeper understanding of the workflows and interface, which is difficult to convey through documentation alone.
I’m really interested in this plugin and I’m glad my quick tumble setting it up could be useful!
I’m working on setting up a specialized vault for a creative project and I’ll be trying to integrate this plugin into it. I’ll make a list of bugs and questions for you as I go
