Deconstructing my OmniFocus Dependency

January 29, 2014 by Gabe | [mmd] |

This post is about productivity masturbation. It's an inevitable fact of life, but probably not something that I should have an audience for. You've been properly warned.

I've broken this discussion into separate posts because apparently people don't like long articles anymore. The subsequent article will be all about the tools for working with plain text tasks. An electronic system is only as good as the software used to interact with the data. Luckily, plain text files are somewhat of an industry standard. The range of support for the TaskPaper format is broad but some tools are much better than others.

There will be no satisfying conclusion for anyone other than me. A task management system is not as generic as the self-help app market would like us to believe.

The Great Deconstruction

I've been using OmniFocus for about 7 years. Before that I was using the Kinkless GTD system. Along the way I experimented with Things, TaskPaper, RTM and Toodledo but OmniFocus was my touchstone. It felt comfortable and I learned how to make it work very well.

However, this year has brought some disappointments and huge amounts of resistance to my OmniFocus affair. The OmniFocus 2 for Mac beta left me bewildered. OmniFocus 2 for iPhone is so uncomfortable to use that I simply stopped using it on my iPhone, choosing to enter tasks through Siri and letting OmniFocus add those to my database instead.

So, I started exploring again.

The experiments led me to an undeniable conclusion: I've conformed so perfectly to OmniFocus that nothing will replace it. Rather than continuing my search for an OF replacement, I decided to deconstruct my entire system and examine my methods and the intended results. There's no better way to do that than to go back to where it all started: text files.1

Plain Text Task Management

Stripping away all of the tricks in OmniFocus has forced me to reconsider how I manage my task list. Rather than view my system as OmniFocus centric, I'm examining it as outcome-centric. Yes, yes. This seems obvious but it's entirely too easy to get stuck behind my tools and lose sight of their role in the grand plan. I also did not want it to be a feature-set competition between applications.

Without perspectives or alarms, I'm more considered in how much goes into my task list. Instead, far more goes into a "maybe" note file.2

But there are many artifacts that are still quite functional in a plain text list. Start dates and due dates are still valuable but much more limited without alarms. Contexts are possible, but I've all but abandoned them (much more on this later).

I end up reviewing tasks far more in plain text. There's no easy way to defer a task, and keeping it around actually makes everything harder, so I try to remove individual items as quickly as possible. Plain text imposes a penalty on procrastination.

The plain text format I've chosen is TaskPaper, named after the Mac and iOS applications implemented by HogBay Software and Jesse Grosjean.

The TaskPaper Syntax

TaskPaper shares a lot of its concepts with tools such as Org-Mode. While Org is certainly more powerful and flexible, there are limited options for implementing it on a Mac and iOS.

In the TaskPaper format, lines are defined by indentation and signaling characters such as hyphens and colons. Tags are prevalent and loosely defined but there are few rules.

There are comforting similarities between the common bulleted list format in most text editors. If you're familiar with Markdown or even the bulleted and indented list format in Microsoft Word, then TaskPaper is not a big intellectual jump. There are only a few minor additions that transform it from a check list, to a functional project and task manager.

Projects

The project syntax is very simple but extremely flexible. A project is a line that ends with a colon (:).

Repair Trash Compactor Malfunction:

Projects can be nested:

Repair Trash Compactor Malfunction:
    - Submit form X1047 for a new compactor latch
    - Submit form Q371 for work order to replace compactor latch
    Remove Dianoga from Trash Compactor:
        - Submit form QX3379 for Dianoga disposal unit
        - Complete form QX3702 for the jettison of parasite from habitable station

Projects can also have tags. Many of the software tools that work with TaskPaper format files fold (collapse) projects to hide complexity. A project can also contain notes. There are very few differences between a task and project.

Tasks

Tasks are lines that begin with a hyphen and a space. Tasks are grouped into a project by indenting to the appropriate level. Tasks can be added without grouping under a project but I think that's messy. I prefer to have a project to hold them whenever reasonable, Inbox: or Misc: serve can this purpose well but are not required.

Inbox:
    - Submit requisition form X327 for new Wookie cuffs
Repair Trash Compactor Malfunction:
    - Submit form X1047 for a new compactor latch
    - Submit form Q371 for work order to replace compactor latch
    Remove Dianoga from Trash Compactor:
        - Submit form QX3379 for Dianoga disposal unit
        - Complete form QX3702 for the jettison of parasite from habitable station

Tasks can also have sub-tasks. There's no need to bother with project lines if you have a small list of subordinate tasks.

- Service droids
    - Oil change
    - Replace translation circuit
    DO NOT REMOVE SECURITY BOLT

Tags

Tags are where all of the power and flexibility originates in TaskPaper. Tags can be anything but there are a few that are used by default in most applications. Tags are placed at the end of the task or project line and begin with the @ character.

