Trend indicators

[rozie]

For each track count trend to show if it is increasing, decreasing or constant. Arrow up, arrow down and equal sign or plus and minus and equal sign as an idea to indicate trend.

It could be visible as small sign on the track icon on main page and in track details. The last one creates possibility to count trend for different time periods. User could choose in settings if trend should be visible on main screen and for which period.

At this moment I'm not going into details how exactly trend should be counted, can make research and provide info if you like the idea.

[lordi]

Hey, I like the idea and have thought of a similar one before. Maybe there is a trending detector that works for variable time ranges (i.e. it works as expected for low-frequency and high-frequency tracks).

[rozie]

I did a little research. Probably linear regression will be fine here. https://en.wikipedia.org/wiki/Linear_regression There are also some Java implementations in replies to http://stackoverflow.com/questions/5684282/weighted-linear-regression-in-java

It should work for any time period, the only problem I see is longer time period (month, quarter) in it's middle. For example if we have 30, 35, 40, 20 for January, February, March, April and we have 18th of April we can't use value 20, we need to adjust it (20/18 = x/31; x = 34). Or, if we have unaggregated data, we can use raw values. It may be a bit more costly, but it isn't calculated often.

[StefRe]

Great idea. Now that we don't need the "Days since last" summary number anymore, as you can directly read this number in the Streaks/Breaks chart (last downward peak), we could use this summary number to show a trend indicator. Being that today is Labor Day, I decided to do some labor and throw together a makeshift implementation based on the slope of a linear least square fit over the last 14 days (this intervall will be adjustable by the user later). The trend is indicated by a tilted arrow. For clearer visualization and because trends with more than 45° slope are thought to only rarely occur in real life, I limited the range to +/- 45°, i.e. a straight upright arrow stands for a 45° slope. Example with a slope of .116 resulting in an arrow angle of 10.5°:

Plain linear regression is of course a very rough indicator, not taking into account possible seasonal changes and irregular influences but we're not going to write a statistics app after all. Nevertheless some question need to be clarified:

• Should we take the current day into account when calculating the slope (if there are no ticks for the active day - will they be entered later that day?) Right now the active day is included, just for simplicity of calculation.
• How to deal with extreme numbers of ticks on some days (outliers) - they can considerably distort the slope of the linear regression line. No idea yet (again without writing a statistics app).
• What to do if the time range of available ticks is shorter than the selected trend range (if we chose a trend range of say 2 weeks but the first/earliest tick is only 10 days ago). I guess in this case it's best to show a "?" as with a not available weekly average.

I still have to fiddle with the arrow rotation - as you can see right now it doesn't exactly rotate around the center. I also plan to let the user choose different trend ranges (say 2 weeks, 1 month, 3 months, 6 months, 1 year) in the settings preferences (and give the trend range in the caption below the arrow).

[rozie]

This looks even better than I expected. I wanted to show only if trend is increasing, constant or decreasing (so 3 values), but this solution even gives some information of value/speed of change. Great. :-)

It's just a simple mobile app, so I suspect we can skip all those advanced statistics. What I like most in Tickmate is simplicity and usability. So showing simple trend is OK IMHO.

Answering questions:

1. I'd include the current day. It may change (lower) the value of the trend, but on the other hand it may be motivator to do activity that day or to do it more times. If it's simpler and people don't complain - leave it.
2. I'm problably not good person to answer that question as I only use one bit value (did or not), but I'd leave it as is. If people start to complain, they should have an idea how it should work, so then linear regression can be changed for something else. But right now I'd stick to linear regression with all it's pros and cons.
3. If you plan to show one trend only (I thought about counting trends for daily, weekly, etc. values...), and let user choose the range, I'd count what user has chosen with zeros in place of missing values. We don't now if user really wanted to start activity when he performed it for the first time. That would be the problem if trend is counted for all periods, but I assume now we can just stick to the user's choice.

[StefRe]

Regarding item 3: In the end I decided to only show trends when the requested trend range is not greater than the period for which there are ticks recorded. We don't know when the user actually started recording ticks, the only thing we know is the date of the first tick. There is a similar problem with three other summary statistics: the weekly mean, the longest break, and the breaks portion of the streaks/breaks chart. All these only start with the first tick, although this tick might have been preceded by a break - but we don't know how long this break was. Therefore these statistics can't take it into account and only start with the first tick. For consitency reasons, I think we should handle it the same way with trends. At first I thought this problem could be solved by saving the creation date of the track (which would of course only work for new tracks, not for already existing ones), but then again we have the possibility of deactivating a track - so there might be a break simply because the user temporarily deactivated this track. This is why I decided to just let it be the way it is now.

[StefRe]

I did some further research on this topic. For single tick tracks, there is a maximum absolute value of the slope that can’t be exceeded. The maximum slope will be reached when one half of the range is all ticked and the other half is empty. This maximum slope for a range of n days is

This gives the following values and shows that there will be a more or less horizontal arrow in most of the cases for single tick tracks:

Trend range	Days	Maximum slope	Maximum arrow angle
1 week	7	0.21429	12.1°
2 weeks	14	0.10769	6.1°
1 month	30	0.05006	2.9°
3 months	91	0.01648	0.9°
6 months	183	0.00820	0.5°
1 year	365	0.00411	0.2°

From this I see two options:

• Scale the trend for each range to its maximum value (e.g. a 2-week trend slope of .10769 will result in a vertical arrow) to ensure maximum spreading of the scale.
• Scale all trends to the maximum value of the 1-week trend to make them directly comparable to each other.

I favor the first option, as with the second one the 1-year arrow still will be restricted to +/- 1.8° which is practically horizontal.

Trends for multi tick tracks obviously can have any slope. Right now it is capped at 1.0 (= 45° slope) and this maximum value is shown as a vertical dashed arrow. As it is not visible from the summary charts whether the track is single or multi tick I’d prefer treating them equally, i.e. apply the same rules for the trend indicator angle for multi tick tracks as for single tick tracks.

[lordi]

I'd vote for the first option as well. Having a clear indication of trend is more important than comparability between the angles for different timespans IMO.