gtg-user team mailing list archive
Mailing list archive
Re: Reoccurring tasks blueprint
I can see that too. If we need a date at which a series of reoccurring
tasks ultimately ends, I think it should be a separate date, perhaps
called "Reoccurs until". And actually, being able to specify when a
repeated task ends isn't mentioned in the blueprint. I left it out for
simplicity, but I think it might be required.
Hm, I don't really get it. I always think that when people use repeated
tasks they don't need set different start and due for one instance, i.e.
instead of set one instance which starts each Saturday and ends each Monday,
I would set three instance for each of these three days. Below I explain
Do we need "Due for" to be the next due date for date-based sorting to
But if task appears today I should do something with it *today*, shouldn't
I? So what's the point?
Task "Cleaning kitchen" repeats on every Friday. What should be
the content of "starting on"? "Due for"?
This example show forever-type-of-task, I would say, so it doesn't need
"start" and "due".
But let's see another examples:
1. Studying, you learn a subject for one semester each Wednesday - here are
"start" and "due", i.e. when semester starts and ends.
2. Work, doing some project for client for one month - here are "start" and
You may object that these examples doesn't need recurring (especially second
one), but the magic is that when you use recurring it's easy to track what
you've done today and what you must to do.
Look, how you work on project? You did something (i.e. part of a task) and
think "well, I made a good work and will continue this project tomorrow",
but the task still in your list, so you must change start date to remove it
from list and focus on other tasks/projects. But using recurring you may
just check it as "done", because you know that in next time you'll see it in
Otherwise, recurring is needless at all, because you may just change start
* if not, when exactly should be a task shown in browser? When hitting the
start date? After marking a previous instance as done/dismissed? In
advance 1 day? In advance 2 days? X days? How to chose X?
Well, I think we need a special section for repeated tasks, i.e. if user
done or dismissed current instance, s/he may want to edit this task for
changing next instance, so s/he open section "Repeated tasks" and see all of
It won't mess main list and provide simple interface for planning/changing.
And, I'm sure, that instance should appear in main list on date when it
should be done, i.e. in your example with cleaning kitchen - should be
* What to do if I don't do the previous task? Should I show both of the
tasks? Remove undone task?
This is interesting and hard question, in my view... Perhaps, make it as
option, and user may choose preferred one?