I’ve been searching all day for implementations of GTD on the web. 

- iCommit, written in PHP.  The interface is horrible, and the text is way too small.  However, it supports many more GTD features than Tracks.
- MonkeyGTD (use Firefox) than runs on top of TiddlyWiki.  It’s very pretty, but the effects are a little annoying.  Tracks can learn a lot from it.
- GTDGmail, a firefox extension.  For those that have firefox on a memstick and use Gmail, it might be a good implementation.  However, tracks was simpler to install for me (I have some basic RoR knowledge) than getting GTDGmail to work. 
- Remember The Milk, while not a GTD-centric to-do list service, it can be used as such.  It has a very good looking interface.
- Vitalist.  It is a GTD application implemented in ASP classic.  It’s very pretty (except for the icons).  I believe Tracks (which is still my favourite because I can tinker with it) can learn a lot from it.

The problem with all the mentiond apps, including tracks is that they cannot be installed on a mobile or PDA.  Meaning, they require connectivity, and the mobile companies skin you alive with their $1 per megabyte rates.

I just read their policy.  It will only be free during the beta, which might suck if they want to charge an arm and a leg like 37signal charges for their products.

Thanks for the writeup, SpookyET. You mentioned that Tracks could learn a lot from MonkeyGTD and Vitalist. Are there specific things you’re thinking of?

The reason why I have not mentioned specific features is that I want the author and the contributors of Tracks to actually play with all those I mentioned and learn for themselves what’s missing or how to do things better.
- iCommit is pretty ugly, but has a lot of GTD functionality, like references, someday/maybe, voicemail, some other stuff.  It’s all in the horrible menu.
- MonkeyGTD is very taggy.  For example, each context has a someday/maybe, references, etc.  You can add an action to more than one context.  It’s got a very nice GUI and presentation.  However, it’s a little busy.
- Remember The Milk has a very cool nagging feature to force you to get things done.  It can be configured to do GTD.  It’s got a very nice GUI and feedback.  You can also undo deletions (if you deleted a task by mistake).
- Vitalist is nice all around.  It’s got a very simple, minimalist GUI.  It’s pretty.  It’s got Inbox, Waiting, Someday, Reference.  However, they are not tied into contexts.  I don’t know if they should be like Inbox, or tied into contexts.  I haven’t finished reading the book.

I’ve got 100 pages more to read from the book.  But, thus far, Tracks does not match GTD fully.
Inbox: Missing.  FIFO or LIFO.  FIFO would be better, but people should be allowed to choose.
Someday/Maybe: Missing. It has no due dates.  It’s like Inbox.
Reference: Missing.
NextActions:  These are not supposed to have a due date or reminder.  They are supposed to be done ASAP based on context.
Calendar: Missing.  These is where tasks with due dates go.  Reminders go in tickler.
Waiting For: Missing.  List task, the date it was added, and the person.  Notice, there is no due date.  You would create a tickler, check up on X to see if he did Y.
Actions: Context needs to be renamed to Actions because my objective is to finish actions, not to browse contexts.  The tracking of “actions” is the purpose of the system, not the browsing of their holders.

Dashboard:
- Show upcoming N calendar events.
- Show tickler reminders.
- Allow user to select his current context.  Do not list all contexts.  If I am at home, office is irelevant.  I don’t need to see it.  Show N items from that context.

Contexts:
- Contexts might need to be tags.  Let’s say I want to erase a hard drive on my home computer.  I can erase it when I am @home, or I can erase it at any @computer remotely.

SpookyET,

It’s probably worth me spending a moment to explain the rationale behind Tracks. I designed it to help people (actually, to help me) to implement GTD, but because everyone (even those who have read David Allen’s book) do that in a slightly different way, I made it as flexible as possible.

I’ve read a lot about GTD, and a lot of accounts of people trying to use GTD and the biggest reason that people switch tools is that their chosen tool doesn’t quite work the way they’d like it to: something about it just doesn’t make them feel comfortable. That’s why my design choices with Tracks have always been to make it flexible rather than hard-coding something in. In fact, David Allen doesn’t really specify the ‘one true way’ to do things. He offers a system for people to start with and guidance in using that system, but is quite agnostic about tools.

So, many of the features you have listed as “missing” can be put into Tracks by the user if they want to. For example, Inbox, Someday/Maybe and Waiting for are all in copy of Tracks because I just created contexts called Inbox, Someday and Waiting For. I tend to leave Waiting For collapsed so that it doesn’t cause clutter, and just expand it for my weekly review to see if I need to chase anything. Someday I leave hidden from the front page. Some people make Someday-Maybe a project, which is fine too. There has been some good discussion about possibly setting the state for projects so that they would be ‘active’ (the normal state), ‘completed’ or ‘incubating/pending’, which would be effectively someday/maybe. That would mean that you wouldn’t have to shift things between projects when you decided to make a project active, which would be good.

Inbox is an interesting one. Originally, it was intended for use in a paper system, so it was a real, physical box into which you quickly threw things you’d collected as actions, for later processing. Since we’re using a digital system, as soon as you add something to Tracks, it’s collected in the system anyway. Since it’s so quick and easy to assign and context and/or project to an action at the point when you create it, you can (though don’t have to) do that. I tend to just use my Inbox as a collection point when I’m using the API to add actions. I use Quicksilver or an Applescript to add an action to Inbox quickly, and then I’ll process it later. If I’m adding from Tracks itself, I just put it straight where it has to go.

