Thoughts on the definitive GTD app
I've used David Allen's Getting Things Done (GTD) productivity methodology, with various personal tweaks, for several years now, but I keep wavering between digital and paper implementations. There are some fairly good GTD management apps out there for the Mac -- I've been looking in particular at EasyTask from Orionbelt.com LLC, Ghost Action from Ghost Park Software, and Kinkless GTD (kGTD) from Ethan Schoonover, and for over a year I maintained a homemade implementation in Hog Bay Notebook/Mori -- but so far none of them has really clicked in terms of both flexibility and ease of use. I've also used implementations based on index cards (easy to shuffle!) and paper forms and folders, but when I go analog I miss the ability to sort and filter at the click of a button, and sometimes my next actions stay out-of-sight, out-of-mind in their manila folders for longer than they should.
Since several developers are currently working on GTD apps, I've been giving some thought to what my ideal app would look like. Some of these ideas are taken straight from David Allen's "canonical" GTD, some are from how the existing apps work or from various blogs and discussion groups, and some are purely my own.
For Projects, I'd like to be able to set the following attributes:
- Start date
- Due date
- Links (file, e-mail, URL, other?)
Purpose (why?), Parameters, and Outcome (what?) are taken from David's natural planning process. (I believe he uses the word "principles" rather than "parameters".)
Start date and due date are not canonical, but many people find them useful since real-life projects often come with deadlines. I envision the app setting the start date to the creation date of the project entry by default. Deleting the start date would put the project in the Someday/Maybe category; these projects and those with start dates in the future could be hidden from the current view. The ability to hide projects (and Next Actions) with future start dates could also be used to provide functionality equivalent to a Tickler file.
Due dates could be defined as "hard" (the whole project fails if the deadline is not met, for example if a presentation is not ready in time for an event) or "soft" (a delay won't ruin the whole project, but I do have a target date that I'd like to get it done by). The user could set a view to filter out unfinished projects with past "hard" due dates but still show past-due projects with "soft" due dates.
For Tasks (not necessarily "Next" Actions), the attributes I envision are:
- Start Date
- Due date
- "Next" status within project
- Completion status
- Estimated completion time
- Actual completion time
- Links (file, e-mail, URL, other?)
"Singleton" tasks not associated with any project should be possible; it might also be useful to associate a task with more than one project.
I would definitely want the ability to associate more than one Context with a task. Since, if we want the ability to sync with iCal, we do have to specify one specific calendar for a given task, this means we have to define a separate Calendar attribute with only one choice possible (or none if for some reason we don't want to sync that task).
"Domain" is my name for the broad areas of my life that tasks occur in -- personal, business, family/friends, community, etc. I find it useful to keep these categories separate from contexts. Calendars could be based on domains but don't necessarily have to be. The app could offer a preference setting whether to use domains and whether to make them optional or required.
Start and due dates would generally work the same way as for projects. Recurrence could be None, fixed (e.g. the first of every month, every Sunday, every 30 days -- like the Recur setting in kGTD), or flexible (x number of days/weeks/months after the most recent completion date, like the Reset setting in kGTD or the way tasks repeat in Sciral Consistency).
"Next" status is self-explanatory. The user could decide whether a project can have just one "Next Action" or multiple ones (or maybe one per context?).
Completion status could just be a "Done" checkbox. It might also be useful to have a "Suspended" setting with a similar effect to deleting the start date (i.e. the task would be classified as "someday/maybe").
Estimated and actual completion time would give the user a way to determine how long it will actually take to complete projects, which comes in handy for long-term planning (though I don't envision this app becoming a full-blown project management app with Gantt charts and whatnot). There should be a function for monitoring how accurate the estimates are so that the user can improve their accuracy.
I see Waiting For items as tasks with a future start date. My approach to waiting fors has long been non-canonical. I don't see a need for a Waiting For "list" as David recommends, since the actual date when I expect to receive something may be tomorrow or six months from now. There's not much point in reviewing something on a weekly basis if I'm not actually expecting it for another two months. I usually put a reminder of something I'm waiting for in my tickler file (which has always been an analog file-folder system) for the date when I would have to follow up if the item hasn't arrived yet. If it arrives before then, it goes in the inbox for processing like anything else, and I can just toss the reminder when it comes up in the tickler. Otherwise, I make a phone call to ask "where's my widget" or take whatever other action I've defined when the follow-up date comes along.
Users should have the ability to define their own custom attributes (columns) for both projects and tasks and sort and filter on those.
One thing I'm still not very clear on is how to integrate higher-level planning above the Project level, like David's 10,000-foot and higher views. I currently track quarterly Objectives, yearly Goals, and a 4-year Vision. At times I've kept these in one big outline along with the project and task detail in OmniOutliner (without kGTD) or Hog Bay Notebook, but I found it unwieldy. If the "ideal app" incorporates these levels, it's important to be able to hide them during daily "doing" and even during the more frequent (weekly) reviews.
Another nice feature would be both online and offline editing capability, i.e. the ability to access my projects through a (limited?) web interface from any computer connected to the Internet, but also to have the files cached locally so I could work on them when I don't have Internet access.