Omnifocus is a great tool, but
not as intuitive as e.g. Things. This is
not necessarily a bad thing as this is what happens when you give the user the
freedom of tailoring an application to his or her needs.
As a note to myself and perhaps a guide to others trying to figure out how to
use Omnifocus, I have written this short list of usage guidelines.
Folders are Areas of Responsibilities
When I first started to use Omnifocus, I had a hard time keeping my Folders
from becoming Contexts and sometimes seeing the difference between Folders and
Contexts. The reason for this is because the labels used for Folders and
Contexts overlap. They do however not represent the same concepts. For
example, I might have a Folder called “University” and a context called
“University”. This does not mean that I am doing something wrong, it just
means that I have an Area of Responsibility connected to the University
organization and that there is a place called “University” where I can perform
Folders are used hierarchically. Below is an excerpt of my
Project side bar. Leaves in the tree are projects.
- Home (Single tasks)
- Me (Single tasks)
Contexts are Places where I can/should perform the action
Contexts are also used hierarchically. Contexts work a bit different than
folders, as folders are containers of projects, whereas contexts are
containers of contexts which means that both leaves and branches of the
contexts tree are equally valid contexts, not just the leaves in the project
tree. Below is an excerpt of my Context side bar.
- waiting for
- company office
- Tech Store
- Food Mart
One thing to note is that I have multiple “mac” contexts. The reason for this
is that I have one laptop that I carry around. Some tasks on my mac are work
related and some are home related and I want to be able to hide home related
tasks at work and vice versa.
waiting for is a context with a due date for when to check up on what I am
someday/maybe is set by not giving a task a start date i.e. if the task
has no start date, it is a someday/maybe task
One thing I liked about Things was the notion of having tasks not linked to a
project, but to an Area of Responsibility. Basically all “single tasks” I
have are such tasks – tasks I have to do because I have a certain Area of
Responsibility. Since folders cannot store tasks, and my folders are Areas
of Responsibilities I use a project with the same name as my Area of
Responsibility to store my single tasks.
I use perspectives a lot in Omnifocus, i.e. I use different Perspectives in
Omnifocus for different uses of Omnifocus. Here is a list of the Perspectives
I use, what they show, and what I use them for.
Due list: Hides the side bar, grouping and sorting by “Due date”, filter
by “Due Soon”, any duration, any flag state. I use this perspective when
working. If I have nothing more due today or over due, I move on to my Start
list (see below).
Start list: Grouping and sorting by “Start”, filter by “Remaining”, any
duration, any flag state. I use this perspective when I do not have any
tasks due or overdue today. The list shows me which tasks are remaining and
active (i.e. they have a start date today or before today). I usually
collaps the groups “Start any time” (which was equivalent to
“Someday/Maybe”), and “Start within the next week”.
Due list: Grouping by “Due”, sorting by “Start”, filter by “Remaining”,
any duration, any flag state. I use this list to get an overview of what is
coming up in the future and perhaps modify the start dates of tasks.
One thing Omnifocus is not good at is keeping track of general lists. I
discovered this when I read a review of Pocket Docket on Smoking
Apples a couple of weeks
back. Examples of lists that I do not like to have in Omnifocus (since they do not
necessarily have a context) are:
- Books to read in the future
- Movies to watch in the future
- Music to listen to in the future
- Food to try
- … I think you get the idea
One thing I feel is missing from Omnifocus is the notion of a Scheduled
date. This might be a result of my way of using Omnifocus, but I really liked
it in Things. A Scheduled Date is different from a “Start Date” because a
“Start Date” is when the task becomes available. A Scheduled Date is when I
plan on doing the task. I would find this useful as I would like to balance
the number of tasks I do each day when I am planning my work.
You could argue that I could just get rid of the “Start Date” usage and use
“Start Date” as a Scheduled Date. But I like having “Start Date” because it
gives me an idea of how long the task has been on my list. For example, if I
see a task that has a “Start Date” two months in the past and no due date, I
might just remove the “Start Date” which would make it a Someday/Maybe task.