in productivity

Quick entry into Asana using LaunchBar, Script Menu, etc

Here’s a quick way to get tasks into Asana using LaunchBar (my preferred method) or Script Menu. (Requires a little nerdery.)


  1. Install the Asana Command-Line Client and set it up
  2. Download this AppleScript wrapper and update the config properties
  3. Put the script somewhere you can access it (e.g. via LaunchBar, Alfred, Script Menu, etc)

Usage (LaunchBar):

  1. Invoke LaunchBar, type your shortcut to the script and tap space
    • Enter your task title

Usage (generic):

  1. Invoke the script
    • Enter your task title in the dialog box


  • New tasks will appear as private tasks at the top of your “My Tasks” list.
  • If you’re an Alfred user, Mannie Schumpert’s QuickTask workflow is probably better.

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:


  • ⌘ 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. Switch to OmniFocus, select the task, ⌘-' into the Notes field, and add it while you’re thinking of it. 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.

  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.


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

TL;DR: This script opens the project of the selected task(s) in a new window.
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 and realize you need to view or change its 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 script Focus in New Window, which does the following:

  1. Given a selected task (or tasks),
  2. Opens a new Project-based window, 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 on Github.

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.

What if we could give calories away, not just lose them?

Three years ago, I wrote the following vision statement for my career as a product manager:

To develop technologies that help people make sense of the world around them and engage in more meaningful, healthy, productive, connected lives.

I joined AwayFind in 2012 to help people be more productive, stay better connected to the people that are important to them, and spend more time doing things that are meaningful to them. I’m proud of the product we built and the ways AwayFind helps people achieve these goals.

This month, I’m taking a different tack to focus on health, connectedness, and meaning: I’m joining forces with Calorie Cloud and UNICEF to build a fitness platform that connects the wellbeing of people like you and me to those struggling just to stay alive.

What if we could give calories away, not just lose them?

It’s a bold question for a bolder idea – fitting, as Mark Moore and Troy Hickerson developed the Calorie Cloud vision at The Unreasonable Institute last summer. (Watch Mark explain Calorie Cloud.)

I doubt I’ll post many updates as we’ll be heads-down on the project for the foreseeable future, but I couldn’t be more thrilled to partner with them on this journey.

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 “”, 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:


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.

Minimize distractions with Keyboard Maestro

After Ryan Irelan posted about using Keyboard Maestro to block apps, I decided I could adapt the tip for a less cold-turkey approach to computer-enforced self control.

So I’ve been using Ryan’s tip with one minor change: it uses the world’s simplest AppleScript to introduce a time limit for how long distracting apps can remain open (or active). Just create a Keyboard Maestro macro like the following (or download this example):

Hide Twitter

As you can see, this macro waits one minute (60 seconds) before hiding my Twitter client. Works like a charm: hiding the app doesn’t force me to leave Twitter; but reactivating the app becomes a conscious act of will that forces me to answer That Question.

(I use a similar macro to quit my RSS reader after a more generous 10 minutes.)

Amplifying human ability

Steve Jobs (1980):

Scientific American I think it was did a study in the early 70’s on the efficiency of locomotion. What they did was for all different species of things on the planet – birds and cats dogs and fish and man and goats and stuff – they measured how much energy does it take for a goat to get from here to there… and they ranked them and published the list, and the condor won, it took the least amount of energy to get from here to there, and man didn’t do so well, came out with a rather unimpressive showing about a third of the way down the list.

But fortunately, someone at Scientific American was insightful enough to test man with a bicycle, and man with a bicycle won—twice as good as the condor, all the way off the list. And what it showed was that man is a toolmaker, has the ability to make a tool to amplify the amount of inherent ability that he has.

And that’s exactly what we’re doing here. We’re not making bicycles to be ridden between Palo Alto and San Francisco… but in general we’re making tools that amplify the human ability.

