Rethinking Folio: Without Kanbans
Rethinking Folio: Without Kanbans
Doubling down on the knowledge graph.
Over the past year or so, I have developed a notetaking system that I refer to as Folio. In the past month, Folio has undergone a few changes: some being simple evolution of existing Folio patterns, but one in particular is fairly major. I am deprecating the use of Kanbans in Folio, which were — until this time — a major component of the system.
What’s wrong with Kanbans?
I’ve written extensively about Kanbans in Obsidian and Folio. In ‘Kanbanibalization’ in Obsidian, I laid out a fairly complex way to use Kanbans to manage projects. And in The Philosophy of Organizing Our Notes, I described how I had adopted a pattern of putting all tasks in Kanbans:
I now create basically no tasks in individual ‘normal’ notes. The tasks only exist in the Kanban notes. And the Kanban notes are located in folders of the same name, more or less. In the case of my work with Client, I maintain a Client parent folder, and a subfolder for each writing project, in which I keep a Kanban for the project, a checklist child Kanban (here called ‘project’), a Kanban archive file (so I can archive tasks if I wish to), and any other documents central to the project (like this note that I am writing, right now).
This means I don’t have to rely on search to find all the tasks associated with a specific project: I can simply open the Kanban file, and it’s all there, everything in its place. Note that I retain the pragmatic capability to create notes anywhere on anything, and I can subsequently reuse materials I capture long before the project was envisioned and turn materials into tasks on the Kanban or on many Kanbans. I can use parts of Dan Shipper’s The Notetaking Cold War for other projects, and the tasks don’t stack up in that file; they are tied tightly to the project.
But that approach grew to be a chore. The overhead of switching out of a working context — like writing something in a daily note, or making an annotation in a note describing some project plan — and opening a Kanban file and creating a card there felt more like friction than function.
There are other headaches with Kanbans.
Kanbans are separate notes: they can’t be embedded in a code block or like a table. Obsidian does now support a form of transclusion by editing in the hover editor, and other plugins — like Make.md — create true transclusion, but it still introduces some fiddley behavior.
One limitation of using the hover editor is that the Kanban note is rendered as markdown, not in a Kanban board form.
Kanban cards and headings are addressable — like `
![[workings kanban#^hover]]` — but specific built-in capabilities of the Kanban plugin have broken these links for me in the past, unpredictably.Kanbans are exempted from the general rule about notes’ references: a reference like `
[[2024-10-01 some note]]` isn’t updated if the note’s name changes to something like`[[2024-10-01 a better name]]`. This was a continual annoyance.
But it really wasn’t the tiny nits of Kanbans that pushed me away. Instead, I was shifting how I was dealing with projects as a key part of my Folio knowledge base, and the desire to rely more on the graph model that is the central organizing principle of Obsidian. In essence, Kanbans, and other non-graph-centric organizing systems, like tags, diverge from the Obsidian graph, while I am trying to double down on the graph.
Extending the Folio knowledge base: doubling down on the graph.
I have written about how I organize a large and growing collection of Obsidian notes to represent interrelated concepts and the other notes that reference them. I wrote about that in some depth, here. At that time I wrote:
I confess that I have used a simplified version of how I use these links in the example above.
I actually have a more sophisticated approach, which I think of as a knowledge base, where I apply either an asterisk, a plus sign, or a degree symbol as the first character of the knowledge base file names. An asterisk indicates a person file, like
[[@John Maynard Keynes]]Because of aliases, this could also be rendered like this:
[[@John Maynard Keynes|Keynes]]A plus sign indicates a concept, like
[[+heat island effect]]And a degree symbol indicates an organization, like
[[ºApple]]This allows for distinguishing between ‘[[ºApple]]’ and ‘[[+apple]]’, and in both cases they could be aliased, like ‘[[ºApple|Apple]].
I have set up rules for the Obsidian Auto Note Mover plugin so that files with those three characters in their titles are automatically moved to folders for people, concepts, and organization all located in a top-most folder in my vault called ‘00 knowledge’.
Since the time of that post I have added other taxa to this knowledge base taxonomy, which now includes these:
people — indicated by a leading ‘
@’, like `[[@John Maynard Keynes]]`.places — indicated by a leading ‘
~’, like `[[~Paris France|Paris]]’concepts — indicated by a leading ‘
+’, like `[[+heat island effect]]`.organizations — indicated by a leading ‘
º’, like `[[ºApple]]`.projects — indicated by a leading ‘
•’, like `[[•work futures]]`, or `[[•workings]]`.states — indicated by a leading ‘
%`, like `[[%soon]]`, `[[%published]]`, `[[%done]]`, or `[[%in process]]`.
In practice, I can create embedded queries (supported by the Query Control plugin) containing combinations of these taxa, for example finding all instances where an Obsidian block contains ‘[[•work futures]]’ and `[[%soon]]`, like this:
```query
collapsed: false
title: soon
sort: byModifiedTime
line: ("•work futures" "%soon")
```
Here’s the results of that query in my vault:
These results are stories I plan to write about for my Work Futures newsletter in the near term. The `soon` query is one of a series of embedded queries that pair the `[[•work futures]]` project with various states that are applicable to a publishing project, such as `[[%soon]]`, `[[%later]]`, and so on. The `work futures` query contains queries for each of those states. This is the source in that query note:
In essence, this project query emulates a Kanban, although the various states are arrayed vertically, not horizontally. In use, the results are scrollable in each state and across the query results as a whole, a capability the Obsidian Kanban plugin does not provide. (In fact, scrolling across a horizontal Kanban with many states is one of the most annoying aspects of the Kanban plugin.)
I ordered the series of states in a timewise fashion, from `next` to `later`. (I omit the `published` state because it leads to too many results for the `work futures` project, and generally, I’m not searching for published materials. If I want to, I can do a regular search for what every combination of taxa needed.)
The results are clickable, so I can easily jump from a query result, like the `Can Design Thinking Succeed in Your Organization?’ or the `2024-09-18` daily note, and start working there. Here’s the line referenced in the daily note:
The line referenced is a heading in the `2024-09-18` daily note. I use an interstitial journaling style, so over the course of every day I may make dozens of entries, timestamped and annotated with concepts, like `+boeing machinists strike`, projects, like `•work futures`, states, like `%soon`, and other taxa. Note that each of those taxa can be opened, showing the corresponding knowledge base note. Here’s the `ºBoeing` organization note with backlinks, for example, and its corresponding graph:
In my writing work, I am constantly roaming around the graph, visiting various nodes, pulling materials to write newsletter posts and articles. For example, I am at work on a piece on Boeing, and might use quotes and ideas from these various authors. I might also traverse the link to `+co-determination` to see where else union members are demanding seats on boards, and this brings in wider commentary, since I have been ‘annotaxing’ (‘annotating’ + ‘taxa’) using these terms for years.
This cascade of images I hope will give a sense of the utility of a deeply and richly annotaxated volume of Obsidian notes. While the time cost of close annotation — footnoting, highlighting, summarizing, and embedded annotaxing (turning some other author’s use of `Keynes` to `[[John Maynard Keynes|Keynes]]`) — is considerable, afterward I benefit immensely from the graph that it builds. And I leverage other tools and plugins to make annotaxing a note less of a time sink (like the clever ‘link with alias’ plugin).
And unlike tags, wikilinks like `[[John Maynard Keynes|Keynes]]` are situated directly in the text. And when writing a link to Keynes, the Obsidian editor will provide support for annotaxing:
And if I hit carriage return at that point, Obsidian creates the link with the alias.
One more thing…
I have been constantly evolving Folio, and these changes are the outgrowth of my consistent use of Obsidian. I don’t use many other tools, and the graph I have built around Folio’s principles is becoming richer all the time.
