The future of Kanbn

A bit over a year ago I was exploring alternative to Jira’s/Trello’s kanban boards. I was looking for something that would ideally not require an internet connection, and that I would be able to use without leaving my text editor.

That lead me to Kanbn. It was a killer VSCode extension: it looked really good visually and it did most of what I needed it to do. The one issue I had with it at first was that it only allowed for one board per workspace, so I forked the repo and added support for an unlimited amount of boards per workspace. The original author wasn’t interested in merging the changes, so I ended up creating my own version of the extension on the VSCode store as well.

I did some other bits of work after that, but mostly just spent time fixing whatever I had broken when introducing the multiple-boards-per-workspace feature. That’s not to say that it doesn’t need work: there’s little bugs and inconveniences all over the place, and there’s plenty of missing features. I think the time has come to tackle some of them: I want to remove as much friction from my usage of the application, and I’m prepared to invest a significant amount of time to do so.

TLDR: I have some big plans. :) Below I go over the main issues I want to tackle.

Encouraging community involvement

For starters, I want to create and involve the community insterested in Kanbn. I’m therefore creating a Discord server, adding GitHub discussions to the repository, and intend to create documentation and guidance for prospective contributors.

I’m aware that the current community for my the extension is small, but I still want your feedback! And (eventually) more people working on the project, since I estimate it would take me multiple years alone if I tried to implement all the features I want, as well as cater to everyone else’s preferences.

(Also on an unrelated note, if someone wants to create a logo for this project, that would be highly appreciated! Reach out on the Discord server or on GitHub)

More testing

Currently there’s barely any tests in the underlying Kanbn library, and none at all in vscode-kanbn, so I find it very difficult to make changes without breaking existing functionality. That is not very sustainable long-term, and costs me extra development time. Therefore this is one of my main priorities, even though it is going to take forever and won’t affect existing functionality (with the exception of maybe catching some bugs I’m not aware of right now).

Fixing inherent design issues

There are a couple fundamental design decisions that are a big pain in the ass to work around at the moment.

  1. The task’s id, task name and and file name are all basically the same. This makes it extremely annoying (and bug prone) to work on tasks without a permanent id, but it also means that you can’t have a permanent link to a task file, because it might change in the future. I want to introduce the Jira’s ticket numbering system, where the first task you create gets id (and file name), or, or some similar variation, and then keeps increasing by 1. The task names will still be part of the file, so the convenience there won’t change (if anything, it will be more convenient, because the lines will become shorter). And it will greatly simplify the task id handling on the implementation part.
  2. There is no proper subtask support / task linking. Current subtasks are just a single lines of text with a checkbox next to indicate completion. In particular, that means that you can’t have nested subtasks, or add custom attributes to them. I don’t see a good reason to keep it this way.

To add these fixes I will need to introduce some breaking changes to the current format, so I also need to introduce versioned board / task formats, as well as simple ways to convert to newer formats. I expect that will once again be quite time consuming.

Port to

This is more of a personal priority. I’ve recently started using Obsidian for my productivity system, and the only thing I’m missing is the ability to open / embed Kanbn boards.

Now I’m not abandoning the VSCode extension. What I will try to do is extract some parts of the current extension (especially the frontend components) as their own libraries for more code reuse. And who knows, I might even make a standalone Kanbn app in the future!

Removing bloat

The webview components are currently written in React. React is a big framework, and likely unnecessarily so. I intend to explore other frameworks / a plain javascript solution to see if that improves performance, as well as package size.

Similarly the underlying Kanbn package is currently bundled with a cli tool that is not needed for use as a library. I intend to separate the cli tool into a separate package as well.

Rewriting the underlying library in Rust

Somewhat related to the point above, I believe the underlying library would be much better suited for a strongly typed language such as Rust. It will be easier to test, enforce a consistent API, and should be an improvement on the performance.

Plus I want to learn Rust and this is a good excuse to do so. :)

There is also something to be said about doing this rewrite before creating proper tests to avoid the need to rewrite the tests later.

Custom board layouts

Currently Kanbn allows custom css, but there is no way to more meaningfully change the structure. I would like to explore introducing custom user javascript, html, or some custom templating language that would give more control on what columns are shown in a board view, and what happens when moving between columns.

A related feature I’m considering is board views: boards that either combine columns from a board / multiple boards, or filter the columns (based on tags for example).

Undo / redo mechanism

This is an obvious one: for the webview panels to feel like first class citizens in VSCode (and other applications like Obsidian), it should behave as much like the text editor panels. This holds true both for the board and task editor views.

Seemless integration between text files and webviews

Currently there is no way to open the Kanbn board webview from the corresponding md file, or vice versa. Obviously this is inconventient.

Task estimates

Another personal priority. I want native support for task estimates (how long I predict a particular task to take). More specifically I want the task estimates to automatically and dynamically propagate up the hierarchy, resulting in data that looks like this:

2 points (+10 children points)

The 2 points here is the estimate for the current task, and 10 points for all of it’s children. Additionally I’ll want a column with the remaining points based on the completion amount of the current task and children tasks (again dynamic).

Search support

The existing VSCode search functionality is already quite good, but I believe it can be made better. Plus if I make Kanbn into a standalone application at some point, I won’t be able to rely on native VSCode or obsidian search capabilities and will therefore need a custom search solution.

Key bindings for actions

I want to introduce (at least) the following shortcuts:

  • Tabbing between fields in task editor.
  • Shortcuts for selecting and moving task cards in different columns.
  • Undo / redo functionality.
  • Search / filter functionality
  • Switching between text file and webview.

Other small features

There are a number of smaller issues, bugs and missing features that I keep track of. These are not a priority for me at the moment, but if anyone feels passionate about something feel free to contribute! If you have any questions feel free to ask in either GitHub Discussions / Issues or the Discord server!