Task Index

[srid]

Emanote can provide a very simple task tracker that is built-off good ol' Markdown checkbox items.

Basically, add an aggregation page /-/tasks that displays checkboxed tasks (cf. #154) from all notes ... and display them hierarchically using the folgezettel heterarchy (includes folder layout). Include sub-headings in the hierarchy as well.

In addition, if deemed necessary in practice, allow each task to be annotated with metadata like tags, due-date. We need to come up with a syntax for it. For example,

- [ ] Buy milk #shopping due:2021-11-21

With #84 in place we can even provide a way to filter the tasks in browser, by any of these metadata property or task description search.

This feature should remain simple, without bothering with unnecessary features of traditional task trackers.

This feature would be a candidate for #83 - but I feel that it should be done anyway (I need it for my own use) without a plugin architecture in place.

---

• Implement MVP (operates on task list and folgezettel) Add Task Index #182
• Add tags and due-date, as seen necessary in practice (otherwise, discard)

[vcavallo]

I strongly encourage using the http://todotxt.org/ syntax. this is already widely supported by many platforms and apps (I use an iOS app with a dropbox-hosted file myself) and having it inter-opable with emanote would be great!

[srid]

I can see borrowing some of its syntax (such as key:value), but I see no reason why a Markdown app's syntax should interoperate with a non-Markdown app's syntax. Not to mention that doing so violates the requirement of keeping this feature as simple as possible (the plan is to provide a very simple task tracker built off task checklist and Emanote concepts like folgezettel/ hashtags, and not a full-blown task tracker based on an established app, like todo.txt).

That said, #83 should enable anyone to write a more sophisticated task tracker as a plugin.

EDIT: Maybe I should drop support for tags and due-date (see edit in OP) in initial version.

[j-steinbach]

I think we should step away from the whole syntax debate: This is all plain-text. That means we can put whatever we want into our string. As long as it has a - [ ] in front of it, it gets displayed. And then we provide a way to render it more beautifully.

[srid]

Makes sense to consider this as a special case of indexed view (#50).

(Renamed title to "Task Index" accordingly)

So, we are not implementing a task tracker per se. Just a simple index into the tasks across notes (tasks indexed by note route) ... just as the current tag index provides an index into tags (notes indexed by tag). For v1, this ought to be sufficient.

[j-steinbach]

This feature should remain simple, without bothering with unnecessary features of traditional task trackers.

What exactly do you deem unnecessary?

So far I have some experience with org-mode and todo.txt. These are essential features I've come across:

• Toggle Do/Done
• Task priority
• Due date
• Tags/Mentions

[srid]

For Task Index (not task tracker) none of those are necessary. Version 1 is here #182

I can imagine adding some of those (due date, tags, etc.) later on however ... based on actual need as I begin to use this thing for real zettelkasten.

[srid]

Just to be clear, the priority right now is to have an index of some sorts that aggregates tasks that are otherwise spread across a large Zettelkasten. That's phase 1, which the PR implements.

Phase 2 may consider supporting these properties, depending on actual need that unfolds while using Phase 1's result.

[srid]

Phase 1, demo: https://note.ema.srid.ca/-/tasks

[j-steinbach]

inactive = this?

It might work, but feels very much like a band-aid fix. Why exactly are my check-boxes disabled? Can I turn them active again? Is there something I did wrong?

I agree with the added visuals -- why not just use the good old checkmark? Just add them before each done element, and we are good to go. Or we might just write TODO and DONE in front of the items. Or colorize them.

---

Discussion 181

• Convince Srid
• ✓ Propose a task-index design without check-boxes

---

We might also find a symbol for the todo, or --even better-- just let the user define whatever symbols they want.

E: I am not fully happy about the order • ✓, but it is a good first step.

[vcavallo]

Yep, that's what I meant by disabled/inactive. it's a standard HTML attribute, which feels like a good, standards-supported foundation.

Why exactly are my check-boxes disabled? Can I turn them active again? Is there something I did wrong?

Hopefully it will be clear to an Emanote user pretty quickly that this is a generated view and not interactive (especially if nothing else on the site is). But this may be unearthing a hidden issue with todo lists: people want to check them off interactively, not just use them as read-only reports.

I'm ambivalent about Checkmarks on completed items - I'm fine with either - but I feel strongly about differentiating todo lists from regular bullet lists. the ambiguity in the bullet points alone makes me sad. The markdown has different syntax, so the output should have different appearance (not to mention the semantic difference).

[srid]

Keep in mind that the task index displays only unchecked tasks -- so for your "Shopping" example it displays Garlic and Onions only.

I went with (disabled) checkboxes because that's what many task manager apps use. See example. But I'm not married to the design.

I believe that there should be a way to toggle those check-boxes, as without it this feature doesn't feel complete.

Just as when wanting to edit a note being previewed in the browser you'd switch to the text editor and make the change (which gets reflected instantly in the browser) ... in order to modify / check a task, you'd do the same -- ie., switch to the text editor and make the change (which updates the task-index instantly).

The whole idea of having Emanote (rather than your text editor) do the editing of your notebook upon user interaction should be a different proposal / idea. It is mostly out of scope - but definitely worth considering in the future, along with #84.

---

I'd like to take #181 in the direction of supporting some sort of 'filtering' so that an otherwise overwhelming list of tasks can be managed contextually. See #181 (comment)

[j-steinbach]

Does your task manager (the example) let you toggle/edit those notes? Or does it only display them?

I believe my issue still stands: Check-boxes are actionable, they imply that a user can do something.

---

If the task index only displays the unchecked items , then I think a regular good old list (no checkboxs, no nothing) should be good enough:

Todays tasks:

• Convince Srid
• Grab dinner
• Bring out the trash

---

The task index should optionally also allow seeing the finished tasks. I like to get a sense of pride and accomplishment when I see what I already did. This for example makes sense when I have separate todo lists for my projects.

[srid]

There are two ideas here, and it is worth distinguishing between them:

1. Task manager
2. Task index

You are thinking of (1) and I'm thinking of (2). A task index is simply a read-only view helping you answer the question "Okay, what tasks can I select and do now?". Part of answering that question, I think, is to be able to 'narrrow' down the tasks based on various contextual factors. That's it -- everything else is to be generally considered outside the scope. This is why I termed it an "index" (implying read-only view), rather than "manager" (implying edit capability).

Right now I don't want to deal with (1) at all, for reasons mentioned above, viz.:

The whole idea of having Emanote (rather than your text editor) do the editing of your notebook upon user interaction should be a different proposal / idea. It is mostly out of scope - but definitely worth considering in the future, along with #84.

However, (1) should be made possible to be implemented outside of Emanote. To that end, perhaps tasks should be added to the JSON export https://note.ema.srid.ca/-/export.json

---

The task index originally displayed finished tasks too, but I decided to remove them because I have too many of them on my notebook (especially from 'older' project notes that are archived) and they were cluttering the list. I suppose we can provide a way to display them in conjunction with #183 ... or support a way to suppress tasks from 'archived' notes (which entails coming up with a way to indicate which notes are 'archived').

---

Yes, we can remove the checkboxes entirely. Design is very low priority right now for this experimental feature, compared to other things this idea needs fleshed out.

[srid]

I just realized that contextual tags (as in @phone-call, etc.) are actually unnecessary if we have Zettelkasten notions already.

There are two interesting ways to 'filter' tasks, as an alternative to using tags:

1. Filter and display all tasks transitively located under a folgezettel parent note
   • For example, by filtering for all foglezettel descendants of "My Projects/" - you see only tasks defined under that folder. Non-folder folgezettels should work too; so a task/project can below under more than one parent.
2. Filter and display all tasks with a link to some note.
   • Not all kinds of filters can be done with (1). Say you want to view all tasks that involves making a phone call. You simply query for tasks that links to a certain note. If the task is - [ ] Call bank about tax forms [[Context/PhoneCall]], then we would query with something like linksTo:Context/PhoneCall.

Perhaps the same can be said for due-date using #183 ?

[srid]

Like 'timeline backlinks', we could introduce 'task backlinks' panel. It would display all task checklist items linking to the current note. More generally, we are partitioning the backlinks based on their type, and displaying them separately for viewing.

[j-steinbach]

Here is another fast mock-up. I hope the description in the picture explains it.

Some more inputs:

• Colour each task source file differently
• How do we deal with nested tasks? Just nest them?
• If we actually go down the checkbox route, we should not use the HTML checkboxs but instead the unicode ballot box ☐ ☒ ☑, as they are less "interactive". (Note: Not sure how the the system/browser unicode font interaction actually works. Unicode displays based on the local font.)

---

E: The github/markdown checkboxes are also very nice.

• todo
• done

[kukimik]

The Unicode ballot boxes are simple to implement. In particular I imagine one does not have to explain their meaning to screen readers (and other assistive technologies), as they're probably just read as "ballot box" and "ballot box with check", which should be clear for the user. But I'm not sure, this is just a guess.

E: The github/markdown checkboxes are also very nice.

I don't understand. As far as I can see the github checkboxes are just plain HTML checkboxes (<input type="checkbox">)

[j-steinbach]

I don't understand. As far as I can see the github checkboxes are just plain HTML checkboxes ()

You are right, they became interactive :/ I meant their non-interactive visuals in the Preview window, which show a nice grey colour.

[kukimik]

In the github preview window they are still HTML checkboxes, they just have the disabled attribute. In particular the way they're displayed depends on the browser/system you are using. That's the approach that was proposed in #190 and that is currently used in the task list template.

[j-steinbach]

My bad, you are right. This is a matter of styling then -- do you see how the check-boxes in the live preview are really big? The github checkboxes only reach the height of a t, whereas the current Emanote ones are bigger than a T. For comparison: tTt.

I just checked the sizes in the dev-tool: Github is 14x14, Emanote is 20x20. I guess all it takes is decreasing the size to w-4 h-4 to make me happy. No need to spend too much time on this.