The road to Frictionless 2.0

My wife is away for a week, so I've been making great progress on Frictionless 2.0.

2.0? What happened to .85->1.0?

Well, a couple of things.

The first was personal. My job really, really, really began to suck. So pretty much all my spare time was sucked into the job hunt. After I succeeded in landing a new job, all my spare time was sucked into getting my new company up to speed as they'd become an internet company without realizing it. (Transforming brick and mortar companies into internet companies is what I do for a living.)

The second was technical. Frictionless was really one of the first GTD-specific mac applications out there. Most of the other mac-GTD solutions were really just using existing tools in order to use GTD. My favorite of these, Kinkless, was build on OmniOutliner Pro using AppleScript of all things. Developing Frictionless was really born from my frustrations with Kinkless.

So Frictionless started as Kinkless in Objective-C. As I started using Frictionless more and more though, I realized that these days:

GTD Program Principle #1: No GTD program is an Island

That is, you're constantly getting "action items" from numerous places: Email, Websites, Meetings, Phone Calls. Sometimes you're at your computer, sometimes you aren't. Similarly, when you're "doing", you're not at your computer. So I needed to implement connectivity to other programs and printing because GTD programs function best as "glue" between all the things you have going on.

For connectivity, I started with AppleScript. What a bitch and a half that was! But that let me integrate with QuickSilver and Mail, which was key for me.

Then I turned to printing.

Developing for Cocoa is cool, easy, and fun. Printing in Cocoa is well, tedious. Basically, to print something in Cocoa, you have to completely start over. While you can layout your UI in Interface Builder, you can't layout your printouts, and some of the views (like say, TableView) look completely different in print versus the screen.

And I suck as a graphics designer.

So immediately, I latched onto diyplanner.com. "Wow", I thought. If only I could mix their templates into printing so I could print my task lists onto 3x5 cards, an my project outlines onto 8.5x11 sheets of paper. I asked around, and most people in my situation generated HTML and then used WebKit to print with.

So I looked at that. While WebKit is great for the screen, its just so-so for printing. I could use MiscMerge to generate the templates, but it was going to need a lot of hand holding and custom code for each template I suspected. So what I'd really need is a scripting language that went along with each template. Argh.

So then I thought, maybe I'll integrate with iCal instead. Then I could print from iCal. It wouldn't be perfect, but I could perhaps live with that.

So that meant looking at Sync Services. Which looks to be a great API, but the documentation sucks. The sample code only looks at syncing with Address Book. So that meants lots of fussing around with the code to handle all the edge cases, and there are lots of edge cases with syncing. (You've changed the due date in Frictionless, but you've marked it done in iCal...etc.)

Plus really, iCal is just the beginning because what you really want to do is sync with not just iCal, but Stikkit, Google Calendar, Twitter, Backpack. Like I said, no GTD program is an island. What everyone really wants is a GTD program that can be accessible from everywhere. This is especially important for marking things done, making notes, or throwing things into the Inbox.

Looking into all these webapps, I realized that to interface with them, I really needed to write code in Perl, Python, or Ruby because doing SOAP requests from Objective-C sucks.

So that was all very frustrating, and Frictionless worked good enough for me to use everyday. So I sat around for a long time making paper designs for the UI, and watching all the various scripting languages as they built bridges to Cocoa.

Then Apple announced the iPhone.

Serious lust on my part. It also immediately became clear to me that I had to integrate with the iPhone, if only via iCal or the web.

GTD Program Principle #2: The iPhone is going to be the 800-pound gorilla of GTD

So I started doing back of the envelope designs for what an iPhone version of Frictionless would look like, or if iPhone development was closed, what an associated web version would look like. A compelling feature of the web version would also be that you would be able to delegate tasks to others who could accept or refuse the action. iCal was threatening to do this for Leopard, but their implementation sucks, because one of the things about delegating is that it turns one task into two: If you delegate a task to someone, they get a new to-do item, but you end up with a new item "follow up with so-and-so's to-do".

So either iCal integration or a scripting language integration had gone from "would-be-nice" to "must-have".

Then Apple announced that they were throwing resources behind the Ruby-Cocoa bridge. I didn't really take that seriously because the last time I'd tried to use the bridge it hadn't worked for me. Ah, but then I saw the sneak preview.

So I spent a couple of hours poking around, and got a big chunk of my new UI ideas for Frictionless up and running quickly in Ruby.

So now, 4 days later, except for the Apple bugs with NSTreeController, I have the new UI for Frictionless up and running. In effect, I've completely rewritten Frictionless from the ground up. I don't have everything the old Frictionless has yet, and its still a work in progress so I'm not going to release it yet, but the new UI is going to kick serious ass, because I've looked at all the other GTD programs out there and most of them just suck. Its hard to get the necessary and sufficient set of features in a GTD program without cluttering your UI.

The problem is that for some actions, you want all kinds of stuff (start date, do date, due date, recurring, recur delay, recur deadline, context) and for other actions, you want a "done" checkbox. You also want to be able to enter new actions as easily as possible.

GTD Program Principle #3: Minimize Friction

One of the things the current version of Frictionless has is the "quick entry" window that lets you catch those numerous "one off" actions that come up during the day. Or it lets you capture things you "just did". Additionally, the QuickSilver integration lets you use @ and > to specify project and context. I'm going to be extending this and building it into the Quick Entry in Frictionless 2.0. Doing that meant I could completely eliminate 90% of the UI in the QuickEntry window, which means I could actually eliminate it entirely as a separate window. Instead, in 2.0, every window that shows actions will have a quick entry section. Also, you can click on any action and add a sibling or child action to it, even in a task view like the current Next Actions window.

Anyways, I'm pretty happy with how things are going.

If you want to be notified when a preview of 2.0 is released, signup for the mailing list above.

Copyright 2007, Pierce T. Wetter III