Gabe gives Kourosh Dini’s “Creating Flow With OmniFocus 3” two thumbs up. I’ve been hearing good things about this book.
The problem with hunches is that it’s incredibly easy to forget them, precisely because they’re not fully-baked ideas. You’re reading an article, and a little spark of an idea pops into your head, but by the time you’ve finished the article, you’re checking your email, or responding to some urgent request from your colleague, and the next thing you know, you’ve forgotten the hunch for good. And even the ones that you do manage to retain often don’t turn out to be useful to you for months or years, which gives you countless opportunities to lose track of them.
This is why for the past eight years or so I’ve been maintaining a single document where I keep all my hunches: ideas for articles, speeches, software features, startups, ways of framing a chapter I know I’m going to write, even whole books. I now keep it as a Google document so I can update it from wherever I happen to be. There’s no organizing principle to it, no taxonomy–just a chronological list of semi-random ideas that I’ve managed to capture before I forgot them. I call it the spark file.
Now, the spark file itself is not all that unusual: that’s why Moleskins or Evernote are so useful to so many people. But the key habit that I’ve tried to cultivate is this: every three or four months, I go back and re-read the entire spark file. And it’s not an inconsequential document: it’s almost fifty pages of hunches at this point, the length of several book chapters. But what happens when I re-read the document that I end up seeing new connections that hadn’t occurred to me the first (or fifth) time around: the idea I had in 2008 that made almost no sense in 2008, but that turns out to be incredibly useful in 2012, because something has changed in the external world, or because some other idea has supplied the missing piece that turns the hunch into something actionable. Sure, I end up reading over many hunches that never went anywhere, but there are almost always little sparks that I’d forgotten that suddenly seem more promising. And it’s always encouraging to see the hunches that turned into fully-realized projects or even entire books.
This seems like a profoundly useful idea, and not just for writing — but for life.
It’s a variant on the someday/maybe list in GTD, which I’ve never really understood the purpose of until now.
“My world is laden with bad tools, because my culture is simultaneously obsessed with productivity and novelty.”
OmniFocus is the control panel of my life. I write down everything I need or want to do in OmniFocus, and then when the time comes, I do it. This post is for my fellow OmniFocus nerds only; it won’t make sense to anyone else.
Here’s something that bugs me about OmniFocus, and that I’m hoping to see fixed in Version 2.0: The Folders/Projects/Groups structure is plain confusing. We should instead just have items which act as projects if they contain other items, and act as actions if they don’t contain anything else. Actions can exist at the top level, they don’t need to have containers.
Users should be able to nest these action/projects to an unlimited number of levels.
Eliminate parallel projects. They’re just confusing. I know what the theoretical difference is between parallel projects and the other kinds of projects. I just don’t see parallel projects as useful. To the contrary, I see their existence as harmful.
Single-action lists do essentially the same thing. The default for new projects should be configurable in preferences as either sequential or single-action lists.
I plan to write this up as a feature request and submit it to the appropriate email address at the Omni Group; I’d just like to show this to other people first, to see if I overlooked anything.