(video on

This is why I love technology.

AppleScript and Growl: a survey of possible solutions to the “Growl not installed” problem

10/31/11: Updated to work with Growl 1.3 (MAS version).

TL;DR: If you want to use Growl notifications in your AppleScripts without causing problems for people who don’t have it installed, feel free to use this code.

For anyone who writes AppleScripts that use Growl notifications, the problem is familiar: if a user doesn’t have Growl installed, the script throws a fit when they try to run it. Specifically, at load time, the AppleScript interpreter looks for all the applications listed in the script to retrieve their scripting dictionaries, and if it can’t find any of the listed applications, it asks the user where to find it:

Where is GrowlHelperApp.png

This can be frustrating for users who don’t have Growl installed: either they don’t know what Growl is (and therefore have no idea what to do in this situation), or they actively prefer not to have Growl on their system. In neither case do you want to force users to install Growl.

Although others have written about this issue—including a couple solutions that work—I still spent a lot of time and frustration trying to work through the issue and thought it might be helpful to post a survey of different methods that don’t work—and why.

Method one (bad): Growl, straight-up

Pros: Elegant, simple, as Growl intended. Cons: Script chokes on Growl-free systems.

The simplest solution is to call Growl using the intended syntax, ignoring users who don’t have Growl installed. The code is straightforward and easy to understand:

property growlAppName : "Dan’s Scripts"
property allNotifications : {"General", "Error"}
property enabledNotifications : {"General", "Error"}
property iconApplication : ""

tell application "GrowlHelperApp"
        register as application growlAppName all notifications allNotifications default notifications enabledNotifications icon of application iconApplication
        notify with name "General" title "Note title" application name growlAppName description "Note description"
end tell

But if the point of your script is to simplify a task, it’s not very helpful to publish something that won’t run for those who don’t happen to share your idea of a pleasant notification experience.

And you probably don’t want to maintain two versions of the same script.

Interlude: Detecting Growl

To support both Growl-enabled and Growl-free systems, you need to detect whether Growl is installed before deciding what to do. For that, best practice1 seems to be to first check whether Growl is running:

tell application "System Events" to set GrowlRunning to (count of (every process where creator type is "GRRR")) > 0

Then, if Growl isn’t running, check if it’s installed, try to launch it if so2, and run the alternative notification if not:

if not GrowlRunning then –if Growl isn’t running…
        set GrowlPath to "" –check to see if Growl is installed…
                tell application "Finder" to tell (application file id "GRRR") to set strGrowlPath to POSIX path of (its container as alias) & name
        end try
        if GrowlPath is not "" then –…try to launch if so…
                do shell script "open " & strGrowlPath & " > /dev/null 2>&1 &"
                delay 0.5
                set GrowlRunning to my IsGrowlRunning()
        end if
end if
if GrowlRunning then
        NotifyWithGrowl(alertName, alertTitle, alertText, useSticky)
end if

Method two (bad): string encapsulation

Pros: Used to work; doesn’t choke on Growl-free systems. Cons: No longer works with Growl.

For a long while I used a very simple method that encapsulated Growl statements in a string variable, which prevents the interpreter from choking on systems that don’t have Growl installed:

tell application "Finder" to tell (application file id "GRRR") to set growlHelperAppName to name

tell application growlHelperAppName to run script "register as application \"" & growlAppName & "\" all notifications {\"General\", \"Error\"}  default notifications {\"General\", \"Error\"} icon of application \"\""
tell application growlHelperAppName to run script "notify with name \"General\" title \"" & alertTitle & "\" application name \"" & growlAppName & "\" description \"" & alertText & "\" icon of application \"\""

Unfortunately this method no longer works when Growl is installed:

Growl Error.png

So that’s out.

Method three (bad): growlnotify

Pros: Elegant, doesn’t choke on Growl-free systems. Cons: Doesn’t work unless growlnotify is installed.

Another method is to use the growlnotify utility that ships with Growl Extras, and call it via a shell script:

do shell script "/usr/local/bin/growlnotify OmniFocus  -n ‘General’ -m ‘My message’"

But growlnotify isn’t part of the base Growl installation, so for Growl users who don’t have the tool installed, it won’t be obvious why the notification doesn’t work.

Method four (good): osaScript

Pros: Works for Growl users, doesn’t choke on Growl-free systems, uses standard AppleScript syntax. Cons: Verbose and unsightly.

The first method I found that actually works in 2011, described by elasticthreads, is to encapsulate the entire Growl-facing script as its own (perfectly quoted) string, and run that using the shell tool osascript:

set osascript to "property growlAppName : \"Dan’s Scripts\"
property allNotifications : {\"General\", \"Error\"}
property enabledNotifications : {\"General\", \"Error\"}
property iconApplication : \"\"

tell application \"GrowlHelperApp\"
        register as application growlAppName all notifications allNotifications default notifications enabledNotifications icon of application iconApplication
        notify with name \"General\" title \"Note title\" application name growlAppName description \"Note description\"
end tell

set shellScript to "osascript -e " & quoted form of osascript & " &> /dev/null &"

ignoring application responses
        do shell script shellScript
end ignoring

I didn’t want to hardcode the notification parameters, and with all the quoted stringiness, extracting them required writing a method for converting an AppleScript dictionary to string form. Here’s my complete version of this method:

property growlAppName : "Dan’s Scripts"
property allNotifications : {"General", "Error"}
property enabledNotifications : {"General", "Error"}
property iconApplication : ""

set thisNotificationName to "General"
set thisNotificationTitle to "Note title"
set thisNotificationDescription to "Note description"
tell application "Finder" to tell (application file id "GRRR") to set growlHelperAppName to name

on dictToString(dict)
        set dictString to "{"
        repeat with i in dict
                if (length of dictString > 1) then set dictString to dictString & ", "
                set dictString to dictString & "\"" & i & "\""
        end repeat
        set dictString to dictString & "}"
        return dictString
end dictToString

on notifyWithGrowl()
        set osascript to "property growlAppName : \"" & growlAppName & "\"
property allNotifications : "
& dictToString(allNotifications) & "
property enabledNotifications : "
& dictToString(enabledNotifications) & "
property iconApplication : \""
& iconApplication & "\"

tell application \""
& growlHelperAppName & "\"
        register as application growlAppName all notifications allNotifications default notifications enabledNotifications icon of application iconApplication
        notify with name \""
& thisNotificationName & "\" title \"" & thisNotificationTitle & "\" application name growlAppName description \"" & thisNotificationDescription & "\"
end tell

        set shellScript to "osascript -e " & quoted form of osascript & " &> /dev/null &"
        ignoring application responses
                do shell script shellScript
        end ignoring
end notifyWithGrowl

This method doesn’t choke on Growl-free systems, uses standard (though obscured) AppleScript syntax, and works for the Growly. It’s quite a lot of code, though, and isn’t very pretty.

Method five (good): AppleScript literal syntax

Finally—hats off to Dave Nanian for this method—AppleScript has an obscure literal syntax that can be used instead of standard syntax. In brief, literal syntax is a way of describing statements in guillemet-enclosed events and classes. This is what the above code looks like in literal syntax…

property growlAppName : "Dan’s Scripts"
property allNotifications : {"General", "Error"}
property enabledNotifications : {"General", "Error"}
property iconApplication : ""

tell application "Finder" to tell (application file id "GRRR") to set growlHelperAppName to name

on notifyWithGrowl()
        tell my application growlHelperAppName
                «event register» given «class appl»:growlAppName, «class anot»:allNotifications, «class dnot»:enabledNotifications, «class iapp»:iconApplication
                «event notifygr» given «class name»:"General", «class titl»:"Notes processed", «class appl»:growlAppName, «class desc»:"strReport"
        end tell
end notifyWithGrowl

N.B. While literal syntax doesn’t require encapsulating the app name in a string variable, you should do this for two reasons. First, if the application name is used, the interpreter will try to find GrowlHelperApp, thus choking on Growl-free systems. Also, Script Editor will try to convert the code to normal syntax, which you don’t want if you’ve gone to the trouble of crafting this version. Note also Nanian’s warning to use tell my application, not tell application.

This method won’t choke Growl-free systems as long as you don’t run the code; make sure you include a check to see if Growl is installed before running this code.

All tedious things must come to an end

Giving Apple the benefit of the doubt, I’ll make two assumptions:

  1. It’s generally important to have access to the scripting dictionaries of applications referenced in your script.

  2. Growl is an edge case in that it’s simultaneously useful to include in a script but superfluous to the script’s execution.

But it’s a problem that people spend so much time coming up with workarounds for such a seemingly straightforward problem. If you have any other methods for dealing with the “Growl not installed” scenario, I’d love to hear them.

You can download a paste-and-go version of the code (which includes both functioning methods) here, or click here to open it in your script editor of choice3.


  1. Much of this is gleaned from discussion and examples posted at the OmniGroup and DEVONtechnologies forums. I think the current version is most similar to one from Rob Trew.

  2. In theory, you should be able to proceed without explicitly seeing if Growl is running/trying to launch if not, because calling tell application "x" will cause it to launch if it’s not already running. However, there was a time that Growl would crash frequently (I once measured one Growl crash every 7-8 activations), so checking for a successful launch was one way to ensure consistent behavior. Growl has gotten very stable, so this shouldn’t be a problem, but it’s cheap and fast to run the check so I keep it in.

  3. Hat tip to Don Southard’s handy AppleScript-encoding service, which created the “open” link.