Thoughts on date implementations in GTD software

[Jeff Templon]

Hi *,

There is a discussion over on the Todoist forums about start dates. During this discussion I recognized a pattern I'd seen before : problems with the meaning and intent of different date types, which lead to (IMO) confusing and in some cases horribly broken date implementations in software. I promised the folk over on that forum that I'd write up something, this seems like an appropriate place to do it -- here goes. What follows is the way I see the various date types, and ways in which they can be used.

The three dates types that I have an opinion about / use for are: 1) due date, 2) start date, 3) scheduled date. I've seen some software with an "end" date, and can imagine how this might be different than a due date, but since I have no personal use for it, and hence no experience with it, I won't discuss it further.

The easiest date type is the "due" date. If I recall correctly, David Allen is quite clear on this one in the book : a due date is really a due date. It is not some "intention" or "wishful thinking", this is a date that, if the task is not finished by then, something bad will happen. My favorite example on this one is tax returns : in the US, that's April 15th. If you don't file your taxes by 15 April at the latest, you could face a fine from the IRS. That is "due".

So here's already an example of the cognitive confusion that arises due to unclear thinking about dates: in Todoist, if you want to change the due date on the mobile app, you press an icon called "schedule" ... I can choose tomorrow, next week, in a month, postpone ... this is NOT a luxury I usually have with something that has a real due date in the above sense. It might happen that the IRS makes a major mistake and decides to give people an extra two weeks. If I make this change in the task "do taxes", I am not "rescheduling" it as the schedule has to do with when *I* want to *do* it ... maybe I don't want to wait until the last day. Maybe as well I will not "postpone" the task, I wanted to do this on April 13th, I had kept that evening free, ok the due date has been changed to 29 April but I will do it on the 13th anyway, the big mistake happens not to affect my return.

What Todoist is really using the "due" date for is what I would call a "scheduled" date ... this is the date on which I plan to execute the task. It may be on the due date, it will for many people be earlier -- maybe you have to work on April 15th during the day, and in the evening there's a party you really want to go to -- this is why you planned to do your taxes on April 13th instead -- before the due date, you scheduled the "do taxes" task for April 13th. Might be something comes up and you "reschedule" the task to April 14th ... you changed when you wanted to do the task, you of course are not in charge of the "due" date, the IRS sets that. I often joke that the "scheduled" date is the "do" date and this is why so many apps confuse it with the "due" date.

The final date is the "start" date, which in some sense is a convenience date -- I find it less necessary than the previous dates, on the other hand for me personally a start date is more important than a scheduled date, as I borrow some elements of Michael Linenberger's method which makes extensive use of start dates.

I use start dates actually in three different senses:

1) the date before which the task makes no sense. For the tax example, the start date would be January 1st as before that, I don't have all the financial data yet -- the year is still in progress.
2) you can use the start date as a 'scheduled' date if your software doesn't have a real scheduled date
3) for tasks where neither 1) nor 2) make sense you have two options. The first is, just leave the start date blank. The second is, if your task manager allows you to sort by start date in reverse order, you can set the start date to the day you entered the task in your system -- this gives you Linenberger's method. When I used Toodledo, this is what i did.

I realized while I was using Things on the Mac -- which does not allow you to sort by start date in reverse order, but does allow you to manually re-order tasks, and also gives you the option to have new tasks added at the top of the list -- this is exactly the same as using Linenberger's method with start dates in the sense of 3) above. See my contribution about this to Michael's blog:

http://michaellinenberger.com/blog/using-mac-things-task-software-and-myn/

I actually prefer to do it without start dates as it reduces the clutter in the task list and reduces the number of meanings the start dates have. And this is one thing I really miss in Todoist : an option to have new tasks added to the top of a list BY DEFAULT. I know I can type "A" instead of "a" to do this in the app, but emails always show up at the bottom, a default would reverse this behavior (emails and 'a' at the top, "A" at the bottom).

