Jan 2005 15

The road to Tracks 1.1

It’s funny, but there’s nothing quite like actually using your own application day-in, day-out to give you ideas for improvements and new features. I installed Tracks on a server (at TextDrive), and I’ve been using it every day as my only ‘to do’ list. This experience has been surprisingly positive, but it has certainly highlighted the things which are missing or not done quite right. Other users have also been coming up with some great feature ideas and suggestions, so I thought I’d bring these together and discuss where I see Tracks going over the months ahead. This isn’t an exhaustive list by any means… h4. The big picture

I had two original reasons for developing Tracks. The first was that I wanted to learn Ruby and Rails, and I’ve always found it easier to learn programming with real-world examples. In many ways, I think it’s like learning any foreign language; you can read all the books you like, but you really start learning when your scooter breaks down on the way to Luca and you have to explain—in Italian—to the person who stops to help that you think the spark plugs are gunked up.

The second reason was that I had just read David Allen’s Getting Things Done, and I was keen to put the theory into practice. I tried a number of todo-style applications, as well as hand-rolled text files and scripts, but nothing quite hit the spot for me. So when I started designing Tracks, I had the GTD method firmly in mind. That doesn’t mean that I’m slavishly attached to one way of doing things (in fact, GTD itself is quite flexible in this respect), but I do think that ease of use and speed are vital. If it takes more than a few clicks to add a next action, that’s too much effort. I can see that some improvements could be made here, but my experience so far is that it’s not bad. I keep the ‘home page’ for tracks (todo/list) open in a tab in OmniWeb all the time, and when I want to add something, I just need to switch to the tab, type in a brief phrase for the description, choose a context from the list and hit return (few of my NAs have due dates). As a sidenote for other Quicksilver users, I’ve also taken to pasting the URL of any associated files into the notes field, using Redcloth to make it into a link—you just need to find the file in Quicksilver then type ‘GU’ to select the action ‘Get file URL’, and you can then drag the link onto the notes field to form an URL. This makes it easy to locate files when you come to actually process the action.

I’ve got lots of ideas for new features, but I don’t want to bloat the application or clutter the interface. That’s why I’m planning that any substantial new bits of functionality—particularly if they require a new chunk of user interface—can be enabled and disabled in the settings file. If you don’t need that feature, you don’t have to see it.

The boring bits

This will probably brand me forever as a ‘not a real programmer’, but I find writing error checking routines and bits of validation code boring. I know they are necessary, but I’m always wistfully thinking about all the new, exciting and shiny things I could be coding instead. Still—like eating spinach—it has to be done. So a big priority is going to be to do a lot more validation of the data that users enter, automatic checking of what database format they are using and so on, so that Tracks ‘just works’ transparently. When a problem can’t be fixed automatically, I need to generate more informative error messages. A good example of this would be the settings.yml file. YAML (the language) is rather fussy about the format of the file. Arnaud ran into this problem, and it was tricky to diagnose. A method which automatically checked the format of the file before trying to load it and generated an message that there was a problem with the format of the file would save a lot of time.

More flexibility

There needs to be more flexibility in the way that data is displayed. I had a request to be able to sort the display of contexts. Currently, they are just sorted in the order in which you added them (for me, this happens to be alphabetical order!). I think it would be nice to be able to sort them in an arbitrary order, perhaps with the context you use most frequently at the top. So I’m planning to provide a ‘move up/move down’ button to each item on context/list to allow arbitrary sorting, which will also be reflected on the main page. While I’m at it, I might as well do something similar for projects.

I’d also like to prevent some contexts from being shown on the front page. For example, I’d like to have a ‘wish list’ context, in which I could jot down books, CDs, DVDs or gifts I’d like to buy for other people. But I don’t want that cluttering up the main page; if I could add those items quickly on the main page, and then view them later using a bookmark, that would be perfect. I could do this with another field for each item which indicates whether or not you want to see it on the main page.

Dealing with the future

