Schedule as Next, Waiting or Inbox

Nobody else has this either, so don’t worry, but if it is not too difficult to implement something like this before everything is too settled with the app, then there may be a golden opportunity for GTDNext to be the “most GTD” of all GTD apps (except and the most effective of them all when it comes to “scheduled”.

As we all know there is no such thing as “scheduled” in GTD. There is a calendar and calendar actions, of course, e.g. appointments etc, but those we normally keep on our calendar. The closest to “scheduled” in GTD is the Tickler file. This is the “incubator” (DA’s own term) for items that are too early to even consider right now. In GTD these are to be taken to the inbox on the “tickle date”. Getitdoneapp does it exactly like that, and it is of course “very GTD”, but for the majority of us users the majority of tickler items (aka “scheduled” items) we are really quite sure from the very outset that we will want on the Next list (for us to do; the most common case) or on the Waiting list (for others to do, say expect John’s monthly report). Only a minority of our tickler items are such that we will actually need to completely process them from scratch on their “tickle date” (aka “start date”). Many are very stable recurring routine actions, like “send report” or “expect report” or “review contract renewal/termination” etc.

It would be very neat if the task property of being “scheduled” were not considered as a “Type” (Next, Waiting etc) but instead as an entirely separate “on-hold” condition (based on a date), which could be combined with any of the “Type” destinations (inbox. next, waiting …). In other words, scheduled for next, scheduled for waiting, scheduled for inbox.

Most apps take for granted that all tickler items will end up as next actions (or much worse, as fixed calendar actions). This is not seriously bad, though, because at least you have them out of the way until then, and when they arrive in focus on that day you can always consider (“process”) them just like any other inbox item, and move them to Waiting if they are for someone else to do, or trash them if they are not relevant this time round etc. But it would certainly be more efficient and flexible, and sometimes a bit closer to GTD, to pre-designate them to the intended destination straight away, including the inbox.

Concerning calendar actions (a different but related story):

In GTD these are normally kept on a calendar, not on the lists, hence their GTD term, but:

Quite a few people seem to like to keep some of their calendar actions in (or integrated with) their list actions, in the same app. This may be the case if:

  • if the calendar action is a part of a particular project, making it highly desirable to review the whole project in one place
  • if the calendar action is to be done today, in which case keeping a copy in Focus eliminates the need to constantly flick between list and calendar all day long
  • if the user has so many calendars to keep track of manually anyway that one more or less does not matter (e.g. team whyteboards, family calendar by the phone, what have you)
  • if the user is not strictly GTD, and tends to book time slots or specific days with himself/herself for no externally fixed reason at all - just for the sake of making a “schedule” to cling to (aka “daily todo lists”), which is strongly advised against by DA.

To accommodate calendar actions (which would be a nice “luxury” to implement) it might actually be useful to have Calendar as a “Type”. Even after the calendar date arrives these should stay labeled as Calendar actions (not Next actions) (in a different color etc just like the other “Types”). For example, on the Focus list it would certainly be useful to see the difference clearly between such fixed agreed calendar actions (e.g. appointments) from the ones you have chosen to focus on more “dynamically” as per the normal GTD procedure. Having Calendar as a Type would also make it easier for both developers and users if you ever introduce calendar feeds or calendar integration. Then the Calendar Type would separate those particular “dated” items that definitely should be represented on a regular “appointment calendar” from all those regular actions that just happen to have a first possible date (start date) and/or a last possible date (deadline / end date) (e.g. to submit an application), which usually need not be shown at all on a calendar (or if so, usually on a separate “action visualization calendar” that you can switch off or ignore without thereby hiding any appointments or other “true” calendar actions).