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.
I received a recent email that asks:
… I’m having a hard time keeping up with all the reading material I’d like to read/watch and I keep adding links into a huge “Someday Maybe/Reading” project in a “Reading” context that grows and grows, because I’m adding way more than I am able to “pull out”.
So I guess my question would be how do you approach keeping up with all the reading material? Is there something I can do to help me make time for reading more? …”
Great question. I’m still developing how to handle this one myself. Unfortunately, I will say upfront that I do not believe I can fully answer your question. My book list, too, grows faster than it shrinks. There are those who can read quickly, but I am not one of those individuals. Even if I were, there are more books than anyone can read in a lifetime.
Further, “making time” is a matter of renegotiating agreements, something Merlin Mann has called the ultimate ninja skill. Such a question taps into the much larger, “How can we spend our lives doing more of what we want?”
Beyond the careful examination and adjustment of our habits and commitments, I would argue that the growing list is a “fortunate problem” of our time. There was once an era when having more books than can be read was an amazing luxury.
As with much of our work, we must regularly acknowledge loss, including of those things we would have liked to read. Still, we can create methods for arranging our book lists to reflect and support our decisions of what to read, what to place on hold, and what to delete.
For this post, I will focus on book reading and not articles or videos. I tend to separate these from each other, though similar methods can be considered for either.
Method 1: External Book List
Some users recommend keeping a reading list outside of OmniFocus entirely. For example, Tim Stringer of Learn OmniFocus suggests using a Goodreads account. Aleh Cherp of Academic Worklows on a Mac suggests using a text file. Either are excellent ideas and maintain a solid simplicity.
In these cases, you could select one book from the external list and create a repeating task in OmniFocus to read it. This way, you still have your ongoing book reading task centralized in OmniFocus, while keeping the larger list removed from sight.
For example, if you use flags to signify your daily work, your task list might appear as:
Method 2: Internal Book List
I tend to keep my reading list in OmniFocus. The result is similar to above, though with some adjustments. My preferences include the following:
- As above, I aim for a single book task that I am working on until I am done. The other book tasks might be useful in their own projects or folders, but I’d like to be focusing on one in my day-to-day if possible.
- As you are doing, I would prefer to include my booklist in OmniFocus. While it does add to the database, I find that including books within their related projects outweighs any detriments. In terms of task presence, as long as I have a method of hiding the information when it is not relevant, yet keep it quickly accessible when it is, I have organized the information effectively.
- Further, I wish to make the book I am reading on option, not a requirement.
I do have a @Book Reading context:
Within this context are numerous tasks, each representing a book I wish to read:
The @Book Reading context itself is rarely visited. I could create a task to read from it regularly, but then I would be confronted with a large list every time, making it difficult to use as an action-oriented list. Still, a task to regularly review the task could be useful when considering what to keep or remove. For example, a monthly repeating maintenance task could work:
The list is one that is not regularly fully cleared. A context such as this does take on more of the storage tank role. There are definitely contexts and perspectives that I try to clear daily or nearly so. My flagged list is an example of tasks I fully intend to complete daily.
The important thing is that I acknowledge how I use any particular list. We build our systems upon trust. But trust is not a boolean concept. It is not on or off. We can ask of any component of our environments “How do I trust this?” to reveal a more nuanced picture.
To better enable focused action, I select one book from these @Book Reading tasks to read regularly until done. I then convert it into a “Considered task”, by:
- Setting it to repeat daily,
- Changing its context to @Considerations, and
- Altering its wording to include the word “Consider …”
To see how this works in action, let us begin with the daily view. Notice the daily repeating task to visit considered tasks:
Selecting the link presents the considered tasks:
The number of considered tasks is kept low (preferably below five to seven). Therefore, it is generally not overwhelming when seen.
When ready to move on to the next book, I delete the task and change another @Book Reading task to a Considered task. The cycle continues.
In this way, one book remains in progress. It does not need to be read daily as it is a “considered” task. Other books remain hidden from view. However, those other books remain accessible to their related projects or perspectives.
Much of my use of OmniFocus is about guiding habit. It is useful to create repeating tasks that I check off regularly. The process develops a habit.
However, after some time, these sorts of tasks can easily bog down the system. Many repeating routine tasks obscure those that we would prefer to otherwise call our attention. For instance, an important task to contact your employer could be lost in an array of deferred tasks, as seen here in the Forecast perspective:
(Note, the deferred tasks option is turned on):
One means of solving this issue is to have a Retired Habit context:
Whenever you feel that you have internalized some habit:
- Assign it to @Retired Habit.
- Create a repeating task to visit @Retired Habit.
I have the task as part of my weekly review template. In this way, I can decide if it is truly a task that I can delete or something I would like to return to my active system. In this way, repeating tasks can act as training wheels that I can take on and off as needed.
There are lots of little additions that I’m liking about OmniFocus 2. As an example, from the change log:
Here’s an example of how this can be helpful: I have a number of projects titled “Overview” which are essentially administration type projects that oversee the rest of the projects sitting in a folder. Something like:
One of the issues has been that in Review mode, I would have to guess which “Overview” folder I was reviewing. It wasn’t a big deal, but it was something. In any case, this feature totally helps out. To turn it on,
- Go to review mode (Command-6) by default.
- Select the view icon (or type Shift-Command-v)
- Select the option “Show Folders in the Outline”:
Now we can have a better view of the hierarchy: