Since Date (in Next, Waiting, Someday)

A Since date would be the date a task became listed (visibly) on the Next, Waiting or Someday lists. Maybe I created the task straight onto that list on that date. Or maybe I dragged it there from somewhere else on that date. Or maybe it became automatically (sequentially) released to that list from a suspended/dependent condition within a project on that date (or became manually released from such a state). Or maybe it arrived from the tickler file (directly or indirectly) on that date.

I always try to remember to write this “since” date down on every task, but it is a lot of work and I often think twice and often forget, and I sometimes swear out loud when I notice that the date is missing. Why?

Waiting is perhaps the most obvious use case. If I asked someone to do something, or ordered something from a supplier, or was informed by someone or some company or authority that I can expect such and such in the near future and later discover that the results have not shown up, I usually want to know since when I have been waiting. My memory often slips me. If it has been too long I might need to consider reminding them or asking them, but if it actually has not been all that long, then maybe I can wait a bit longer. Also, if I do choose to remind them it is always good to have the date of their promise handy (sounds professional, and may make it easier for them to remember what I am talking about and more difficult for them to pretend they never heard of it).

Next is another list where a Since date can be very useful indeed. Here the situation is often the reverse. I may have promised or led someone to believe that I will do something for them reasonably soon, or maybe someone mentioned to me that they expect something, which I made a note of. Later on, when I review my list, I may have forgotten how long it has been since I heard that or made that promise. The “age” of the promise or expectation is one of several important factors that I tend to consider when determining what to do now - the age may impact the task’s urgency or priority to some extent. Another valuable use of the “since” date is while doing a general review. If a task has been sitting on the Next list very long it could be that there is something “wrong” with how it is listed - maybe it does not have the tags it would need; maybe the wording is not clear enough etc.

Someday/Maybe is my list of stuff that I am not sure whether I will ever want or need to do, or will ever have a chance to do. Some of it (a minority, in my experience) can be moved into Next once some hesitation has been eliminated, but most of the Someday/Maybe tasks just sit there and get old, just in case I would want to revive them or if I should ever get that same thought again. The Since date then can be a helpful tool to determine whether something should be moved into some reference file or even be trashed.

Simple Possible Implementation

Most apps have a “scheduled” date (tickler date). For tasks in Next, Waiting and Someday this date field is not used for anything at all. A Since date might be an excellent way to make good use of that “investment” in data space and screen space/layout.

Why a past date - why not a timer?

Now, someone might say “Why don’t you just set a timer for when you need to look at it?” My answer to that is:

  • timers have no past memory. A timer simply does not answer the original question “since when have I had this on my list” and simply does not fulfill the function that a Since date has.

  • all a timer does is it leaves it for you to solve the complex and totally unnecessary riddle "What was I actually thinking back then, whenever it was - I can’t even remember when. Why remind myself today? Was there something special about this particular day of all days? Or was today just an arbitrary day that sounded reasonable at the time I set up the timer?

  • I don’t want to be disturbed by loads of timers going off, especially not since this will typically happen on days that are not convenient or nothing needs to be done yet about that task. Instead, I want my lists organized such that I can easily review whatever I want when it suits me.

A Since date is something I always suggest on app forums, and the suggestion usually meets with quite some approval from fellow users, but developers never pay much attention to this. As far as I know, no app has this. And I think I understand why. Although it is such a simple feature, very much in line with GTD thinking, it goes totally against the more “busy” and “time management” oriented thinking that pervades the industry, even in apps that call themselves GTD, with features such as alarms/reminders, nagging/snoozing, location alerts, target due dates etc etc etc etc etc - in other words features designed to actually escape the fundamental GTD principle of reviewing your lists, and to replace objective facts with premature timing decisions. Conversely, a Since date is an objective and review oriented feature, constantly available whenever you need to review the facts and make an informed decision right there and then.

2 Likes

Interesting idea. One quick clarifying question. Does the date change each time it is moved to one of the lists? Or could a date just be listed somewhere on the edit pane that shows the date the task was created?

