‘Kanbanibalization’ in Obsidian

Moving from Search and Dataview to Kanban, all the way down

[Originally posted 2022-10-21: Note that these ideas have progressed in the year since, and I will be moving the materials formerly on Medium back to Substack. Expect more to appear.]

I have been experimenting with an evolution in how I manage my work in Obsidian. Ever since I adopted Obsidian, I’ve used Dataview as a unifying element of my workflow. In a nutshell, I’ve relied on this basic model, which I have called Taskidian in the recent past (see Taskidian [Unwonked]):

1. I defined tasks in whatever Obsidian context I happened to be: in a daily note, in an interview file, in a meeting note, in an annotation of a webpage pulled into Obsidian by one external tool or another.

2. I relied on various Taskidian-specific metadata to be able to find and filter tasks.

3. I used the search box or the Dataview and custom queries plugins to subsequently search for specific tasks or groups of tasks.

Over the last few months, I’ve started to use Kanban boards for work management, and I have shifted my thinking in a fundamental way. In Taskidian 1.0, I could be very unstructured in where I created tasks because I heavily annotated them with metadata so searching for them later was relatively easy.

---

---

Now, I qualify that claim as ‘relatively’, but several of the cons of Taskidian meant that when looking at a dataview or a search result I was presented with a generated list of tasks that were 1/uneditable and 2/ unorderable. So, if I used Dataview to find, for example, all the tasks associated with a subproject — denoted by [øø:: subproject] — they were just a jumble. I took the step of adding an additional metadata field to denote the stage in the project, as in [do:: next]. Here’s an example task of that form:

- [?] [ø: work futures] [øø:: longtermism] MacAskill thread [do:: next]

With that extra metadata, I could group or search via the next value of the do field. Complex Dataview queries, but more or less workable. However, messing with the outputs of search and Dataview is a problem, because — with the exception of clicking off tasks and clicking through to edit the source tasks in their respective files — you can’t manipulate Dataview and search results directly.

I’ve long favored the visual presentation of Kanban boards, so I took another run at their use, in place of increasing the metadata overhead of do:: fields.

Here’s an example of a ‘stack’: the term I’m using for a specific sort of Kanban, which has these lists: now next soon someday done. The first list has a simple task, defined in the Kanban card directly. The card in the next list is complex, shown by the link symbols. This means the task is transcluded from another file. Hovering over a link shows the source file, and clicking on the link will open the source. Clicking elsewhere on the card opens the card for editing.

Kanban ‘Leaf’ — A Detailed Editorial Project

[Note: the Kanban board rendering displays cards in read mode, so that does things with footnotes and tags, as in the task in the next list, above].

Here’s the same Kanban with the complex task open for editing:

Complex Kanban task open for editing

You might wonder about the complexity of creating such a transclusion, but it is surprisingly easy. In this case, I created the original task in the interview file I made, then I shifted to the interview sander stack Kanban file, created a new card in the next list, and created the transclusion. Because of Obsidian's built-in transclusion support, I only had to type [[ and then select from a list which was refined by my typing interview and the file appeared. I appended ^ to select a block and scrolled down the dialog to pick the task. I then selected the defined task and added a ! to start off the transclusion.

The immediate benefits of this over a search or Dataview query are considerable.

• The elements in a Kanban can be moved around by dragging and dropping, so I can denote a task as now instead of next easily, without having to edit the metadata in the source file.

• The Kanban resolution means that files can be accessed easily through the displayed links if I do in fact want to edit something in a task.

• As with search and Dataview results, I can click off the underlying tasks.

But I discovered an even more interesting benefit: Kanban boards can be nested, to very good effect.

Kanban ‘Tree’ — The Work Futures Editorial Calendar as a Kanban

There is no option to choose the mode of the nested Kanban: it is displayed as Markdown mode. But that resolves as I would have chosen anyway. In this way, the editorial calendar file represents a Kanban ‘tree’, a kanban that includes another kanban as a card, or to follow the metaphor, as a leaf of a tree. Here’s an illustration showing two ‘leaves’ being incorporated into the Work Futures editorial stack Kanban:

Look! It’s a tree!

And of course, as shown here, other project kanbans could be included in the editorial calendar. I intend to do that going forward, now that I am ‘kanbanibalizing’ all my existing project searches and dataviews into trees and leaves.

Also, if some step in the Interview project, for example, turned out to be complex enough to warrant its own kanban, it could be created and nested in the Interview kanban. Then the Work Futures editorial kanban would show three levels of projects. I am not contemplating that at present in my own planning process, but for larger scale work it might make sense.

In the future, the Kanban plugin might support swimlanes, and other techniques to handle scale and scope, but for now, this sort of complexity could get out of hand with more than two levels.