Implement numerical habits with AT_MOST target type

[KristianTashkov]

This implements the option to select target type in Habit creation and editing. Screen looks like this:

There are multiple changes to make this work throughout the app. We can pick and choose which to merge or which to change. A list of the changes I'm introducing:

1. Habit screen option to select target type
2. Score formula changes.
   • There was a bug in numerical rolling sum calculations where not entered days were adding +1 to the rolling sum (since they are -1 originally)
   • Implement the formula in the AT_MOST case. It basically has two thresholds. Below the target you are considered 100% completed. Between the target and twice the target, you are getting linearly less progress. After twice the target you have 0% completeness
3. The color in the general Habit List to be calculated correctly for AT_MOST.
4. The color in the calendar view. To be honest even the AT_LEAST implementation is weird there, but tried to capture it's meaning respectively for AT_MOST
5. The check whether something is completed or failed seems to be disconnected from the colors on the main screen (we are not dividing by denominator). I added it but it might have been intended?

In general a good question for us to answer is how do we want to treat not entered values for AT_MOST. If we take the 0 we have today for numerical habits, it means that an AT_MOST habit is automatically completed on a not entered day, instead of the usual "auto fail".

[iSoron]

Thanks for working on this, @KristianTashkov. A few thoughts:

• The scoring formula is fine. Thanks also for identifying and fixing that existing issue.
• In the main screen, I think we should only use lowConstrast for question marks (that is, if question marks are enabled and if no data is entered for that day). Everything else should be either colorful (if the target is met) or mediumConstrast (otherwise).
• Currently, when you create a new "at most" habit, the score starts at zero and the calendar starts completely blank. However, if you add one repetition a few weeks ago, the score suddenly jumps up, and many days in the calendar suddenly lighten up. I think this is quite unexpected. The issue here is that the app currently assumes that everything before the first repetition is a failure. Ideally, the score should start at 100% and the entire calendar should start lightened up. This might be tricky to implement. I think we will need to provide a default value both to the methods that compute the score, and to the calendar chart. On a positive side, implementing this would also help: Allow some habits to receive a checkmark automatically at the beginning of the day #125.

[KristianTashkov]

In the main screen, I think we should only use lowConstrast for question marks (that is, if question marks are enabled and if no data is entered for that day). Everything else should be either colorful (if the target is met) or mediumConstrast (otherwise).

Yeah I can update this. In general the use of color is very inconsistent in the app, especially between numerical history chart and the main screen. If the default value is not zero, then what should the color/text be on no data entered days if you don't have question marks enabled?

Currently, when you create a new "at most" habit, the score starts at zero and the calendar starts completely blank. However, if you add one repetition a few weeks ago, the score suddenly jumps up, and many days in the calendar suddenly lighten up. I think this is quite unexpected.

In the initial version I started off the habit with a default value of 2 * target so it auto fails when no value is entered. While this makes the charts more consistent, I'm not sure I like the behavior it adds, where you have to open the app every day and say "I didn't do this bad habit, don't penalize me". I can return that behavior if you insist, but the current behavior at least is a bit more consistent with "if I don't track something, nothing happened". I understand how going back and adding a day makes the chart inconsistent, but is this really a valid use case? If you went back to add a new first occurrence, wouldn't you add everything in between too?
Waiting for guidance on how to continue, I see three options:

1. Leave it as is with a default value of 0. I vote for this one
2. Make the default during scoring and history chart color calculation to 2 * target. I don't really like this option but it's your call
3. Try to make the habit start at 100% and have a customizable default value. I think this should be a separate effort to introduce a user set default value for a habit on not-entered days and not part of this PR.

WDYT?

[hiqua]

As I mentioned on your other PR, I think that ideally the UI should have some kind of toggle button instead of a selection with only two options

[iSoron]

@KristianTashkov Sorry for the delay. I agree with you that the default value should be zero. I also agree that making the default configurable would be a different feature and a different PR. I just think that, if we pick zero as the default value, then a natural consequence is that a completely new AT_MOST habit should have a perfect 100% score. My concrete suggestion is to:

1. Initialize previousValue to 1.0 in ScoreList.kt:94 for AT_MOST habits.
2. Initialize value to Square.ON in HistoryChart.kt:192 for AT_MOST habits.

[KristianTashkov]