Pedro made a comment about sorting by due date that I found quite interesting. He said that he would like to be able to sort by due date, because he often enters NAs which have due dates months ahead and he doesn’t want to see them first on his list. At first, I resisted the idea because I feel strongly that due dates should only be one aspect of the importance of an item. I only use them myself when there would be no point at all in doing that action after that date. For example, if I’m going to give a talk at a conference on a certain date, then there’s no point in writing my talk after that date.

However, when I thought about it more, I realised that he had a good point. One of the strengths of the GTD approach is that you can capture everything you have on your mind in a safe place, and thus stop sub-consciously worrying about it. Some of those things—whether they have a due date or not—might not come into play until some time later. You don’t really want them cluttering up your list now, but you do want to be reminded about them at the appropriate time. That made me think about the idea of a ‘tickler file’, in which you can put things to be reminded about in the future. You could add an action and ask to be reminded about it on 1st March 2005. The action would then be held in a ‘Tickler’ context (not shown on the main page) until 1st March, at which point it would turn up in the appropriate context on the main page (and perhaps highlighted somehow, so that you notice its arrival).

Reporting

I find the growing list of completed items very satisfying. But it would be nice to be able to generate some kind of report—perhaps on a weekly basis—of what was completed, and what is still to do. From my own experience, I know that if the report also listed how long uncompleted actions had been sitting around unattended, it would be quite informative (or perhaps ‘shocking’ is a better word), and might help give me the kick I sometimes need to move forward. If nothing else, identifying items which have been hanging arond gathering dust often tells you that you haven’t really identified what the very next action is. In the long term, I’d like to produce fancy graphs of performance, and archive monthly or yearly reports of activity, but this would be a nice first step.

Shiny new features

One thing I’m missing a lot at the moment is a view of my appointments today. I use iCal, and I can easily switch to see it, but it would be much slicker to be able to see the ‘hard landscape’ of my appointments in a simple list on the main page. iCal (and some other calendar applications) use the text-based VCARD format, so it should be possible to suck that information in. If you could also add appointments, that would be super-cool, but I don’t want to get too carried away. I read an article about Webbin’ up by Reid, and was inspired by the idea of having todos, email, calendar and notes all on (or linked to on) one page. Keeping it simple, fast and uncluttered would be the trick, though.

I hope that gives you some idea of the directions I’m thinking about. As ever, if you’ve got any ideas or suggestions, feel free to comment here, on the wiki or by email (butshesagirl at this domain).

32 Comments

In search of a replacement tool for iCommit (a web based GTD tool, free in v2.0, going to paid in 3.0), I (just) installed Tracks. I like what I’ve seen so far, but have not found my Holy Grail just yet. Since this seems to be the thread for requesting features/submitting ideas, here’s my $0.02:

My daily (working) life consists of an ever changing mix of one-off tasks, daily tasks and tasks that are repeated at a variety of intervals. I assume many people could say the same about themselves.

What iCommit has as a great feature is one that is already in the plans for Tracks: the ability to indicate a future time where relevance starts. The GTD equivalent concept is, in a way, the 43 folders mechanism.

What I do for my daily tasks is to not mark them as done, but to nudge the relevance counter to the next day. That makes it drop out of the master view (which is date-specific, defaulting to today), where it re-appears tomorrow.

For regular maintenance tasks, like processing my bills to pay, I nudge them ahead (for example) a week, since it matter less when exactly I do it then it matters that it is pointless to do it for at least a week.

This ties into the GTD ‘philosophy’ because deciding NOT to do something now is just as important as doing something else; both allow you to stop thinking about it at this moment.

My Holy Grail has been for some time to extend this mechanism from days to minutes. I.e. I want to be able to kick something off my list for ten minutes, two hours, half a day, etc. It would reappear by itself, allowing me to focus on the top of the list.

An alternative application of the same infrastructure ties in with ‘calendar’ items: I sometimes know I need to call back someone on a spefic day, but not before 11:30. Until 11:30 on that day, that item does not need to clutter my view. (note that preparation for the call, etc, is a seperate task and ought to be handled as a next action prior to the call itself. It rather depends on how granular you write out your actions)