Inbox:
    - Submit requisition form X327 for new Wookie cuffs @done

Tags may have an attribute in parentheses after the term. Attributes can be just about any string value. For example, setting a date when a task was completed:

Inbox:
    - Submit requisition form X327 for new Wookie cuffs @done(2014-01-22)

There's no limit on a tag except that it should be a single word preceded by @. Most of the applications I'll discuss place special meaning on the @done and @today tags. Several applications will automatically apply a time stamp to the @done tag.

Projects may have tags too.

Rather than looking at tags as simple markers, I've placed special emphasis on their attributes. A tag is a relationship or state for a task. The attribute provides meaning to the tag. For example, @waiting(Jon) indicates that a task is in limbo but it also immediately identifies the cause of the bottleneck. More on this later.

Notes

A task or project may have a note, which is created by adding text below it without preceding with a hyphen or ending it with a colon. A note is any text that is not part of a project or task. I prefer to indent notes under a task or project. Tasks can also be bulleted lists which some applications, like TaskPaper for Mac, will treat as a check list.

Inbox:
    - Submit requisition form X327 for new Wookie cuffs @done(2014-01-22)
Repair Trash Compactor Malfunction:
    - Submit form X1047 for a new compactor latch
    - Submit form Q371 for work order to replace compactor latch
    Remove Dianoga from Trash Compactor:
        - Submit form QX3379 for Dianoga disposal unit
            Remember that there is a 35% loss rate of Troopers during any deployment
            * Wet gear required
            * Should require low skill status
        - Complete form QX3702 for the jettison of parasite from habitable station

Notes can be verbose in a TaskPaper document. Several applications allow for notes to be hidden or folded by default. I like to see the notes on my tasks, because it often provides some immediate feedback. I've also noticed that since I've moved to this text-centric format that I've consolidated more of the research and reference material into the task list.

The Personal Choices

There are a couple of specifics that I recommend you think about up front if you want to go this route. The indentation level and method must be consistent. I chose tabs for indentation, instead of spaces. It's easier to find a tab character when writing scripts. If you choose spaces, decide if it will be two or four spaces. Realize that not all applications support every indentation method or mixing of methods.

I've also chosen to add a blank line between projects. It helps provide a visual boundary between related items.

File Structure

Decide on your file structure. I'm using separate files for "areas of work": Personal, work, website, etc. I've also carved very large projects (think multi-year with hundreds of tasks) into separate files. I've prefixed each file name with tp, such as "tpHome.txt". This makes it much easier to find the files on my machine and to write scripts against them.

I've also concluded that it's best to keep my task files isolated in their own directory. It's a sub-directory of my notes folder which makes it easy to quickly switch when using a Dropbox-based text editor. The second post in this series will highlight workflows that make this obvious.

Inbox

You will want to decide if you need an Inbox project in each file or a separate Inbox file. I've chosen to use both. I have an explicit Inbox document for general miscellany or when I just don't want to take the time to think about where something goes.

I also prepend inbox tasks to the top of my "area of work" files. For example, I have a file for Home Tasks. New items just get prepended to the top. They are immediately apparent when I do a review and easily moved or transformed into a project.

Archiving

I'd also recommend choosing if you want to archive and if so, where you will archive completed or dropped tasks. Many tools will archive to the bottom of the current file. I like that method. The one downside is that if you rely on search, it will become more difficult over time. I plan to clean my archive footer periodically to a separate file. Think of this as the OmniFocus database cleanup.

Many applications will apply a time stamp to a task when it is completed. This makes the archive more useful for examining a project postmortem.3

Tagging is the Key

Yes, I'm beating this horse thoroughly.

Because of the nature of the tools for plain text, tagging items is significantly more useful than a simple bulleted list. I use the following tags regularly:

@start(2014-01-19) @due(2014-01-19) @today @waiting(Jon) @hold

Many applications and scripts will perform "clean-up" of @done tasks and projects, moving them to an archive. Some also provide separate functions for quickly applying the @done tag. This is the common method for marking anything as complete.

The @start tag is not a standard tag but I've found ways to generate views into my lists that only show tasks and projects that are currently available to start (start date before or equal to today's date).

I like the structure of the @waiting tag. It's easy to filter and the tag parameter describes the nature of the delay.

I've also found value in using status flags:

@draft
@started
@deferred

The @started and @deffered tags can include optional time stamps to indicate the date that the action was taken. In this way, the task becomes self-documenting.

I've also sporadically adopted "grouping" tags. Through the power of search, I can group tasks and projects in an almost arbitrary way. By applying an @group(1) tag to tasks I can view them all together, even if they don't coexist in the same project.

Just Say No to Contexts

I've found that the OmniFocus and GTD contexts don't work for me as well as they once did. I don't have many context tags anymore. Instead of a @grocery context, I have a grocery list. Instead of a @hardware context, I have a hardware store list. The reality for me is that there are very few tasks that are not simply a "computer" context and I have one of those with me at all times.

I began to rely on contexts in OmniFocus for bucketing projects and tasks together, and that's not what a context should be for, especially in OmniFocus, which only allows one context per task.

Tags are more flexible than the limited contexts available in OmniFocus. The original idea of GTD that resonated with me was that I just need to capture tasks and not spend a lot of time on managing the system. The narrow applicability of contexts in OmniFocus has forced me to spend too much time conforming to an application. I'm using this as an opportunity to build the system I need.

The only traditional context I've found value in with TaskPaper is the @call but it serves a different purpose in TaskPaper.

- Make appointment with Empire Psychologist @call(867-5309)

Previously I placed this meta data in an OmniFocus note field or occasionally in the task title. This method makes much more sense to me.

By deconstructing how and why I used contexts, I came to realize that there are very few "modes" that I work in. However, there are many "states". Some may like to apply the concepts of energy levels. Personally, I don't have that luxury very often. I have obligations, energy levels be damned.

Instead, there are many situations where a task becomes relevant to a condition, such as being in a specific meeting. I found myself preparing for a meeting by creating a new context and assigning various tasks to that new meeting context. With tags, this becomes trivial and ephemeral.

I may move through a task list in preparation for a meeting and simply add a @group(1) or even just @group1 tag a bunch of tasks that are up for discussion or delegation. The free-form tagging provides a lot of flexibility for grouping and reorganizing information without the fiddliness of creating limited contexts and reassigning tasks. Through the power of search, I can easily bring up all of the relevant items, grouped by the tag. Hopefully, by the end of the meeting, I've completed the items and the tag no longer exists in my active tasks.

Nesting is Best

One of the OmniFocus (and Kinkless GTD) features that felt very satisfying to me was the nesting of dependent projects and tasks. Nesting provides a natural structure and flow to a project. Seeing the dependencies laid out in a hierarchy allows me to evaluate the missing pieces and get a sense for the progress at a high level.

Plain text provides an easy framework for nesting projects and tasks. It's just text. The TaskPaper format allows nesting projects, tasks and notes and most compatible applications and scripts support it. The syntax works from the inner most elements outward and upward. In the example below, the project "Dinner Party Reservation" is dependent on completing the "Final Guest List" project.

Palpatine's Birthday Party: @start(2014-01-25) @due(2014-02-13)
    Dinner party reservation:
        - Lookup Regal Beagal's phone number
        - Tally guest count
        - Book party @due(2014-02-05)
        - Confirm dinner party @due(2014-02-10)
        Final Guest List: @today
            - Lookup Maul's phone number
            - Call Maul to get the list of work contacts @call(867-5309)
            - Call Mason to get his Palpatine's pub crawl buddies
                Mason is in the contact list
            - Vader to provide Palpatine's sister's number @waiting(Vader)

The nesting of tasks can also serve my occasional need for sequential rather than parallel tasks. A nested task must be completed before the parent task.

Conclusion and Continuation

Taking apart a system that has become second nature is difficult. Through this process, I was doing double entry into OmniFocus and text files. I would not recommend this undertaking during a very busy time. The beginning of 2014 was the perfect opportunity for me to learn a new system and spend many hours thinking about where things break and where they flow.

Perspectives in OmniFocus felt like magic when I first began using them. They hide so much of the complexity in a large list. A carefully crafted perspective provides a tunnel-like view through all of the mess. An immediate consequence of switching to plain text was a loss of that narrowing. But I also cleared more of my stale tasks more often. Perspectives in OmniFocus are great enablers but make it easy to ignore, postpone and delay a lot.

Reviews in OmniFocus for iPad are also a tremendous convenience and one that I took advantage of. But the review process is easily numbing and disregarded. I can't claim that reviewing a text file will make this better but it certainly removes the lazy option for now.

Seeing my notes as equal citizens in my task list has also helped place more emphasis on the associated complexity and difficulty. It's satisfying to stop in the middle of building out a project's action plan and write detailed notes. Text is nice.

As I'd already concluded with OmniFocus, time dependent tasks are best left to a separate alert system. Appointments go in a calendar, tasks go in the task manager and alarms go in an alarm service.


  1. My needs are likely unique to me. I get paid to manage large, multi-year, technical projects. I track hundreds of individual tasks over 18-25 month spans. I don't need a better todo list. I need execution plans. 

  2. And let's be honest. The Maybe file is just one step above the trash can. 

  3. Every project should die. The question afterward, is whether it was a good death. If your projects live on forever, then I do not envy you. 

blog comments powered by Disqus