gtg-user team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Le 20/02/12 04:46, Tim Sammut a écrit :
> 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.

Be careful with that reasoning. Any implementation might make the
standard "one task" case harder. If the task editor is more confusing,
this would make GTG a *lot* harder to use. (from the perception point of
view).

This is why this feature takes so much time. We are very careful here in
order to stay at least as good for the majority of use case while
allowing more use cases.

Once this will be settled, everybody will look at the design and think:
this was trivial, why did it take so much time? But this is UX. When it
looks trivial, it means you've won and you've worked hard for months.
(the fact that nobody is able to come up with a mockup which can, at
least, be the start of the discussion, is particularly revealing of the
complexity of the problem. Or did I missed some mockups? ).

Lionel

>
> 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?
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-user
> Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-user
> More help   : https://help.launchpad.net/ListHelp