I hope this makes sense; I’m happy to go into more detail if need be. (I spent enough time dreaming about it to be very specific about use cases smile

Another topic altogether is two comments I wanted to contribute with regards to task dependency.

1. I went around the block designing task-planing tools a few times. The most striking observation that I have made is that if you keep on refining your tool, you eventually end up with MS Project, regardless of your starting point. For all its faults, a lot of common sense and failures alike have gone into its development. If you are working on a design that covers the same ground, you would do well to study MS Project, if only to avoid its mistakes.

2. Keeping track of what tasks depend on the task under view is a real thorny problem. Keeping track of what tasks this depends on (and their satus) is a piece of cake. Since the object for most people (for me anyways) is to determine whether or not a particular task is relevant enought to show in the current context/view/whatever, that might be handled by an algorithm as simple as:
- Am I dependant on anything?
- If so, are all those things done?
- Only then -> show me.

A Rubyish way of putting that would probably be more like an object iterating a ‘Done’ test over its set of dependancies, recursively ANDing the result with the default of True. (Ruby rules. smile

For all I know, someone in the contributor community already figured this out, but hey, you never know if it might help. smile

An additional comment on the ‘reverse view of task depedancy’ I described above is that it could very nicely dovetail with the practice of ‘determining the next action’ as described in the GTD book.

My typical thought process is something like: ‘I need to achieve A. But I need B for that. And I need C for B. And D for B as well.’ The tools I have used so far more or less force you to input D, C, B and A in that order.

It would really streamline my workflow if a tool would allow my to pick anything out of my Inbox, turn it into a Next Action and then note my thought process as above:

- The Next Action from my Inbox would be A.
- The button / pick list / search box / whatever to indicate what task A depends on would also have a ‘Create new’ button/option that would launch me into the Next Task creation screen for B. By going through this step, A has gained a prerequisite task and thus won’t show up in any default view.
- I can repeat this towards C.
- To create D in the same manner, I would need to get into an edit screen for B again.

An optimisation for usability could be to keep the last few items accessed in a clickable ‘Recent’ list as part of the UI. This might be a FIFO stack handed from page to page, but even in a persistent database backed form it need not be a heavy burden on performance.

Schmolle: Thanks very much for your comments. The tickler is actually already implemented in the trunk version of Tracks, so hopefully, that would fulfil your first point. However, it works only on the date when the action should be shown, not the date and time. I’m not sure that we’ll every get to that level of granularity, because it simply wouldn’t be useful for most people.

Re: MS Project. I’ve never used this (I don’t use Windows, and MS Project isn’t available for Mac OS). However, I have used similar project management tools, such as OmniPlan. But project planning is a very different beast to GTD personal task management, so I don’t intend to integrate many project management features (the exception might be task dependencies within a project—see below).

Re: Dependencies: We’ve had a lot of discussion about dependencies over the past few months in comments here, on the mailing list and the forum. The problem isn’t so much how to implement it in the database (that’s fairly easy, as you pointed out), and we already have a ‘state’ column for actions and functions to switch actions between active, hidden/inactive and completed states. The problem is in how to a) allow users to specify the dependencies, and b) to show the dependencies in the UI.

Your ideas in your second comment are interesting, but getting rather complex. The main design goal for Tracks is to keep it as simple and streamlined as possible, so we think carefully about anything that adds a lot of complexity.

I’m really interested in your project.  I stumbled upon it yesterday by accident.  I was actually planning on writing my own GTD app using ruby on rails, but now I think I’ll give this a spin.  Thanks!

My better half has pointed out how useful it would be to have project notes. Currently when we add tasks we put the phone number for the required contacts into the task. If there were project notes then we could put all of the project phone numbers etc into the project notes.

Dave.

Duh… Look and ye shall receive ?

It’s already there and I hadn’t even noticed !

Apologies…

Dave

Greats blog! Thanks for you work.

Name:

Email (not shown on page):

Location (optional):

URL:

Remember my personal information

Notify me of follow-up comments?

Please enter the word you see in the image below: