Task Management System: Difference between revisions

From Adam Colton
Jump to navigation Jump to search
No edit summary
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 3: Line 3:
People act like they have limited tasks and unlimited time, but just the opposite is true. And it gets worse - not only is our time limited, but so is our will power. Over do it, we burnout. So how do we pick a set tasks that can actually finish, feel good about and burn ourselves out? This should help.
People act like they have limited tasks and unlimited time, but just the opposite is true. And it gets worse - not only is our time limited, but so is our will power. Over do it, we burnout. So how do we pick a set tasks that can actually finish, feel good about and burn ourselves out? This should help.


== Road Blocks ==


== Tasks ==
== Tasks ==
Line 28: Line 29:
*** y011504150815 would be the 15th of January, April and August every year.
*** y011504150815 would be the 15th of January, April and August every year.
* Locked: a locked task cannot change it's date (except on complete/repeat cycle)
* Locked: a locked task cannot change it's date (except on complete/repeat cycle)
At some point I may want to add a months number to monthly repeats (month day and date), allowing repetition ever N months. I'm also considering changing the day pattern so that 00 would mean the first sunday rather than sunday of the first week, because most first weeks don't have a sunday.


Automated Re-balancing, day or all. If you rebalance a day - tasks in reverse priority order will be pulled off and bumped to the next fit. If you rebalance all, each day, in succession will get rebalanced (for the next two weeks).
Automated Re-balancing, day or all. If you rebalance a day - tasks in reverse priority order will be pulled off and bumped to the next fit. If you rebalance all, each day, in succession will get rebalanced (for the next two weeks).


One note, I previously supported task dependency spawning (create one task when another was completed), that is going to be handled with projects this time.
=== V0.2 ===
Add a task end date. After which it will no longer repeat and if it is not completed by that point, it will automatically be deleted.


== Users ==
== Users ==
Line 53: Line 57:
*# When tasks are added, they are added to the current date
*# When tasks are added, they are added to the current date
*# When tasks are added, they are added to next fit
*# When tasks are added, they are added to next fit
* Repetition
* RepetitionStage


Projects are a way to group tasks into sets of dependencies. A project is divided into stages, tasks belong to a project-stage.
Projects are a way to group tasks into sets of dependencies. A project is divided into stages, tasks belong to a project-stage.
Line 60: Line 66:
All tasks in project not in the current stage will be placed on the backlog (not given a date). As soon as one stage is complete, all the tasks from the next stage will be added, following auto-balance rules.
All tasks in project not in the current stage will be placed on the backlog (not given a date). As soon as one stage is complete, all the tasks from the next stage will be added, following auto-balance rules.


There are some questions I need to think about more - how will repeating tasks be handled? can a project repeat? should there be conditionals?
There are some questions I need to think about more - how will repeating tasks be handled? should there be conditionals?


== Rewards ==
Projects can repeat. They use the repetition object. The repetition is tied to completing a stage. Just like tasks, when a project repeats, it makes a full copy of itself.
Two tables, one for users to define rewards. The other for them to track when they cash in points for a reward.


== UI ==
== UI ==
The first UI I build is going to be plain HTML, just to stub out the functionality. Lauren will build the rest.
The first UI I build is going to be plain HTML, just to stub out the functionality. Lauren will build the rest.


== API ==
== Rewards ==
* /user/new
Two tables, one for users to define rewards. The other for them to track when they cash in points for a reward.
** Operation: creates a new user
** Required: username, password
** Returns: userid
* /user/login
** Operation: login
** Required: username, password
** Returns: userid
* /task/new
** Operation: Creates a new task
** Required: title
** Optional: date, priority, points, automation
** Returns: task object (json)
* /task/update
** Operation: Updates attributes of a task
** Required: task id
** Optional: any task attributes
** Returns: task object (json)
* /task/delete
** Operation: deletes a task
** Required: task id
** Returns: confirmation
* /task/done
** Operation: Marks a task as done
** Required: task id
** Returns: confirmation
* /timer/new
** Operation: creates a new timer
** Required:
** Optional:
** Returns:


