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):
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.)
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 mydate-relatedscripts.
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:
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.)
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. ↩
Thanks to David Sparks and Benjamin Brooks for the insights that led to this realization. I mentioned this in a little more detail here. ↩
Here are the settings for my Do perspective:
… and here are the settings for my “Due” perspective:
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. ↩
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:
Collect all actions I want to do today by assigning them a Start Date of today.
In “Do” perspective, assign time estimates to each item.
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:
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.
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.
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.
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. ↩
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. ↩
Move the script to ~/Library/Scripts/Applications/Mail/
Set your hotkey in Fastscripts (Using a letter key is possible but not recommended. Try another character like `\/=- or an F-Key.)
The script will then move selected message(s) to a folder named “Archive”.
Existing shortcuts to file messages in Mail.app get you down to two or three keystrokes, but that just isn’t good enough for someone who has tasted the sweet, sweet bliss of single-keystroke archiving in Postbox or Gmail.
In my original reply to this superuser thread, I suggested using an AppleScript to move selected messages to an archive, and triggering the script using a single-key shortcut using Fastscripts. That script is simple and straightforward, but it has a major shortcoming: it leaves you hanging with no next message selected, so you have to manually select your next message. Not ideal.
My new script archives messages with a bit more smarts. Here’s what it does:
If a mailbox is in the foreground, the script moves selected messages to the folder named “Archive” and selects the next available message. Boom.
But you don’t want to accidentally archive messages whenever you hit your archive key. If the frontmost window isn’t a mailbox, the script will ignore the archiving functions and (optionally) type some text wherever you are. This is useful if you use a single key to trigger the script; without this function, you would never be able to type that key into a mail message because it’s intercepted by FastScripts before getting to the Compose window.
For interested scripters, here were some challenges:
Select next message: The solutions I found online select the next message by sequential Message ID, which usually means that it only works if your mailbox is sorted by Date Received. Using visible messages gets messages in the order in which they’re displayed. Watch out, though: if message threading is turned on, the top-level thread item is not selectable. See my workaround in the script.
Enter the keystroke that was captured: Merely telling System Events type the character that triggered the script will trigger the script again, resulting in a virtual infinite loop. I used a paste routine to work around this.
That’s it… happy archiving!
22 Mar 2011 update: fixed bug that caused selection to be lost when only the topmost message in a mailbox is selected.
11 July 2011: as described here, I’ve switched to a Start-based workflow and updated my scripts to reflect this change. By default, these scripts now set the start dates of selected items, not due dates—though you can still switch to “Due mode”. This post has been updated to reflect these changes.
I’ve added two more scripts to my OmniFocus repertoire: Today and Tomorrow.
As one might expect, Today sets the “Action Date” of selected item(s) to the current date, and Tomorrow sets the action date to the next date. (By default, the Action date is the Start date, but you can switch to use the Due date if you prefer.)
Why might you need this? A few days of ignoring OmniFocus is enough to make any date-sorted view overwhelming. My Defer script is one method to deal with these items: defer them by a day, a week, etc. But sometimes you just need to set these items to today. Or tomorrow.
As with Defer, these scripts work with any number of selected tasks.
If you use the default “Start” mode:
The Start date of each selected item is set to the current day
If an item has a previously assigned Start date, its original time is maintained. Otherwise, the start time is set to 6am (configurable in the script)
If you use “Due” mode:
The Due date of each selected item is set to the current day
If an item has a previously assigned Due date, its original due time is maintained. Otherwise, the due time is set to 5pm (configurable in the script)
If an item has a Start date, it is moved forward by the same number of days as the due date has to move (in order to respect parameters of repeating actions)
Putting it all together
I’ve set my keyboard shortcuts for Defer, Snooze, Today, Tomorrow, and This Weekend to ctrl-d, ctrl-z, ctrl-t, ctrl-y, and ctrl-w, respectively (using FastScripts), so shuffling tasks couldn’t be easier. Use cases:
Catching up after holiday: Select all overdue tasks, hit ctrl-t to bring them current. Then snooze or defer the ones you won’t get to today.
Planning today’s tasks: Select your tasks and ctrl-t them into the day’s queue. Planning tomorrow? Use ctrl-y instead.
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.
Run the script with one or more items selected in OmniFocus
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.)
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.
It couldn’t accept basic documents like PDFs (flexibility fail)
It wasn’t scriptable (extensibility fail)
You couldn’t import/export data en mass (openness fail)
But the Evernote team have been hard at work, and with the recent addition of scriptability and an API, it’s worth a serious second look.
Accessibility is undoubtedly where Evernote shines: you can access your data on the web client, your Mac or PC, or your iPhone or Windows Mobile device – and it all stays synchronized. Ergo, you still have your data when the network goes down. (The mobile Evernote clients act more as search/input portals into your Evernote data, though the latest iPhone version now stores your “favorites” locally so you can access critical notes offline. Also, if you prefer to keep some data private, you can selectively opt out of synchronization.)
Besides being Evernote’s killer feature, accessibility is also the cornerstone of the product’s business model: Evernote itself is free, but if you need more than 40MB/month you’ll need to upgrade to the premium version ($5/month or $45/year). The most exciting Evernote use cases will probably be mashups that use its API, which means increased bandwidth needs – and, therefore, subscriptions. (N.B.: Evernote’s API documentation describes the bandwidth elements as the “accounting structure”.)
Evernote accepts text/RTF files, images, web clippings, PDFs, and audio notes. To get files in, you can drag-and drop files onto the desktop client, email them to a special Evernote email address, or use the bookmarklet to clip content directly from any web browser. Handily, if you have part of a web page selected, the bookmarklet just saves the selection. Read: Evernote is most in its element when used for web clippings.
In addition, images can be snapped from your webcam or iPhone camera. More on this later.
Unfortunately, Evernote can’t handle many common document types, including Word documents (though RTF documents work passably). Most other filetypes (mind maps, outliner documents, etc) are out of the picture as well.
In the Mac client, the built-in content editor is little more than a glorified text editor. Text formatting is limited to font/size, bold/italic/underline, and alignment, though you can also attach images. (Not to mention the insulting font selection, which includes Arial but not Helvetica – shame!) The Windows client also provides some drawing tools (useful with a tablet PC), a broader font selection, and outlining functions. Update 11/10/08: Version 1.1.6 for Mac introduces orderd/unordered lists and tables.
Scalability: 6/10 (est.)
I haven’t thrown a tremendous amount of data at Evernote yet, so it’s unclear how performance is affected by a large data set. (I was hoping to put it to the test via the Delicious bookmark import, but Evernote just imported the bookmarks as links, rather than scraping the bookmarks’ targets.)
From a user interface perspective, scalability may be a problem. Items are accessed by browsing (by tags and metadata) as well as search. Aside from the ability to use multiple “notebooks”, there is no standard hierarchical organization. Users with a large number of tags or documents might become frustrated by this.
Basic search functions are solid, though generally unremarkable (no regular expressions, no advanced operators). You can combine search terms with tag filters.
In addition, Evernote has a couple search tricks up its sleeve:
Images pass through Evernote’s OCR engine when synchronized, turning image text into searchable data. This even works, to a large extent, on handwriting – slick!
Evernote metadata includes standard text tags as well as optional location data, so you should be able to search by location as well as content
The Mac client now includes a basic AppleScript dictionary, which allows for integration with other apps. No content-level scripting, but the most important feature – note creation – is available.
In addition, the Evernote API provides full access to Evernote data. I’m not aware of any Evernote-based applications yet, though Pelotonics is planning some level of integration. If useful integration emerges, this is will be a big win for users.
Disappointingly, despite claiming export options as a feature, Evernote maintains a tight grip on your data. Need to send a file to your colleague? Forget drag-and-drop: you’ll need to go through Evernote’s export or email functions.
On the Mac side, the only export option produces a proprietary Evernote-formatted XML file with document contents embedded. The Windows client can also export in HTML, web archive, and text formats.
When emailing files, Evernote wraps most notes in an ad-encrusted PDF document before sending. (Yes, it’s as bad as it sounds. Look for the “Plain text note” here. That PDF is what you get when you try to email a text file.) Mercifully, you can email PDFs in their original form – though whether this is by design or oversight is unclear. What is clear is that Evernote doesn’t make it easy for you to use your data as you wish.*
A third option is to share your documents in a public notebook (like this one). This of course not the same as export, but it does provide a refreshing level of social openness uncommon in tools of this nature.
Evernote deftly handles web clippings and snapshots, and ubiquitous access makes it a viable tool for web research and data management.
Perhaps paradoxically, Evernote’s impressive accessibility also limits how I use it. Synchronizing data through Evernote’s server means I won’t use it for sensitive data. So although it’s hard to imagine a situation in which I won’t have access to my iPhone, Mac, or a web browser, it’s also hard to imagine a situation in which said access is truly critical. So I typically use Evernote for less important (but nonetheless useful) tasks:
Clipping captioned images and business cards for OCR
Jotting beer-tasting notes
Snapping photos of the same
Misc. data capture when I’m away from my computer
Bottom line: despite its limitations, Evernote is a great tool. At the free price point, you’re unlikely to find a more robust tool… so give the elephant a whirl.
*Comparisons could be drawn to DRM-laden music purchased from iTunes: it’s quite likely that you’ll never want to use it outside the iTunes/iPod ecosystem. But if (or when) that day comes, you won’t want to deal with their restrictions on your data. Same principle.