The road to Tracks 1.1
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).
Filed under: communication development
)
Site RSS
Sun, 16 Jan 2005 @ 14:57 ¶