@iSoron I picked some of my changes from the other PR (#1106) to handle having a different history chart square.
I implemented starting AT_MOST score from 100% and also made lowContrast only be used for question marks, otherwise use mediumContrast for below target (even for zero).
Is there anything else you want me to implement for this?

[iSoron]

Thank you for the changes, @KristianTashkov. See some comments below.

[iSoron]

In general the use of color is very inconsistent in the app, especially between numerical history chart and the main screen.

Could you please elaborate on this? What do you find inconsistent, and do you have any suggestions to improve it?

[KristianTashkov]

Could you please elaborate on this? What do you find inconsistent, and do you have any suggestions to improve it?

We use color to denote different states of habits in two places: main screen and history screen.

YES/NO:

Most of it is okay, color means completed, half-color (either not full check or dimmed square in history) means auto success, no color means fail. If you have question marks enabled, there isn't a colorful question mark though, it just gets overridden to an auto check and there is no notion of unknown. If you try to "fail" it just reverts to a success. If color means "success" of some kind, shouldn't we have a colorful question mark to indicate "nothing is entered, but you didn't need to today anyway". Then "failing" it just makes it "auto success" vs "manual success".

Numerical

1. No color means unknown or 0. Why is 0 special? If it means failure, shouldn't for AT_MOST everything above 2 * target mean failure as well?
2. Half color means some progress but not enough. Then why is the HistoryChart entirely full for those days, shouldn't it be dimmed like YES_AUTO was?
3. For AT_MOST ff we are giving some score in the range of [target, 2 * target], shouldn't that be some progress and be half colored/history chart dimmed?

In general it seems yes/no uses color to indicate "success", while numerical uses color to indicate "presence of data". I think color should always indicate success for both, and we can use dimness to indicate whether you have fully reached the target, or only made progress towards it. Doing nothing on that day, or going above your 2 * target should then mean failure, similar to NO in yes/no and be without color.

[KristianTashkov]

@iSoron made the changes you requested and added tests for both AT_LEAST and AT_MOST habits when calculating score.

[iSoron]

Thank you for the implementation, @KristianTashkov. I have merged it with some minor UI changes (see the last two commits). I'll comment on the color inconsistencies soon.

[iSoron]

If color means "success" of some kind, shouldn't we have a colorful question mark to indicate "nothing is entered, but you didn't need to today anyway". Then "failing" it just makes it "auto success" vs "manual success".

A question mark indicates that the app does not have sufficient data to determine whether you have successfully completed a habit on a given day. Color, on the other hand, indicates that you have successfully completed the habit. If we stick to these definitions, then the concept of a colorful question mark is unclear to me, since the definitions of "color" and "question mark" seem to contradict each other.

Regarding auto success, if you have a weekly habit, and you completed it yesterday, then today is unequivocally a success, regardless of today's value; so, even if we don't have data about today's value, the app can still confidently say that you have completed the habit; that's the reason why we don't show a question mark.

No color means unknown or 0. Why is 0 special? If it means failure, shouldn't for AT_MOST everything above 2 * target mean failure as well?

The idea here is that light grey means missing data, while dark grey means failure. Note that, if you have question marks enabled, then any zero values are interpreted as missing data. I agree that the current implementation does not follow these conventions. For example, before this PR, we always showed zero values as light grey for numerical habits in the main screen. After this PR, we are always showing zero values as dark grey, regardless of question mark preference. The calendar and history charts are also not following them. PRs to make this more consistent are very welcome.

Half color means some progress but not enough. Then why is the HistoryChart entirely full for those days, shouldn't it be dimmed like YES_AUTO was?

That's not accurate. Color means success, period. For YES/NO habits, in the calendar, we are using different shades and patterns to indicate different types of success (automatic, manual, skip).

[KristianTashkov]

A question mark indicates that the app does not have sufficient data to determine whether you have successfully completed a habit on a given day.

I think this is a very weird definition of the feature and the option in preferences doesn't say that:

Show question marks for missing data

Regardless of whether the day is a success, there is missing data here. We allow a user to add a manual checkmark on a day they weren't expected to, so until they provide us with a checkmark, or confirmation that they didn't do the habit this day, this is missing data to me.
Specifically for my use case: I try to have an entry for each habit every day, and I use the ? to find which habits I haven't given an explicit value today. The current auto success breaks that. And to add to that with its current implementation, there isn't even a guarantee that a current YES_AUTO won't convert to ? based on future days.
Right now both types of numerical habits start the day with ?, only YES/NO are not following this rule.

That's not accurate. Color means success, period. For YES/NO habits, in the calendar, we are using different shades and patterns to indicate different types of success (automatic, manual, skip).

Then why is 5 out of 10 in a numerical AT_LEAST habit colored with full color, it's definitely not a success, but it's shown that way? In the main view it's also not shown with full color making it different than the calendar. There was a recent ticket for this as well, wondering why are we not showing these days as failures. I think we already have the dimmed option, I see no reason why we shouldn't use it to indicate the middle state of "some progress, but neither full failure or full success". We have this concept in scores, why not reflect it in the UI?

[iSoron]

I think this is a very weird definition of the feature and the option in preferences doesn't say that: [...] Regardless of whether the day is a success, there is missing data here.

Perhaps we could clarify the option title, but the expanded description already clarifies that question marks are supposed to differentiate between actual lapses (NO) from days with missing data (UNKNOWN). We make no promises about using question marks to differentiate anything else, so I don't see any inconsistencies here. It's also clear to me that question marks should not be colored.

Specifically for my use case: I try to have an entry for each habit every day, and I use the ? to find which habits I haven't given an explicit value today. The current auto success breaks that.

Please feel free to open a feature request for that. (I think we might already have one).

Then why is 5 out of 10 in a numerical AT_LEAST habit colored with full color, it's definitely not a success, but it's shown that way?

That's a bug.

I think we already have the dimmed option, I see no reason why we shouldn't use it to indicate the middle state of "some progress, but neither full failure or full success". We have this concept in scores, why not reflect it in the UI?

The initial implementation used a color gradient to indicate level of completeness. The main issue is that light colors look too similar to grey, so it was hard to distinguish whether data was missing, or if the data was there, but had value close to zero. This was specially true for some palette colors, such as yellow. If we are using a single dimmed color, it's unclear to me the advantages when compared to just using grey.