Lightweight To-Do list formatting

I recently ran across the todo.txt format project, which allows use to use plain text action item lists to create and manage your projects. I love the simplicity of the idea but there were a number of items that prevented me from wholeheartedly adopting it.

First, I think it’s really ugly. It’s hard to scan, especially when there are lots of things to do. I know that the idea is this is an intermediate representation but that representation is visually heavy.

Second, it’s missing notes. Freehand notes are an important part of task management, whether noting down the phone number for the car place when you need to get your snow tires put on.

Third, it’s order dependent, with a left-to-right layout that really doesn’t work for me.

Fourth, I don’t think the (A)-(Z) priority format is particularly readable.

Even though I do like the +Project and @Context annotation, I feel like todo.txt is a few steps  short of a much more flexible and readable intermediate form.

So I started brainstorming on how I might tweak this concept to be more flexible. For one thing, I think the example strains to make the project and context “fluent” in a way that they don’t have to be. Yes, you may want to query to see “what are all the projects I am working on?” and “what contexts do I work in?” so I can support differentiating them but I don’t think they need to be integrated into the to-do text.

What follows is a very lightly-considered redesign that I have pulled entirely out of thin air. I did not spend much time on this and I’m sure there are better ways to redesign this to support text-based lightly annotated human-readable to-do lists. I’m throwing this out there as a starting point in case any of you want to carry this discussion further. It’s a design exercise for me, one that allowed me to take some of these thoughts out of my head and throw them into a blog post. So take this for what it is.

Imagine tagging that looks like more like this, depending on whether you’re annotating project or context values. Part of me pushes back at the notion of the two types of tagging but I appreciate that you might want to query “show me all my projects” and “show me all my contexts”, and I recognize the value in that:

@(tag) or +(tag)
@(key: value) or +(key: value)
@(priority) or +(priority)

A priority can be as simple as a number, which I think people would process better than “A”, “B”, “C”, etc. As a pattern of (0-9)+, it would also allow easy differentiation in parsing between a tag (arbitrary text) and a priority. Priorities would range from 0 (highest priority) to any arbitrary number (lower priority). I doubt people would use more than two or three priority levels (low, medium, high), if they use them at all.

Because dates are critical for todo deadlines, you could pull them out with NLP or be more explicit: @date(due: 2019-05-02). The single keyword would allow you to parse a date with more flexible keys and disallow an explosion of keywords you might encounter by trying to pre-design specific scenarios like @due(2019-05-02), @checkin(next Tuesday), etc.

Relative dates would need a creation date, which if you’re using an editor rather than the raw format could be injected as @date(created: 2019-05-02). The second you do that, though, you’re moving away from the idea of human-readable, simple annotation, tool-consumable.

In my head, a better system would not be single-line. Adding blank spaces between items significantly increases vertical space so python-inspired indentation can avoid that:

Set up appointment for snow tires
  Call and talk to Judy 505-555-1212 # comments are always great
  She says to contact them at least one thursday before the weekend you want # Not thrilled by the manual line breaks here
  to bring the car in.
  @(home) +(winterizing) +(2) @(before: 2019-12-01)
Put snow scraper in car
  @(car) +(winterizing) @(done) # yay me!
Get flu shots for Bob and Francis
  Already got them for Fred and Mary
  @(family) +(health) +(season) +(Costco) +(1) +(shopping) # It's a shopping run, even if it's not strictly buying something

This is rough, obviously, but I think it’s a bit more readable than blockiness of the current format and a bit more flexible:

If working with an editor tool, I’d prefer if done items were automatically moved down to the bottom or maybe removed entirely or added to a different “done.txt” list.

Also, once you have the power of full tagging and categorization, a well built tool should allow you to pull on each of those to view related items in more structured ways. The format is simple but the way you present tagged information doesn’t have to be.

Anyway, those are my thoughts. I see a project with good bones that misses out on a bunch of human factors. What kind of changes would you make to turn this into a more usable and universal approach? Or would you just say “plain text is not really appropriate here” and use OmniFocus or Things instead? I’m curious as to what you think.

Update: Readers mention:

6 Comments

  • If you haven’t looked at Org mode before you might find it solves all of the issues mentioned above. Downside is that Emacs is the best place to use it (only a downside of course if you don’t like the thought of Emacs), however most other editors include plugins which support some of the features.

  • I like the indentation method you outlined. As an avid OmniFocus user I do find myself venturing back into plain text lists often. Making it flexible and accessible is always an issue.

  • How about the TaskPaper format? Plain text, simple and has freeform notes. Some clever tagging, too.

  • Indentation is in a way a form of outlining: You put the title of the task in a heading and hide secondary details like notes and tags in the hierarchy. The file system is also an outline, a pretty good one in fact, because it automatically keeps metadata like creation dates.

    Imagine this system: your tasks are files. One file per task. The main title of the task is the filename, all surplus information goes into the file. In a terminal context listing your tasks could be as simple as a ls ~/todo or an alias. In fact advanced usage like filtering could be build with simple shell pipelines.

    I’m more of a GUI person, so I could imagine using Finder for that. Here is a screenshot of your example in a particular Finder window configuration, less window chrome, list view, preview enabled. I put the priority in the filename, to automatically order prioritised tasks first. Also there are Finder’s builtin tags, red here standing for “winterizing”. Of course that wouldn’t scale for freeform tags.

    Modern text editors and note taking apps have a builtin file list. Here I’m using iA Writer, using the same files. iA Writer has a hashtag function, so I reintroduced your tags and put context tags in the same namespace.

    But without specialised tooling tags and contexts are a little bit cumbersome. The file system only gives you folders for organisation. That is a lot, but it is only one dimension. I personally don’t see that as failure. I’m not a good tagger, either I overtag very specific and don’t remember them or don’t use tags at all.

  • Re Tim — this reminds me of this article about using Notational Velocity and text files as a TODO tool… worth reading, when thinking about text-based todo task systems.

  • Check out doing by Brett Terpstra: https://brettterpstra.com/projects/doing/

    It’s a commandline tool to manage tasks using the taskpaper format. i’ve been tracking hours with it since round about 10 years. taskpaper supports multiline notes and indentation, but i think “doing” does not.

Join the Discussion

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>