First of all, I would like to say that I ABSOLUTELY appreciate your work and I find it AMAZING. Otherwise I would not decide to invest my time to (consturctively) criticize it. What follows is some criticism to make it even better.

Short summary: I think that Tracks fails to implement some basic GTD things and that to change it does not need too much technical effort at all, it needs some thinking and sublte touches thought.

David Allen in his book advocates some basic practices which together make the whole GTD system. Tracks system does not intentionally implement the suggested workflow in a rigid way (you back it up by allowing flexibility in your post  ) but it rather offers framework which can be used by users in various ways. I - as a programmer myself -  appreciate this flexibility, but I think it is confusing for people which do not see the underlaying “database/code” structure.

There are lot of small things which can back what I am saying as an example I start with the main menu. Nonprogrammer coming from GTD would expect to see something like:

  * Inbox
  * Next actions
  * Projects
  * Someday/Maybe
  * Waiting for
  * Ticker file
  * Calendar
  * Reference

instead she sees:
  * Home
  * Contexts
  * Projects
  * Tickler
  * Done
  * Notes
  * Preferences
  * Export

which is very different. Ok, let’s give it a “try”. Let us start with the “Collection” phase to “Inbox”.

The button in the right form says “Add action” which by itself is confusing. Does it insert Actions? Or stuff in Inbox? Who knows. Ok ...She tries to enter something in inbox - fills in descriptions and hits “Add action”. 

Whoops. 1 error prohibited this action from being saved There were problems with the following fields: Context can’t be blank ...

Why the context could not be empty? Inbox items have NO context, they are just list of the open loops in your life, no actions, just collection. What to do? There might be many possible ideas. Maybe adding new context “no context”, maybe adding context “inbox” ... which itself is wierd, because inbox is NOT context at all.

Ok, so I have 50 items in inbox and I proceed according to David Allens book with “Process” phase and I expect Tracs to help me with it, which is the role of any such software - to facilite COllection and Processing.

I go through items and decide what to do with them, there are these options:

1. Trash them ... there is a nice X at each item. Perfect, this works as expected.
2. Put them to someday/ ... well, that is not so obvious? The programmers solution would be to put it to some hidden something (context, project), but this is absolutely unintuitive for a normal person.
3. Put them to reference ... it is not obvious how to do that either, but let us say that the reference as such is not implemented ... could elaborate on that later if you want.
4. It is under 2 mins action -> do it and delete it. Perfect, we already know how to do that.
5. It is single action longer thatn 2 mins -> we want to put it to some mext action list and optionally attach context to it. Again we struggle when there is no context, so probably we introduce some artificial “no context” context. At this moment the “context” attribute is used to at least three very different purposes - collecting inbox stuff, hiding maybes, and serving as a real context. This is not good.
6. Delegate it - the is no delegation in tracs, so probably we reuse contexts fourth time? At this time it is clear that the “context” has only partially to do something with real context, so it is misnamed at least.
7. Make a project - jupiii, we have this one clearly here. Shame that it is not easy to convert item from inbox to project easily, so we put the text to cllipboard, if there are notes, we cut paste them to newly opened text editor window and create new project, pasting everything back (ok, I do not want to underestimate non programmers, but I thing that even this may make some “normal” people feel uncomfortable at least). We have new project and we can even nicely put new nenxt actions to it and attach contexts to it. Here - again - we came across the “context mess” because next action from a project put in the inbox context really makes no sense.

That is it. I could elaborate on other thigs as well, and I will if you are interested, but I hope you get the idea for the moment.

I thing something should be done with it. I feel that these issues do not need too much rewriting of the code, rather they would need some serious thinking and some touches to interface. Or maybe a tutorial on tracks? Who knows? If we want to follow David Allens “Natural planning” approach it is too early to offer solutions now anyway, it is time to define the problem and set up the goal to solve it once it is identified. Only after that we can talk about solutions.

So my only questions to end up my post is: Do you understand what I mean and do you agree that there might be a problem?

Regards
Jakub

I see you have put a lot of thought in your post. You also reference the post of bsag where she explains the rationale behind the design choices.

I think that a lot of what you are saying has to do with the role of a tool like Tracks in your GTD workflow. Should the tool encompass and reflect all of a GTD workflow or is it a tool you can use for parts your workflow, i.e. not necessarily a tool that supports every step of the workflow. Furthermore not everyone is adhering to the workflow, i.e. you do little reviews of your todos constantly, get your mind empty constantly not only weekly. I personally want an interface/tool that helps me do this from one page and not explicitly force me to switch pages which I sometimes see in other GTD tools. Tracks does this well with the homepage.