Your other points:
Reference: You have notes - how does that differ from reference (apart from the name, which is trivial)?
NextActions: They don’t have to have a due date or reminder, but they can. Note that the due date is the latest possible date on which you can do the action, or the effort is wasted. It’s NOT the date on which you do the action, because you do it as soon as you can.
Calendar: It’s missing deliberately. There are a hundred and one calendars out there, and everyone has their favourite. It would be reinventing the wheel to provide a full calendar implementation. However, I do plan to integrate some of the popular calendar implementations (like 30boxes, gCalendar) by using their APIs. Then you get the best of both worlds.
I don’t get the point about Actions being renamed to contexts, I’m afraid.
Dashboard: Something that I do plan to add.
Contexts as tags: Has been discussed, but there’s a problem of display when you have multiple tags applied to an action.

As you can probably tell, I’m very opinionated about Tracks, but I think that’s important!

Based on my reading, this is my understanding of the system.

Inbox:
———————-
- A list where you add everything that is on your mind for processing later via FIFO or LIFO.
- Item movable to Rubbish (delete).
- Item movable to Someday/Maybe
- Item movable to Tickler.
- Item movable to Reference.
- Item movable to Waiting On.
- Item movable to an existing Project, or one creates a new Project from it.
- Item movable to Context.

Reference:
———————————
- Belongs to Action
- Belongs to Project
- Belongs to Nothing

Project:
————————-
- Has one or more contexts which have actions.

Action:
————————
- One liner
- No description; if you have to describe it, you have failed.  It is written badly, or it is too complicated—should be a project.

Context:
—————————
- Has one or more projects, which have Actions in different lists by action type (or, actions with no project).
- Types:
  * ASAP—no due date
  * Tickler—You want to be reminded 6 months from now to have a look at it
  * Someday/Maybe—You’ll look at it in the future.
  * Calendar—Must be done by/at a specific date and time.
  * Waiting For—Not actionable by you.

Waiting For:
———————————
- Has actions listed [Action], [Person], [Project], [Context], [Date Deferred]
- Those that have a “due date” should also be listed in “Tickler” to be reminded that person X has not done his job.

————————————————————————————————————————-

So what does all this mean for the interface?

Dashboard
——————————
- It should not list everything.  It should not be busy whether I have 10,000 actions or 10 actions.
- It should only list what I care most about.
- A few critical actions (due now, or tomorrow, or N days from now)
- A few tickler reminders.
- A few ASAP.

Projects
—————————
- Browse projects.
- Upon clicking on project, you see contexts.
- Click on contexts to see actions.

Contexts
—————————
- List Calendar actions first that are critical, due now or very soon.
- List ASAP actions.
- List Tickler actions.

———————————————————————————————————————-

Menu:
———————-
[Dashboard], [Inbox], [Projects], [Contexts], [Actions], [Tickler], [Calendar], [Someday/Maybe], [Waiting On], [References]

Miscellaneous things:
————————————————
- Now, you talked about flexibility.  By no means I’m advertising strict adherence to the system.  No one forces you to add an item to “Inbox”; then move it.  You can add an action to a context directly.
- As for the calendar, one should not be reinvented.  I’m sure that there is a great calendar component for Rails that can be adapted to work with tracks. Looking at a calender entry, it should say Project, Action, and/or Context.
- I found a great outline of the book here.

If you don’t mind, I’d like to post this on the mailing list to see people’s opinion.  Just like RSS, people preffer for stuff to come to them than browsing forums.

If you don’t mind, I’d like to post this on the mailing list to see people’s opinion.  Just like RSS, people preffer for stuff to come to them than browsing forums.

Sure, feel free. Some people like mailing lists, others like forums: that’s why I have both

I’m still not sure that I see anything significant in your list that can’t be done already, with the exception of the dashboard, which as I’ve said is planned.

Projects
—————————
- Browse projects.
- Upon clicking on project, you see contexts.
- Click on contexts to see actions.

That’s one click too many in my view. Personally, I see projects and contexts as alternative ways to slice your actions. With the [C] and [P] links, you can see which context/project an action belongs to in either view.

- Now, you talked about flexibility.  By no means I’m advertising strict adherence to the system.  No one forces you to add an item to “Inbox”; then move it.  You can add an action to a context directly.

Sure, but with your hardcoded inbox people who don’t want to use an inbox have to put up with an empty container and a space being used on the navigation bar. The way it currently is (i.e. people can add a context called Inbox if they want) it’s completely flexible. I don’t see that your description of an inbox adds any actual extra functionality.

Like I said, I don’t want to restrict flexibility.  People should be able to hide/show any component they want.
I see projects as spanning multiple contexts.
If the project is to buy a car, you have to take actions at different contexts (dealer, insurer, bank, etc.).
The clicking I mentioned above was the easiest way I could explain it.  It does not necessarily mean that people would have to click.

SpookyET: The system you describe is very close to the http://www.gtd-php.com/ implementation. I was using it before I moved to Tracks and suggest you check it out.

The one item I would really like is the project state that was talked about. Being able to create a project and send it into a pending state that I could review and thus remember. I still suggest calling it Someday so that GTD people coming to Tracks will understand it’s use.

Thanks