[eatmytag]

I have been using Omnifocus since the early beta days with a few lapses into Things, THL and Toodledo. I have always returned to Omnifocus though as it in my opinion is the most complete, ubiquitous, and speediest solution (if you are using a Mac and iPhone).

Here is a repost of my usage guidelines that I am using at the moment. I am posting them here as I myself would have liked to read something like this in the beginning of my Omnifocus days. Original post here: http://fnurl.se/usage-guidelines-using-omnifocus. You might find the original post easier to read as there is more formatting.

<markdown>

# Usage Guidelines: Using Omnifocus #

[Omnifocus](http://www.omnigroup.com/products/omnifocus/) is a great tool, but
not as intuitive as e.g. [Things](http://culturedcode.com/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
certain actions.

Folders are used hierarchically. Below is an excerpt of my
Project side bar. Leaves in the tree are projects.

* Home
	* Home (Single tasks)
* Me
	* Me (Single tasks)
	* Webb
* Work
	* University
		* Teaching
		* Company

## 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
* phone
* anywhere
* work
	* mac
	* steve
	* lisa
	* university
	* company office
* home
	* mac
* shopping
	* Tech Store
	* Food Mart
* online
	* facebook
	* email

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.

## GTD specifics ##

* *waiting for* is a context with a due date for when to check up on what I am
  waiting for

* *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

## Single tasks ##

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.

## Using Perspectives ##

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.

## List keeping ##

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](http://smokingapples.com/iphone/pocket-docket/) 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
* Wishlists
* ... I think you get the idea

## Scheduling tasks ##

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.

</markdown>