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:
‘