So the other thing I'd like Todoist to do, is to implement two dates: firstly a real due date (not the current 'do' date), and secondly my preference would be to have start dates that I could use in senses 1) and 2) above. A feature associated with 1) above is that in the default views (with the exception of "next 7 days"), tasks with start dates in the future would not be displayed. It should also be very easy -- preferably one button click away -- to see the unfiltered view (tasks with start dates in the future shown). This was one of Todo Pro's big mistakes : it took five or so clicks to be able to see the tasks with future start dates, and then another five clicks to hide them again.

I hope this is a valuable contribution to the discussion and to the future development of Todoist -- aside from the somewhat confused and incomplete date implementation, it's a nice product!

JT

 

[Folke]

I am not sure I agree with everything you said there, but with quite a bit. The whole issue gets more convoluted than it would need to be by all the names that app developers and different users toss around for all of these things.

I think it is meaningful to make use these kinds of dates:

1) The earliest date you can consider what to do with this thing, perhaps even do it.
In GTD this is the Tickler date, In apps it is usually their so-called start date or scheduled date you can use for this. The tasks will be "hidden" until that date. (This is what you called start date, type 1)

2) The latest date you can get this done without breaking some agreement or dictate.
I cannot recall whether DA mentions this, but he probably does. In any event I think due date or deadline are appropriate terms for this. (Deadline is actually better, because I have noticed that some people confuse due date with calendar date, 3 below)

3) I fixed date/time that you MUST do something
In GTD this is called calendar action. (I have noticed that some people call it due date, though). Most GTD followers put these calendar actions primarily on their calendar, not in the list app. (Calendar actions are one very limited case use of what you call start date type 2 or scheduled date; see final paragraph below)

In addition, i personally also like a "since date", the date on which I put the item in a given GTD category (Next, Waiting, Someday). (This would be roughly equivalent your start date type 3 above, the "Linenberger" date.)

In addition, some people want to note a date/time on which you need a "forget-me-not" reminder, typically some time before it is too late to start getting it done. This is not described in GTD, but in those apps that have it it is generally called reminder (or sometimes "tickler" - possibly a confused interpretation of 1 above, or total ignorance of the GTD Tickler file). Personally I do not use forget-me-not reminders much at all. They are not very necessary if you review your tasks frequently and adjust their visibility in some way such that you can see them more easily when the timing is getting critical - but that's a matter of taste, I guess. Neither of these methods is GTD by the book.

It is worth noting that in GTD you do not normally use any subjectively "intended" dates at all (e.g. personal target dates or scheduled dates or whatever you would call them) - only external "hard landscape" dates, such as 1, 2 and 3 above. You simply do not make "personal plans" (daily todo lists, weekly schedule etc). You decide what tasks to do continually by making a situation dependent choice from your next actions list(s) and/or from what suddenly happens to you (which may not even be on the list). If you absolutely want to do non-GTD "personal subjective scheduling" I suppose you could consider these to be "phony calendar actions" and threat them as such.

 

[mcogilvie]

For start dates, I just ask "When do I want to see this again?" This covers all of the above, I think, but also covers the typical case where I'm not smart enough to figure out an exact date.

 

[manuelhe]

I also dislike the approach that many apps take about assigning tasks to dates. It does appear at first that it would be an efficient way to remind you about tasks on a daily basis but contexts in the stream of life events often does not coincide with the context necessary in a calendar to get the task done.

I think the problems arises when meaning is ascribed to a date as a type of date. A date is highly contextual and while certain event time-stamps may be similar to one another, there are nuances about their meaning that is embedded in the requirements and context of the "thing"

In my system there are only two types of date (aka time-stamps).

They are "Start" and "End".

This covers everything I need to actually make them work in a calendar and convey no meaning in and of themselves. It can cover a week long blues festival, an hour lunch appointment and a hard and fast deadline. The hard and fast deadline is a special case in that the Start and End are simultaneous.

In my system I embed the meaning of what a date means in the descriptions of my outcomes and actions and the context to which it belongs.

Also, I use dates only when absolutely necessary, following David Allen's advice that dates should be for things that are hardscape; i.e things that cannot be moved. Usually these involve agreements made in coordination with other people.