Taskidian [Wonkish]

A Task System and Project Management Approach for Obsidian

Proviso

This post is oriented for Obsidian users with a familiarity with the Dataview plugin. For others, it may be impenetrable.

Background

For years, I have argued that markdown needs a richer set of states for tasks. The idea that tasks have only two states — open and closed — is nothing like how we think about tasks, in fact. When I create a task it could be something I need to do immediately, or just an idea I am musing about. Some tasks cannot proceed until something else occurs, for example, and a task that I have been working on for weeks is very different from a task denoting a task that — while open — I have yet to actually start to work on.

Many work management tools have offered a wider range of options for tasks, either through explicit task states or through task attributes: many systems implement priority schemes, explicit deadlines, and task dependencies.

Typora and Taskora

Prior to migrating to Obsidian for my 'workings' -- the tools we use to think, write, and remember -- I had relied on Typora, a wonderful markdown editor platform. Typora doesn't aspire to being a workings platform like Obsidian. For example, it lacks backlinks, wikilinks, transclusion, and a graph depiction of cross-document references. However, I developed a task management system that worked well for me in Typora, which I referred to as Taskora. I will not recap the many features of that system, but it served as the starting point for the task management system I am using now on Obsidian, which I call Taskidian. Taskidian can be considered Taskora 2.0.

Taskidian is a parasitic task management model, in that it builds upon and extends the base task model of markdown, and incorporates other plugins of great power on Obsidian, most notably Dataview.

---

---

The Core Taskidian Task System

In most markdown-based platforms, such as Obsidian, tasks are represented as having two states:

- [ ] an open task

- [x] a completed task

These are rendered like this in Obsidian:

As I mentioned in the background, there are many other states for tasks. In a perfect world, I might create a plugin for Obsidian -- as others have done -- that would extend the base task model by denoting additional task states by putting other characters between the square brackets of the task prefix. In this way an urgent open task could be represented by this:

- [!] an urgent task

Since the hypothetical Taskidian plugin doesn't exist, though, the Obsidian platform renders this text simply as a completed task. (In Taskora, I avoided this problem by leaving off the initial '-' for all task states, and not worrying about rendering, which is not what I'd like).

Also, there are a large variety of Obsidian plugins that rely on the open/completed binary states of markdown tasks, which I want to be able to use in Taskidian so I need to continue to support those fundamental states, even while wanting to denote other states. As a result, I am relying on the Dataview plugin and its model of task attribution to denote the other desired states. (Note that foundational open and closed tasks -- without Taskidian annotations -- can still be used for simple purposes -- think shopping or packing lists -- but do not benefit from other aspects of Taskidian, such as Dataview queries to support project management, about which more later.)

All the state annotations take the form of Dataview attributes, where I have adopted the option-o character ('ø') as the name of the task state. So the urgent state discussed earlier is denoted in this way:

- [ ] [ø:: !] an urgent task

which renders as this:

(To avoid typing Taskidian task prefixes I use TextExpander on my Mac and have defined the sequence '//!' to generate that prefix, for example.)

Here are the current task states that I use commonly. Note that it is a flexible convention, and can be modified and extended by other users.

Taskidian Task Convention

Taskidian tasks can be `prospective`, `active`, `inactive`, or `closed`. Taskidian tasks can change state. And at a markdown/Obsidian level, they are either `open` or `closed`.

undifferentiated tasks

- [ ] undifferentiated task, may be prospective, active, or inactive (too vague for project management)

prospective tasks

- [ ] [ø:: ?] prospective, possible task, not started

- [ ] [ø:: ¿] prospective, anticipated task, under review (still prospective, but actively being researched)

active tasks

- [ ] [ø:: =] in process task

- [ ] [ø:: !] urgent task

inactive tasks

- [ ] [ø:: /] blocked task (waiting on something else to complete)

- [ ] [ø:: :] inactive task (formerly active, now suspended but not blocked)

closed tasks

- [x] undifferentiated closed task (bought milk, for example)

