I think about it since I’ve started using obsidian. I really love all the ecosystem of plugins, themes and snippets that makes the app so dinamic. But, at same time, I try to be aware to don’t use complex/unique extensions that could make the vault depend on them - which could, for example, break my notes if I needeed to change of software or just stop using the X/Y/Z extension.
So, what are your thoughts about it? I think that the best plugins and snippets are the ones which makes the original structure easier to deal with - as if they were a “easier way” for do things you could already do without them on Obsidian - and the ones which doesn’t affect what they’ve done if you delete them.
At the end of the day, plugins and snippets should be complementary to the original experience - and not experiences by themselves. I’m not saying you can’t use this kind of extension, I just want to talk about it with the community to check if I’m crazy.
Ps: My english isn’t so good, so, if I wasn’t clear, I can develop more my idea.
Trigger behind this thought
I’d want to make obsidian more similar to notion when it comes to visual aspects (like banners, folder icons, better image managment), and I wanted to use plugins and snippets for that - but my mindset about it makes me uncomfortable to apply this.
My benchmark was not Notion but MS Word. I no longer have any attachments to it (workflow-wise).
My ultimate goal is to impart knowledge. My computer knowledge is very limited – so it’s about whole other topics.
So if e.g. callouts with hover or sidenote CSS hack look good, it may not be possible for my viewers to see, either online or in an interactive PDF. We must be always on the lookout for how to balance the practical and eye-candy side of things and must have the reader – if any, the competition is large and attention spans are shorter and shorter each year – to look out for.
The number one thing is efficiency – we don’t live forever, so if you need plugins because that’s how you can bang-bang, you use them.
If you rely on plugins like Templater, Dataview, ExcaliDraw or Commander and were they no longer possible to be used in Obsidian, then it would be your choice not to upgrade Obsidian. This is not likely to be happening, but you are responsible for your workstation and you can do what’s needed for you to stay efficient.
Right now I know that I am missing out on a ton of stuff. Automation bits, eye candy, Dataview (I am waiting on Datacore or something to change my mind to have a different approach), and the possibilities with this program are virtually endless.
So I am spending a lot of time on the forum…which takes time away from what I need to do (read, write = type), but Obsidian needs this kind of investment (your time) and time will help you deal with what are absolute musts and what you can say goodbye to.
You’ve got me some insights about it… Mainly when you said “we don’t live forever”. Maybe it’s part of the game to consider the tradeoffs of getting plugins/snippets, and even using obsidian - all about trust or not on what I’m using.
I really love how Obsidian have the infinite possibilities, maybe I gotta enjoy it as a tool without getting so woried. As I said, it’s a tradeoff process where the focus is building knowledge - whatever way you use to do that.
Thank you, I feel more relaxed to enjoy extensions as they were created to be - complement your PKM. I’ll try to define better filters to choose if I use or not an extension.
By the way, thank you as well for all your effort helping people on the forum, I’m sure I represent a lot of users saying that
My thought was something like: This extension improves a lot the basic Obsidian experience. Considering that, if, someday, this extension stop working, it will break my notes?
I support extensions, and use a lot of them - I was just worried about getting dependent on them to have my notes with me in a long-term. But, considering what @gino_m said, maybe this way of thinking isn’t the right one.
But what do you think about it?
I think worrying about what if Curio goes kabloom is a needless distraction. Keep multiple backups of your data. Don’t use any plugins if using plugins causes too much ideation. Otherwise, enjoy yourself.
One of my reasons for using Obsidian/markdown/plain text is to future proof my work. I remember when WordPerfect 4.2 was the standard, and now those files are not accessible unless you use an app to convert them into another format.
When I upgraded from Scrivener 2 to 3, a number of my Scrivener files became unreadable. Corrupted Scrivener files can be recovered as plain text files, but you lose the structure/order, so if you happen to be looking at a corrupted book with 100 scenes, you have to manually figure out how to put those files back into order.
I regularly preview or edit from outside Obsidian, so I know how “human readable” my notes are and what functions I would lose if Obsidian was gone. Generally, I use plugins that make my work easier rather than those that create a new, non-plaintext format. My files are built for utility rather than beauty.
So I export my canvases as jpg files if the data is important enough to save and view 10 years from now.
embedding would be gone, but the reference is still there if I am looking for the note/object that was embedded.
I would lose my calendar navigation of daily notes, but they are named in ISO standard so that they sort chronologically in file explorer/finder/navigation, and of course they are searchable by name/date.
Links and wikilinks work outside of the Obsidian environment. Headings, bold, tables, etc. are all standardized.
Saved queries/dataview don’t work, but you can search with other utilities. Block quotes/callouts work. YAML works. Kanban boards show up as outlines.
Use a plaintext editor or previewer to look at/edit your files. Then you’ll know how future-proof they are.
Strong agree with pdworkman — there is a spectrum of portability, and some things will still provide (less-convenient) value without the plugin.
Even wikilinks, which are a default core feature, are a lot less compatible than Markdown links. But I like them much better and I know a wikilink means “a file with this name somewhere in the vault folder”, so they’re still useful without software support — just less smooth. (And wikilinks seem to be spreading, so compatibility is increasing.)
I used to use a plaintext notes app called Zim Wiki which I liked very much. But it had no mobile app, so when I got a smartphone I switched to using generic text editors. I lost functionality but was able to keep going. Then Obsidian came along and I got my functionality back and then some!
You’ve enlighten me on two things: how my first idea is translated in practice, and what can I do to satisfy my objective of keeping the notes safe. Thank you for the tip, I’ll absolutely follow it!
But I hope we’ll be able to continue using Obsidian for years and years.
Just another question (very simple, but I don’t have the necessary knowledge to answer it by myself) - how can I deal with images embed on my notes? At first, I think images behaves as links, so, if I have the image file whitin the notes on X folder, it’d be everything ok.
You reference them.
You can use the Wikilink reference, but it is superior to use markdown links for referencing your images so other apps (like MWeb on iOS) and non-Obsidian or non-Obsidian-Publish programs and web apps can interpret them and make use of them.
I use Wikilinks for internal links and use markdown links for referencing images.
They look like this: ![image](assets/filename_image1.png); ![image](assets/filename_image2.jpeg);
I try to remain true to the filename when naming and referencing images, but usually I remove spaces between strings; a file named File name is such will have images named Filenameissuch_image1, etc.
You can make use of the Paste Image Rename plugin for keeping your image names identical with filenames.
But that will reference images with Wikilinks.
What you can do is use regex to exchange those to markdown links.
You can use a plugin (Regex Pipeline or better, Apply Patterns) to exchange links within the file or you can use a text editor like VSCode, Notepad++, Sublime Text, etc. to make changes for your whole vault. (Make a backup first, just in case you make a mistake somewhere.)
In my case (I have an ‘assets’ attachment folder under each of my folders, you may not need that):
Replace: !(assets/$2$3$4) or:
If you have spaces between strings in image names, you must add < and >:
You particularly need to be aware of syntax that’s unique or rare (there’s some in Obsidian core) and workflows that are dependent on on a particular mix of plugins. That’s not unusual - it’s very easy to become dependent on any program that you use intensively. Plugin problem is greater in Obsidian because many plugins aren’t maintained long-term and the Obsidian architecture hasn’t yet stopped changing and breaking plugins.
I’ve moved in the other direction. After many years of writing in a markdown editor, I now write in Word (notes in Tangent, prep in Mindomo). Partly that’s because Word improved enormously when I wasn’t looking, partly because I prefer to write in a single file (Word handles huge files without a hitch, markdown editors rarely do; and outline modes in Word are very usable and that’s rarely true for markdown editors once you have a big file), and partly because of the friction produced when switching between ‘markdown’ editors’ syntax variations. Tables and images are far better handled in Word.
That depends on your ecosystem. True for markdown programs, but a number of non-markdown programs use wikilinks.
The problem with all image linking systems is that you need a robust, long-term asset management system. For one reason or another, most links eventually break.
I have an asset management system I hope to be robust, but I still prefer finished document formats that contain the images (docx, pdf; can be imitated with zips that contain all necessary files, but that’s higher friction).
To add images to notes, I either paste them or drag them into the note. This will embed them and name them with the same name as the original file. You can use Ozan’s Image in Editor Plugin to ensure that you can see your images when you are in edit mode.
As far as where the embedded images are stored, you can choose to have them in a specific folder in your vault or in the same folder as the note. Either works, it just depends on how you like it. I prefer a separate folder so that my file list does not look too cluttered.
As far as longevity/portability goes, the embed code in the markdown note will have the name of the graphic file, so you can do a system search if Obsidian were gone or you accidentally moved it somewhere Obsidian couldn’t find it.
I’ve actually dealt with a number of corrupted Word files over the years. The bigger they are the more easily they get corrupted. I prefer not to keep my working files in Word (ie. I write books, and the chapters are individual md files, nice and small and unlikely to get corrupted, when I’m ready to send to my editor I do compile into one big Word file, and hopefully it is stable enough until my editor is finished with it and I can move it into Vellum)
The Obsidian core plugin Outline is actually really good for long notes with multiple headings and heading levels. I looked around at a bunch of different TOC plugins before I realized that the Outline plugin is what I wanted. I work with some files on a weekly basis that have 20-30 headings, and it is really slick to be able to jump between them and move them around.
I haven’t experienced a corrupted file for some years now and given backups and versions I never lost any data. I’ve also had corrupted markdown files - but again haven’t lost data. I tend not to worry about corruption outside of databases.
I’ve tested it with very big files and it doesn’t work (often an error message saying that indexing is taking a long time - even when the file has been in the vault for months). And even with smaller files, it isn’t as smooth as Word or with as many features. And fewer levels of headings (6 vs 9).
Yes indeed. All my publishers require docx and so do 95% of my collaborators. If I’m sent something it’s a docx 99% of the time (the 1% is a Google Docs link; markdown files never). A one-off conversion isn’t so bad, but a to-and-fro either means multiple conversions both ways or staying in Word. Lowest friction is doing everything in Word. Which has the advantage of a consistent comments system across drafts. I can’t avoid using Word (I suppose I could use other WPs and lose features) so the only question is how early in the workflow I start using it.
I’ve always thought of this as the Scrivener approach. I call it little-endian to contrast it with the big-endian approach of having the whole book and working down to its components. I’ve used it and tried to like it but I never have. Not sure why. Both methods ought to be the same because the parts are identical- eg scenes, sections, chapters, book - but it doesn’t work like that in my mind. I much prefer starting with the whole MSS in my mind. The whole outline in one place - even when there’s only a few bones and little flesh.
Which brings me to ecosystems. Word has a rich ecosystem, markdown’s is poorer with friction points from syntax differences. Mindomo will export a map to docx with headings in the right place, notes becoming body text (formatting and colours preserved), comments becoming Word comments, and with a TOC at the top; there is a markdown export but it is nowhere near as useful. This makes it easy to do plotting and outlining in Mindomo (which I often used to do anyway) and then just continue in Word.
I don’t love Word, but it has become very utilitarian for me. I used to defer switching to it as long as I could, now I’m content to use it from the beginning which makes life simpler. Even coming round to adding extra notes via the OneNote sidekick.
I don’t use it for notes or research, only writing.
There are some quite interest points here - especially in the comments.