gtg-user team mailing list archive

[Tim Sammut <tsammut@xxxxxxxxx>]

Thanks.

To be honest, I don't know that there is only one correct way to
implement this. I think that simplicity is important, and that things
work in a predictable and consistent way for users.

We don't have reoccurring tasks today; so it would seem that most any
implementation would be a large step forward in this particular area.

I will try to get the blueprint updated soonish.

thanks much
tim


On 02/07/2012 06:17 AM, vova wrote:
>> 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 why.
> 
>> Do we need "Due for" to be the next due date for date-based sorting to
>> work correctly.
> 
> 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 "due" too.
> 
> 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 your list.
> 
> Otherwise, recurring is needless at all, because you may just change
> start date.
> 
>> * 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 them.
> 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
> Friday.
> 
>> * 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?