Also, I personally think there is no perfect tool to support the complete workflow and we should not aim to make Tracks one. This is why Tracks does not shine as a tool for reference (your point 3) for example. People are using various specialized tools for that. I’m personally using OneNote which works perfectly for me.

I have a context @inbox which is the first in my context list. Because it is the first, it is automatically the default context in the new-todo form. So in my collection phase I can quickly enter a new todo and not think about context/project at that time. I think this is the way many users of Tracks have organized this.

2. Someday/maybe can be easily supported by Tracks right now, although you’re right that its not very clear from the start. There is a request to make it a bit smarter (i.e. remember the context it belongs to if you want to commit to the todo)

6. I think David Allen also refers to Waiting for as a context…

7. Also, converting a todo to a project is an enhancement request too. This is a good idea.

So, while I understand your issues of the ‘flexible’ use of contexts, I do not agree that its a “mess”. I do think we could use some sort of a use guide to help people ‘configure’ Tracks to suit their needs of their implementation of GTD.

Thank you for your thoughts,

I agree with you that Tracks should not aim to be full implementing GTD (and yes, I understand that the reference feature is better handled in other tools) and stay open to various approaches. But I expect that one such non-marginal approach will be to implement GTD methodology (meaning the part of it for which tracks is aimed) and if you want to fulfill your mission, which is to stay “open to different approaches”, it should facilitate this approach as well.

I also advocate to carefully consider people who as non-programmers can get easily confused by small things which are obvious to programmers. Every software project is developed by programmers and it unfortunately causes some bias to how many of them wind up. I have already seen quite a few good projects which stayed closed to smaller community than it could reach only because of the lack of effort to reach the wide public.

Also I am not necessarily talking about new very complicated features here. One of the directions in which solution can be found is certainly what you have suggested: some kind of tutorial to help people ‘configure’ Tracks to implement GTD. I think it would be very helpful even if we take some “typical implementation” free of specific personal “tricks” everybody invents for themselves. Than write a really simple and slow tutorial which guides user step by step through the “configuration”.

To address your other comments:

ad) reference
I use personal wiki to hold reference, because than everything is online. To me it would help if there can be some special markup configured so it creates links to predefined url. Example: If i write in the task “Review [[committee meeting notes]]” and configure in my preferences the url pattern like “http://wiki.personalurl.com/wiki/page_id=%u” which can be than replaced - in this particular example - to link to http://wiki.personalurl.com/wiki/page_id=committee_meeting_notes

ad) @inbox
Here I think that the problem simply is that we put open loops not actions in inbox. It is during the processing when it gets into good shape and is converted to action of project with defined outcome. I know that many people put immediately actions there and also that some people prefer to skip inbox altogether and put the things directly where they belong to. Although it is good practice it has its dangers as well. D.A. in his book has the whole part of the book consacred to “processing” which in fact is exactly the conversion of inbox vague list to actions, projects, references, etc. and he also describes what can happen if the process is not done correctly. So although I understand that some people do not even need inbox, I would like to see the possibility to implement it as in GTD and to facilitate the process of “processing inbox” as I have described in my previous post.

ad) 2. someday/maybe: Sprry, I am not sure which “easy support” you mean.

ad) 6. I do not think so, he rather suggest to set up the system so it is easy to switch between waiting for and next actions list as it may happen quite often during course of one project. I like very much the idea of tracks that contexts, projects and tags are completely “orthogonal” or “independent” so one can use whatever combination she wants. However “Waiting for” vs “Next action” should be orthogonal as well. I can have context “telephone” and task “call Andy about the proposal” which I want to put on “Waiting for” list with note “WF: Maria to deliver the proposal”. How it is implemented now, it can not be done, because implementing “Waiting for” can be only done by context, so we should be throwing out the real context “telephone” and replace it by some artificial context “@Waiting for”. This is exactly one of these small things which can make feel it uncomfortable to use the system.

ad) 7. inbox -> project. I am glad to hear that this is going to be facilitated. I, however, think that than the inappropriateness of implementing inbox as context will be even more evident.

To finish, I would like to say that the “context overloading” is not the only thing I am advocating against. My aim would be to start serious discussion/brainstorming about all the Tracks aspects which might be counterintuitive to normal person. And as usual in the brainstorming phase I am not judging which of these “small inconveniences” is really important and which is not. As an other example I have mentioned the main menu, which I think should be changed or at least configurable so it can suit even these who happen to want it more GTD way.

