Removing 'tasks in view' functionality?
Simon Paquet
I would like to start a discussion on the potential benefits and
downsides of our 'show tasks in view' feature.
This feature is currently implemented in the following way:
- tasks with a start date and a due date are shown in *all* the views
- tasks with a start date, but no due date are shown in month view and
multiweek view, but *not* in week view and day view
- tasks with a due date, but no start date are *not* shown in any view
- tasks without due date and start date are *not* shown in any view
The benefit of this is, that certain types of tasks can be seen in the
views and the views can function as the main management area for all your
events and tasks.
The downside is obviously that not all tasks are shown, which is highly
confusing for most users. Just look at the various bug reports, the
dozens if not hundreds of questions here, in mozilla.support.calendar or
in other support forums to get a good impression for that.
When we implemented this, we didn't have a task view and the
unifinder-todo only offered a very basic task-related functionality. Now
we have task view (in Lightning and hopefully in Sunbird as well for
0.9), which can function as the main management area for tasks, so I
would propose, that we remove this functionality to reduce user confusion
and streamline our UI.
I would appreciate your comments!
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Archaeopteryx
event views so that you can't see them unified. Ssitter pointed to the
unclear definition of tasks (in the past), a good example for a this is
the implementation of start and end times for tasks which has no
"all-day" option. From my perspective (and which I think most users use
which use calendars to put together their agenda):
- The (current event) pane view is used for planning when to do
something and available time frames.
- Subscribed calendars are used to see interesting events or events
which need my presence/action/etc and I copy them to a personal calendar
- The task list is used for managing the ongoing todo items.
So finally, tasks should be in the pane view like events (maybe with a
checkbox to enable/disable the presence of events/task/all) and tasks
should be more eye catching.
Archaeopteryx
Bas van den Bosch
> So finally, tasks should be in the pane view like events (maybe with a
> checkbox to enable/disable the presence of events/task/all) and tasks
> should be more eye catching.
I agree, the option to show tasks in view should stay, I don't think
this has to be enabled by default and we can move this to the preferences.
- tasks with a start date and a due date are shown in *all* the views
This should stay
- tasks with a start date, but no due date are shown in month view and
multiweek view, but *not* in week view and day view
If these tasks have no due date, imho they should only be shown on the
startdate (otherwise one would have everlasting allday-events).
- tasks with a due date, but no start date are *not* shown in any view
I think tasks which have a due date should automatically get a startdate
which defaults to the creation-time in the task-editor. If the users
chooses to unset the starttime, it should only be shown on the enddate.
- tasks without due date and start date are *not* shown in any view
This should stay
As for the weekview and dayview I think tasks with only a due or
start-date should be shown as a single line at the specific time with an
icon (like we have on events with alarms now). Tasks with start and due
time should be shown as events with the task-icon. Multiday tasks should
appear as allday events in all three views.
gr
Bas
Prasad Sunkari
>
>> So finally, tasks should be in the pane view like events (maybe with a
>> checkbox to enable/disable the presence of events/task/all) and tasks
>> should be more eye catching.
>
> I agree, the option to show tasks in view should stay, I don't think
> this has to be enabled by default and we can move this to the preferences.
>
> - tasks with a start date and a due date are shown in *all* the views
> This should stay
>
> - tasks with a start date, but no due date are shown in month view and
> multiweek view, but *not* in week view and day view
> If these tasks have no due date, imho they should only be shown on the
> startdate (otherwise one would have everlasting allday-events).
The ambiguity lies in the fact that the due date is optional, but at the
same time more important than the start date. It would be a lot
confusing to the user when the tasks are shown at the due date (in the
first case) but at the start date in the second case.
IMHO it could make more sense to show only tasks that have a due date in
the calendar views. Showing some on the due date and some other at the
start date could be confusing to the user.
>
> - tasks with a due date, but no start date are *not* shown in any view
> I think tasks which have a due date should automatically get a startdate
> which defaults to the creation-time in the task-editor. If the users
> chooses to unset the starttime, it should only be shown on the enddate.
The same argument holds. If we show tasks in the calendar views, all
tasks should either be shown at the start date or at the due date.
>
> - tasks without due date and start date are *not* shown in any view
> This should stay
>
> As for the weekview and dayview I think tasks with only a due or
> start-date should be shown as a single line at the specific time with an
> icon (like we have on events with alarms now). Tasks with start and due
> time should be shown as events with the task-icon. Multiday tasks should
> appear as allday events in all three views.
>
Just like the all day events space, should there be a special space for
the tasks? I am not sure, its just a random thought.
Michiel van Leeuwen
> When we implemented this, we didn't have a task view and the
> unifinder-todo only offered a very basic task-related functionality. Now
> we have task view (in Lightning and hopefully in Sunbird as well for
> 0.9), which can function as the main management area for tasks, so I
> would propose, that we remove this functionality to reduce user confusion
> and streamline our UI.
You separate the management of events from the management of tasks. But
I think that users are not managing those two separately, they are
managing their time. Therefore, I think that both classes of things that
take time (events and tasks) should be shown in one single view, the one
most use to manage time: the main views.
If there are bugs in the way tasks are shown in the view, those bugs
should be fixed, instead of the feature being removed.
Michiel
ovidiu
> Bas van den Bosch wrote:
>>
>>> So finally, tasks should be in the pane view like events (maybe with a
>>> checkbox to enable/disable the presence of events/task/all) and tasks
>>> should be more eye catching.
>>
>> I agree, the option to show tasks in view should stay, I don't think
>> this has to be enabled by default and we can move this to the
>> preferences.
as they are both calendar/time management related.
Second, I think it should not be enabled in preferences, but rather
having an obvious button (or check, but then it should be in an
important position close to calendar view), precisely to reduce the
confusion. More, I see the need to visually distinguish events from
tasks (in same view) to a point where one is rectangular and another has
rounded corners (for example) so that it is immediately understood. I
mean from a glimpse, not like using small icons in a corner.
>>
>> - tasks with a start date and a due date are shown in *all* the views
>> This should stay
>>
>> - tasks with a start date, but no due date are shown in month view and
>> multiweek view, but *not* in week view and day view
>> If these tasks have no due date, imho they should only be shown on the
>> startdate (otherwise one would have everlasting allday-events).
>
> The ambiguity lies in the fact that the due date is optional, but at
> the same time more important than the start date. It would be a lot
> confusing to the user when the tasks are shown at the due date (in the
> first case) but at the start date in the second case.
>
> IMHO it could make more sense to show only tasks that have a due date
> in the calendar views. Showing some on the due date and some other at
> the start date could be confusing to the user.
"event" in a task), but also those who don't have a due (start or no
start) can be shown *along* with allday-events . I would see this as a
solution to the current "not showing all tasks in cal" and if there is a
problem with "everlasting event", it could be shown only in today.
I think this is a delicate thing (and approach) and finally the idea is
to try to get those closer to the logical behavior. For example, I
considered "the due date" to be 'the event in a task', or the "task with
no due" to be an 'all day event'. This may be only my POV, but I think
the approach should follow this kind of logic in defining elements and
views.
>
>>
>> - tasks with a due date, but no start date are *not* shown in any view
>> I think tasks which have a due date should automatically get a startdate
>> which defaults to the creation-time in the task-editor. If the users
>> chooses to unset the starttime, it should only be shown on the enddate.
>
> The same argument holds. If we show tasks in the calendar views, all
> tasks should either be shown at the start date or at the due date.
Agreed again. I would opt for due [read above] and I agree with "auto
start date" if you define an end date. Following my proposal above, I
wonder if is better to show those with *no* start on the end or as "all
day" till the end.
>
>>
>> - tasks without due date and start date are *not* shown in any view
>> This should stay
As above (and above above), I think those should be shown as "all day"
(even if only today, for economy.. ) for the sake of showing all task
and for the sake of consistency.
>>
>> As for the weekview and dayview I think tasks with only a due or
>> start-date should be shown as a single line at the specific time with an
>> icon (like we have on events with alarms now). Tasks with start and due
>> time should be shown as events with the task-icon.
again, I would like it more visually distinguished. (rounded vs square
or different border, dotted vs solid, or different background gradient etc)
>> Multiday tasks should
>> appear as allday events in all three views.
>>
>
>
> Just like the all day events space, should there be a special space
> for the tasks? I am not sure, its just a random thought.
>
maybe a special all day space for tasks is a good idea, considering the
limited space .. I like it in the perspective of asking for a more
visual separation.
Conclusion, I think tasks should stay and there is to be "fixed" the way
it shows. And if the thing with views grows to the point of getting some
stuff on a wiki or another pic samples, is even better ..
--
ovidiu
Pete
> IMHO it could make more sense to show only tasks that have a due date in
> the calendar views. Showing some on the due date and some other at the
> start date could be confusing to the user.
I agree with that. Consider a company calendar with tasks that you
didn't create. With the proposed behavior you would know that tasks
only appear on due dates in the views. This would also make it more
consistent with the proposed task list in the Today Pane which seems to
also be based on due dates:
NO DUE DATE
TODAY
TOMORROW
SOON
I suppose that people want to see a task in the views on the start date
so they know when a task starts. However, I suggest that this might be
better handled in the Today Pane with another section such as "Started".
For example:
NO DUE DATE
STARTED
TODAY
TOMORROW
SOON
A task could be shown in the "Started" section in the Today Pane until
it fits into one of the other sections. This would be nice for tasks
that start several weeks before they're due. For example, if a task has
a start date of 1 Apr 2008 and a due date of 20 Apr 2008:
On 1 Apr 2008:
STARTED
* My Task
TODAY
TOMORROW
On 19 Apr 2008:
STARTED
TODAY
TOMORROW
* My Task
Simon Paquet
>> When we implemented this, we didn't have a task view and the
>> unifinder-todo only offered a very basic task-related functionality. Now
>> we have task view (in Lightning and hopefully in Sunbird as well for
>> 0.9), which can function as the main management area for tasks, so I
>> would propose, that we remove this functionality to reduce user confusion
>> and streamline our UI.
>
>You separate the management of events from the management of tasks.
Exactly. They are totally different and should be treated as such.
>But I think that users are not managing those two separately,
What makes you think so?
>they are managing their time.
Sure. And we give them two totally different options for that.
Looking at other applications (Outlook, iCal, Evolution, KOrganizer), all
of them separate tasks and events. We don't.
That's fine, if we have a compelling reason for this UI decision, which
we don't. And to make it even more serious, we confuse users by moving
away from the accepted application logic.
>Therefore, I think that both classes of things that take time (events and
>tasks) should be shown in one single view, the one most use to manage
>time: the main views.
I would like to hear your thoughts on how to display
- tasks with a start date, but no due date are shown in week and day view
- tasks with a due date, but no start date in all views
- tasks without due date and start date in all views
You can't just say that someone's solution to a problem is wrong. You
need to propose a better solution. I don't see this in this thread.
>If there are bugs in the way tasks are shown in the view, those bugs
>should be fixed, instead of the feature being removed.
These are not bugs. There's simply no good way to display those types of
tasks in the views, which is why we have never done it.
If there's a solution now, great, tell us about it!
Simon Paquet
>The issues show be motivation to fix them and not to split task and
>event views so that you can't see them unified.
Great, let's hear your solution to the problem. I already proposed mine,
but didn't see yours.
Simon Paquet
>> So finally, tasks should be in the pane view like events (maybe with a
>> checkbox to enable/disable the presence of events/task/all) and tasks
>> should be more eye catching.
>
>I agree, the option to show tasks in view should stay, I don't think
>this has to be enabled by default and we can move this to the preferences.
>
>- tasks with a start date and a due date are shown in *all* the views
>This should stay
>
>- tasks with a start date, but no due date are shown in month view and
> multiweek view, but *not* in week view and day view
>If these tasks have no due date, imho they should only be shown on the
>startdate (otherwise one would have everlasting allday-events).
>
>- tasks with a due date, but no start date are *not* shown in any view
>I think tasks which have a due date should automatically get a startdate
>which defaults to the creation-time in the task-editor. If the users
>chooses to unset the starttime, it should only be shown on the enddate.
This runs contrary to the notion of what a task is. If a user wants to
complete a task by a given date, he may do that today, tomorrow or any
time between now and his given due date.
Altering his data is therefore the wrong approach. We only do that if a
user´choose an illegal action (e.g. start time is after end time). We
don't do that on totally valid data.
>- tasks without due date and start date are *not* shown in any view
>This should stay
Great! So we keep the user confusion?
Is it just me, or is everyone in this thread except me not concerned
about ur confusing UI in this situation? I haven't read a single posting
here, that acknowledges the issue at hand and proposes a solution that
solves this issue.
I did propose a solution. You may not like it. That's totally fine with
me. But we need to discuss solutions here, nothing else.
Thomas Stache
> - tasks with a start date and a due date are shown in *all* the views
> - tasks with a start date, but no due date are shown in month view and
> multiweek view, but *not* in week view and day view
> - tasks with a due date, but no start date are *not* shown in any view
> - tasks without due date and start date are *not* shown in any view
>
For those not breathing Calendar day-in and day-out, could someone
explain what the intended use of the start date is, and what the listed
combinations mean (for the app, or the engineers back then)? It would
probably help to establish a common baseline for the discussion...
From using my Palm I'm only used to the due date, PalmOS never had two
dates for a task.
Thanks.
ovidiu
> Michiel van Leeuwen wrote:
>
>
>>> When we implemented this, we didn't have a task view and the
>>> unifinder-todo only offered a very basic task-related functionality. Now
>>> we have task view (in Lightning and hopefully in Sunbird as well for
>>> 0.9), which can function as the main management area for tasks, so I
>>> would propose, that we remove this functionality to reduce user confusion
>>> and streamline our UI.
>>>
>> You separate the management of events from the management of tasks.
>>
>
> Exactly. They are totally different and should be treated as such.
>
>
>> But I think that users are not managing those two separately,
>>
>
> What makes you think so?
>
>
>> they are managing their time.
>>
>
> Sure. And we give them two totally different options for that.
>
> Looking at other applications (Outlook, iCal, Evolution, KOrganizer), all
> of them separate tasks and events. We don't.
>
> That's fine, if we have a compelling reason for this UI decision, which
> we don't. And to make it even more serious, we confuse users by moving
> away from the accepted application logic.
>
>
"inegrated view". And I don't think is a small thing.
Let me explain: initially it was a workaround for not having the agenda
view. Now, if you didn't had it, maybe it would have come to a moment
when it would have been added as a "step forward" or a "extra feature"
in comparison to others. If already having it why to remove it (and add
it later)? To deal with confused users, I think only minor UI needs to
be changed, visually separating better and having all in view. (But I
detailed my point in another subthread ..)
I say this while I see integration with other data as a possible long
term goal. And if so, task and events is an immediate one. [Take for
example gcaldaemon which gets rss inside cal. Or think of the timeline
experiment inside seek extension (I know, different tech, but the idea
...)] Meaning I think of a calendar grid as a "view" for various data in
future.
Well, that is a personal POV
--
ovidiu
ovidiu
> Bas van den Bosch wrote:
>
>> - tasks without due date and start date are *not* shown in any view
>> This should stay
>>
>
> Great! So we keep the user confusion?
>
> Is it just me, or is everyone in this thread except me not concerned
> about ur confusing UI in this situation?
that this is the very issue [the ui ..] and not the tasks in view just
like that.
> I haven't read a single posting
> here, that acknowledges the issue at hand and proposes a solution that
> solves this issue.
>
>
Sorry, I proposed a solution in reply to Prasad Sunkari, but I'll state
again if that was not the appropriate way.
I see tasks with no dates as "allday" events (and if not to fill the cal
view with infinite all day, it can be displayed only in today).
This may apply also to tasks
-with *no due* date and a start
-with *due*, without start -untill the due
There was an idea about a separate "all day" space for tasks there,
also.( Which, again, shows concern for UI confusion .. ;) )
That was just the immediate idea that popped. I may come up with others
if the "all day" doesn't seam correct. I was thinking of the unifinder,
but I don't have a clear idea yet so didn't throw a general "search or
unifinder may be an alternative ..". I'm still thinking (still concerned
..) and will get back.
ovidiu
> Simon Paquet schrieb:
>> - tasks with a start date and a due date are shown in *all* the views
>> - tasks with a start date, but no due date are shown in month view
>> and multiweek view, but *not* in week view and day view
>> - tasks with a due date, but no start date are *not* shown in any view
>> - tasks without due date and start date are *not* shown in any view
>>
>
> For those not breathing Calendar day-in and day-out, could someone
> explain what the intended use of the start date is,
that he can eventually say "watta hek took you so long .." :). Now
seriously, the deadlines are more important, but the start is also
needed for project management issues. The simpler example is that some
tasks cannot be worked on before a certain date. Think like "I don't
have that problem until next week"
> and what the listed combinations mean
- [o] start date [o] due date
clear period of time to do it
[example: buy something next week; only monday have the money, but wanna
get it till friday]
- [o] start date [x] due date
some have a certain start (can't perform before a date) but no deadline
yet. can also add a deadline later ..
[example: same as above but no deadline yet. example 2: marriage .. :)]
- [x] start date [o] due date
this is the most common. it is about setting deadlines ..
- [x] start date [x] due date
general tasks, "when I'll get the time for it" like
> From using my Palm I'm only used to the due date, PalmOS never had two
> dates for a task.
I think various devices have implementations aiming to be as simple as
possible. But that is not the same in a computer one. maybe it is the
case for putting an emphasis on certain elements while leaving others as
advanced options (like those apps that have a "details" or "more"), but
that may be just to free some space or for the speed of usage, but not
like is useless.
Simon Paquet
>> I haven't read a single posting
>> here, that acknowledges the issue at hand and proposes a solution that
>> solves this issue.
>>
>Sorry, I proposed a solution in reply to Prasad Sunkari, but I'll state
>again if that was not the appropriate way.
>
>I see tasks with no dates as "allday" events (and if not to fill the cal
>view with infinite all day, it can be displayed only in today).
>This may apply also to tasks
>-with *no due* date and a start
>-with *due*, without start -untill the due
>
>There was an idea about a separate "all day" space for tasks there,
>also. (Which, again, shows concern for UI confusion .. ;))
I forgot to add an important aspect in my original post. In 0.9 we will
likely have the today pane available in calendar and task view as well.
So then we will have an integrated display of events and tasks. They are
just not fully integrated into the views. IMO this would allay most of
the fears that some people have right now.
Simon Paquet
>> - tasks with a start date and a due date are shown in *all* the views
>> - tasks with a start date, but no due date are shown in month view and
>> multiweek view, but *not* in week view and day view
>> - tasks with a due date, but no start date are *not* shown in any view
>> - tasks without due date and start date are *not* shown in any view
>
>For those not breathing Calendar day-in and day-out, could someone
>explain what the intended use of the start date is,
You have a task with a clear start date, but you do not know when you
might finish the task. This is relevant in a project management context,
where you might start a task at a certain date, but the end date is
unclear, because it depends on the completion of another task.
>and what the listed combinations mean?
Sure.
|- task with a start date and a due date
That one is pretty simple. The task has a defined start and end date, so
know you when you need to start working on the task and when it must be
finished.
I would use this, if I needed to get a task done in a certain timeframe,
e.g. an action like "Review document XYZ" would be a task, if I need to
review the document during the next week (start date: 2008-04-07 08:00;
end date: 2008-04-11 17:00) and I know that I won't get the document
before Monday morning.
For me personally, I use this only if the timeframe is longer than a day
and I am doing other stuff during this timeframe as well. If I would
reserve 2-3 hours for the document review exclusively, that would be an
event for me, not a task.
|- task with a start date, but no due date
See above
|- task with a due date, but no start date
This one is pretty similar to the "task with a start date and a due date"
thing with the exception, that I do not know when I might be able to
start working on this.
So if my boss would tell me "I will send you document XYZ sometime during
the next week and I need you to review it by Friday" I would give this
task a due date, but no start date, because I might the document on any
day of the next week.
|- tasks without due date and start date
That one is pretty simple as well, you either don't know the start and
end date or you don't care about them. So a task "Review document XYZ"
without start and end date would mean that you either don't know when you
need to start and finish working on this or that the task is just not so
important and that can you can review the document anytime during the
next few days/weeks as long as you do it sometime.
Michiel van Leeuwen
> Michiel van Leeuwen wrote:
>
> Exactly. They are totally different and should be treated as such.
>
>> But I think that users are not managing those two separately,
>
> What makes you think so?
>
>> they are managing their time.
>
> Sure. And we give them two totally different options for that.
But that's wrong! When somebody ask me if I have time to do some job for
them, I need to look into a calendar to figure that out. Then I need to
look at events and tasks. I might not have many events at a given day,
but a whole lot of open tasks. Or it might be the other way around. Time
if filled by both things.
> I would like to hear your thoughts on how to display
I'm not going to given them :)
I would like to finish the discussion on whether tasks should be
displayed before discussing how they should look like.
Michiel
Simon Paquet
>>> You separate the management of events from the management of tasks.
>>
>> Exactly. They are totally different and should be treated as such.
>>
>>> But I think that users are not managing those two separately,
>>
>> What makes you think so?
>>
>>> they are managing their time.
>>
>> Sure. And we give them two totally different options for that.
>
>But that's wrong! When somebody ask me if I have time to do some job for
>them, I need to look into a calendar to figure that out.
This will be possible in 0.9. once Sven Giermann has implemented the
today pane for the other modes as well. Then you can take a look at your
events in your favorite view and look at your tasks on the right side in
the today pane.
>Then I need to look at events and tasks. I might not have many events at
>a given day, but a whole lot of open tasks. Or it might be the other way
>around. Time if filled by both things.
I agree, but both types of actions are vastly different. Tasks are much
less time-related than events, where the start and end date is mandatory
(for tasks it is not).
It is therefore far from optimal to push tasks into a time-based display
like our views. It raises issues and user confusion (as described here in
the thread), which you fail to acknowledge.
>> I would like to hear your thoughts on how to display
>
>I'm not going to given them :)
That's what I expected :-)
>I would like to finish the discussion on whether tasks should be displayed
>before discussing how they should look like.
You can't divide those two decisions.
My proposal is based on the sub-optimal display of tasks in the current
views. To solve the issues that I describe, there are only two possible
solutions:
1. Remove the "tasks in view"-feature
2. Propose a solution for displaying all tasks in the views adequately
IMO there's no adequate solution for option 2, which is why I favor
option 1.
I'm fine with you opposing option 1. But if you are, then I'm expecting
something for option 2 from you. You can't get one without the other.
ovidiu
> ovidiu wrote:
>
>
>>> I haven't read a single posting
>>> here, that acknowledges the issue at hand and proposes a solution that
>>> solves this issue.
>>>
>>>
>> Sorry, I proposed a solution in reply to Prasad Sunkari, but I'll state
>> again if that was not the appropriate way.
>>
>> I see tasks with no dates as "allday" events (and if not to fill the cal
>> view with infinite all day, it can be displayed only in today).
>> This may apply also to tasks
>> -with *no due* date and a start
>> -with *due*, without start -untill the due
>>
>> There was an idea about a separate "all day" space for tasks there,
>> also. (Which, again, shows concern for UI confusion .. ;))
>>
>
> I forgot to add an important aspect in my original post. In 0.9 we will
> likely have the today pane available in calendar and task view as well.
>
> So then we will have an integrated display of events and tasks. They are
> just not fully integrated into the views. IMO this would allay most of
> the fears that some people have right now.
>
> Simon
>
(Simply, this resolves having both on screen, but there may be a case
about time some task occupies.)
ovidiu
> Michiel van Leeuwen wrote:
>
>
>>>> You separate the management of events from the management of tasks.
>>>>
>>> Exactly. They are totally different and should be treated as such.
>>>
>>>
>>>> But I think that users are not managing those two separately,
>>>>
>>> What makes you think so?
>>>
>>>
>>>> they are managing their time.
>>>>
>>> Sure. And we give them two totally different options for that.
>>>
>> But that's wrong! When somebody ask me if I have time to do some job for
>> them, I need to look into a calendar to figure that out.
>>
>
> This will be possible in 0.9. once Sven Giermann has implemented the
> today pane for the other modes as well. Then you can take a look at your
> events in your favorite view and look at your tasks on the right side in
> the today pane.
>
both event and task on screen" is somehow resolved, but we have to see
if that is the only concern of a user. I think, considering this whole
thread, that there may be little differences in the way people (at least
in discussion) see tasks vs events, as the very basic definition.
Meaning these: first, users state here rather personal approaches and
understanding (I do, at least in cal issues) and second, defining task
vs event is kinda fuzzy, (if people are already using them in a way,
they will likely see it that way regardless of theory).
>
>> Then I need to look at events and tasks. I might not have many events at
>> a given day, but a whole lot of open tasks. Or it might be the other way
>> around. Time if filled by both things.
>>
>
> I agree, but both types of actions are vastly different. Tasks are much
> less time-related than events, where the start and end date is mandatory
> (for tasks it is not).
>
common holidays, but also like a meeting, while a *task* is an element
that *needs action from you*. That is one thing, the other being the way
they are defined in time. Events are simple, tasks are not so clear how
to define in time. But, at least some, they are defined in time.
You said in another post that you use tasks with start and end when they
go in parallel with other stuff. If to spend time only for that process,
you will make it an event. Well, that is another attribute in the
definition of a task, having it along or not with others. In this case,
may look like possible to remove tasks from cal, but this may lead to a
new kind of confusion if users are not aware/informed of this approach.
I always plead for the need to guide and teach users in an indirect (UI)
or direct (tutorial, how-to's, wizards/assistents) and this may be the
case .. Some may not see tasks like that.
> It is therefore far from optimal to push tasks into a time-based display
> like our views. It raises issues and user confusion (as described here in
> the thread), which you fail to acknowledge.
>
could be. The only confusion not simple and solvable in visual
refurbishment is having *All* Tasks displayed, IMO. Which may be enough
if no acceptable solution .. Visual disemination of event and task (not
like having them in separated panes/lists) could solve others too and
add more ierarchy and sense to all, but I'll stick to the discussion
about the *correct and full display of tasks in cal grid*. Maybe is a
matter of a complete rethink of how they fall into that grid. In that
case, maybe not being the case to prolong the way today but having
another tech behind..
>
>>> I would like to hear your thoughts on how to display
>>>
>> I'm not going to given them :)
>>
>
> That's what I expected :-)
>
they are probably smarter than mine, so he's more carefull with them :).
Not that is hard to be smarter ..
>
>> I would like to finish the discussion on whether tasks should be displayed
>> before discussing how they should look like.
>>
>
> You can't divide those two decisions.
>
> My proposal is based on the sub-optimal display of tasks in the current
> views. To solve the issues that I describe, there are only two possible
> solutions:
>
> 1. Remove the "tasks in view"-feature
> 2. Propose a solution for displaying all tasks in the views adequately
>
> IMO there's no adequate solution for option 2, which is why I favor
> option 1.
>
> I'm fine with you opposing option 1. But if you are, then I'm expecting
> something for option 2 from you. You can't get one without the other.
>
Agree that those 2 are about same thing. Or should I say, the discussion
is about *the correct display and views for tasks and events*. I also
agree that is rather "all or nothing" when it comes to tasks, where 2.
does not have yet a convenient solution.
I'm still not so conviced about eliminating a view (tasks on a calendar
grid, on a time line) as I see it possible to be a smart future feature
alternative to having tasks in a list. And also cause tasks may lead to
defining "busy" times in a calendar, while marking an event for that may
be just a workaround.
I'm having some sort of idea about how to show them in cal, but is still
a fuzzy one. I will think more on that before rushing into answers (not
that I play hard to get now, like above.. :) )
Michiel van Leeuwen
> This will be possible in 0.9. once Sven Giermann has implemented the
> today pane for the other modes as well. Then you can take a look at your
> events in your favorite view and look at your tasks on the right side in
> the today pane.
Except that the main view and the today pane will eat from different
datasources (bug 412800).
And the today pane displays only one day, while the main view could
display the entire month.
So not exactly the same...
>> I would like to finish the discussion on whether tasks should be displayed
>> before discussing how they should look like.
>
> You can't divide those two decisions.
>
Yes, you can.
Your proposal sounds like: "I don't know how to display tasks. lets just
not display at all"
My position: "Let's figure out if we want to display tasks. Once we
decided that, we can spend time figuring out how to display. If we can
really not figure out a solution, we can always remove them by then"
The discussion of if tasks should be displayed depends a lot on what
tasks are. We had that discussion here some time ago. I don't think
there was a simple answer. ovidu also mentioned a few different types it
in this thread.
Michiel
Simon Paquet
>> This will be possible in 0.9. once Sven Giermann has implemented the
>> today pane for the other modes as well. Then you can take a look at your
>> events in your favorite view and look at your tasks on the right side in
>> the today pane.
>
>Except that the main view and the today pane will eat from different
>datasources (bug 412800)
The datasources are the same, it's just up to the user to decide what he
wants to display in the today pane.
>And the today pane displays only one day, while the main view could
>display the entire month.
I don't know how this relates to tasks? The today just incorporates the
unifinder-todo, which displays all tasks (past/present/future,
open/completed) unless you activate the option to hide the completed
tasks.
>So not exactly the same...
Not true. See above.
>>> I would like to finish the discussion on whether tasks should be displayed
>>> before discussing how they should look like.
>>
>> You can't divide those two decisions.
>>
>Yes, you can.
>Your proposal sounds like: "I don't know how to display tasks. lets just
>not display at all"
>My position: "Let's figure out if we want to display tasks. Once we
>decided that, we can spend time figuring out how to display. If we can
>really not figure out a solution, we can always remove them by then"
Well, I'm still waiting for a proposal that supports your position here.
Until now, you've only said that we need to keep the option and fix the
current issues. What your posts are lacking however are concrete
proposals on how to fix these issues.
My proposal lies on the table and I'm willing to post a patch for it.
I'm not asking you for a patch, but I'm asking your for a proposal.
How do you want to display tasks without start and end date in the views?
How do you want to display tasks without start date in the views?
How do you want to display tasks without end date in the views?
>The discussion of if tasks should be displayed depends a lot on what
>tasks are. We had that discussion here some time ago. I don't think
>there was a simple answer. ovidu also mentioned a few different types it
>in this thread.
That is exactly my point. Because there are so many answers to the simple
question of what a task is and what it means, it's highly unlikely to fit
tasks into our views, which are currently restricted to the adequate
display of time-based actions.
Bas van den Bosch
>
> Exactly. They are totally different and should be treated as such.
>
>> But I think that users are not managing those two separately,
>
> What makes you think so?
I for one don't treat them separately, neither does Michel judging his
mail. Seeing the reactions to my previous suggestion, I propose the
following:
* don't show tasks in view per default
* If the preference is set to show them, only show tasks with a due date set
* As tasks can't be allday, for tasks without startdate show a single
line with a distinct icon at the due time in weekview, dayview and monthview
* tasks with a starttime and duetime set, show them the same way as
events but with a distinct icon
Let's have best of both worlds, no tasks in view per default and
avoiding user-confusion so tasks without due aren't shown and tasks with
due are shown.
gr
Bas
Thomas Stache
calendaring tool, but nevertheless I'd like to highlight their solution
to tasks (applies to day and week views)
http://farm4.static.flickr.com/3155/2379009749_c83938f8ee_o.png
(at original size on my 1280x1024 screen)
Tasks are displayed in a separate box below the day columns, whereby
tasks with due dates are shown on that day, and tasks without dates are
shown "today" (as the Timesheet task in the screenshot).
The clou is the possibility to drag the task up into the event area, to
block a time to work on the task. That time will appear as "busy" e.g.
for free/available scheduling. Tasks that have been assigned a time this
way, will appear in the month view day box with that time.
I have to admit I really love that visualization, which in my opinion
covers a lot of use cases mentioned so far.
PS: I'm not a fan of the "today pane in calendar mode" idea, as that
takes a lot of valuable screen estate from the week/month views, that
can use any pixel they can get.
Daniel Boelzle
> - tasks without due date and start date are *not* shown in any view
> This should stay
>
> As for the weekview and dayview I think tasks with only a due or
> start-date should be shown as a single line at the specific time with an
> icon (like we have on events with alarms now). Tasks with start and due
> time should be shown as events with the task-icon. Multiday tasks should
> appear as allday events in all three views.
I partly agree with the above. Everything that is timely constrained
(i.e. either has a start or due or both) could be reasonably shown in a
time grid (the calendar views), and the solution to show a one-liner
above looks good to me (maybe we could further iconify it, but that's
just sugar).
Tasks that don't have a start nor end shouldn't bloat the all-day
sections on all days IMHO, because the user yet has no notion of when
the todo has to be done. I think it's valid to manage those tasks off
the calendar views. The idea of deducing a start out of creation time
doesn't convince me either. I think what matters most for those tasks is
that the user could easily mark them as started and thus automatically
gets them into his calendar view.
just my 2 cents, regards,
Daniel
>
> gr
>
> Bas
> _______________________________________________
> dev-apps-calendar mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-calendar
ovidiu
> http://farm4.static.flickr.com/3155/2379009749_c83938f8ee_o.png
> (at original size on my 1280x1024 screen)
>
> Tasks are displayed in a separate box below the day columns, whereby
> tasks with due dates are shown on that day, and tasks without dates
> are shown "today" (as the Timesheet task in the screenshot).
> The clou is the possibility to drag the task up into the event area,
> to block a time to work on the task. That time will appear as "busy"
> e.g. for free/available scheduling. Tasks that have been assigned a
> time this way, will appear in the month view day box with that time.
>
show all tasks. the 'drag' may not be necessary first, but having this
kind of separated space, but still on grid, should work.
> I have to admit I really love that visualization, which in my opinion
> covers a lot of use cases mentioned so far.
think the whole discuss began in month (and multiweek, same ..) where
the hours are not so important, but the way it shows tasks.
>
> PS: I'm not a fan of the "today pane in calendar mode" idea, as that
> takes a lot of valuable screen estate from the week/month views, that
> can use any pixel they can get.
a redundancy that makes me wonder ..
Michiel van Leeuwen
> Until now, you've only said that we need to keep the option and fix the
> current issues. What your posts are lacking however are concrete
> proposals on how to fix these issues.
After my first post, I didn't do any suggustions. I'm just trying to
figure out what the actual problem is.
is it:
- There is no need for tasks in the main view, because they are visible
in other places
- Tasks in main view is buggy, shows incomplete data
- something else
?
> My proposal lies on the table and I'm willing to post a patch for it.
>
> I'm not asking you for a patch, but I'm asking your for a proposal.
>
> How do you want to display tasks without start and end date in the views?
> How do you want to display tasks without start date in the views?
> How do you want to display tasks without end date in the views?
>
I don't really want to write a complete proposal without having an
answer to my question above.
But for now, i can say that my suggestion would boil down to adding
implicit start end/or end times to tasks that lack one. Then that task
would be presented in a separate area (just like all-day items) at least
for the day/week views. For month view, I think it would be the same.
All this configured by (hidden) prefs, due to the vastly different usage
of tasks
> That is exactly my point. Because there are so many answers to the simple
> question of what a task is and what it means, it's highly unlikely to fit
> tasks into our views, which are currently restricted to the adequate
> display of time-based actions.
I think we can't get around adding some prefs, sure (how much i always
try to prevent that, in this case there is no way around it)
Just boiling out because you can't get a simple solution is too easy for
me. I'd like to spend some thought and discussion on it first.
Michiel
Simon Paquet
>> Until now, you've only said that we need to keep the option and fix the
>> current issues. What your posts are lacking however are concrete
>> proposals on how to fix these issues.
>
>After my first post, I didn't do any suggustions. I'm just trying to
>figure out what the actual problem is. Is it:
>- There is no need for tasks in the main view, because they are visible
> in other places
Partly that.
>- Tasks in main view is buggy, shows incomplete data
Mostly that. As I said in the initial post, how we currently present the
tasks in the views is highly confusing and not very well thought out.
>> My proposal lies on the table and I'm willing to post a patch for it.
>>
>> I'm not asking you for a patch, but I'm asking your for a proposal.
>>
>> How do you want to display tasks without start and end date in the views?
>> How do you want to display tasks without start date in the views?
>> How do you want to display tasks without end date in the views?
>>
>I don't really want to write a complete proposal without having an
>answer to my question above.
>But for now, i can say that my suggestion would boil down to adding
>implicit start end/or end times to tasks that lack one. Then that task
>would be presented in a separate area (just like all-day items) at least
>for the day/week views. For month view, I think it would be the same.
>All this configured by (hidden) prefs, due to the vastly different usage
>of tasks
That sounds similar to what Thomas showed in the screenshot from "that
other calendar application". I haven't thought this through really. I
would probably need to see some more mockups (especially of our
multiweek/month) to really make up my mind about this.
>> That is exactly my point. Because there are so many answers to the simple
>> question of what a task is and what it means, it's highly unlikely to fit
>> tasks into our views, which are currently restricted to the adequate
>> display of time-based actions.
>
>I think we can't get around adding some prefs, sure (how much i always
>try to prevent that, in this case there is no way around it)
>Just boiling out because you can't get a simple solution is too easy for
>me. I'd like to spend some thought and discussion on it first.
Well, in my experience often the most simple answer is the right one. I
believe that this is is the case here as well. We'll see...
djo0012
> I know I got flak the last time I even mentioned that other well known
> calendaring tool, but nevertheless I'd like to highlight their solution
> to tasks (applies to day and week views)
>
> http://farm4.static.flickr.com/3155/2379009749_c83938f8ee_o.png
> (at original size on my 1280x1024 screen)
>
> Tasks are displayed in a separate box below the day columns, whereby
> tasks with due dates are shown on that day, and tasks without dates are
> shown "today" (as the Timesheet task in the screenshot).
day/week view, and for the multiweek/month view we can handel them in
the same way (about wich day we are showing it) but not having a
separated space for it since it's not time (hour) related
> The clou is the possibility to drag the task up into the event area, to
> block a time to work on the task. That time will appear as "busy" e.g.
> for free/available scheduling. Tasks that have been assigned a time this
> way, will appear in the month view day box with that time.
I realy like that, maybe it's can wait a little to implemant it but that
was one of the suggestion I wanted to do cause a task mostly finish
being an event at some stage when you think you are doing it (ex: you
need to review a document for next friday and you have a free tim on
wednesday afternoon you set this time to do that task
>
> I have to admit I really love that visualization, which in my opinion
> covers a lot of use cases mentioned so far.
I agree, even the part for task without start and due date are not using
all space in the all day section (like few other proposal) when you have
a lot of undefind task (no start and due time)
>
> PS: I'm not a fan of the "today pane in calendar mode" idea, as that
> takes a lot of valuable screen estate from the week/month views, that
> can use any pixel they can get.
agree too, mainly when you are using a 12" screen in 1024*768, even in
the mail view a miss space I dont wanna see what will hapen in calendar
view, I just hope that the setting will remember the config (show the
today pane or not) as par view and not as a whole.
ovidiu
Sunbird Event Repeat Idea
by D. Brown
http://groups.google.com/groups?selm=mailman.270.1208190696.6882.wishlist%40lists.mozilla.org
It goes for a different presentation of repeating events, but it may
very well give an idea about visualisation of tasks without all dates
(start, end ..). Here's the pic:
http://s128.photobucket.com/albums/p200/kneilo_yute/?action=view¤t=sunbirdexample.jpg
To interpret it for the task issue, the "noStart" or "noDue" would
benefit of such "arrows" representation, also working for week maybe,
with a less clear arrow stop/end for those undefined dates. Like
[Task] >>> .. or [Task] o o o ..
vs
..>>>[task] or ..o o o [Task]
while a general task with undefined dates (noStart+noDue) would possibly
benefit of another representation, for example with arrows in both
directions or a different (dotted?) line, or different arrows ( >>>?,
one > for each day shown or only couple of days ahead and before today
..). Or may very well end up in a separate space under the main pane,
like the week picture above, or like (or into?) the unifinder (or
unifinder with 2 sections .. hmm, kinda complicating ..).
If this is a bit closer to something viable, please comment on it and
add to it.
I can assume is kinda hard to get it with the present organisation of
the elements in the calendar grid. I was also proposing graphical
different presentation of task vs event, which already needs another
selector (now they are all eventboxes ..) and I cannot say what is
easyer or safer to do. But I would try some derivated mockups if there
is of any interest (like ways of splitting those lines in dayboxes or
event/task boxes, or instances) with proposals of ways to arrange them,
but with a visual start point.
[ Or I could come up with more kinds of funky representation, regardless
of imlpementation dificulties, but it may just be called "eye candy"... ;) ]
djo0012
> Sunbird Event Repeat Idea
> by D. Brown
> http://groups.google.com/groups?selm=mailman.270.1208190696.6882.wishlist%40lists.mozilla.org
>
>
> It goes for a different presentation of repeating events, but it may
> very well give an idea about visualisation of tasks without all dates
> (start, end ..). Here's the pic:
> http://s128.photobucket.com/albums/p200/kneilo_yute/?action=view¤t=sunbirdexample.jpg
>
long task on the week view, because task are often long (from a few
hours to a few day) all space in these days or cut in two (cause of the
box model which is normal). so having only a thin line on the side would
give us a lot more space for interesting information (text and not just
a coloured rectangle)
> while a general task with undefined dates (noStart+noDue) would possibly
> benefit of another representation, for example with arrows in both
> directions or a different (dotted?) line, or different arrows ( >>>?,
> one > for each day shown or only couple of days ahead and before today
> ..). Or may very well end up in a separate space under the main pane,
> like the week picture above, or like (or into?) the unifinder (or
> unifinder with 2 sections .. hmm, kinda complicating ..).
I'm actually trying to get some ui design to have a task unifinder (and
mainly the task mode into sunbird) in bug 405508 (
https://bugzilla.mozilla.org/show_bug.cgi?id=405508 ). so this undefined
date task would already be in there, we can have a filter that would be
"time unrelated" (to be worked out by someone who has a better English
than me :p). and that would be 2 click away (or maybe 3...)
djo0012
> doesn't convince me either. I think what matters most for those tasks is
> that the user could easily mark them as started and thus automatically
> gets them into his calendar view.
and end time based on now and the normal length of an event. it's
actually the same in task but start date is compulsory and is set to
last midnight.
so if on creation the start date is already filled you doesn't change
his data without user knowing about it. let the start date stay
compulsory (so you cannot remove it) you never have a task without start
date. I doesn't think that's a problem since most of the time when you
doesn't fix a start date it's because you can do it asap, if no you have
a start date (cannot do it before then...)
Taraman
IMO there is a big difference between tasks and events. As some of the
above said, events have to adhere to starting- and end-times much more
strictly.
This means for me, if I have to do something exactly at a certain
time, I use an event to represent that in my calendar. Nevertheless I
need a way to block a certain period of time for a task.
If I have to do something until a certain date, I might do it today,
but I might as well do it tomorrow or any day until it is due.
I use the task list as a reminder, what I have to do and my wish would
be that if I select today, I get all the things I could do today.
This leads to the following perfect solution for my way to use it:
- If a task has no date set it is not shown in the views.
- If I want it to appear today I set a start date only and it is shown
on the current day as "all day item" until I mark it complete.
- If I want it stop appearing sometime, I set a due-date only and it
shows as above, but stops showing on the due date. It might even get a
warning symbol on that date.
- If I want to block a period of time for that task I set both dates
and get a duration and it is shown like an event.
That way I get a good overview what I can do today without getting a
Task shown only on the startdate as it is now and then forget about
it, or have 10 Tasks spanning 3 weeks and thus spamming my calendar.
For finding out which of the tasks has the highest priority or the
neares due date, I can use the task-mode.
Regards
Markus
mjh
answer is the right one" As a user of Sunbird I offer the following
proposal for displaying task information on the calendar. I think it
is simple <grin>. I propose that tasks primarily be dealt with in a
task-mode or task (sub)window. However, I do believe that *dates*
associated with tasks should cause a display in the calendar if that
preference is set by the user.
Propose that:
- Individual tasks are *not* separately displayed on the calendar
- The preference to "display tasks in calendar" will only produce
"reminder" entries on those dates whenever a date is explicitly
associated with a task
- A single reminder named "Task-Start" and/or a separate single
reminder named "Task-Due" is displayed on a day if there are any tasks
with that day set for start or due respectively.
- If there are multiple tasks with this day set as Start, only one
"Task-Start" reminder appears on the calendar, but mouse-over will
list (only the names of) the tasks that have this day as their Start.
Similarly for "Task-Due".
- These reminders will display on all calendar views, and will display
"as if" they were an all-day event on that day.
- A preference could be set to limit what tasks will cause a reminder,
e.g. exclude completed or cancelled or low priority or ...
Thus,
- tasks with no dates will not cause a display in any calendar view
- tasks with a Start but no Due will cause a "Task-Start" reminder to
display on the start date only in all views
- tasks with a Due but no Start will cause a "Task-Due" reminder to
display on the due date only in all views
- tasks with both Start and Due will cause the respective reminders to
display on both dates in all views
In my opinion, if the user wants more than a simple reminder to appear
in the calendar, then they should/will create an event. I believe
this proposal is simple and will prevent clutter of the calendar. I
believe it should be intuitive to the user: if they enter a date they
get a reminder on that date, if they don't enter a date they don't get
a reminder. Nothing more, nothing less.
Just one user's view,
Mike
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
IMHO as a business user / telecommuter / hater of Outlook (which I
refused to use), I mostly agree with the above post.
I think we are hung up on the Task<>Event distinction. When I have a
"function" which is date &/or time sensitive, I create (or convert a
Task to) an Event which visually blocks out time. The battling boxes
display conflicts.
Repeating Events are easier to manage than repeating Tasks. They do
tend to clutter the calendar view, so I created a "repeater" calendar
which I turn off, leaving the alarms active and read-only mode (to
avoid mistaken entries).
If the function is not date/time sensitive, aka the "round tuit" item,
it's a Task which needs only to appear in a separate list. If it is
an item of high priority, it is actually an Event requiring date,
time, and reminder.
"Tasks in view" is, to me, counter-intuitive because the Tasks don't
appear in ALL views. That being said, the screenshot posted by T.
Stache is an appealing alternative.