OmniFocus

There are 20 posts filed in OmniFocus (this is page 1 of 2).

Scripts updated for OmniFocus 3

OmniFocus 3 gave users a long-awaited feature: the ability to assign a task to multiple contexts. But the transition also came with a nomenclature change: the old contexts now became tags, a change that was reflected both in the UI and the underlying AppleScript dictionary.

Unfortunately, there wasn’t a graceful transition for scripts: OmniFocus 3 doesn’t know what a context is, so older scripts that referred to them needed to be updated to reflect the new world order.

Of course I’ve updated all the scripts that I use with OmniFocus on a daily basis – many of these updates were made when OmniFocus 3 was in beta early last year.

But after receiving a steady trickle of emails from people wondering how to fix some of my OmniFocus AppleScripts (the answer always being some variant of “search for context and replace it with tag), I came to the embarrassing realization that I never actually pushed the updates back to Github.

Sorry, everyone!

I took some time this weekend to update all my scripts on Github. Here’s what’s changed:

  • I took the opportunity to scrape out lots of unnecessary code related to Growl, since 100% of respondents to my Twitter survey (n=3) no longer use Growl. So the scripts are all leaner and cleaner.
  • A couple other minor changes, like cleaning up the text of notifications. For example, the Total Time script used to waste the script headline (“title”) telling you “Script complete”: Now the key information gets top billing:
  • And yes, the scripts are all updated for OmniFocus 3. (Still shaking my head that it took this long for me to notice.)

“Was that a train?”

On a road trip this week, my wife thought she saw something in passing.

We didn’t think there were any trains in the region. I looked up from my iPad, but whatever it was passed out of sight before I could spot it.

I could have easily bookmarked the spot in Rego or Google Maps, but I wanted to actually be reminded to search for the item on our return journey.

So I did the sensible thing and quickly

  1. Created a tag in OmniFocus and assigned it the location “Here”
  2. Set the tag to alert me of any available tasks on arrival
  3. Created a task to “Look for the train”

Now, on the return journey, OmniFocus would alert when we approached the location in question.

Everything was in place for the perfect train-looking-landmark heist… until we took a different route home. D’oh!

Time to check Google Street View, I thought.

But alas! When I viewed the tag in OmniFocus, its location coordinates had been replaced with the generic road name “Highway 6”.1

Back at my Mac, I was able to dredge up the coordinates using BBEdit to search the OmniFocus database.2

A quick Google Maps search brought me to the spot. I did find a rather disturbing billboard in the vicinity, but no evidence of a train (or train imposter). So the end of the story is that, while it was a fun process, we still have no idea what the landmark actually is.

Anyway.

Props to BBEdit for best-in-class search capability, which didn’t blink at the hundreds of compressed XML files in the OmniFocus database.

And props to the driver, who found a faster way home.

Discuss.

  1. Normally a friendly location name would be more helpful than a latitude and longitude, but in this case it left me with little to go on. ↩

  2. Open the OmniFocus database in BBEdit, then use Multi-File search. Be sure to enable the “Search compressed files” option, which will traverse the OmniFocus database’s compressed XML documents. This quickly landed me at <location name="National Highway 6&#10;Cambodia" latitude="12.3435" longitude="105.101" notificationFlags="1"/>↩

Log ad hoc items into OmniFocus

OmniFocus provides my daily roadmap for where I’m going. But maps can be unreliable: sometimes an emergency requires a detour … and sometimes you just pause for an unscheduled cup of coffee or phone call with a friend.

To quickly log those unanticipated events in OmniFocus – without imposing additional overhead on the system – I invoke these simple scripts from LaunchBar:

  • Log completed item to OmniFocus (CC) – saves a completed task to my work-misc project
  • Log completed item to OmniFocus (Misc) – saves a completed task to my personal-misc project
  • Log distraction to OmniFocus – saves a completed task to my distractions project

When something comes up that I’d like to log:

log-distraction

  • ⌘ space to invoke LaunchBar
  • logcc, logmisc, or dist to choose the type of entry
  • space to start typing
  • [type what it was]
  • Enter to save

Now a completed task appears in the appropriate location, and my Completed Tasks perspective gives a more accurate representation of the day.

To use it, download the script and customize the project name and context to fit your needs. Should work with Alfred as well.