* template
== Hats ==
** Operation:
This is 'context' or 'domains'. Allows users to have different point patterns and exceptions and place tasks into different 'categories'. The objective is to let people divide things like personal, work and school into different categories.
** Required:
** Optional:
** Returns:

Latest revision as of 18:05, 18 October 2013

I've worked on a number of these over the years. The current one is pretty good and mostly meets my need. However, I want to rebuild it and add a little more rigor.

People act like they have limited tasks and unlimited time, but just the opposite is true. And it gets worse - not only is our time limited, but so is our will power. Over do it, we burnout. So how do we pick a set tasks that can actually finish, feel good about and burn ourselves out? This should help.

Road Blocks

Tasks

  • Title
  • Date (null puts it on a backlog) - I've run into a lot of trouble with this in the past, I think I'll store it as an int this time representing days since 8/13/84
  • Points
  • Priority: Priority is high, medium, low and critical. Critical ignores point balancing, so all critical tasks end up on today if you do an automatic rebalanced, even if that violates point balancing. H/M/L will rebalance allowing higher tasks to get done sooner, but still obeying point balancing.
  • Notes
  • Repetition - Only once instance of a task can be active at a time. All other instances appear as 'ghosts'. When a task is completed, the points are given and the active instance gets moved to the next day.
    • After Complete
      • r[n] where n is any integer
      • Repeats n days after the task is completed
    • Weekly Pattern
      • w[(0-6)*] for instance w135 for mon, wed, fri
      • Task will recur on the next weekday matching the pattern
    • Monthly day pattern
      • m[((0-5)(0-6))*] for every two integer set, the first number is the week (0-5) and the second integer is the day of the week
      • m1131 would be the second and fourth monday of a month
    • Monthly Date pattern
      • M[(-/+)01-31*] every signed two integer pair represents a day of the month, if a number is negative, it counts from the end of the month.
      • M+01+15-1 would the 1st, 15th and last day of every month
    • Year Pattern
      • y(((01-12)(01-31))*] the first two integers would be the month, the second two would be the date
      • y011504150815 would be the 15th of January, April and August every year.
  • Locked: a locked task cannot change it's date (except on complete/repeat cycle)

At some point I may want to add a months number to monthly repeats (month day and date), allowing repetition ever N months. I'm also considering changing the day pattern so that 00 would mean the first sunday rather than sunday of the first week, because most first weeks don't have a sunday.

Automated Re-balancing, day or all. If you rebalance a day - tasks in reverse priority order will be pulled off and bumped to the next fit. If you rebalance all, each day, in succession will get rebalanced (for the next two weeks).

V0.2

Add a task end date. After which it will no longer repeat and if it is not completed by that point, it will automatically be deleted.

Users

  • point-to-minute conversion
  • points per day pattern
  • viewing preferences
  • Project auto-balance default

Points Per Day

Kind of a one-off. This table allows the user to set a single day to a value other than the built in default.

Timers

  • Title
  • Done

Projects

  • Title
  • Auto-Fill Setting
    1. Tasks will not be automatically added, only tracked
    2. When tasks are added, they are added to the current date
    3. When tasks are added, they are added to next fit
  • Repetition
  • RepetitionStage

Projects are a way to group tasks into sets of dependencies. A project is divided into stages, tasks belong to a project-stage.

I should be able to sum up the points in a project and come up with a completed percentage.

All tasks in project not in the current stage will be placed on the backlog (not given a date). As soon as one stage is complete, all the tasks from the next stage will be added, following auto-balance rules.

There are some questions I need to think about more - how will repeating tasks be handled? should there be conditionals?

Projects can repeat. They use the repetition object. The repetition is tied to completing a stage. Just like tasks, when a project repeats, it makes a full copy of itself.

UI

The first UI I build is going to be plain HTML, just to stub out the functionality. Lauren will build the rest.

Rewards

Two tables, one for users to define rewards. The other for them to track when they cash in points for a reward.

Hats

This is 'context' or 'domains'. Allows users to have different point patterns and exceptions and place tasks into different 'categories'. The objective is to let people divide things like personal, work and school into different categories.