On 22 Aug 2008, at 22:12, Dieter Plaetinck wrote: > Bsag explained her opinion/rationale behind tracks here > http://www.rousette.org.uk/projects/forums/viewthread/62/#151 > but IMO you can not really be a good GTD app by trying to keep > things flexible and general. ( that should be clear if you read all > of the above). So I hope she (and everyone else, of course) reads > and thinks about this, and replies of course :-) Maybe bsags > opinion has evolved a bit over the years? :)
Sorry for the delayed reply -- I seem to have spent most of this summer either away or catching up from various absences! Anyway, people have been asking similar questions on the forum about whether my opinion [1] on Tracks, GTD and flexibility has changed since I posted about it in 2006. The answer might well end up being a rather long one, so the 'executive summary' for those short of time is: "No, not much. If anything, I've (personally) moved away from the canonical GTD method even more than when I posted in 2006." Now for the longer version. [Note: I've made a slightly shorter response on the forum because I was limited to 6000 characters there!] 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 [2], 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 [3] 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. I told you it would be a long explanation! I hope it helps the discussion a bit. However, Tracks is a community product, and there needs to be a consensus on the design and features, rather than me artificially imposing my opinion, which might not work well for the majority. cheers, bsag [1]: http://www.rousette.org.uk/projects/forums/viewthread/62/#151 [2]: http://en.wikipedia.org/wiki/Sisyphus [3]: http://www.culturedcode.com/things/ -- but she's a girl - the weblog of a female geek http://www.rousette.org.uk [EMAIL PROTECTED] _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
