Task urgency color coding

[Wolter HV]

I am going to start working on a functionality that makes use of the start date and due date of a task to estimate the current urgency level of the task, and notify the user about it through color coding.

HOW IT WORKS
It is based on the following suppositions:
 * If the user selects a start date and a due date for a task, it might not be strictly necessary to start working on the task right when the start date is reached - it would be optimal, but not always do we have the time to do so.
 * The dayspan (as I am calling it in this project), which consists in the span of days between the start date and the due date, has a portion of days in which the task really needs to be worked on in order to be complete by the due date, which I call the reddays (red-days), that are roughly equivalent in number to the 30% of the dayspan, and are logically adjacent to the due date. This number will not be an integer, so the value has to be ceiled.
 * The bigger the task a user needs to accomplish, the lengthier the dayspan he will accommodate for it. This way, the latter seems to work for any scale of task.

PLANNED COLOR CODING
 * If a task has no start date, it will not be processed.
 * The urgency color of any task is initially green
 * If a task's start date has passed, the color will be yellow
 * If a task is within its reddays, the color will be red

In GTG a task will represent its urgency color by having it as background color.
The color of each urgency level will be customizable (for various reasons, starting out with theme compatibility).

CONFLICTS WITH EXISTING FUNCTIONALITY
There is a conflict with the background color that is given to tasks based on their tags. Both modules cannot work together, so the user will be prompted to select either.

ABOUT IMPLEMENTATION
I was wondering though, should this be written as a plugin or directly into the applications source code? I would have started by the application's source code but then again I don't know it as much as to have a founded opinion. Of course, I do not expect this "blueprint" to be accepted into the main tree, so what I am thinking about here is a patchset for those users who would like the functionality.

[Wolter HV (wolterh)]

If anybody wants to check the progress on this, check out this branch lp:~wolterh/+junk/gtg-urgency

[Wolter HV (wolterh)]

The functionality is complete. You can check it out from the branch I published in comment #1.

[Izidor Matušov (izidor)]

Wolter, thanks for coding that, it looks good.

Few notes:

1) You have a bug there: Set start date to 2013-01-31 and due date to 2013-12-31 => it is green. Now change start date to 2011-01-31 and the color is yellow. (Probably there is error with end of years, I haven't looked at your code yet)

2) Most of GTG users don't use start date => the feature is quite useless. It would be much more better to also generate color for tasks which don't have any start date.

3) Use more colors. Why doesn't it use more colors? You don't have to pay for that. You could specify just two colors (at beginning and at end) and then use gradient between those colors. Proposed behavior:
startdate in future => without color
with no startdate/with already passed startdate:
  duedate in more than 2 weeks => initial color
  less than 2 weeks => somewhere in the middle in gradient

How to compute the color:
# For red/green/blue
grad = (duecolor - startcolor)/14
if today < startdate: return startcolor
else: return grad * (duedate - startdate)/14

With this I would be glad to have something like that in GTG

[Wolter HV (wolterh)]

Thanks for your revision, I will try to address your points the best I can.

1) Well I have specified yellow to be used when the start date has passed, and 2011-01-31 was at the beginning of this year. The color yellow, in other words, indicates that you should be working on the task. If you specify such a long period between your start date and the due date, it must be because you really need to work on the task a lot of time. Have I missed the point?

2) I would say the feature is rather "quite unused", it is not useless. In fact, is one of the features I like the most about GTG. Being remembered to start a task a prudent time before it is due can be very helpful in completing it punctually. It is a good idea to assume a start date for tasks with such attribute unspecified, I guess 2 weeks will do just fine. Note that by "assuming" a start date I don't mean to actually set a start date for a task, but calculate the colors as if so.
However, I also want you to understand why I ignored tasks without a start date. Personally, when a task is not very important, or can be done quickly, I don't assign a start date. I don't need it to be colored, because of its lesser importance and ease of completion. Therefore, I think this should be customizable.

3) It is a matter of personal taste, I know I could use all 16+ M colors and I wouldn't have to pay one cent - but I think 3 is a nice number. I know a gradient would be nice too, so I think it should be a decision of the user whether to use 3 colors or a gradient. This could be done with ease. If I understood correctly, you suggest a 2 week anticipation period for tasks without a start date in order to start coloring the task?

In conclusion, I think that to satisfy a wider span of users, the things you suggested as much as the initial behavior I planned should be a matter of choice.

[Wolter HV (wolterh)]

I have curiosity for your algorithm. Why is the gradient factor divided by 14, and the gradient color as well? (as in why not another number, is there a logic to using 14?)
Also, I suppose that the else should return instead grad * (duedate - today)/14, am I wrong?

[Izidor Matušov (izidor)]

I am sorry, I wasn't in good shape somehow and made many mistakes in my comments.

1 & 2) 2) The right word should be not used so often instead of useless. My point was that I get confused about the coloring. I expected to be something like:
 * green => you have a lot of time to do it, don't worry
 * yellow => you should be actively working on it
 * red => deadline, work 24hour on it

Using this assumption I was confused by your algorithm. You used it differently: (computed on the expected duration of task)
 * green => you don't have to work on it
 * yellow => work on it
 * red => deadline

3) Yes, it is a matter of taste. There is underlying, unwritten concept of 2 weeks - date 2 weeks before is refered to "in 13 days" and so on. Therefore I choose 2 weeks and magic constant 14. The algorithm was written from top of my head and it should demonstrate the math behind it. Yes, you are right, it should be used today instead of startdate.

I suppose it would be better to implement this feature as a plugin (according to this discussion). Please, try to catch me on IRC, jabber and we can discuss implementation details of changing plugin API to allow creating plugin like this.

[Wolter HV (wolterh)]

Don't worry about it, sometimes we are not understood as much as we wanted.

1) The colors mean exactly what you expected. I can't find a difference between the descriptions you gave for your expectations and your actual findings. I see though that the red color in your findings is "deadline", which does differ from "deadline, work 24hour on it". But I would say the latter is more accurate in fact, because the red color doesn't appear firstly on "D-Day" (if we might call it that), but a "prudent" period before the deadline. Precisely, in the last 30% of time you got, 100% being the time between the start date and due date.

I don't think changing the API for a plugin that could do this would be a very hard task. How about if we arrange a meeting with the gtg developer team? Personally, I will have to wait until January 4th; I will be in vacations in the meantime :)

Happy Holidays until then!

[Wolter HV (wolterh)]

Izidor I am available everyday between 1500 and 600 UTC for the discussion of the issue.

[Lionel Dricot (ploum-deactivatedaccount)]

To add my 2 cents, I would say that a task without a start date should be considered as having its start date "today". Because if you don't set a start date, GTG assume you can start it right now.

Another option would be to consider the creation of the date as a start date. In fact, it might make sense for GTG to automatically set a start date when you create a task.

[Izidor Matušov (izidor)]

Wolter> please, contact me when you are available and I will be online (jabber/IRC)...

[Wolter HV (wolterh)]

Izidor> I have looked for you on the channels but haven't seen you online. Please suggest a time for our meeting.

[Wolter HV (wolterh)]

Update:

The feature has been turn into a working plugin, available at the branch lp:~gtg-user/gtg/urgency-color-api
The branch includes the plugin, and a change to the plugin api which is necessary for the plugin to work. The plugin is ready and waiting until the merge request is accepted.

[Wolter HV (wolterh)]

The first branch I linked to is not up to date, hereafter replace it with lp:~gtg-user/gtg/urgency-color-api

[Wolter HV (wolterh)]

Izidor, there is a bug related with the background color setting method, or so I believe. This bug makes the plugin bring up very old completed tasks about when activated. I guess it calls some sort of "show task" method?

[Izidor Matušov (izidor)]

Wolter, I played with it but I can't reproduce your bug. Could you give me exact steps how to reproduce it? Or maybe create a screencast?

[Wolter HV (wolterh)]

Izidor I fixed it in one of my latest commits. You added a call to reset_filters() function in the set_bgcolor function in the plugin api, which was bringing about all the tasks ever closed (in my end at least); I figured that replacing that for reset_filters(transparent_only=True) fixed the issue.

[aslam karachiwala (akwala)]

Just noticed this in the Plugins list. When I tried enabling it, GTG crashed...

Traceback (most recent call last):
  File "/usr/share/gtg/GTG/gtk/preferences.py", line 380, in on_plugin_toggle
    self.pengine.activate_plugins([p])
  File "/usr/share/gtg/GTG/core/plugins/engine.py", line 214, in activate_plugins
    plugin.instance.activate(api)
  File "/usr/share/gtg/GTG/plugins/urgency_color/urgency_color.py", line 41, in activate
    self.prefs_init()
  File "/usr/share/gtg/GTG/plugins/urgency_color/urgency_color.py", line 96, in prefs_init
    'preferences.ui'))
GError: Failed to open file '/usr/share/gtg/GTG/plugins/urgency_color/preferences.ui': No such file or directory

Synaptic does not list preferences.ui iamong the installed files.

[Wolter HV (wolterh)]

Hm, thats a bit weird because if you see the branch, the file is there: http://bazaar.launchpad.net/~gtg/gtg/trunk/files/head:/GTG/plugins/urgency_color/

Can you please reinstall?

[Izidor Matušov (izidor)]

I forgot to include that file in setup.py, solved in rev 1106. It should work now.

[Roquentin (antonio-roquentin-deactivatedaccount)]

Thanks for the nice plugin. May I suggest adding a color code for overdue tasks? At the moment there is no way in GTG to visually mark these tasks, since bold font applies equally to both due today and overdue tasks. I know this would already make 4 colors - and that these tasks simply shouldn't be there in the first place :-) - but it could be a useful feature.

[Wolter HV (wolterh)]

This might be a good idea, perhaps a grey tone or blue. What do you think?