Log completed item to OmniFocus

A solution to Premature Quick Entry

You’ve done it a million times: You added a task in Quick Entry. Then, seconds later, you came across a link that would have been useful to include. Or an idea that should be part of that task.

At this point, you have two options:

  1. Quickentry a new task with more details. You’ll have to merge the two later, but hey.
  2. Edit the task:
    • Switch to OmniFocus
    • Locate the task (which might require opening a new window and some digging)
    • Select the task
    • ⌘-' into the Notes field
    • Add details while they’re fresh
       
      (By now, you’ve totally broken your flow – and eliminated any benefit of using Quick Entry in the first place – but that’s it’s a small price for being organized.)
       
      or…
       
  3. Fire up LaunchBar, hit a-n-space to access the Append Note to Newest Task script, and type your note. Tap Enter and rejoice: your note is added to that task you just created, and you haven’t lost your flow.

If you want to add links or other notes instead – or you (gasp!) don’t use LaunchBar or Alfred – just execute the script without custom input and it will append your clipboard contents instead.

Enjoy:

Append Note to Newest Task

p.s. Related but far less useful: Append Note to Selected Task(s)

p.p.s. Updated 2015-05-17 to work around a bug that overwrites a file attachment when editing a task note.

OmniFocus: Jump to a task’s project view without losing your place

2017–04–17 update: Now includes an option to focus in new tab. Thanks Marek and Kraig for the request.

TL;DR: This script opens the project of the selected task(s) in a new window (or tab).
Get it here.

It’s been a while since I last posted… so what better way to break the silence than with some new OmniFocus scripts?

I don’t think it’s controversial to say that context-based perspectives are the secret sauce of OmniFocus. Without context views, OmniFocus would be a simple outliner with quick entry and a few filters. But context perspectives let you view the exact cross-section of tasks you need to be effective.

That is, until you view a task in a context-based perspective and realize you need to see the whole project.

It should be simple to view a project’s details without losing your place in the current context view. And it was simple in OmniFocus 1: while in a context view, double-clicking a task would open its project in a new window.

OmniFocus 2 lost this feature, unfortunately. The two best options it provides are:

  • Quick Open (⌘O): allows you to type the name of a project and open it in a new window (if that option is selected). But this requires typing and the cognitive overhead of thinking about the name of the task’s project.
  • Show in Projects (⌘⌥R): brings you to the project view of the selected task. But since OmniFocus has no navigation history, there isn’t an easy way to go “back” to the original context view. It all begins to feel like a road trip:

Actual path

It’s worth mentioning that Kourosh Dini presents some very useful and related workflows in his excellent Creating Flow with OmniFocus, but in my view none of these methods has the simplicity of a quick – and mindless – round-trip to the task’s project view.

So, without further ado, I present the scripts Focus in New Window and Focus in New Tab, which do the following:

  1. Given a selected task (or tasks),
  2. Opens a new Project-based window or tab, focusing on the desired project(s)

That’s it. It’s an extremely simple concept that makes this round-trip quick and painless:

Desired path

For ease of daily use, I’ve named the script “Focus” and given it a descriptive “opens-in-new-window” icon. It now lives in my toolbar next to the real Focus action:

Focus in Toolbar

I’ve been using this countless times per day and thought it high time to share it with the world.

Get it here:

Focus in New Window/Tab

p.s. This script includes a custom icon to look better on your OmniFocus toolbar, so I’m linking to a zip file that includes this and other scripts; let me know if this is an inconvenient way to download it.

p.p.s. I’ve also updated some of the older scripts, notably Snooze and Shift (formerly called Defer). If you use them – especially if you also use LaunchBar or Alfred – you may want to take a look.

p.p.p.s. Because OmniFocus doesn’t currently (as of 2017–04–17) have native AppleScript support for managing tabs, Focus in New Tab has a few dependencies. Please check the inline notes if you run into any hiccups.

Bless you, OmniFocus (or, How I Learned to Stop Fidgeting and Quickly Rename Multiple Versions of the same Application)

The upcoming OmniFocus 2 refresh provides more than ample reason for excitement. Forecast view? Updated review mode? The giddy feeling of firing up this morning’s sneaky-peek build to find yet another shiny new release ready for your eager paws? Check, check, check.

