OmniFocus is very much an app about doing. It’s not designed with graphical reporting in mind. Here’s a neat app, though, put together by Thomas Schoffelen, that shows a list of open tasks, and completed tasks from the last 7 days, last 3 months, and completed per weekday.
We can have any number of types of task lists, be they a perspective, a context, or a project. Some lists stick around: the daily list, phone calls to make, things to file, agenda items, and more. They fill up, we clear them, and they fill up again.
Two questions we can ask when approaching any list are:
- Do I intend to complete this list?
- If so, how often?
These questions are useful because completable lists affect us differently. When we can arrange a list to be completed regularly, we effectively create a reliable channel of work. Whatever we throw in there, so long as it isn’t large enough to clog the system, has a good chance of being done. As soon as one task starts to stick around though, other tasks tend to stall, too, and soon we’re wading through cobwebs.
We can consider a Principle of Completable Lists:
Lists that are sensed as readily completable within an easily envisioned time frame are more enticing, readily done, and resistant to procrastination.
These lists tend to be short, easily envisioned, with tasks that are either made of habit or are themselves easily envisioned. For example, I use the Dashboard as a completable daily list. I hope to finish it by the end of the work day, though it is not always possible. When it is not, I consider what about it needs adjusting, be it that the tasks are not clear enough, or perhaps that I have taken on too much and need to delay or drop some things.
If we wish to make a list completable, then we need to pay extra attention to its tasks. Consider for each task:
- Is it appropriate for this list?
- Is it clear and specific enough? I.e. Is it broken down to the point of confidence?
- Would it be useful to convert it to to repeating task? I.e. Is it better broken down in time, perhaps performed over several sessions of work?
- Is there something that needs to happen before this task?
- Is a next action actually scheduling a time for the task itself?
- Is it well written?
- Is it too large for this list? (E.g. would it benefit being converted to a Land & Sea project.)
- Is it an actual action?
Notice that these questions are just as appropriate for use during review sessions. And of course for the entire list:
- Are there too many tasks?
- Can I imagine actually doing all of these tasks in the time frame I intend?
Jesse Hollington recently wrote a great post called Getting more Focused with OmniFocus. He’s totally got the Grouping Tasks by Session down, complete with a really nice hotkey/script.
The script takes a link in a task and executes it. So you can have a link to a perspective, application, URL, etc and go straight there with a key command. He uses Fastscripts to set the hotkey. I don’t own that software, so I linked it up using Keyboard Maestro. Here’s my setup:
How we word our tasks can make a significant difference in how we approach them. For example, several rules of thumb may be:
- Start with a verb
- Maintain both simplicity and clarity when possible
- Act as though you are delegating the task to someone else. (In fact, you are delegating to your future self.)
In the last post, Grouping Tasks by Session, I showed my Dashboard Perspective:
On Twitter, Brandon Pittman asked me what’s the difference between “Read book” and “Read: book”. I said, “not much,” but in hindsight, I realized that there is some rhyme/reason to the nomenclature. The syntax can also be useful to highlight my intentions in several ways.
A Structure of Task Words
The structure is a single verb followed by a colon, for example “Process: X”. I originally picked up this task-writing style from Tim Stringer at Learn OmniFocus. He tends to use it for working with perspectives.
There are several words I now tend to use to start tasks, each with their own cautions. I do not use this convention all the time. They do tend to show up more in the Dashboard perspective, or areas I visit with regularity. The following is a list of how I sometimes write my tasks and my intentions behind them:
- “Develop:” or “Continue:” are useful words to continue a project where I do not know how long it will last. Most any creative work can fit in this mold. The task often is repeating with a link to materials of the work, a context, or a perspective dedicated for that project.
Example: “Develop: Music piece”
The task repeats. Every session that I feel I have done enough ends by marking the task complete. The task then appears again at the repeat frequency. When the work itself is complete, I delete the task.
- “Consider:” is useful for considering if I want to do something. I have a dedicated context for considered tasks, but I can also have considered tasks sprinkled elsewhere.
Example: “Consider: Continue arranging photos” (unflagged, repeating, in @File & Flow : Home context.)
Once the work is considered, whether actually done or not, it can be marked as complete. See also the post on the considered task for an in-depth look at its use and cautions.
- “Process:” Indicates a series of tasks that are generally memorized and should be completed in one session if possible.
Example: “Process: (some track of music)” means to do all the editing, mixing, and transfer to a Dropbox folder marked for review.
Example: “Process: Communications” means to review the Waiting for list, clear my phone, emails, and text messages, and make all needed calls, emails, and text messages.
Caution: This term is most useful for fully practiced work, where you know the methods and materials involved. If it needs to be left incomplete before ending its session, consider writing an additional task to mark where you left off.
- “Review:” is useful to look over a list. I can do none, some, or all of it.
Example:“Review: Office Filing” – flagged and repeats on weekdays. I have in mind the intention of clearing the list every few days or so, but I do not have to do all of it when I see it. I make that decision during each work day. If I feel I have done enough filing tasks for the day, I mark the “Review:” task complete. I anticipate seeing it again on the next workday.
Caution: One needs to acknowledge the intention of the list. If a list never completes, is too large to review in a single setting, or is completed too slowly, is this acceptable? If not, adjust the list so that trust for its use is maintained.
- “Clear:” is similar to “Review”, “Clear” tends to refer to a list. However, instead of doing none, some, or all of it, my intention is to do all of it.
Example: “Clear: Home Filing” which is flagged and repeats on Fridays. I aim to complete the task by the end of the weekend.
Caution: Lists that we intend to complete in a span of time tend to take the greatest skill and finesse. For example, a daily list (like the Dashboard) is intended to be completed within the day. All of the skills of drafting tasks, setting repeats, acknowledging what can and cannot be done, etc. come into play.
- “Practice:” is specific to the practice perspective. These are pieces of music that I am either composing or learning. I set them at some Defer Another interval, practice it on the day it shows up, and mark it complete. Periodically, I’ll change the repeat interval depending on how well I feel I know the piece.
Example: “Practice: Toccata in D Minor” unflagged, defer another set to q3 days, @Piano.
- “Arrange:” means that I plan to re-arrange where the task sits in a project. This is useful if I send a task to a project from the Inbox, but I know that I want to change its position because of sequential groups of tasks.
Caution: These tasks are best addressed as soon as possible. Otherwise, the system decays quickly.
It should be stressed that, with the exception of “Arrange:”, these terms are mostly useful for habitual tasks, usually representative of larger projects, areas of focus, or commonly visited lists. They are also in an evolving state of use.
To Finish or Not to Finish (a List)
There is certainly overlap between some terms. For example, “Read: …” is just another version of “Continue: …” or “Develop: …”.
Other terms, though, such as “Clear” and “Review”, highlight an important distinction of how we can approach our lists. Some lists are meant to be completed in a period of time. Some lists are not. But it is the acknowledgement of the intention that is most important. The lists themselves do not care.
For example, I have @Laptop as a context. There are presently 84 tasks in it. It would be ridiculous for me to actually work from the context directly. I know that. But, I still find it to be a very useful context when paired with focus and/or workflow perspectives. If I focus on a particular project, I can see a small number of @Laptop tasks. Suddenly, clearing the tasks makes sense.
As another example, I maintain the @File & Flow tasks as a list that I wish to complete within the span of days. Any task that sits there longer is either poorly placed, not broken down enough, or I need to consider whether it is a larger task than I originally considered or admitted to myself.
We can easily be overwhelmed by looking at even a realistic list of things we’d like to do today. This is particularly the case if there are many small tasks. A good list is one we can easily review in a short period of time so that we can make a clear decision about what to do next. For this to be the case, we generally need a short list.
However, this pushes against two other productivity tenets:
- Tasks should be clear and specific.
- One should offload as much as possible into a trusted system.
Offloading everything as clear and specific tasks can quickly generate a huge list. While we can use flags to highlight certain tasks, we would easily create the same problem by flagging too many.
Sessions vs. Tasks
Instead, consider organizing your work by sessions. I use a custom perspective, called the Dashboard, to organize my intended daily sessions of work. Here is an example:
See the Dashboard settings in the footnote below.
The Dashboard Perspective functions as a central hub. Any major projects or flows of habit appear here. My intention is to complete the list before the end of the workday. In this example, you can see that there are 5 general areas of work I intend to visit. Each “task” carries a link to the batched tasks I care to do for today.:
Some tasks are batched by project. Some are batched by context. All are batched by whatever criteria I find most useful. The brevity of the Dashboard Perspective allows me to make a quick decision as to what I would like to do next without having to wade through the smaller tasks.
In its years, my use of the Dashboard Perspective has evolved. When it began, it was more about doing all the little things that I needed to so I could get to the major things. Later, I added my major projects so they would all sit together. When the perspective was at its busiest, I had dozens of specific, clearly worded tasks in this one list. I would rarely visit any others. While the system “worked”, I also remember feeling harried. sometimes looking at the list over and over again. Thankfully, as my “system” began to be more about my own habits, individual tasks could be removed.
The Dashboard now represents sessions of work more so than individual tasks. There are the occasional exceptions, but specific tasks tend to be more associated with projects and contexts and remain unflagged. I go to them as a part of the flow from flagged tasks as shown above.
Simplicity is certainly a hallmark of maturity. But, it is not often a first step. It is a character of mastery gradually woven into our endeavors and lives.
Test build of OmniFocus 2.3
After I’ve done my morning routines, I might open OmniFocus and see the above. It is a simple list. Should I care to delve into details, I can select a link resting in the note field of a desired task, and work from there. I could also just work from what I believe, in the moment, to be a good next action. The lists only support me in making my choices. At this point, the only costs in maintaining this simplicity are the weekly review and the occasional adjustment.
I often hear that OmniFocus is not simple. Compared to other programs, that can be the case. But, OmniFocus is complex to the degree that it can support a complex life. It can also be a means of assessing where life is more complex than need be and aim towards simplicity.
What you can do with a musical instrument is also not necessarily simple. But an artist can get there with time and effort. More importantly, it is not a simplicity of the instrument we aim for, but that of expression. The instrument is only a channel supporting that process. Its complexity is about supporting depth and nuance.
As we attempt any new craft or project, we build supports, not fully knowing their upkeep or maintenance. How could we know? We haven’t done it before. While we could take the word of those who claim experience before us, and it is certainly important to hear their thoughts, we must also experience it ourselves. Without grounding in the self, we are without play, and therefore without mastery.
As we continue to review and iterate our systems, we learn and re-learn, finding new ways of creating. The costs of supports become more readily known.
We can then ask, with greater assurance, of any support:
“Is this worth its cost for what I find meaningful?”
Each pass polishes our systems into a smoother simplicity.