Easier to start with an image:
The main idea is to have sequences of targets. Current implementation of targets is basically "do X times per Y days".
What I mean by sequences is to chain targets in one cycle, like "do X times in Y days, repeat Z times; do A times in B days, repeat C times; ....; goto beginning". Above image's first two habits are "do X times in 1 day, repeat 5 times; do 0 times in 2 days"
Implementation on the frontend is straightforward, at least with the current heatmap algo based on buckets (link). Below, I'll reference the variable names from the linked code for convenience.
Uncertainties:
-
Straightforward, but tedious. What currently happens for one target value, will have to first determine at which part of the target's sequence we currently are, before we can safely calculate bucket's width in case of being cut off by dateEnd or nextTarget. That's given that the current heatmap algo doesn't change, and it very well might in the future.
-
Initially thought of making it the default behavior of targets. A sequence of one target is basically how the current targets work, but that would require either a. three new array columns or b. new M2M table. Both add more overhead, which is a bad thing for a cornerstone feature of habit targets. So, defaulting this feature is off the table.
-
There are only two use-cases I can think of that this feature solves nicely, like:
- tracking things that you want to happen only on weekdays/weekends
- doing something with exact gaps, like once in exactly 10 days - "do 1 time in 1 day; do 0 times in 9 days"
Both of these probably don't require the complexity of the general approach that I'm describing here. Hard to justify.
-
DB schema stability. I wanted to implement sequences before the release, so that the 1.0.0 db habit's schemas won't have to be touched for a while. But honestly, with everything already mentioned, if I made it a release feature, I would increase the chances of schema changes down the line.
-
UI/UX. This obviously requires a form submission of its own, some kind of layout to edit it all, and it also raises a question how to even introduce/explain this feature.
Anyway, this is some food for thought. Proper implementation of this can easily take a month, or months even.
Everything above is definitely not a final design, as a feature for chaining 2 targets may be in fact all that's needed, and that wouldn't cause much overhead either.
Easier to start with an image:
The main idea is to have sequences of targets. Current implementation of targets is basically "do X times per Y days".
What I mean by sequences is to chain targets in one cycle, like "do X times in Y days, repeat Z times; do A times in B days, repeat C times; ....; goto beginning". Above image's first two habits are "do X times in 1 day, repeat 5 times; do 0 times in 2 days"
Implementation on the frontend is straightforward, at least with the current heatmap algo based on buckets (link). Below, I'll reference the variable names from the linked code for convenience.
Uncertainties:
Straightforward, but tedious. What currently happens for one target value, will have to first determine at which part of the target's sequence we currently are, before we can safely calculate bucket's width in case of being cut off by dateEnd or nextTarget. That's given that the current heatmap algo doesn't change, and it very well might in the future.
Initially thought of making it the default behavior of targets. A sequence of one target is basically how the current targets work, but that would require either a. three new array columns or b. new M2M table. Both add more overhead, which is a bad thing for a cornerstone feature of habit targets. So, defaulting this feature is off the table.
There are only two use-cases I can think of that this feature solves nicely, like:
Both of these probably don't require the complexity of the general approach that I'm describing here. Hard to justify.
DB schema stability. I wanted to implement sequences before the release, so that the 1.0.0 db habit's schemas won't have to be touched for a while. But honestly, with everything already mentioned, if I made it a release feature, I would increase the chances of schema changes down the line.
UI/UX. This obviously requires a form submission of its own, some kind of layout to edit it all, and it also raises a question how to even introduce/explain this feature.
Anyway, this is some food for thought. Proper implementation of this can easily take a month, or months even.
Everything above is definitely not a final design, as a feature for chaining 2 targets may be in fact all that's needed, and that wouldn't cause much overhead either.