But unlike last time around1, OmniFocus 2 isn’t ready to take over my life yet, so for the moment I’m still usually working in OmniFocus 1. Every couple days I fire up OmniFocus 2 to kick the tires a little more and sometimes provide some (hopefully useful) feedback to the good folks at the Omni Group. (And yes, they’re listening.)

Unfortunately, switching fluidly between the two versions becomes problematic when you bring third party tools into the mix. Case in point: AppleScripts that tell application "OmniFocus" expect that they’re working with an application called OmniFocus. So if OmniFocus 1 is called “OmniFocus 1” and OmniFocus 2 is called “OmniFocus”, your scripts will always invoke OmniFocus 2 until you rename the applications – even if you’re currently working in OmniFocus 1. That’s hardly ideal if you’re switching version with any regularity. And it was keeping me from using OmniFocus 2.

The solution? A script, of course! Here’s a script that automates the process of switching between primary versions of OmniFocus. This is what it does:

  1. Checks your applications folder for items matching the name OmniFocus* and asks you which version you’d like to bless2 [See the end for a version that skips this]
  2. Renames the blessed version to “OmniFocus.app”, and the other versions to “OmniFocus [version].app”
  3. Launches the blessed version

Here it is in action:

Bless OmniFocus demo

For those who enjoy reading detailed notes:

  • If you choose the version that’s already blessed, that version will be activated and no renaming will occur.
  • If OmniFocus (or many OmniFoci) is running when a the script is ready to rename, the script will handle quitting and relaunching for you.
  • If you happen to have multiple copies that would have the same target name, only one will be renamed (i.e., files shouldn’t be randomly overwritten).
  • While I built this workflow for the purpose of OmniFocus testing, it could work just as easily with any other application: just change the application name at the beginning of the script. You can also change the applications folder.
  • If the script encounters an application without a version number in its metadata, it will be renamed according to its creation date.
  • If you use the tell application "System Events" to choose from list line, the dialog will appear at the front (rather than possibly being buried behind windows). However, in my experience, System Events can hang, so I endure the less convenient version in order to keep things running quickly.
  • …and of course, your user account needs to have the proper permissions to rename the files.

I’ve been using this for about a month without issue, but of course use at your own risk and please let me know if you have any issues.

Grab the script here:

p.s…

Michael Schechter wondered about a version that blesses a specific version, rather than prompting for user input. This could be useful if you want to…

  • Set up a Hazel rule or timed Keyboard Maestro action to automatically switch versions
  • Keep two versions of the script for each version of the app to trigger by a launcher

So if you’d prefer a “headless” version, try this one.

  1. OmniFocus 1 replaced Ethan Schoonover’s exceptionally clever but ultimately hackish OmniOutliner scripts, Kinkless GTD, so it wasn’t long before OmniFocus quickly surpassed kGTD’s utility. But OmniFocus 1 is now a very mature product, so it may be some time before OmniFocus 2 can fill its shoes.↩
  2. Blimey, why the blessing? The name comes from a system command to choose which operating system to run on startup. The OS that’s set to run is “blessed”, and you select it by running the bless command.↩

All OmniFocus scripts updated for a “Start-based” workflow

Like many OmniFocus users, I used to plan my days using Due dates. Planning to pick up supplies a the hardware store today? Set Due Date==Today. Need to call a friend back to catch up? Set Due Date==Today.

This behavior makes sense, on one level level: just sort everything by Due date and you can see when things are planned. But every time a date isn’t met, it has to be pushed back, creating the need for most of my date-related scripts.

Worse, indiscriminate use of Due dates dilutes their value and undermines any task-planning system.

Need to pay a credit card bill today? It’s lost in the mess of other things that are artificially “due” today, and that red Due badge is no longer a respected indication that something needs to happen today.1

But there’s a better way.2 Just use Start Dates to plan what you think you should do, and reserve Due Dates for things that actually have to get done. (To keep this straight, I use a “Due” perspective to show what’s actually due, and a “Do” perspective to show what I’m planning to do.3)

The benefits of this approach are enormous. Things that actually need to happen don’t get lost in the shuffle, and (using time estimates) you can work with more realistic expectations of what can/should happen in a a day.

But switching to this workflow also required re-tooling my scripts, many of which focused on Due dates.

So, as of today, all my OmniFocus scripts default to a Start-based workflow. Here are some of the major changes:

  • Today, Tomorrow, and This Weekend all set the Start date of selected tasks by default.

  • In addition to pushing back due dates of tasks, Defer now has the option to act on un-timed tasks by pushing their start date back by the given number of days. (This option is on by default.)

  • All scripts now work when launched from the OmniFocus toolbar.

  • Scripts no longer fail when an OmniFocus grouping header is selected.

  • All scripts reorganized for performance and clarity.

You can continue these scripts with a Due-based workflow, of course: this is a matter of changing a single setting in each script.4 But if you’re successful with a Due-based workflow, you have much more discipline than me.

Download the lot of them here. (And as always, let me know if you have any problems with them.)

 

 

  1. Lest anyone complain of the cost of OmniFocus: I’m sure I’ve paid more money to my credit card company in day-of-due-date payment penalties than I have to the OmniGroup. ↩

  2. Thanks to David Sparks and Benjamin Brooks for the insights that led to this realization. I mentioned this in a little more detail here. ↩

  3. Here are the settings for my Do perspective:

    Do Perspective.jpg
    … and here are the settings for my “Due” perspective:

    Due Perspective.jpg
    Both live in my toolbar for easy access.↩

  4. For example, in the Defer script, there is a line: “property snoozeUnscheduledItems : true. Simply open the script in AppleScript Editor and change ”true“ to ”false" to switch this setting. If you have any problems, feel free to email me. ↩

Plan your day better with OmniFocus time estimates

Confession: I usually fail to accomplish what I plan for a day. When the morning begins, big plans are in place… but at the end of the day, a pile of undone tasks lingers in my OmniFocus “Do” perspective.1 More often than not, they just get snoozed for the next day’s action list.

And the process repeats.

It’s demoralizing to watch the Pile of Do grow, and I often feel out of control when looking at what seems like a reasonable list of things to accomplish in a day’s time. Clearly, good intentions need to be tempered by reasonable expectations.

Enter time estimates. Over the years I’ve been using OmniFocus, I’ve never really used its ability to assign a time estimate to projects and tasks. It seemed like a lot of effort for very little benefit: all OmniFocus really does with time estimates is sort/filter.2

But time is a critical dimension of doing: without time, there is no action. It should follow that time estimates are just as important.

So here is my new morning routine:

  1. Collect all actions I want to do today by assigning them a Start Date of today.

  2. In “Do” perspective, assign time estimates to each item.

  3. Check the total time of the day’s planned items; remove lowest priority items until my list is doable. (Use the Total time and Snooze scripts to make this step easier.)

This routine has several immediate benefits:

  1. Assigning estimates forces you to clarify next actions. In cases where it was difficult to assign a time estimate, I realized I hadn’t clarified the next action well enough. Poorly defined next action → inaction.

  2. Using estimates helps clarify what is feasible for the day. This morning, my first pass included almost 14 hours’ worth of work. Without time estimates, I wouldn’t have known how feasible this plan was.

  3. You can start right now. No need to assign estimates to everything in your OmniFocus database; just estimate what you’re looking at for today.

Having seen how simple this process is, I’m shocked I didn’t do this years ago.

 

 

  1. I keep two perspectives side-by-side in my toolbar: “Due” and “Do”. Due shows tasks sorted by due date; these are items that really truly have to get done by the given date. Do shows tasks sorted by start date; these are the items that I plan to do on a given day. This gives me the benefit of some planning flexibility without the problems that come from recklessly using due dates. For more on this method, see this David Sparks post, which inspired me to use it. ↩

  2. While OmniFocus doesn’t do much with estimates out of the box, there are some scripts that can do things like starting timers to keep you on task. See this discussion thread for more info. ↩

OmniFocus script: Get total time of selected items

2017–04–23 Update: Fixes an issue that could cause the script to fail if certain top-level perspective separators are selected.

2011–07–06 Update: If you downloaded the script before 18 July 2011, there was a bug that could cause an additional hour to be added to the time. That issue is fixed in the current version.

Total Time.png

Here’s a script to sum the total time of selected items in OmniFocus. Just select some items, fire it off and see how overcommitted you are.

Download it here.