Thank you for you reactions and have a nice weekend

I understand that Tracks could add a lot of functions/pages to support parts of the workflow even better than in the current solution. Inbox, someday/maybe, waiting-for are all candidates. There are enhancement requests for all of them. I’d suggest you add a bit of detail to those tickets to give people some insight as to what you mean.

The arguments you give in this thread are all clear. I’d like to know what you for example mean with an inbox. What use cases are you thinking of?

ad reference - this is a nice idea, please make an enhancement ticket
ad 2 - I mean a hidden context
ad 6 - I like the use case. I think of waiting-for for delegated todos. There have been requests for a dependent-on relation between todos to just do what you describe: a todo depends on the completion of an other todo. That way you don’t have to add a note, but use a seperate todo for it.
ad 7 - now only to find a comtributer to create a patch

As to your aim: your aiming for something very subjective here. What is counter intuitive to one person is intuitive for an other. (Let’s not touch the issue of defining a normal person here). I’m not trying to discourage you here or push you away, but lets start this discussion from your point of view and not from the point of view of a not-existing normal person.

Thanks understanding. I will try formulate some use cases and submit them as enhancement ticket.

Short comment to your last paragraph only. I agree with you that it is not good to speak of any “normal person”, and it is possible that I have been little bit subjective in previous posts. What I meant by “non-programmer” were the people with no expirience with programming have sometimes quite different approach and are not so used to “tweak” tools when they do not work the way then want them to. But it is complicated discussion I agree.

To remain as “objective” as possible I would like to consider the standpoint of someone wanting to implement the GTD methodology as it is in the Allen’s book. If we have tutorial which implement if fully (of course with obvious intended exeptions like reference, calendar, etc) than people who want to start with Tracks have something to begin with and even if they do not want to implement full GTD, they can benefit from the tutorial. At the same time it can serve to point out the places where the GTD implementation is still somewhat shaky.

Who here would like Tracks to be a “GTD implementation” that is immediately usable without config? This is certainly what I want; the best implementation I have found to date is Hipster PDA, which presents significant challenges with automation

Whilst “configuration advice” for using Tracks with a GTD workflow would be good, much better from my POV would be a tool which empraces the (now widely known) terminology and workflow from David Allen and needs no configuration at all for a “by-the-book” GTDer, so that using it is obvious and intuitive. Jakub’s concerns with overloading context and with menu structure are part of this, and whilst they could be incrementally tackled with enh requests that’s probably most useful if there’s an initial agreement on principles.

The “rationale behind Tracks” post from bsag explains her thinking from Aug 2006—bsag, anything you’d add to this now? In particular, do you think there’s a place for restructuring menus along the lines that Jakub suggests, adding top-level Waiting For and Someday/Maybe (not the same as “deferred actions” imho) lists, and maybe adding an unstructured Inbox with a [______] (send-to-inbox) input field on each page?

I’ve found that there’s “aerodynamic drag” from the mismatch (as I perceive it) between the Tracks UI
and what I expect to be thinking about as I GTD my way through the day—and this may explain why I don’t use Tracks nearly as much as I thought I would.

Whilst I wholly agree that much in the GTD book is left open to interpretation, the menu structure Jakub suggests is immediately recognisable as “vanilla GTD”. If we add some dynamic menus, tags and “focus” views in the style of the wonderful
Things (screencast) then I humbly suggest that Tracks might be rather more widely useful.

Does anyone else have enthusiasm for taking Tracks in this direction? bsag, does this fit with your vision?

“Be excellent to each other!”

—Thomas.

Reinier Balt - 01 August 2008 12:03 PM

I’d like to know what you for example mean with an inbox. What use cases are you thinking of?

Suppose you are working on something, you’re busy doing a task.  All of a sudden some random idea pops into your head (Think of something like. ‘this reminds me, i should check <foo>’ or ‘would i be able to do <bar>?, i should research into that’).

The last thing you want (and should do) at that moment is stop doing what you’re doing and start thinking ‘is this an action?’, ‘is this a project?’, ‘how should i file this’, ‘what are all the attributes (contexts,projects,tags, due dates,....’)

At that moment you should be able to open your program, type <foo> or <bar> in it and that’s it.  You need to get it out of your head as quickly as possible because you’re busy with something and you should not loose your focus.

That’s the concept of the inbox.  You collect several things like this and when you have the time you process them one by one and carefully enter the right things in your GTD program.
When you’re not behind a pc you would usually write it down somewhere, but when you’re on a pc it makes sense to input in software on the pc.

