OmniFocus snooze script

Last Updated: 2010-06-15

Here’s an AppleScript that “snoozes” selected OmniFocus items by setting their start date to a future* value. These items will then be unavailable (and out of sight in views showing “available” items) until the snoozed start date.


  1. Run the script with one or more items selected in OmniFocus

  2. Choose how long you would like to snooze the items (in # of days)

The script will then set the start date of selected items to the current date + the number of days selected in step 2. For example, snoozing with the default value of 1 day will set the tasks to begin at 12:00 AM tomorrow.

Finally, if you have Growl installed, the script will display a Growl confirmation.

I highly recommend initiating the script from a third-party launcher such as FastScripts or Quicksilver. This will prevent delays within the OmniFocus application due to Growl bugs.)

Download it here.

* This doesn’t have to be a future value. Choosing 0 as the snooze value will set the start date to midnight today; choosing -1 will set the start date to midnight yesterday.

NetNewsWire script: Subscribe to full-text feed of current subscription

Update Dec 2010: it looks like FullTextRSS is down. I’ll leave this up, but be forewarned: it probably won’t work. FiveFilters and WizardRSS provide similar services, so you may want to look there.

Here’s a script that attempts to subscribe to a full-text feed of the current subscription in NetNewsWire. It does this using EchoDittoLabs’ excellent FullTextRSS service.

To use, select a headline or subscription title in NetNewsWire and run the script. The full-text feed will appear in your top-level items.

Thanks to for the URL encoding routine. The script worked without the routine but it seemed safer to include it.

[Updated 2/22 with change suggested by Pascal.]

[code lang=”AppleScript”] (* Fulltextrss.scpt v 0.1b

Attempts to subscribe to the current subscription via EchoDittoLabs’ FullTextRSS service (

Contains no error checking; use at your own risk

Dan Byler *)

property fulltextpre : “”

tell application “NetNewsWire” if exists selectedHeadline then set this_headline to selectedHeadline set stdfeed to RSS URL of subscription of selectedHeadline else if exists selectedSubscription then set stdfeed to RSS URL of selectedSubscription end if try set theTextEnc to my urlencode(stdfeed) set fulltextfeed to fulltextpre & theTextEnc set theresult to subscribe to fulltextfeed on error display dialog “Oops—something went wrong.” return end try end tell

— urlencode routine taken from on urlencode(stdfeed) set theTextEnc to “” repeat with eachChar in characters of stdfeed set useChar to eachChar set eachCharNum to ASCII number of eachChar if eachCharNum = 32 then set useChar to “+” else if (eachCharNum ≠ 42) and (eachCharNum ≠ 95) and (eachCharNum < 45 or eachCharNum > 46) and (eachCharNum < 48 or eachCharNum > 57) and (eachCharNum < 65 or eachCharNum > 90) and (eachCharNum < 97 or eachCharNum > 122) then set firstDig to round (eachCharNum / 16) rounding down set secondDig to eachCharNum mod 16 if firstDig > 9 then set aNum to firstDig + 55 set firstDig to ASCII character aNum end if if secondDig > 9 then set aNum to secondDig + 55 set secondDig to ASCII character aNum end if set numHex to (“%” & (firstDig as string) & (secondDig as string)) as string set useChar to numHex end if set theTextEnc to theTextEnc & useChar as string end repeat return theTextEnc end urlencode [/code]

Download a copy here.

Give before you ask: lessons from the Twine DM snafu

No matter what service you provide, even the most well-intentioned invitation can be seen as a demand for time, effort, and attention. Given the lack of established protocols for interacting online, I submit a single cardinal rule-of-thumb for interacting with people, online or off:

Give before you ask.

The following story is not ultimately about Twine, or about Twitter. It’s an illustration of what happens when asking comes first in an increasingly crowded information ecosystem. It’s about relationships, requests, and demands—the subtle dance that characterizes the interplay between “social” and “information”. (Full disclosure: I have a close relative who works at Twine, and I’m an avid Twitter user, so I want both companies to succeed.)

Here’s the 30-second recap:

  1. Twine implemented a feature to let its users connect with their Twitter followers. It did so by inviting them via direct message (DM); however, to Twine users it wasn’t 100% clear that DMs would be the mechanism.

  2. People started receiving impersonal-sounding DMs from loose Twitter acquaintances inviting them to join Twine. This seemed like a spammy auto-DM campaign and incensed some high-profile Twitterers. When Chris Brogan blogged about it, the Twitter ecosystem lit up with largely negative reactions.

  3. Nova Spivack, Twine’s CEO, responded. He engaged Chris Brogan immediately. He was personal, listened, and took responsibility. In my view, his response was spot-on. (Here’s their conversation—click “Show conversation” to see the whole thing.) Net result: the DM feature was disabled. (1)

Although Twine’s fumble was largely technical (the DMs were supposed to point to a more personal landing page, for instance), its approach to Twitter was misguided as well. Why? Because users felt pitched, not informed. Put another way, Twine didn’t give before it asked.

What would it look like for Twine to “give” first? One simple way would be to make it easier for Twine users to share what they’re doing on Twitter. Add a “Tweet” button so users can share what they’re reading with their followers, all without leaving Twine. It doesn’t sound like much, but it would reverse the dynamic between Twine and Twitter. Here’s what would happen:

  • On the surface, Twine tweets would change from friend requests to “actual information”
  • Visitors’ first impressions of Twine would improve. Instead of seeing a sign-up page on arrival, users would see Twine as in its real capacity, a source of information and discussion
  • Some users would stay at Twine longer if they could tweet without breaking their flow
  • Traffic would feel organic, not forced
  • Traffic may grow more slowly, but pageviews would be more valuable
  • Bottom line: users (of both Twine and Twitter) would feel respected, because the tweets they send or receive would be interesting, rather than asking them for a favor

All this from giving before asking.

In addition—but as a secondary option—it would be nice to see which of your Twitter connections are on Twine and connect with them there. (Twitter contacts who are already on Twine are more likely to reciprocate; those who are not members are likely to see the invitation as spam. The former should be encouraged, and the latter treated with care.)

I think Nova nails it with this comment: “Integrating external services with Twitter is a more subtle art than expected.” He’s right: the details are subtle. But the gross concept stands: give before you ask.

(1) Spivack blogged about the experience—you can read his thoughts here. And the Twine team officially responded here.

OmniFocus defer script updated

Updated 6/15/10: minor edit to improve efficiency

The updated Defer script for OmniFocus is ready. Changes include:

  • Bug fixes to make the script more reliable, particularly when deferring multiple items.

    • For most of these I’m indebted to Curt Clifton, who made the most critical bug fixes on the OmniFocus forum. (If you use OmniFocus, his scripts and tools are invaluable; be sure visit his site.)
  • The default action now defers both start and due dates.

  • Notifications code has been rewritten to make the script friendly for machines without Growl installed.

    • While testing, I discovered that GrowlHelperApp crashes on nearly 10% of notification calls. To work around this, the script now checks to see if GrowlHelperApp is running; if not, the script launches it. If Growl is not installed or can’t launch, the script displays a generic notification of the defer results.

If you experience delays with the script, it’s almost certainly an issue with Growl, not OmniFocus. This is much less of an issue if you launch the script via a third-party utility like FastScripts, because any Growl-related delays will be absorbed by the script launcher, not OmniFocus. If you primarily invoke the Defer script from your OmniFocus toolbar, you can always disable alerts to speed things up. To do this, simply open the script in Script Editor and change property showAlert to false.

Download it here.