The Taskora Convention
We need richer tasks in markdown [wonkish]
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.
I am in a special situation since I am using the Typora markdown editor system to manage my workings. Over the years, I have tried a variety of ways to enrich tasks beyond the checklists that Typora has implemented. Recently, I have settled on a system that I call the Taskora Convention.
The Taskora Convention
In many markdown editors — like Typora — the sequence of characters ‘- [ ]’ and ‘- [x]’ are rendered this way, respectively:
If I wanted to represent an urgent task, say, by using the sequence of characters ‘- [!]’, it would render like a bulleted list element, and not look like the other sorts of tasks:
However, if I enclose all task prefixes in tick marks (‘`’) Typora and other markdown editors treat the ticked text as code, like a programming language. While this blocks the rendering of open and closed tasks into round boxes, it has the benefit of making all tasks look similar, and highlights the prefix.
Here’s the list of task types in the (draft) Taskora Convention. I will discuss each afterward.
Unlike the common extensions of markdown, there are four types of open tasks in Taskora.
Not Started — `- [ ]` represents tasks that have been created but where no work has started.
Like all tasks in Taskora it can have a deadline, like
or can be assigned to someone as in
Note that Typora doesn’t support the @-mention convention, but it can still be searched for productively, like finding all the tasks assigned to ‘@mike’.
In Process — A task that is in process (and not blocked) is marked `- [=]`, and other attributes can be used to set a deadline, assign the task, or indicate when work started. For example, here’s an in process task with a start date (leftmost) and deadline (rightmost):
The ‘:’ ties the two dates together. Note that a date by itself is taken as a deadline (unless a ‘:’ is tacked on) since deadlines are more common than starting dates.
Blocked — A blocked task is denoted with ‘- [/]’ and can include information about what is the blocker, like this:
The ‘finish elitarian research’ is the blocker, and while it implies another task, but one that is not explicit. It could be an explicit task, which would use a @-mention:
Alternatively, this might be set up as a subtask, below.
Urgent — Means that no work has started on the task, otherwise it would be either in process or blocked.
One of the subtleties introduced in Taskora is two forms of inactive tasks.
Possible — The first (`- [?]`) is one I use many times a week, denoting a likely task, but one not yet started, aside from thinking about it.
Suspended — The second (`- [:]`) is when a task — in whatever state — is suspended, not because of a blockage, with the possibility it could be reopened later.
Closed — The form of the default closed task but enclosed in tick marks`-[x]` is still used for closed tasks, and can bear all sorts of attributes, like deadlines, assignments, tags, etc.
I have appropriated the use of ‘>’ to indent subtasks under parent tasks. (Note in this example you can see a naming convention I use, where the project name is the first few words in a task, in this case ‘work futures’.) Here’s an example with two levels of subtasks:
In the above, the first task is the top-most parent. Note: I use a convention to repeat the project name and parent task name for tasks so that I can find the parent and all subtasks with one search for ‘work futures | write elitarian post’, shown below.
Typora’s search results are clickable, so I can click to get to any desired task. The search works over all files in the folder so this would bring up all hits across all files.
Making Taskora Workable
The principal key to Taskora is the Typora search capability.
Let’s say I want to find all the tasks of any state associated with ‘work futures’. I could use a search term like ‘]` work futures’. Note I have to include the tick character:
If I wanted only in process work futures tasks, I would use this search: ‘=]` work futures’:
Or, if I wanted only possible work futures tasks, ‘?]` work futures’:
An important part of my Taskora workflow is using TextExpander to, well, expand text abbreviations into Taskora constructs. I’ve defined a group of text snippets (on the left) with corresponding shortcodes (on the right) to quickly create tasks:
In this way, I can type ‘//!’ and TextExpander turns that into ‘`- [!]`’, and so on.
Taskora implemented in Typora
Taskora is parasitic on Typora: it lives there, but Typora doesn’t implement it explicitly. Taskora works in its present fashion because of the way that Typora treats ticked text, the way that search works, and the reuse of markdown blockquotes.
Typora’s developers could in fact decide to support Taskora as a specific superset of markdown. Perhaps that could be implemented the clever way that Typora has chosen to support markdown tables, LaTeX, and various diagramming systems (like Mermaid).
Taskora can be adopted today for use in Typora and other markdown systems.
One feature that would make Typora better across the board, as well as supporting Taskora better, would be the ability to save searches within the search capability. That way I could define a search like ‘]` work futures’ and it would appear in a list as I typed in the search box. Another feature that could help would be saving the results of a search as a markdown file.
Of course, a richer task system could benefit from deeper support than these initial steps, and I will try to sketch something out about that, and I will plan a follow-up on Taskora as I continue to use it daily.