Or would / should it look like this?

Date Created:  5/09/2014
On <list name> since: 5/13/14

Hmm. I think there can be several possible ways:

To have it in the edit pane should be good enough, even though I think I just might have a slight preference for having it in the same visible position where you will have the scheduled date for ticklers - but I am not sure, and both are fine.

The original creation date of the “task object” as such is often of little relevance for me as I often “recycle” my tasks (just change the wording, or drag it from next to waiting etc). I think the main “reset cases” are probably the ones I mentioned above:

  • created the task straight onto that list
  • dragged/moved it there from one of the other two lists
  • arrived from the tickler file (directly or indirectly) to this list
  • became automatically (sequentially) released onto this list from a
    suspended/dependent condition within a project (or became
    manually released from such a state)
  • and maybe a manual “reset” would also be useful if I just reword a used “task carcass” and leave it on the same list? No, perhaps not really necessary. In those cases I could just, for example, change it to waiting and then back to next; in just two clicks.

I am very glad you are asking, and are taking your time to think about this. I confess I have not figured it all out myself :slight_smile:

I think the only date needed is the “on list since” (the second one in your example, James).

You don’t want to have too much information showing. And I think being able to sort by “on list since” would be enough for 95% of people. I don’t think there’s very many times where you’d really need to know, “I wrote this down on September 7th” if it was “waiting Since September 10th” or a "next since “September 21st.”

But I really, really like this idea. Helps to see what you may be avoiding. Not strictly a David Allen idea, but one that I think works in harmony with it–what tasks are you freeing from your mind (DA) that you may be trying to put off, which is anti-GTD in spirit, if not in the letter of the book-law. :wink:

Yes, and just to be very clear about a related thing: The since date is definitely not equal to a “last edited” date. We need to have the the full ability to reword tasks, add comments, add and change tags, even move tasks to other projects etc, because none of this really changes the “age” of the task, in the sense “since when has it been possible to get this thing done”.

Quite often the since date will happen to be exactly the date it was created. This will happen every time a newly created task is placed immediately on one of the main “current” lists (Next, Waiting, Someday). But as soon as the task is “inactivated” by being created/moved into the tickler file (scheduled with a start date) or into a sequentially dependent position in a project, then the creation date as such is not of any great relevance, nor is any other form of “since” date. But the very day it gets out of its “freezer” - and is possible to get done - that is the day we would like to track as a since date. (In the case of a tickler file item, this means the scheduled date just changes its name from “start” to “since” on this day, but stays unchanged.)

Final remark: The reason why I also suggest that the moving of a task from one of the three “current” lists to another (e.g. Next to Waiting or vice versa; or Someday to Next) is a matter of convenience more than a matter of principle. It makes it easy to save time by reusing old tasks rather than create new ones all the time. For me, it is quite often the case that I can reuse the same task and ping-pong it many times between lists. For example. I can have a task called “Amend draft contract” on my Next list. I then make some amendments to the most recent draft and send it off, and then simply drag the task to Waiting, while I am waiting for the other party to respond. When after maybe a day or so I receive an amended draft from them the ball is back in my court again, and I then drag the task back to Next. And so on, maybe a dozen times. I only check off the task when the draft has reached a mutually agreed state for signature. I find this convenient, so it would be very nice to have this auto-reset of the since date whenever I drag a task from one “current” list to another. Off-hand, I cannot hand think of any case where this would be undesirable, but I may have overlooked something.

+1 for this suggestion :). Personally, I would prefer to see the “since” date directly in the list view instead of having to click each action to see the “since” date (maybe “display since-date in list view” could be a user preference setting).

1 Like

+2 for this idea. I like the fact of having a date that identifies how long it was on this list. per @trebo, It will help to see what I’ve been avoiding.