Also, I just read Lionel Dricot's suggestion: I think those are good ideas, but I wouldn't want the plugin to "invent" start dates. If the user puts no start date, it is assumed that he does not want the task to be colored. However, I support your idea of having GTG set a start date automatically if you want to.

[Roquentin (antonio-roquentin-deactivatedaccount)]

I am not sure about the best default color for overdue tasks. Perhaps a darker red or purple? But blue and grey are also fine.

Quick feedback on plugin usability (in case you are interested in): I ended up using white for the background of tasks I don't have to worry about. Actually I wonder whether those tasks need any color coding at all. Anyway, the user is free to choose now. Thanks again.

[Wolter HV (wolterh)]

Well, of course, feedback is *always* welcome! But yes, one of the primary goals I have is to let the user chose customize where due, so I am glad you could chose your favorite color for low urgency tasks!

[Roquentin (antonio-roquentin-deactivatedaccount)]

I realized that if I wanted somewhat darker colors for the cell background, I needed a white foreground color for the text. The solution for tags-based coloring in GTG is to always use a very pale background. For urgency-based coloring I think it makes sense to use dark backgrounds for specific tasks (e.g. overdue).

I ended up changing lilblarch so that text is rendered white if the background brightness is larger than a threshold, see attached. Any better ideas?

[Roquentin (antonio-roquentin-deactivatedaccount)]

I was eager to get coloring for overdue tasks, so here is a patch that does it. For sure it's not ideal, but it works for me.

[Wolter HV (wolterh)]

Thank you very much for your contributions Antonio! The font foreground color dynamic is an excellent addition to the GTG project indeed. I will take a look at the patch so it is applied to the plugin. Again, thanks!

[Wolter HV (wolterh)]

I have checked the overdue patch, which I completely approve, but the foreground color patch I could not apply:

The text leading up to this was:
--------------------------
|diff --git a/liblarch_gtk/__init__.py b/liblarch_gtk/__init__.py
|index 3e4b3be..14896f2 100644
|--- a/liblarch_gtk/__init__.py
|+++ b/liblarch_gtk/__init__.py
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
bzr: ERROR: Patch application failed

I am guessing you made your code edits based on an older GTG version?

[Wolter HV (wolterh)]

I think we should move this overdue topic on to a new bug report, and for other readers: Any bug you find on the urgency-color plugin, please report as a new bug!

[Roquentin (antonio-roquentin-deactivatedaccount)]

I agree we should close this report. I think the plugin is ready and I am enjoying it :-)

Concerning the fg color patch: I simply got liblarch from git and modified the file liblarch_gtk/__init__.py. Anyway, I will open a separate bug for that.

[Roquentin (antonio-roquentin-deactivatedaccount)]

Wolter: for the white fg color story, follow Bug #1002083. I will open a bug report to discuss the issue of overdue tasks, ok?

[Wolter HV (wolterh)]

That is perfect. Lets do it just for the record, because I have already patched with your patch and made some further changes which I will discuss in this new bug you (or I, if you prefer) will report.

[Roquentin (antonio-roquentin-deactivatedaccount)]

Opened Bug #1002160 for overdue tasks in this plugin.

[Wolter HV (wolterh)]

Izidor, I finally found more appealing to have gradient coloring and implemented it on my branch lp:~wolterh/gtg/urgency_gradient, which I have linked to this bug.

[Wolter HV (wolterh)]

Oh I forgot to say that the branch may require previous merging of the branch lp:~wolterh/gtg/bug1039655

[Roquentin (antonio-roquentin-deactivatedaccount)]

Hi Wolter, I was curious to check out your branch. How is the coloring supposed to work now? Also I am not sure if it was a problem with my local config file but the "Configure plugin" button in the plugin menu was greyed out.

[Wolter HV (wolterh)]

@2013-02-08 18:29 - Antonio Roquentin:
> Hi Wolter, I was curious to check out your branch. How is the coloring
> supposed to work now? Also I am not sure if it was a problem with my
> local config file but the "Configure plugin" button in the plugin menu
> was greyed out.

Oh well, glad to hear! Now the same three colours are used, only that
now they change gradually from the one to the next. And yes, it should
be a problem with your configuration for I can test it running the debug
script (located at /scripts/debug.sh). Please tell me what you think!

[Roquentin (antonio-roquentin-deactivatedaccount)]

On line 107 there is

grad_half_dayspan = grad_dayspan/2

which gives problems when grad_dayspan = dayspan - reddays = 1, since they are all integers (eventually I get a float division by zero). I will do some more testing and come back (probably opening a new report...)

[Wolter HV (wolterh)]

@2013-02-11 13:06 - Antonio Roquentin:
> On line 107 there is
>
> grad_half_dayspan = grad_dayspan/2
>
> which gives problems when grad_dayspan = dayspan - reddays = 1, since
> they are all integers (eventually I get a float division by zero). I
> will do some more testing and come back (probably opening a new
> report...)

Oh yeah I forgot that line :) it is fixed now, thanks for pointing it out!

Wolter Hellmund