If the software you use for action management (tracks) is also capable of handling the inbox task, it’s a win win.  If it doesn’t you must use an external note-taking program and when in processing mode you end up copy-pasting stuff into tracks.

So even if you want to allow people to skip the collection/process phases (not always recommended but in some situations it can work), it should be possible for other people to do use tracks for collecting *and* processing.

Thanks Dieter_be and Thomas,

everything you have written fits exactly to my way of thinking and adds many details to it. I also think that before we start to push in any direction being it coding and/or making request for enhancement, we should agree whether this fits into the project at all. We also need to collect ideas and use-cases so we can prioritize in what is more and what is less important in GTDization of tracks.

Let me just add to Dieters excellent reasoning for inbox one detail: there are really many hidden dangers in putting the things directly to the system avoiding the inbox idea. The process stage of GTD is mechanism which is aimed to avoiding them. Many people for example tend to put very vague informations to “Next Actions” list which than leads to items which stay long time, because they are rather vague aims than real physical actions. etc.

I would like to nuance my previous post.

Seeing the need for the collection/processing phase of GTD is one thing, knowing where to implement it is much more difficult.  Anyone can implement the full gtd system, as long as you see tracks as one element of the bigger system.  There are several different ways to implement collection & processing by using other programs or even simple scripts.

The question comes imho basically down to : what practical advantages could it give to add the collection and processing parts into tracks versus doing it somewhere else and use tracks for the action managemnt only?
In fact even collection and processing should not necessarily be in 1 program.  You could for example collect into some text file/database with 1 script/program and use another (or tracks, maybe) to load that data, and process it.

To answer the question from above, I’m thinking about three things:
1) context switching (change of focus, visibility of windows) between 2 programs vs 1 program that has 1 dedicated page:  even with good window managers and/or big/dual screen setups it’s easier for the eye to look on one page imo.
2) the need of copy-pasting when making a note (from inbox) into an action.  First of all:  the shorter your notes the better they are.  (as long as you know afterwards what they are about )  So they should contain just a few words.  I’m imagining that the processing-phase-page of tracks could handle note by note and when handling each note, it could by default already show a new action form filled in with as action description the contents of the note.  If you want to convert the note into an action you need to type less in the action description field, and it also doesn’t do any harm in case you would like to drop the note or do something else with it.  This is something you cannot do if not implemented in tracks.
On the other hand, we/I could write a desktop tool that iterates over all your notes and presents a form as described above, and uses the tracks rest api to submit the actions to tracks.  It would be as fast as using tracks itself + you can scratch argument 1 because by using the api you don’t need the tracks interface at all.
3) key combos:  on most systems you can assign keyboard shortcuts to open programs (making it really fast if you want to get something out of your head quick). You can’t do that with web apps.  But on the other hand you could also keep a browser with tracks open in another virtual desktop and use a keycombo to switch to it, so it’s sort off equally fast I guess.

For now i wrote a small shellscript that i can trigger with a key combo.  It pops up an input dialog and appends my text to a textfile that forms my gtd inbox.  A very fast way to collect stuff.
See: http://dieter.plaetinck.be/a_fast_way_to_get_stuff_out_of_your_head_and_into_your_gtd_inbox

After thinking for a while and coming up with 2 real and arguments and 1 semi argument, I conclude that by writing a little desktop app as described in ‘2)’ , all arguments are taken care of.  So I think that tracks does not really need to implement collecting/processing.  It would be nice, but offer no practical advantages if we write a little desktop tool to handle the processing (we already have a script for the collecting )

I will think a bit more about this and if I come up with more ideas/remarks I’ll let you guys know.
I’m also very curious to what you guys have to say about this.

I agree that in your particular case your solution is perfect. On the other hand to make it universal solution could be very difficult. The beauty of tracks (and any web application) is it’s accessibility by all OS’es, mobile phones, palms, anything with reasonable browser can do it. However when you start to develop desktop application/shell whatever, you are always cofined to one platform - it is enourmously hard to make it portable. In fact the portability and accessibility from anywhere seems to me the main reason to implement anything as web application, which tends to be always less UI ideal than any desktop appplication.

Good point.  Portability is point to be added to my list, and a key argument to promote the ‘tracks should implement the ‘collecting/processing’ processes.

And btw, if some users don’t like to do the collecting/processing steps, these steps can be on totally separate pages, as they don’t need tight integration - UI wise - into the other parts of tracks.  So these pages could even be configured to be not shown, if the authors of tracks want to allow this.

