| 2012-02-05 21:33:46 |
Wolter HV |
description |
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. |
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. |
|
