I agree. Obsidian’s core developers provide very little task-manager-specific features; those features are all up to volunteer plug-in developers who will likely get bored with the thing and move on a lot faster than OmniGroup or CulturedCode will get bored with selling OmniFocus or Things, etc. Unless dental work is one’s hobby, you don’t buy a screwdriver to brush your teeth.
There are many talented individuals who are providing some very interesting ‘add-on’ plugins that increase the functionality of Obsidian. And your observation may be accurate going forward. On the other hand, again maybe, the Devs (there are 2) have the ability to concentrate on the core aspects of the app and then Sherlock the features that show the most interest.
Excited for this episode.
For what it’s worth, while it is definitely fiddly, I replaced OmniFocus with Obsidian over a year ago and have been doing just fine.
I was spending as much time writing scripts and fine-tuning perspectives for OmniFocus as I am now working with different Obsidian searches and dataview queries. And I’m getting as much done now as I was then.
Might as well expand on what I’m doing, since it only requires 5 plugins. I use:
- note metadata to set review dates and statuses
- the Kanban plugin with MetaEdit to give myself an overview of what I’m working on, and to update the status of projects via MetaEdit’s KanbanHelper feature
- Dataview queries to surface task lists from projects depending on their status and review dates and such.
- A simple Templater macro to update review dates.
- MacStories’s Shortcut Launcher to time-block projects and tasks to my calendar
On a related note, I think I can assuage some concerns about “plugin rot” and abandonware.
First, it’s definitely a valid concern. No one wants to make a tool an essential part of their workflow if, once it breaks, there’s no replacing it. I share your worries.
However, while it’s easy to get scared about the possibilities here—plugin developers are probably a little more likely to abandon ship than Omni Group—I don’t think it’s a real concern for most plugins for a few reasons:
- The plugin API is unlikely to change very much. Or, to put this differently, Obsidian changed more rapidly in the past than it will in the future. So, plugins that exist now are unlikely to suddenly become unworkable, even if the developer moves on to other things.
- Plugins are often supported by multiple developers, and in general are helped by the developer ecosystem. Since most plugins are open source, if something breaks, others can come in and fix them. (I’ve actually done this!)
- The Obsidian API is very easy to use, and most plugins are actually quite simple. Anything that does break should be simple to fix, and devs can probably be hired to fix it in the worst case scenario.
- If you really want, you can download previous versions of the app and previous versions of all plugins. Think of it like keeping backups of your data and your tools, like you’re keeping spare parts around. Obsidian’s previous releases are here, and you can find previous releases of plugins by going to any plugin’s GitHub page and selecting “Releases,” usually on the right sidebar.
Is it ideal that most plugins are someone’s hobby project? No, definitely not. But I’d rather have a very customizable app with lots of diversity in tooling over holding my breath waiting for Things or OmniFocus to add a feature I really want. (Which I’ve been doing for years!)
Tradeoffs, eh!
I would love to see how you put this together @ryanjamurphy - any chance you’d be willing to demo this?
I am ready and willing, but not available quite yet! I think it’ll take half a day to create a sanitized workspace with demo data to explain it and put together easy-to-follow instructions.
Maybe if I stopped procrastinating by visiting talk.macpowerusers.com…
Gimme a deadline!
and @mikeschmitz I also think a thorough discussion of WHY one would want to take this route rather than using a dedicated task management application would be helpful. I have in mind Sinek’s book, Start with Why. It would seem to me that providing examples and reasons WHY one might want to consider this option is an important first step before getting into the HOW. What are the advantages of using Obsidian as a task manager? Why is the fiddling and friction worth it, what is the payoff?
I’m NOT arguing one way or the other–just suggesting that WHY is fundamentally more important than HOW. If the WHY is sufficiently answered then the how will be easier to deal with. I recognize that the why will vary from person to person but surely there are general principles that answer the question of why?
It’s a fair point.
I have a few reasons, but the main one is that I want project planning and project “doing” to happen in the same place. If I’m writing a paper, I don’t need to go into OmniFocus and create a “Write a paper” project—I can just write the paper in Obsi, make that file represent a “project,” and add tasks inline.
While that’s the core of it, there are some other benefits:
- I’ve wanted a Kanban view of stuff in OmniFocus for forever. Now I’ve got it in Obsidian
- I can also interleave task-specific information (e.g., the “notes” field in OmniFocus) with project-specific information alongside different sections and images… I find I think less about where to put information this way, whereas in OmniFocus I was sometimes like “in which action’s notes did I put that link…?”
- Customizable metadata. You can sorta achieve this with hacky use of tags in other task managers, but with Obsidian I can add attributes and make them mean something. E.g., I can tell a Dataview query to sort tasks by “high/medium/low” energy. Granted, this requires being willing to learn how to “code” using dataview.
Of course, I don’t begrudge OmniFocus, Things, or those of you who love 'em. I just always felt something was missing, and that’s no longer true with the method I’ve adopted in Obsidian.
I have a few reasons, but the main one is that I want project planning and project “doing” to happen in the same place.
Thanks Ryan. Sometimes I get soooo frustrated–with myself! Talk about a yoyo, I feel like I’m in constant motion/tension on these matters! My fault entirely. So I have a few random thoughts/questions. Any insights you have will be appreciated. In no particular order:
- It seems that those who benefit most from an app like Obsidian are those with some coding/scripting skills, true/false? I have none and no inclination or time to learn coding/scripting.
- I like the notion of writing articles in Obsidian but I find that the markdown syntax clutters the UI, do you? And, isn’t one doing extra work to “clean-up” the final “product” in a rich text editor when it starts as markdown? I recall a recent podcast where Gruber was the guest. He said, to paraphrase I believe accurately, “markdown is overused, it is intended for writing for the web.” That was the gist of it but not his exact words. The only writing I do for the web is my blog. And, Pages and Word allow for exporting to plain text if/as needed. And, as you know, DT has a robust file conversion feature, including to markdown. If one is not primarily writing for the web, why use markdown?
- Have you considered NotePlan? I just learned this morning that NotePlan integrates well with Obsidian. As a result, one could have the advantages of NotePlan’s tasks features and access notes in Obsidian. I’m not using NP, I don’t want to pay a $60/year subscription but here is a great video on this: https://youtu.be/-HaUHb4R5XI
I know you have more to do than respond to my questions and quandaries but I read posts in this forum and then start to thinking that I can still do things better. What’s wrong with me!!
It seems that those who benefit most from an app like Obsidian are those with some coding/scripting skills, true/false? I have none and no inclination or time to learn coding/scripting.
I don’t think I can comment on this front. Maybe if I got a concussion, lost my coding abilities, and then tried…? hah.
I think it’s just that if you have the ability to script a little, Obsidian pays dividends. Similar to how using e.g., Bookends and Zotero might be basically equivalent unless you are good at AppleScript, in which case you can do more with Bookends, but it doesn’t affect your use of Zotero, because the latter can’t do AppleScript.
Certainly, though, some of the benefits I’m talking about (e.g., neat Dataview queries that give me views into my tasks and projects) would require you to just copy-paste what I (will eventually) share to use. That’s one kicker—to make the most of it, you’ll have to depend on community members who are sharing their approaches. It would be better if there was a good GUI for these features instead, making them more accessible to non-coders. Maybe eventually!
I like the notion of writing articles in Obsidian but I find that the markdown syntax clutters the UI, do you?
At this point I write markdown in Messages, even though it doesn’t render, so I’m definitely guilty of the overuse Gruber was talking about.
However, I think Gruber’s wrong about that—making him just a recent example of a classic pattern: the inventor who spurns uses of his inventions he didn’t imagine! (I’ve actually argued with him and Dave Weiner about this…)
Markdown’s really just a grammar for adding stuff to words. And it’s a really convenient one, because by representing that stuff in plain text, it’s easier to manipulate and use it. For me, it’s an escape from the fight with proprietary formats of a decade ago. You should be able to put something in plain text that, without being exported or imported, can be rendered in any number of applications. That’s the key, for me: one copy of anything.
However, the latter part of your question here definitely makes things challenging. I do have to write in Word for academia, and so inevitably the stuff I make has to be converted from Markdown to .docx. There’s lots of good options for this, so it doesn’t bother me too much, but yes—there is a very annoying step in the paper-writing process where I take the results of such an export and spend half-an-hour modifying it to fit whatever template is required.
However x 2, I’ve never been able to escape from that last step. In my experience, publishing in academia always demands some kind of convert-to-the-conference-template step, and that’s always annoying. So, whether I have to do that from a rich text editor or a markdown editor, it’s still there.
Have you considered NotePlan?
I used to use them simultaneously → Using Obsidian and NotePlan together.
Obsidian’s since built out a few features that let me drop the sync process. But yes, if you can/want to make it work, it’s a fun combo. I believe @JohnAtl and others here are more of an expert on NotePlan these days than I am now! → Some of my NotePlan templates and use cases
I also think a thorough discussion of WHY one would want to take this route rather than using a dedicated task management application would be helpful.
Take, for example, David Allen’s Getting Things Done (GTD), the life-management system that inspired many of the dedicated task management applications. The GTD system (or a variant) is medium-agnostic and can be implemented in various ways: some people implement it on a few standard index cards or in a single text file. (Follow those links to read the reasons why people use those media.) For years I’ve implemented GTD in my personal hypertext system, a set of simple rich-text HTML files written in TextEdit (a format that I described in this forum here and here). I imagine that my reasons for implementing a life-management system in my way are similar to @ryanjamurphy’s reasons for implementing a system in his way: it was the best way I could find to integrate all the aspects of my life and work. I won’t go into the detailed reasons, but that was my bottom-line conclusion.
I’ve been considering using Obsidian—all I would need to do is convert my existing files from HTML to Markdown using Pandoc, so I could very easily move my current system into Obsidian; it makes perfect sense to me, but I haven’t decided yet if the balance of pros and cons leans in that direction. My current system relies heavily on macOS tags, and I am unsure about abandoning them for Markdown tags.
all I would need to do is convert my existing files from HTML to Markdown using Pandoc
You may not even have to convert your existing files. Markdown supports inline HTML. In my limited experience, Obsidian does a reasonable job rendering HTML documents, at least if they’re fairly simple.
You may not even have to convert your existing files. Markdown supports inline HTML. In my limited experience, Obsidian does a reasonable job rendering HTML documents, at least if they’re fairly simple.
Nope, I just tried opening my system as a vault in Obsidian, and it doesn’t work; Obsidian doesn’t see the HTML files. It was a great idea, though—it never occurred to me to try. Converting to Markdown would be easy; I would just lose some of the rich-text features such as highlighting that Markdown doesn’t support, as far as I know. Thanks!
highlighting that Markdown doesn’t
Actually, markdown does support highlighting. The syntax will vary a little depending on the flavor of md you are using but either :: or == works.
Change the file extension to .md and it should show up in Obsidian.
However x 2, I’ve never been able to escape from that last step. In my experience, publishing in academia always demands some kind of convert-to-the-conference-template step, and that’s always annoying. So, whether I have to do that from a rich text editor or a markdown editor, it’s still there.
That is a good point! In my case, however, my main academic work at this point aside from graduate course lectures is a book project, which I’ve found is best done in Scrivener (after trying Obsidian, Craft and Ulysses). Consequently, my main use case is writing work related communications and presentations. I’m not sure it makes a lot of sense for me to write in markdown and then clean it up in a PDF or Pages doc. I know that Obsidian and other editors like iA Writer render to Word, PDF, etc., but I often need to add images, tables, etc., which is clunkier in markdown than in a rich text word processor.