The portability argument also counts for the missing ‘reference system’ implementation, and UI-wise it can also be a totally different page in tracks.  One could argue that we could use a 2nd web application (a wiki or something) for the general reference system, but then you miss out on some possibilities / some points where integration could be possible.

I’m thinking of:
1) 1 application/interface is easier to navigate then 2
2) in processing phase-> add to general reference
3) integration of ‘notes’ into general reference
etc

A general reference system is probably pretty hard to implement because it needs several features (tagging, categorisation, links between documentation/notes to each other, ...) , but there is probably already much ROR-based code out there that can be re-used for this…

i’m working on adding (or trying to add) an implementation for the gtd collecting&processing;steps to tracks 1.7-dev
http://github.com/Dieterbe/tracks/tree/master
I’m new to git, ruby and RoR so I’m going slowly, but steady (and I’m having fun)

Sorry for the delayed reply—I seem to have spent most of this summer either away or catching up from various absences! First for a little history. I read David Allen’s Getting Things Done, and immediately felt that the workflow he described would help me keep on top of my life. At the time, there were very few (perhaps none, I don’t remember exactly) desktop applications for the Mac. I had coincidentally just started learning Ruby and Rails, and since I didn’t then know anything about Cocoa programming for Mac OS X (I do know a little about it now), I decided I’d try to write something in Rails. It would be a good practical project for improving my coding skills, and I would hopefully produce something useful at the end. Once I’d produced something which more or less worked, I Open Sourced it, in case anyone else might find it useful.

Along the way, I learned that ‘canonical GTD’ as described by David Allen wasn’t the best way of doing things for me. These things are very personal and different for every person, but I didn’t really need an Inbox (it was so easy and quick to add new actions that I just did it, rather than making yet another loop to go through—sorting stuff out in the Inbox), and I didn’t need dependencies. In fact, I have very few projects in the traditional sense of finite pieces of work which can be completed. The vast majority of my work as an academic is a never-ending cycle of stuff which needs to be done. On good days, this feels like a natural cycle, like the seasons or the agricultural year. On a bad day, I feel like Sisyphus, rolling rocks uphill . I’ve found that I like to be able to see everything easily (even if that is an overwhelming amount of stuff), because I find it reassuring to know that nothing is getting ‘lost’. I like flexible ways of categorising and sorting things, because I find I have a lot of overlap between my odd kinds of projects.

I’m well aware that a lot of these things conflict with what The David advises, but all I can say is that it works for me. Reading GTD was invaluable for me in actually making me think about what I need in an organisational system. Also note that I’m not saying this the THE RIGHT WAY for anyone else. It works for me, and that’s all I can say.

Anyway, fast-forward to today: Tracks has gathered a truly wonderful community of users, contributors and passionate advocates. Others have added terrific new features which have improved Tracks beyond all recognition from its very simple and humble origins, and which I would never have been able to code myself. Tracks is as good as it is today almost entirely due to the hard work and effort of the other developers, and I am extremely grateful for that.

However. Tracks is now a product of its community, and as such it must be useful for a diverse group of people. Consequently, it now has some features that I don’t personally need or use. This is absolutely a good thing, because it isn’t just me using it, but it makes it much more difficult for me to say what my ‘vision’ for Tracks is, because most of you won’t like it, and it would be a backwards step. There are also now literally hundreds of GTD applications for all platforms, online versions, iPhone/iPod touch etc., etc., which means that people do have a choice.

So, for what it’s worth (and bearing in mind everything I’ve said above), here’s my opinion on the discussion:

1. Personally, I would make Tracks even *less* structured than it currently is. It’s interesting that thomasn mentioned Things on the forum. I actually think that Things also doesn’t conform to GTD, and is much the better for it. It does have an inbox (which you aren’t obliged to use), but it doesn’t have contexts at all, and splits projects into projects (more traditional-type projects) and areas (like my Sisyphean tasks above). It has no dependency mechanism. All the other organisation (apart from Someday and Scheduled) is done using tags, which you can filter on to slice your actions anyway you like. I think this works very well, and supports all kinds of systems, with very minimal ‘futzing’. Actually, if Things had been around when I was first thinking of Tracks, I wouldn’t have bothered writing it . So one very radical suggestion would be to just get rid of contexts in Tracks, use the excellent existing tagging system to organise things, and improve the filtering. Though we don’t want to just slavishly copy Things .
2. Education and expectations. This is a very valid point. Some features could be changed, and some might be fine as they are, but we need much better tutorials and documentation to show users how they can bend Tracks to their will. It’s worth saying (see my point 3 below) that Tracks users are probably more likely to be tinkerers than not, because Tracks isn’t trivial (despite all our best efforts) to install. It’s not a desktop app, so you need to jump through a few hoops to install, unless you’re using one of the hosted versions. However, that shouldn’t be an excuse for not documenting things properly.
3. Tracks is multi-platform and can be used on a server or a personal computer. This is its great strength, but it also constrains what we can do, because it has to be platform-portable. My opinion is that the best way to deal with that is to behave like a good *nix command line utility: do one thing very well, but offer wide-open pipes in and out to allow integration with other tools, and to allow users to customise their own workflow. We’ve now got a great API thanks to Luke and others, but we could take it even further.

