Moon-Jumper Tasks: Difference between revisions

From Adam Colton
Jump to navigation Jump to search
 
(12 intermediate revisions by the same user not shown)
Line 15: Line 15:
* Points: time/energy requirements of the task
* Points: time/energy requirements of the task
* Label: task context
* Label: task context
* Active : Condition


I was going to have an "Expires", but conditions have the permanence flag. If a condition becomes permanently false, the task expires.
I was going to have an "Expires", but conditions have the permanence flag. If a condition becomes permanently false, the task expires.
Line 22: Line 21:
* 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.
* 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.
Line 30: Line 28:
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.
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: when a task is given a date, it will not be active until after that date.
* Date: Takes a date and before/after.
* Computed: Takes a date repeater and a date event; 3 days after group stage 2 is done.
* 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.
Line 43: Line 41:
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.
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
* Task
* Group Stage
* Group
* Group


Line 51: Line 48:
* NOT
* NOT
I may not need AND. The combination of any two conditions is treated as an AND, so an OR would stand alone.
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 ==
Line 57: Line 70:
=== Task Repeater ===
=== Task Repeater ===
Title, label, points and priority are all copied
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 Repeater ====
Notes either repeat off a base template or off the last instance.
Notes either repeat off a base template or off the last instance.
Line 88: Line 104:


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.
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 ==
== Special Views ==
Line 94: Line 112:
* Main task list: this filters everything down to a list for today. It doesn't just show todo, it also keeps tasks complete visible.
* 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.
* 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