I agree that it is a good idea. Otherwise you have to hack the app and use it in anorher way that the developers made it. What I use in NirvanaHQ to get similar result for Waiting for tasks is:

  • I do not use Waiting list and instead of that I use Waiting tag/context
  • if I need to be reminded at some day that I am waiting something from somobedy this day, I create a scheduled tasks with Waiting tag/context.
    I can this way filter all my waiting tasks by context and be reminded at some date. Of course, I can use also Due dates for the same, but if this is not really hard due this day I do not want to use it.
    I would be happy if I do not have to use such hacks…

One way of implementing a since date is almost described here: Scheduled Tasks Functionality Blog Feedback - #5 by Folke

If every task - of any “type” - can have a “start date” (typically used as a scheduled date), and if those tasks that do not have a future start date are given today’s date by default when they are created, we basically have the makings of a “since date” (or actually a “creation date”, but it is a good start.)

This could then be combined with e.g. a manual reset button to today’s date if an old task is reused for another purpose, and with an automatic reset if the task is moved to another “type” (from Next to Waiting etc) or is moved out of “sequential hiding” and becomes visible on these main lists.

And if it is manually set to a future date it will show up in Scheduled (while keeping its “type” such that it can be delivered to the correct list). That’s what a scheduled task is - a task with a future start date.

I like the idea of having a “on list since” date, but I really don’t like the idea of having it view-able in the central pane in the main view. That in my mind is precious real-estate that we don’t want to “clutter” with every possible piece of meta data on the task. I want to keep it as clean as possible with the info you refer to most.

Would it still be helpful to have this “on list since” date in the right “edit panel”?

Yes, @James, for me personally the main value is to actually have this date somewhere (automatically set; minimizes the risk of forgetting to make a note of it), wherever it is located. The display position - main view or task edit view, is of secondary importance. Like @Elurven I would prefer the main view, but the edit pane is fine, too. I’d happily settle for that.

Another thought: It is hard to predict now how much information all in all in the final version is going to be invisible on the main lists (notes, since date, repeat interval settings etc). Maybe at some stage it would be useful to consider having a list toggle between “short view” and “detailed view” (“execution view” vs “review view”). Having “hidden” information of all sorts clearly visible, even if it looks ugly and cluttered, without having to click the individual tasks, is particularly useful when you want to go through the whole list and verify that all settings are correct.

Out of “technical curiosity”, and from psychological UI aspects, what do you think of the idea to use the same “date field” both as a since date and as a scheduled date? In other words, to always have a “start date” field in the task edit pane (just as you also always have a due date field). This start date is automatically set to today’s date when the task is created, then changed automatically when the task is moved onto a new main list or comes out of sequential hiding. And the start date can also be set manually to any date at all, e.g. a future start date, which will block the task from being visible on its “type” list and instead make it eligible for being shown on the Scheduled list. It seems to me that this is a good way to “economize” with date fields, and it also opens the door for controlling onto which of the “type” lists a scheduled task will show up (an often requested feature). It is already “typed” correctly; the “scheduled” property is implicit from the fact that the start date is in the future, not in the past. The Scheduled list would show tasks of all “types” that have a future start date. This also means that Scheduled as a separate “type” is no longer needed, and the existing “blue type” can instead be used for Calendar, “fixed doing date”, which would be a very useful distinction to make e.g. on the Focus list (appointments vs other focused tasks). In other words, there would seem to be three valuable user features that come almost for free by simply making full use of the “start date”. What are your thoughts on this?

It’s an interesting idea. The way I understand the problem is that people often can’t remember how long ago they added a task or moved it to a particular list. Having this date visible would help them “get more done”.

The way I understand your proposed solution to that problem is to use the existing start field and just update it every time a task is moved to a new list.

There are a couple of challenges I see with this approach.

  1. The method breaks down if you ever decide to create a start date in the future for the task and put it on the scheduled list. I will no longer have a place to keep track of when the task was first created or moved to a list, because the field is now being used to track when to place the task back in my active list.
  2. I think the use of a single field for two purposes (keeping track of date created/moved and scheduling it for the future) will be difficult for many users to understand. It would also probably require us to have a huge label for that field, to explain it’s use, which we really don’t like to do.