Thanks for getting back to us   It was worth the delay

I disagree with you on some of your opinions, but I’m very happy we agree that the most important considerations when designing/implementing tracks features is general usability/‘wishes fulfilment’.  Eg: increasing the quality of the tracks experience for the average user and not for any contributor him/herself personally.

This basically opens the door for many new contributions (collect/process, general reference system,...) as long as those patches are reasonably stable/maintained and provide more use for those who want it then it bugs those who don’t need it.

I agree with you on the recurring tasks thing.  This is in fact something the gtd book doesn’t say much about.  But Reinier is implementing recurring tasks, and I’m sure something usable will be coming out of those efforts.
Also, many actions just never get ‘done’, period.  Things like grocery shopping etc, where the most natural thing is maintaining lists with items.  Items are added/removed continuously, but ‘grocery shopping’ will never be “done”.  (You could make ‘grocery shopping’ a project but that wouldn’t solve the situation)  For stuff like this, we should imho have some wiki-like features in tracks.  (in fact, I think we should have a full general reference system in tracks, but that’s another story)

Your last point is very tricky.  Generally I agree with the ‘do one thing and do it well’, ‘offer input/output methods so different tools can be chained together’ , but I think webapps like tracks are an exception to that rule:
1) On some platforms, your environment is limited.  Eg on some smartphones you can only have one application open at the same time, or switching between applications/webpages is a heavy/cumbersome operation.  Also, communication methods between applications can be more limited on phones than on pc’s.  (see also gorn’s last post)
2) Doing many things inside one application allows you interaction between those ‘things’ that sometimes are not possible - or much harder - when doing it with multiple applications.  eg having notes for each action/project show up in your reference system, I’m sure you can up with more examples.

So one very radical suggestion would be to just get rid of contexts in Tracks, use the excellent existing tagging system to organise things, and improve the filtering. Though we don’t want to just slavishly copy Things

Slavish copying, with due regard to intellectual property, is exactly what I had in mind

One of the UI niceties of Things is that selecting multiple “tag” buttons at once applies a filter which ANDs these tags; this, together with tag hierarchies, a quick-input Inbox, some Waiting For logic and a menu layout in “Classic GTD” style, would give me much of what I’m after.

That said, I’ve actually stopped using Tracks for now, and gone back to a HipsterPDA until I have another PDA I’m happy with—perhaps an OpenMoko with a longer battery life. It’ll take some interesting technology before the battery life can match the Hipster, though…

@bsag: thanks for the explanations; with a bit of thought, maybe Tracks can still give you what you want while becoming easier to use OOTB as a “vanilla GTD” tool? As a common vocabulary, GTD is pretty rich and well-documented; I’m guessing that implementing your workflow in a tool using that vocabulary might be easier than implenting a more orthodox GTD flow with the current Tracks. We probably won’t really know how this would work out, though,  until someone has a go at implementing it.

—Thomas

Dieter_be - 22 September 2008 04:20 PM

I agree with you on the recurring tasks thing.  This is in fact something the gtd book doesn’t say much about.  But Reinier is implementing recurring tasks, and I’m sure something usable will be coming out of those efforts.

Just to clarify, I do find recurring tasks useful - I was talking about task dependencies, such as making “Paint room” dependent on “Buy paint”, so that the latter must be completed before “Paint room” is actually activated and available.

I would also really strongly warn against ‘bloat’. Particularly with a web app, every feature added (even with really careful optimisation) can make everything much slower to load to the point where it’s painful. So I wouldn’t recommend adding a reference system (beyond the notes we have already) or a wiki. I think those things are the prime examples of features which should be piped into and out of Tracks, despite your points 1 and 2, which are perfectly valid.