Home » Eclipse Projects » Mylyn » What algorithm does Mylyn use for color in task list?
|
| Re: What algorithm does Mylyn use for color in task list? [message #12565 is a reply to message #12446] |
Fri, 13 July 2007 19:06   |
Eclipse User |
|
|
|
Originally posted by: beatmik.acm.org
Dave Syer wrote:
> What algorithm is used to decide what color to display. I haven't changed
> the default settings for colors in Windows->Preferences, but today (Friday)
> everything went red. End of week. None of the red tasks have completion
> dates, so what is it telling me?
See the Task List's view menu's "Show UI Legend" action for an
explanation of the colors and a link to how to change them.
Mik
|
|
| | |
| Re: What algorithm does Mylyn use for color in task list? [message #12644 is a reply to message #12624] |
Sat, 14 July 2007 01:15 |
| Eclipse User |
|
|
|
Originally posted by: beatmik.acm.org
Dave Syer wrote:
> I figured something out but I still don't undertstand. It seems that Mylyn
> thinks something is past scheduled date if it is scheduled to start earlier
> than today. What about the end date? Surely it is only red if it is not
> finished but scheduled to complete before today?
>
> So I can switch all my angry red tasks to black again by cancelling the
> start date, but that seems to defeat the object somehow. Don't you think?
Yes, that would defeat the objective so instead what's recommended is to
schedule for today (or a later day in the week, or defer) when wanting
to get rid of the angry red in the morning or on Monday. For details
see the "Task management and personal planning" section of:
http://www-128.ibm.com/developerworks/java/library/j-mylar1/
Mik
|
|
| |
| Re: What algorithm does Mylyn use for color in task list? [message #14226 is a reply to message #12729] |
Tue, 17 July 2007 16:37 |
| Eclipse User |
|
|
|
Originally posted by: beatmik.acm.org
Dave Syer wrote:
> Thanks. From the article in the link: "At the end of the workday, any tasks
> that should have been completed but weren't turn red". But the red tasks
> are those whose *start* date are earlier than today, not the scheduled end
> date. Surely it makes more sense to flag as red if you overrun the end
> date, not the start date?
Good point. This is related to a subtlety of what it means to schedule
a task for Today, which schedules it for the end of the workday and tuns
it blue instead of red. The point of that is to avoid needing to
continually re-schedule start times throughout your workday. I've added
an explanation to:
http://wiki.eclipse.org/Mylyn_User_Guide#Scheduling
Mik
|
|
| | |
| Re: What algorithm does Mylyn use for color in task list? [message #16061 is a reply to message #14324] |
Thu, 19 July 2007 19:07 |
| Eclipse User |
|
|
|
Originally posted by: beatmik.acm.org
The reason we don't currently do this is that the UI takes the premise
that a single scheduled date is the common case for most tasks, and that
tasks get deferred very frequently. In other words, we're leaning much
more heavily to David Allen's "Getting Things Done" approach of time
management than to a Microsoft start/end date style which should be
better overall for project management but can also be much more tedious
for day-to-day task management.
But note that we are very close to the "start date < now < end date"
approach, just that we make the day explicit (similar to how we make the
workweek explicit). So when "now" is the same day as the start date the
task goes blue. That said, I would like to explore this further in case
it helps us resolve how frequently tasks go red in the Task List.
Here's a quick cut at altering the current policy to incorporate these
suggestions, let me know what you think
* Tasks whose scheduled date is today continue to go blue so that they
stand out without being annoyingly read. They stay blue until they are
done or hit their end date.
* Tasks that have a due date go red once they hit that end date.
This would address the current problem of frequently having to
re-schedule your red tasks for today. The red was meant to encourage
re-scheduling things that have passed their date, but the blue might do
a good enough job of that and make things that are actually overdue (and
not just in need of rescheduling) more explicit. If you end up with too
much blue on a given day you then re-schedule things to be black (future
days this week) or to disappear (delegate to a future week.
Mik
Stefan Langer wrote:
> I tend to agree with Dave. It would be much clearer and more concise
> with other scheduling facilities to use the start date < now < end date
> for the highlighting. This would imply that it is nessecary to have a
> start date when an end date is defined and it is possible to leave out
> the end date which means indefinite or to leave out both which simply
> means this task is not scheduled at all.
>
> Stefan
>
> Dave Syer schrieb:
>> Mik,
>>
>> That's much clearer thanks. But I don't see why you need two
>> different highlighting rules for start and end date - why not just
>> have "active" tasks (with start date <= now <= end date) blue, and
>> overdue tasks (now > end date) red? I see that it makes sense to have
>> an implied end date at the end of the day if it is not expicitly
>> specified, but the current behaviour doesn't seem intuitive.
|
|
|
| Re: What algorithm does Mylyn use for color in task list? [message #17411 is a reply to message #16061] |
Thu, 19 July 2007 19:33 |
 Dave Syer
Messages: 95
Registered: July 2009 |
Member |
|
|
Mik,
That sounds perfect to me.
Dave.
"Mik Kersten" <beatmik@acm.org> wrote in message
news:f7ocqp$emv$1@build.eclipse.org...
> The reason we don't currently do this is that the UI takes the premise
> that a single scheduled date is the common case for most tasks, and that
> tasks get deferred very frequently. In other words, we're leaning much
> more heavily to David Allen's "Getting Things Done" approach of time
> management than to a Microsoft start/end date style which should be better
> overall for project management but can also be much more tedious for
> day-to-day task management.
>
> But note that we are very close to the "start date < now < end date"
> approach, just that we make the day explicit (similar to how we make the
> workweek explicit). So when "now" is the same day as the start date the
> task goes blue. That said, I would like to explore this further in case
> it helps us resolve how frequently tasks go red in the Task List. Here's a
> quick cut at altering the current policy to incorporate these suggestions,
> let me know what you think
>
> * Tasks whose scheduled date is today continue to go blue so that they
> stand out without being annoyingly read. They stay blue until they are
> done or hit their end date.
>
> * Tasks that have a due date go red once they hit that end date.
>
> This would address the current problem of frequently having to re-schedule
> your red tasks for today. The red was meant to encourage re-scheduling
> things that have passed their date, but the blue might do a good enough
> job of that and make things that are actually overdue (and not just in
> need of rescheduling) more explicit. If you end up with too much blue on
> a given day you then re-schedule things to be black (future days this
> week) or to disappear (delegate to a future week.
>
> Mik
>
> Stefan Langer wrote:
>> I tend to agree with Dave. It would be much clearer and more concise with
>> other scheduling facilities to use the start date < now < end date for
>> the highlighting. This would imply that it is nessecary to have a start
>> date when an end date is defined and it is possible to leave out the end
>> date which means indefinite or to leave out both which simply means this
>> task is not scheduled at all.
>>
>> Stefan
>>
>> Dave Syer schrieb:
>>> Mik,
>>>
>>> That's much clearer thanks. But I don't see why you need two different
>>> highlighting rules for start and end date - why not just have "active"
>>> tasks (with start date <= now <= end date) blue, and overdue tasks (now
>>> > end date) red? I see that it makes sense to have an implied end date
>>> at the end of the day if it is not expicitly specified, but the current
>>> behaviour doesn't seem intuitive.
|
|
|
| Re: What algorithm does Mylyn use for color in task list? [message #18615 is a reply to message #17411] |
Sun, 22 July 2007 16:59 |
| Eclipse User |
|
|
|
Originally posted by: rob.elves.eclipse.org
+1 - I'd like to try that scheme out. But I'll need to change some (bad)
habits such as intentionally leaving tasks red as nagging reminders.
Since some Bugzilla repositories support shared/common due dates,
intentionally setting a task as overdue will not be practical for a
personal use case such as this.
-Rob
Dave Syer wrote:
> Mik,
>
> That sounds perfect to me.
>
> Dave.
>
> "Mik Kersten" <beatmik@acm.org> wrote in message
> news:f7ocqp$emv$1@build.eclipse.org...
>> The reason we don't currently do this is that the UI takes the premise
>> that a single scheduled date is the common case for most tasks, and that
>> tasks get deferred very frequently. In other words, we're leaning much
>> more heavily to David Allen's "Getting Things Done" approach of time
>> management than to a Microsoft start/end date style which should be better
>> overall for project management but can also be much more tedious for
>> day-to-day task management.
>>
>> But note that we are very close to the "start date < now < end date"
>> approach, just that we make the day explicit (similar to how we make the
>> workweek explicit). So when "now" is the same day as the start date the
>> task goes blue. That said, I would like to explore this further in case
>> it helps us resolve how frequently tasks go red in the Task List. Here's a
>> quick cut at altering the current policy to incorporate these suggestions,
>> let me know what you think
>>
>> * Tasks whose scheduled date is today continue to go blue so that they
>> stand out without being annoyingly read. They stay blue until they are
>> done or hit their end date.
>>
>> * Tasks that have a due date go red once they hit that end date.
>>
>> This would address the current problem of frequently having to re-schedule
>> your red tasks for today. The red was meant to encourage re-scheduling
>> things that have passed their date, but the blue might do a good enough
>> job of that and make things that are actually overdue (and not just in
>> need of rescheduling) more explicit. If you end up with too much blue on
>> a given day you then re-schedule things to be black (future days this
>> week) or to disappear (delegate to a future week.
>>
>> Mik
>>
>> Stefan Langer wrote:
>>> I tend to agree with Dave. It would be much clearer and more concise with
>>> other scheduling facilities to use the start date < now < end date for
>>> the highlighting. This would imply that it is nessecary to have a start
>>> date when an end date is defined and it is possible to leave out the end
>>> date which means indefinite or to leave out both which simply means this
>>> task is not scheduled at all.
>>>
>>> Stefan
>>>
>>> Dave Syer schrieb:
>>>> Mik,
>>>>
>>>> That's much clearer thanks. But I don't see why you need two different
>>>> highlighting rules for start and end date - why not just have "active"
>>>> tasks (with start date <= now <= end date) blue, and overdue tasks (now
>>>> > end date) red? I see that it makes sense to have an implied end date
>>>> at the end of the day if it is not expicitly specified, but the current
>>>> behaviour doesn't seem intuitive.
>
>
|
|
|
| Re: What algorithm does Mylyn use for color in task list? [message #18859 is a reply to message #18615] |
Wed, 25 July 2007 02:17 |
| Eclipse User |
|
|
|
Originally posted by: beatmik.acm.org
+1 that we experiment with a scheme modified along these lines.
However, note that yours is more than a personal use case, with the
scheme exactly as is we would be losing some information that other
users could currently be relying on.
Currently you look at your Task List in the morning and see a bunch of
things in red, and other things in blue. The things in red are likely
to be things that require first attention because they were scheduled to
be done yesterday or before, but are not done yet. If we went with the
proposed scheme as is we would lose this distinction.
One thing that we could experiment with is making it more clear that the
sorting sorts by scheduled date. However, the UI would be confusing if
there was no visual feedback for scheduling for today a task that was
over its scheduled date. So we might need to retain some kind of visual
feedback.
David: could you please file a bug report for this and post the URL? We
can start some experimentation in the dev builds.
Mik
Robert Elves wrote:
> +1 - I'd like to try that scheme out. But I'll need to change some (bad)
> habits such as intentionally leaving tasks red as nagging reminders.
> Since some Bugzilla repositories support shared/common due dates,
> intentionally setting a task as overdue will not be practical for a
> personal use case such as this.
|
|
| | | | | | | | |
| Re: What algorithm does Mylyn use for color in task list? [message #573548 is a reply to message #14324] |
Thu, 19 July 2007 19:07 |
Mik Kersten
Messages: 287
Registered: July 2009 |
Senior Member |
|
|
The reason we don't currently do this is that the UI takes the premise
that a single scheduled date is the common case for most tasks, and that
tasks get deferred very frequently. In other words, we're leaning much
more heavily to David Allen's "Getting Things Done" approach of time
management than to a Microsoft start/end date style which should be
better overall for project management but can also be much more tedious
for day-to-day task management.
But note that we are very close to the "start date < now < end date"
approach, just that we make the day explicit (similar to how we make the
workweek explicit). So when "now" is the same day as the start date the
task goes blue. That said, I would like to explore this further in case
it helps us resolve how frequently tasks go red in the Task List.
Here's a quick cut at altering the current policy to incorporate these
suggestions, let me know what you think
* Tasks whose scheduled date is today continue to go blue so that they
stand out without being annoyingly read. They stay blue until they are
done or hit their end date.
* Tasks that have a due date go red once they hit that end date.
This would address the current problem of frequently having to
re-schedule your red tasks for today. The red was meant to encourage
re-scheduling things that have passed their date, but the blue might do
a good enough job of that and make things that are actually overdue (and
not just in need of rescheduling) more explicit. If you end up with too
much blue on a given day you then re-schedule things to be black (future
days this week) or to disappear (delegate to a future week.
Mik
Stefan Langer wrote:
> I tend to agree with Dave. It would be much clearer and more concise
> with other scheduling facilities to use the start date < now < end date
> for the highlighting. This would imply that it is nessecary to have a
> start date when an end date is defined and it is possible to leave out
> the end date which means indefinite or to leave out both which simply
> means this task is not scheduled at all.
>
> Stefan
>
> Dave Syer schrieb:
>> Mik,
>>
>> That's much clearer thanks. But I don't see why you need two
>> different highlighting rules for start and end date - why not just
>> have "active" tasks (with start date <= now <= end date) blue, and
>> overdue tasks (now > end date) red? I see that it makes sense to have
>> an implied end date at the end of the day if it is not expicitly
>> specified, but the current behaviour doesn't seem intuitive.
|
|
|
| Re: What algorithm does Mylyn use for color in task list? [message #573856 is a reply to message #16061] |
Thu, 19 July 2007 19:33 |
Dave Syer
Messages: 95
Registered: July 2009 |
Member |
|
|
Mik,
That sounds perfect to me.
Dave.
"Mik Kersten" <beatmik@acm.org> wrote in message
news:f7ocqp$emv$1@build.eclipse.org...
> The reason we don't currently do this is that the UI takes the premise
> that a single scheduled date is the common case for most tasks, and that
> tasks get deferred very frequently. In other words, we're leaning much
> more heavily to David Allen's "Getting Things Done" approach of time
> management than to a Microsoft start/end date style which should be better
> overall for project management but can also be much more tedious for
> day-to-day task management.
>
> But note that we are very close to the "start date < now < end date"
> approach, just that we make the day explicit (similar to how we make the
> workweek explicit). So when "now" is the same day as the start date the
> task goes blue. That said, I would like to explore this further in case
> it helps us resolve how frequently tasks go red in the Task List. Here's a
> quick cut at altering the current policy to incorporate these suggestions,
> let me know what you think
>
> * Tasks whose scheduled date is today continue to go blue so that they
> stand out without being annoyingly read. They stay blue until they are
> done or hit their end date.
>
> * Tasks that have a due date go red once they hit that end date.
>
> This would address the current problem of frequently having to re-schedule
> your red tasks for today. The red was meant to encourage re-scheduling
> things that have passed their date, but the blue might do a good enough
> job of that and make things that are actually overdue (and not just in
> need of rescheduling) more explicit. If you end up with too much blue on
> a given day you then re-schedule things to be black (future days this
> week) or to disappear (delegate to a future week.
>
> Mik
>
> Stefan Langer wrote:
>> I tend to agree with Dave. It would be much clearer and more concise with
>> other scheduling facilities to use the start date < now < end date for
>> the highlighting. This would imply that it is nessecary to have a start
>> date when an end date is defined and it is possible to leave out the end
>> date which means indefinite or to leave out both which simply means this
>> task is not scheduled at all.
>>
>> Stefan
>>
>> Dave Syer schrieb:
>>> Mik,
>>>
>>> That's much clearer thanks. But I don't see why you need two different
>>> highlighting rules for start and end date - why not just have "active"
>>> tasks (with start date <= now <= end date) blue, and overdue tasks (now
>>> > end date) red? I see that it makes sense to have an implied end date
>>> at the end of the day if it is not expicitly specified, but the current
>>> behaviour doesn't seem intuitive.
|
|
|
| Re: What algorithm does Mylyn use for color in task list? [message #574365 is a reply to message #17411] |
Sun, 22 July 2007 16:59 |
Robert Elves
Messages: 87
Registered: July 2009 |
Member |
|
|
+1 - I'd like to try that scheme out. But I'll need to change some (bad)
habits such as intentionally leaving tasks red as nagging reminders.
Since some Bugzilla repositories support shared/common due dates,
intentionally setting a task as overdue will not be practical for a
personal use case such as this.
-Rob
Dave Syer wrote:
> Mik,
>
> That sounds perfect to me.
>
> Dave.
>
> "Mik Kersten" <beatmik@acm.org> wrote in message
> news:f7ocqp$emv$1@build.eclipse.org...
>> The reason we don't currently do this is that the UI takes the premise
>> that a single scheduled date is the common case for most tasks, and that
>> tasks get deferred very frequently. In other words, we're leaning much
>> more heavily to David Allen's "Getting Things Done" approach of time
>> management than to a Microsoft start/end date style which should be better
>> overall for project management but can also be much more tedious for
>> day-to-day task management.
>>
>> But note that we are very close to the "start date < now < end date"
>> approach, just that we make the day explicit (similar to how we make the
>> workweek explicit). So when "now" is the same day as the start date the
>> task goes blue. That said, I would like to explore this further in case
>> it helps us resolve how frequently tasks go red in the Task List. Here's a
>> quick cut at altering the current policy to incorporate these suggestions,
>> let me know what you think
>>
>> * Tasks whose scheduled date is today continue to go blue so that they
>> stand out without being annoyingly read. They stay blue until they are
>> done or hit their end date.
>>
>> * Tasks that have a due date go red once they hit that end date.
>>
>> This would address the current problem of frequently having to re-schedule
>> your red tasks for today. The red was meant to encourage re-scheduling
>> things that have passed their date, but the blue might do a good enough
>> job of that and make things that are actually overdue (and not just in
>> need of rescheduling) more explicit. If you end up with too much blue on
>> a given day you then re-schedule things to be black (future days this
>> week) or to disappear (delegate to a future week.
>>
>> Mik
>>
>> Stefan Langer wrote:
>>> I tend to agree with Dave. It would be much clearer and more concise with
>>> other scheduling facilities to use the start date < now < end date for
>>> the highlighting. This would imply that it is nessecary to have a start
>>> date when an end date is defined and it is possible to leave out the end
>>> date which means indefinite or to leave out both which simply means this
>>> task is not scheduled at all.
>>>
>>> Stefan
>>>
>>> Dave Syer schrieb:
>>>> Mik,
>>>>
>>>> That's much clearer thanks. But I don't see why you need two different
>>>> highlighting rules for start and end date - why not just have "active"
>>>> tasks (with start date <= now <= end date) blue, and overdue tasks (now
>>>> > end date) red? I see that it makes sense to have an implied end date
>>>> at the end of the day if it is not expicitly specified, but the current
>>>> behaviour doesn't seem intuitive.
>
>
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 13:28:38 GMT 2024
Powered by FUDForum. Page generated in 0.04575 seconds |
] 
Search
Help
Register
Login
Home