- [x] [ø:: !] closed urgent task (and all other Taskidian tasks, too)

Taskidian Project Management and Examples

The Obsidian Dataview plugin is central to Taskidian project management, which takes advantage of Dataview attributes and queries extensively. Following the pattern of Taskidian states -- indicated by Dataview attributes like `[ø:: !]` -- I use a double-ø ('øø') to indicate a project name, as in `[øø:: workings]`. (As with Taskidian prefixes I have defined short text keys in Text Expander so that I avoid having to type common project names. I use '//wo' for the `workings` project, for example.)

I have been working on this post for some time. In my project management approach, I rely on journaling. On 2022-03-08 I created an entry in my `workings journal` folder, nested in my top-level `00 workings` folder, managed in my Obsidian vault. In my system, all journal files are titled by date and then explanatory text. (Note: I plan a post focused on folders, tags, and file conventions.)

Here's that folder/file structure:

00 workings

00 workings/workings journal

00 workings/workings journal/2022-03-08 - various taskidian writings

The initial task was structured like this in the journal file:

- [ ] [ø:: ?] [øø:: workings] intro to taskian

That `intro to taskidian` task was created as a prospective task in the `workings` project, initially, but the other day I decided to make that project urgent, and to add some subtasks and a due date. Here I added the `due::` attribute, which lines up with Dataview usage, and can be searched for in queries. I also added three subtasks to remind myself of things to mention:

Subtasks are a native Obsidian capability: tasks nested under the parent task. The block -- headed by the parent task -- can be referenced as a whole, and Obsidian will offer up a link for the entire block, but not subtasks independently. The subtasks here are the three nested tasks below the parent. Note that I don't attribute the subtasks in this case, since Dataview attributes on subtasks are in effect ignored by Dataview’s Task queries.

Here's an example of a Dataview Taskidian query, `due this week`. I created a file with a single query, to display tasks due this week. The query is this:

TASK FROM "2022 journal" OR "2021 journal" OR "00 other projects" OR "00 work futures" OR "00 workings" OR "00 cisco"

WHERE !completed

WHERE (due >= date(today)) AND (due <= date(eow))

GROUP BY due

(Note: the laborious list of top-level folders is intended to avoid certain other top-level folders: specifically, journals from previous years. It's an approach I use in many Dataview Task queries.)

The result of this query (at this moment) is this:

I want to draw your attention to the March 15 task, which is the one we've been discussing. First, note the link icon that Dataview appends to tasks and subtasks. These are clickable, but the links only refer to the file the task is located in, so you may have to scroll around to find the task. (This is a limitation of Dataview, and should be fixed.) If I am going to click on the link, I often land at the file and search for the task, like `intro to taskidian` in this case.

Note also that the tasks revealed by the Dataview query are drawn from all over, and are sorted by date, not file name or project name, although both of those options can be set up. In this case, I am grouping/sorting by date.

Note that the `intro to taskidian` task has a block reference appended, which means that there is a wikilink and/or transclusion referencing the task. I mentioned that Taskidian tasks can be `blocked`, and I use a convention occasionally to link a blocked task to the task blocking it. Here's an example, in the `2022-03-08 - various taskidian writings` file:

Here you see the third task -- `redo Wrestling with the angel of death` -- is `blocked` and `needs` the `intro to taskidian` to finish before it can continue, which is indicated by the `^df92ec` block reference. Note the connection between the two is just a reference, but could be a full transclusion if I added a '!' before the wikilink, but since the two tasks are in the same file, not necessary. Also, this could all be accomplished informally in text, like this:

`- [ ] [ø:: /] [øø:: workings] redo Wrestling with the angel of death with Taskidian instead of Typora) (needs Intro to Taskidian) [due:: 2022-03-31]`

I'll show one other query to see that `blocked` task that is due at the end of March, the task at the bottom:

Here's the query for `# due this month after this week`:

TASK FROM "2022 journal" OR "2021 journal" OR "00 other projects" OR "00 work futures" OR "00 workings" OR "00 cisco"

WHERE !completed

WHERE (due >= date(eow)) AND (due <= date(eom))

GROUP BY due

So, the query finds all incomplete tasks with a due date on or after the end of this week but before or on the end of the month.

`Project Status` files

In my use of Taskidian, I create a project folder -- like `00 workings` -- and in that folder, I create a status file, like `00 workings/workings status` which includes something along the lines of this query to display tasks by subproject, which I represent like this `[øøø:: obsidian]` (note that I left out subfolders in the earlier examples for simplicity):

TASK

FROM "2022 journal" OR "2021 journal" OR "00 workings"

WHERE (øø = "workings") AND !completed

GROUP BY øøø

The query produces something like this:

Compatibility with Kanban

The Obsidian Kanban plugin relies on Obsidian/markdown tasks and is compatible with Taskidian. For example, here's a Kanban for a hypothetical project called `Jones`.

Here's the Kanban, with project and task attributes included, so that they will appear in other Taskidian queries, and not just within the Kanban:

The underlying markdown:

Note that the Kanban plugin places limitations on what you can do. Anyone trying something fancy -- like subtasks -- should read the Kanban plugin documents closely, because any additional markdown can be wiped out by the Kanban plugin.

Integration with Daily Notes

I wrote a lengthy post recently -- How I Use Daily Notes In Obsidian [Wonkish] -- that touched on how I have integrated Dataview/Taskidian into my daily notes. I won't recap that here except to say that I more or less treat daily notes as my landing page or home page in Obsidian, and then -- a few times a day -- I browse project-specific status files, and read, create, and manage journal files. I am also highly reliant on the various Taskidian queries I display in the right margin under the daily calendar.

---

---

Looking Back, Looking Ahead

Taskidian provides a much richer task state model than plain vanilla Obsidian markdown. The project management model laid out in this post has been developed in the context of Obsidian and relies greatly on the Dataview plugin to do much of the heavy lifting.

In the perfect world, I would like to imagine a Taskidian model that would do a great deal more than what Dataview queries provide. For example, there could certainly be a better way to indicate dependencies between tasks than the `needs` convention I am using at present. Classic methods like Gantt charts would be nice. I haven't spent any time looking at charting approaches like Mermaid or Excalidraw, or various mind mapping tools, but they might serve to some extent.

One of the nice qualities of Taskidian is that it stays very close to markdown since Dataview's annotations are textual and in context. All the information needed is found right in the tasks' text: there is no hidden database somewhere. So Taskidian, like Obsidian, is based principally on markdown. Yes, Taskidian takes advantage of Dataview, but if I had to migrate from Obsidian to some other system, the information is all there in the tasks’ text. In that way, Taskidian's philosophy lines up with Obsidian's.

Taskidian has stabilized in recent months, after some experimentation and extensions in the first months of my migrating to Obsidian. However, it's possible that additional capabilities offered by new plugins or a more advanced Dataview could lead to new extensions to Taskidian. We'll just have to see where it goes.

One dimension that has not been explored to date relates to sharing Obsidian documents with collaborators. Up to the present day, I have not looked into shared Obsidian approaches (aside from a peek at Sekund, which I will be writing up, soon). However, I could readily imagine adopting sharing conventions used in other work management solutions, like task assignment. In such case, I might rely on Dataview again:

- [ ] [ø:: !] [øø:: Jones] [due:: 2022-03-19] [to:: bette boop] [from:: stowe boyd] plan kickoff

which renders like this:

[Note 2022-03-19: In an earlier version of this post I suggested using superscript (‘<sup'>’) for the various Dataview attributed on the task above, but it led to a bug in the Dataview parser, so we have to avoid that.]

I could gin up Dataview queries that would group/sort by assignment to track those attributes. Likewise, as a member of a group sharing a set of Obsidian documents I could run Dataview queries to pull up tasks I had assigned to others, and those assigned by others to me. Here's an example query running in the right-hand side panel:

That aspect of Taskidian is going to be very fruitful in the future, I believe.