Moon-Jumper Tasks: Difference between revisions

From Adam Colton
Jump to navigation Jump to search
No edit summary
 
(27 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Basic Fields ==
The task system is more than just a check list. It helps manage productivity at 3 stages.
 
When planning, it helps break projects into smaller pieces and see the dependencies between those pieces and set the priority relative to all other ongoing projects. This aids in setting realistic expectations.
 
Day-to-day it should actively filter what tasks can be worked on and which are the most important. This reduces the visible list down to something that represents a days work in a limited context (home, work, school).
 
By tracking the data and providing analysis, it can make predictions and highlight areas for improvement. Knowing how long a medium priority tasks sits before completion helps predict when a specific task will be done. Knowing the average workload or the ratio of work created to work completed is valuable. Seeing the distribution of high, medium and low priorities can help re-asses what those values really mean.
 
== Tasks ==
A task can take a list of conditions. It will only show up as active when all it's conditions are met.
 
=== Basic Fields ===
* Name: name of task
* Name: name of task
* Notes: additional notes, hyperlinks are automatically linked. Should add a task notation link too.
* Notes: additional notes, hyperlinks are automatically linked. Should add a task notation link too.
Line 5: Line 16:
* Label: task context
* Label: task context


== Read-Only / Computed Fields ==
I was going to have an "Expires", but conditions have the permanence flag. If a condition becomes permanently false, the task expires.
 
=== Read-Only / Computed Fields ===
* State
* State
** Active: task can be worked on. It will show up in lists and when the priority is high enough, it will show up in the main list
** Active: task can be worked on. It will show up in lists and when the priority is high enough, it will show up in the main list
** Backlog: tasks assigned to the backlog will never become active until they are removed.
** Pending: some pre-req hasn't been met.
** Pending: some pre-req hasn't been met.
* Group: Task is
* Date Active: when a task changes from pending or back log to active, this is updated.
* Date Active: when a task changes from pending or back log to active, this is updated.
* Date Complete: date when a task is marked as done
* Date Complete: date when a task is marked as done


== Conditions ==
== Conditions ==
* Date: when a task is given a date, it will not be active until after that date.
Under the hood, I think this needs to be a little more complex that True/False. A condition should ternary T/?/F. And it should indicate if it will ever change.
* Task: a task can be made dependent on other tasks, it won't be active until all dependent tasks are completed.
* Group Stage: a task can be added to a group, it is part of a stage. Only when all prior stages are complete can you work on that task
* Date: Takes a date and before/after.
* Computed: Takes a date repeater and a date event; 3 days after this task is done.
* Date Range: Takes two month/day and returns true for dates in between.
* Date Range: Takes two month/day and returns true for dates in between.
* Set: creates a set of conditions so that if you want several things to work off the same conditions, they can all be wired to the same set.
* Set: creates a set of conditions so that if you want several things to work off the same conditions, they can all be wired to the same set.
* Weather: takes the users location and lets user exclude tasks based on certain weather conditions (temperature, rain probability). One catch is that this should not reset the active date. This is a nice-to-have.


UI Conditions
UI Conditions
Line 26: Line 39:
UI conditions can themselves have display conditions. So a button can be set to not show up until some task is complete.
UI conditions can themselves have display conditions. So a button can be set to not show up until some task is complete.


== Maybe Conditions ==
Values with in the task system itself can be used as conditions. The condition can be linked to the item being either done or active.
* Weather: takes the users location and lets user exclude tasks based on certain weather conditions (temperature, rain probability). One catch is that this should not reset the active date.
* Task
* Group
 
Operators
* AND
* OR
* NOT
I may not need AND. The combination of any two conditions is treated as an AND, so an OR would stand alone.
 
It will be really cool if these can show up as red/green indicators in the UI.
 
Backlog becomes a condition that always returns non-permanent false. Not sure if I want to display it that way.
 
=== Database Model ===
The challenge is that I need something where I can efficiently ask
  select all conditions where condition_set = X
and then iterate over the results and see what needs to be computed
 
Ways to do this:
* Polymorphic: store type+ID, requires doing one select per table.
* Unified Table: Can get bulky
* Binary Table: hold the common fields (id, type, value, permanent) in the table, then gob the rest of the struct and put it in a binary field.
 
I think I like the last.


== Repeaters ==
== Repeaters ==
A repeater returns the next date in a sequence, or returns nothing, indication end of repetition.
Need repeaters for each object.


=== Task Repeater ===
Title, label, points and priority are all copied
It may make more sense to just have a UI for task group repeat and you can have a group repeat with a single task. Easier than two different UI's for single vs multi tasks.
==== Notes Repeater ====
Notes either repeat off a base template or off the last instance.
=== Conditional Repeater ===
==== Date Repeater ====
* Until: Will repeat until all it's conditions are met. Always returns today or nothing.
* Until: Will repeat until all it's conditions are met. Always returns today or nothing.
* Days: Repeats some number of days after completion
* Days: Repeats some number of days after completion
Line 37: Line 83:
* Month: Repeats by day of the month, negative means counting from the end of the month.
* Month: Repeats by day of the month, negative means counting from the end of the month.
* Date: Takes a month/day.
* Date: Takes a month/day.
=== Button/Switch Repeater ===
Make a new or keep a link to the old


== Priority ==
== Priority ==
Line 46: Line 95:
* How would you promote a task?
* How would you promote a task?
* What to do when changing priority?
* What to do when changing priority?
It might be nice to let users set a prioriy-profile-goal defining their goal for a ratio of H/M/L tasks.
I might bring back priority date gradients.


== Label ==
== Label ==
Maybe do calendar import: Import a calendar and scale a labels point based on free time.
Maybe do calendar import: Import a calendar and scale a labels point based on free time.
Label points could be done with conditionals too. Say a Label has a default point value. You can attach conditions. The highest value condition will be returned.
Should let people give Labels a color and an icon.
== Special Views ==
A lot of the views are just CRUD, but a few are worth mentioning.
* Main task list: this filters everything down to a list for today. It doesn't just show todo, it also keeps tasks complete visible.
* Dashboard: Show productivity statistics; points completed per category for the last week and last month. Ratio of H/M/L tasks. Points created per category and maximum point recurrence.
== Task Groups ==
We can get rid the of the Group/GroupStage model. Instead, we'll have an actual, simple task Group. A task group has tasks or sub groups. A group can have a condition set. And a group produces two conditions (active, done). A group can have a label, a group can be backlogged. A group can have a priority, but that just sets the default priority when adding a task.
There are interesting operations on a group:
* Show all tasks dependent on the tasks in the group.
* Backlog all tasks in group.
== Tools ==
JS Graph tools
* http://arborjs.org/
* https://github.com/d3/d3/wiki/Gallery
** https://bl.ocks.org/mbostock/950642


[[Category:Moon-Jumper]]
[[Category:Moon-Jumper]]

Latest revision as of 12:08, 25 October 2017

The task system is more than just a check list. It helps manage productivity at 3 stages.

When planning, it helps break projects into smaller pieces and see the dependencies between those pieces and set the priority relative to all other ongoing projects. This aids in setting realistic expectations.

Day-to-day it should actively filter what tasks can be worked on and which are the most important. This reduces the visible list down to something that represents a days work in a limited context (home, work, school).

By tracking the data and providing analysis, it can make predictions and highlight areas for improvement. Knowing how long a medium priority tasks sits before completion helps predict when a specific task will be done. Knowing the average workload or the ratio of work created to work completed is valuable. Seeing the distribution of high, medium and low priorities can help re-asses what those values really mean.

Tasks

A task can take a list of conditions. It will only show up as active when all it's conditions are met.

Basic Fields

  • Name: name of task
  • Notes: additional notes, hyperlinks are automatically linked. Should add a task notation link too.
  • Points: time/energy requirements of the task
  • Label: task context

I was going to have an "Expires", but conditions have the permanence flag. If a condition becomes permanently false, the task expires.

Read-Only / Computed Fields

  • State
    • Active: task can be worked on. It will show up in lists and when the priority is high enough, it will show up in the main list
    • Pending: some pre-req hasn't been met.
  • Date Active: when a task changes from pending or back log to active, this is updated.
  • Date Complete: date when a task is marked as done

Conditions

Under the hood, I think this needs to be a little more complex that True/False. A condition should ternary T/?/F. And it should indicate if it will ever change.

  • Date: Takes a date and before/after.
  • Computed: Takes a date repeater and a date event; 3 days after this task is done.
  • Date Range: Takes two month/day and returns true for dates in between.
  • Set: creates a set of conditions so that if you want several things to work off the same conditions, they can all be wired to the same set.
  • Weather: takes the users location and lets user exclude tasks based on certain weather conditions (temperature, rain probability). One catch is that this should not reset the active date. This is a nice-to-have.

UI Conditions

  • Button: Can only be pressed once.
  • Switch: Can switch on and off.

UI conditions can themselves have display conditions. So a button can be set to not show up until some task is complete.

Values with in the task system itself can be used as conditions. The condition can be linked to the item being either done or active.

  • Task
  • Group

Operators

  • AND
  • OR
  • NOT

I may not need AND. The combination of any two conditions is treated as an AND, so an OR would stand alone.

It will be really cool if these can show up as red/green indicators in the UI.

Backlog becomes a condition that always returns non-permanent false. Not sure if I want to display it that way.

Database Model

The challenge is that I need something where I can efficiently ask

 select all conditions where condition_set = X

and then iterate over the results and see what needs to be computed

Ways to do this:

  • Polymorphic: store type+ID, requires doing one select per table.
  • Unified Table: Can get bulky
  • Binary Table: hold the common fields (id, type, value, permanent) in the table, then gob the rest of the struct and put it in a binary field.

I think I like the last.

Repeaters

Need repeaters for each object.

Task Repeater

Title, label, points and priority are all copied

It may make more sense to just have a UI for task group repeat and you can have a group repeat with a single task. Easier than two different UI's for single vs multi tasks.

Notes Repeater

Notes either repeat off a base template or off the last instance.

Conditional Repeater

Date Repeater

  • Until: Will repeat until all it's conditions are met. Always returns today or nothing.
  • Days: Repeats some number of days after completion
  • Week: Repeats by day of the week.
  • Month: Repeats by day of the month, negative means counting from the end of the month.
  • Date: Takes a month/day.

Button/Switch Repeater

Make a new or keep a link to the old

Priority

This is always hard to get right.

I like the 4 priority stages I use. 3 normal levels and Now that means it always shows up in the main list (overriding point limits).

I'd like to add a hidden secondary priority. Each priority level forms a queue. When a task becomes active, it's set to the bottom of it's priority queue. You can also "Bump" a task to send it to the bottom of the priority queue.

  • How would you promote a task?
  • What to do when changing priority?

It might be nice to let users set a prioriy-profile-goal defining their goal for a ratio of H/M/L tasks.

I might bring back priority date gradients.

Label

Maybe do calendar import: Import a calendar and scale a labels point based on free time.

Label points could be done with conditionals too. Say a Label has a default point value. You can attach conditions. The highest value condition will be returned.

Should let people give Labels a color and an icon.

Special Views

A lot of the views are just CRUD, but a few are worth mentioning.

  • Main task list: this filters everything down to a list for today. It doesn't just show todo, it also keeps tasks complete visible.
  • Dashboard: Show productivity statistics; points completed per category for the last week and last month. Ratio of H/M/L tasks. Points created per category and maximum point recurrence.

Task Groups

We can get rid the of the Group/GroupStage model. Instead, we'll have an actual, simple task Group. A task group has tasks or sub groups. A group can have a condition set. And a group produces two conditions (active, done). A group can have a label, a group can be backlogged. A group can have a priority, but that just sets the default priority when adding a task.

There are interesting operations on a group:

  • Show all tasks dependent on the tasks in the group.
  • Backlog all tasks in group.

Tools

JS Graph tools