That’s how I see it anyway. Thanks as always for your ideas!

James

That is true. But as far as I am concerned that does not matter in the least. The since date will get rewritten all the time anyway if I move it from one list to another etc. It can never be trusted as a true creation date, neither does it need to be. I don’t need to know the creation date. Nor the date on which I originally made the task “scheduled”.

For scheduled tasks I have the date that it will become possible to do something about it. For the “asap” tasks - Next, Waiting, Someday and Inbox - I need the since date to tell me when it did become possible for me to do something about it. That’s all I need - to know since when it has been possible for someone (often me) to get this thing dealt with. If I schedule something it is because it cannot be dealt with until that date - the task’s scheduled date will be the task’s since date when that day comes.

I think probably the main instances when the since date should be set/reset will be:

  • when a new task is created from scratch (creation date)
  • when a task comes out of sequential hold (or other similar “inactivity”) and becomes visible on the main lists (previous date overwritten)
  • when you drag/move a task from one “type” (Next, Waiting, Someday, Inbox) to another of these types (previous date overwritten)
  • when you manually reset (or even set) the since date after having made a mistake or decided to reuse a task as a template for a new task (previous date overwritten)
  • if separate date fields are used for since and scheduled, then also when the task reaches its scheduled date (previous since date overwritten; the task became possible to deal with from this this scheduled date = today.)

Possibly. There are so many different kinds of users. But I think it is pretty intuitive that a “Start date” can be ether the date I did start it or will start it - same thing, sort of.

Toodledo is quite a popular app that uses the same date field, called Start date, in both of these senses. You can set it to default to today’s date for new tasks (creation date), and you can hide/show future tasks (scheduled). People do not seem to have any problems at all with that. But Toodledo has no automatic reset when you move it from one place to another etc, so it is not quite the automated since date we have discussed here, but a combination of a manipulable creation date and a scheduled date. (Some people even use it as a way of getting their tasks “manually” sorted.)

What is your opinion of the “free” user benefits of this approach?:

  • user controlled destination list for scheduled tasks (e.g. will start waiting for monthly report on the 1st)
  • good visibility in the Scheduled list between all the “types” (your nice colored backgrounds)
  • clear visual distinction, even on the scheduled date when you have it on your Focus list, between GTD Calendar actions, e.g. appointments, which really did have to happen that day, and any other scheduled tasks (GTD Tickler file items) that only became “possible to consider” on that day but are not necessarily predetermined to be dealt with on that particular day
  • and of course the since date itself, all in one :slight_smile:

Well … I’ll leave that to you

What’s the status now for the “since date” (“historic start date”)?

I have noticed that a creation date has been introduced - kudos - but this date only coincides with the “since” date for newly created tasks on the Next, Waiting or Someday lists.

For other cases, the “since” date would need to be adjusted to today’s date in some situations in order to show since when the task has been just “sitting” unattended despite being ready for being dealt with. Such automatic re-setting of the since date would need to occur when:

  • when a scheduled task is "released or “spawned”. (The task has only been “unattended” only since its start date because before that date it was impossible to do anything about the task.)
  • when a sequential task is “activated” (made visible on one of the main lists). (The task has only been “unattended” since the date its predecessors had been completed because before that date it was impossible to do anything about the task.)
  • and, ideally also, if possible, when a task is reused/moved to another list, and/or (perhaps safer):
  • when the user sets the since date manually to today’s date (or some other date)

For my personal needs and uses, a since date is a very useful and important date to have available. But a creation date as such is nothing I have ever felt a need for at all. If you want to reduce the number of UI elements, maybe you could offer the user a preference setting for which of these two “modes” the user wants to use for the creation/since date (creation = fixed; since = reset as per the above)? Or, you could used the “scheduled” start date with historic dates for the “since” feature. Either is fine. I prefer the second (seems “cleaner”, more “economical”.)