Elevate: Year Progress Rolling Sum migration to the Elevate App

I second this, I love the fitness trend but the 30 day rolling average is invaluable!

I came here to say just this! The 30 day rolling average was one of the most useful features to compare seasons volume. Also the last year distance was quite insightful for those focused on accumulating miles.

It would be very helpful to add last 30 days and last year average distance/time/elevation if possible.

I would also like to take this opportunity to thank Thomas for his inconmensurable project

@ashdriver @DCunnama @fjavipm I understand this feedback. Actually this legacy feature had coded by someone else (by pull request & thanks to him!!). I encountered many bugs with many users and i wasn't able to maintain the feature in the legacy code. That's why i moved (or forced for you...) the old feature to the new one.

I will bring back this this feature and flag it urgent. To be honest i never really understood the concept of 30 day rolling average and last year average distance/time/elevation for my own purpose. So i can imagine that lot of users (excepting you) will not be able to use it properly. I keep in mind that features needs to be accessible for all.

So could you re-explain me the "need", "use case", "problems solved" behind the 30 day rolling average and last year average distance/time/elevation? So i can code it back in the new year progression? This understanding is required to me and for all others users too.

If you want to bring back the old feature you can still download an old build here: https://thomaschampagne.github.io/elevate/#/builds (with filters branch: master, version: 6.8.1)

Hi Thomas,

Thank you for the response and explanation. Ill give my own needs and usage for this, but hopefully others can add more if there are any:

Need:
A way to compare recent and extended training loads (measured by distance or elevation) from one year to the next.

Use Case:
User can select to display plots of rolling 30 day or 365 day average of elevation or distance (shown on y axis), and date on x axis starting at 1 Jan. Each year with available data can be overlaid in a different colour, and ideally also the ability to select/deselect specific years for direct comparisons between them.

Problem Solved:
This gives a reasonably effective way to compare training effort as measured by distance and elevation at particular times of the year compared to previous years. Often athletes train for specific annual events which fall on approximately the same date each year, and being able to easily compare 30day (and to a lesser extent 365 day) rolling averages is a great way to compare preparation for such events.

Optional additional feature request: The ability to adjust the rolling average window between/below 30 days and 365 days might also be useful, although 30 days is a pretty good fixed value I think. Adjusting the window size could be useful to compare training blocks longer (or shorter) than 30 days from year to year - eg marathon training programs are often set over 3 months.

So could you re-explain me the "need", "use case", "problems solved" behind the 30 day rolling average and last year average distance/time/elevation? So i can code it back in the new year progression? This understanding is required to me and for all others users too.

"Last 30 days" is useful to understand variations in training volume specifically by sport. In long endurance sports, volume and intensity are the keys for success. Leaving apart intensity, which can be obtained in HRSS, volume is the simplest part of the equation but often very hard to get right. For example, the last 30 days feature helps you get your ramp rate leading into the last six-to-eight weeks of your peak event.

Just a small correction - I have been talking about 'rolling averages' over 30 and 365 days but actually total accumulated distance/elevation/time over the window is probably more useful and is how this feature was previously implemented.

I also wanted to chime in and go as far as to say that the rolling 30 and 365 day averages have actually been the number one reason that I use your plugin for, so please please please bring it back :)

To answer the question of usefulness, rolling averages are nice ways to have a more reasonable measure of "streaks" that runners love to track. For example I know that I have had at least 3000 mi rolling average on my legs for more than a year now (to be exact 424 days as you see below). These calculations I perform on a separate Google Spreadsheet but it's easy enough to convert to a plot to include in your plugin.

Threshold | Per week | Cum. Miles | Date reached | Days over | Months over
-- | -- | -- | -- | -- | --
1000 | 19 | 1006 | 2016/03/29 | 1044 | 34
1500 | 29 | 1516 | 2016/08/19 | 901 | 29
2000 | 38 | 2001 | 2016/10/21 | 838 | 27
2500 | 48 | 2505 | 2017/06/19 | 597 | 19
3000 | 58 | 3005 | 2017/12/09 | 424 | 13

It's more clear to me from now... I stayed long minutes on my progressions to catch it. I had a wrong vizualization of the feature before... That didn't help me... But from now, it's not rocket science :)

So i will provide these 2 modes:

• The "Standard Cumulative Mode" which currently exists in the app
• And the "Rolling Streak Mode" => Need your help for the right marketing wording ;)

The "Rolling Streak Mode" will have a customisable rolling day value from 1 to 365. Do we should restrict this to fixed values? I mean 1 week, 2 weeks, 1 month, 3 month,.. 6 months, 1 year. Some users may don't know which day count is the best i guess.

The "Rolling Streak Mode" will be applicable to all progress types: distance, time, elevation & count.

I still don't know what we can display in the table (right side)? The rolling delta between years? What about targets?

Of course things i wrote here are not sealed. You can drop your suggestions, ideas, warnings, ... ;) I will link some builds here. So you will be able to test the feature. I will work primarily on that now, others features are in pending state.

Thanks Thomas, I also concur that this was one of my favourite parts of the plugin. I personally think having it defaulted to 1 month, but allowing the user to set it manually would be great.

I would often switch back and forth between the 1 month, and 1 year to easily compare my loads from one year to the next, and see how my training was going, mostly for events such as the Marathon in running, where training amount is really good to see over fatigue etc.

Cheers!

I'd say fixed values are good for the range - 1 week, 2 weeks, 1 month, 3 months,6 months,1 year.
Maybe add 2 months as well?

For the table values and overview I think keep it the same as the existing progression tables - ie delta with previous and current year, as you suggest.

"Rolling Streak Mode" seems like a decent name to call it to me - at least I cant think of anything better!

Thanks again for all the time and expertise you devote to this project - it is very much appreciated.

• And the "Rolling Streak Mode" => Need your help for the right marketing wording ;)

I put the word "streak" in quotes in my original post as streaks mean something specific to runners and that is consecutive days of running. Some runners believe in NDO (no-days-off) and streaks are how long you can go without a day of break. So in that sense calling it "Rolling Streak Mode" might be confusing. I would suggest something like "Rolling Cumulative Mode" or "Windowed Cumulative Mode" implying a time-window where the accumulation takes place.

The "Rolling Streak Mode" will have a customisable rolling day value from 1 to 365. Do we should restrict this to fixed values? I mean 1 week, 2 weeks, 1 month, 3 month,.. 6 months, 1 year. Some users may don't know which day count is the best i guess.

I would suggest to give an option for units (days, months, years) and a number. For example I would love to have my 2-year rolling accumulation as running is a long-game. In addition it would be nice to give the option to overlay 2-3 different parameters, for example 30day & 1year on top of eachother as the latter is a more "smoothed" version of the former. Of course in order for the y-axis to make sense one would need to plot an average value not total as the totals are drastically different. The average could be displayed on a per week basis that a lot of runners track. So in my table above 3000mi/year correspond to 58/week. So if you were to plot 30day&1year on top of eachother you would see how much you deviate from the 58mi/week target.

The "Rolling Streak Mode" will be applicable to all progress types: distance, time, elevation & count.

Sounds good and that makes sense.

I still don't know what we can display in the table (right side)? The rolling delta between years? What about targets?

I didn't include this on the table above but I also track how long it takes to reach the next threshold or delta as you say. One doesn't want to be moving from threshold to threshold too fast as this is recipe for injury/burnout. What I can offer here is that it will be nice to have the thresholds user-settable in either total (1000, 2000, 3000mi etc) or per week (10, 20, 30mi etc) basis and then display how many days or months you have been over the threshold which is something that will be increasing every day.

I will keep an eye on the thread and thanks again for being willing to re-introduce this awesome feature!

• The "Standard Cumulative Mode" which currently exists in the app

I would also suggest in the standard mode to add the option for monthly not just yearly option. Many runners race the same race year over year so it would be nice to have a "reset" per month in order to compare how the January 2019 accumulation stacked against the 2018 accumulation if that makes sense. At this point all this is feature creep :) so I would be more than happy if you just reinstate the previous functionality :)

Actually what about a simple "Rolling Sum"? The standard mode is more like "YTD Sum" (Year To Date). Just a thought.

So i started the development 2 days ago.

I used that at the moment:

export enum ProgressionMode {
    STANDARD_CUMULATIVE,
    ROLLING_CUMULATIVE
}

@mathin "Rolling Sum" & "Year To Date Sum" seems indeed much simpler. I may switch on these. What do you think others?

Some results here !! :) I finished to code the mainstream logic through TDD. And after few bypasses in the UI, here's some results:

"30 days Rolling Sum"

"3 Months Rolling Sum":

"1 Year Rolling Sum":

The "Year To Date Sum" associated:

And the legacy "Last 30d distance" to compare with "30 days Rolling Sum":

That looks perfect, thanks so much for getting round to implementing something so quickly!

You can validate the current behaviour with units tests here: https://github.com/thomaschampagne/elevate/blob/1f48cd28c5c111c6fe826ae6da6b79d8050c583e/plugin/app/src/app/year-progress/shared/services/year-progress.service.spec.ts#L537

And method here: https://github.com/thomaschampagne/elevate/blob/1f48cd28c5c111c6fe826ae6da6b79d8050c583e/plugin/app/src/app/year-progress/shared/services/year-progress.service.ts#L200

Some results here !! :) I finished to code the mainstream logic through TDD. And after few bypasses in the UI, here's some results:

That is absolutely amazing! Thank you so much, I can't wait to start using the new metrics!

One small question/comment. When I compare (only visually of course) the legacy "Last 30d distance" with the new "30 days Rolling Sum", it seems to me that the "Rolling Sum" is more "jagged" or conversely that the legacy "Last 30d" looks a bit more smooth. Is this just an artifact of the plotting functions or is there any additional data smoothing going on the legacy code?

Thanks again!!!

@mathin It's just the d3 curveLinear mode i use: https://github.com/d3/d3-shape#curveLinear

Using _curveNatural_ it gives that:

@mathin again. About your requests:

In addition it would be nice to give the option to overlay 2-3 different parameters, for example 30day & 1year on top of eachother as the latter is a more "smoothed" version of the former. Of course in order for the y-axis to make sense one would need to plot an average value not total as the totals are drastically different. The average could be displayed on a per week basis that a lot of runners track.

Seems much harder to do it "fast", maybe track it in a new issue to be done later.

So in my table above 3000mi/year correspond to 58/week. So if you were to plot 30day&1year on top of eachother you would see how much you deviate from the 58mi/week target.

You lost me :)

Some UI updates and "6 Weeks Elevation Rolling Sum":

This looks very nice and promissing!
I would favor a 4 week rolling sum over 30 days/1month, and 13 weeks over 3 months.
As most people typically exercise on the same day of the week.
Using the week ritme each trip on sunday replaces the trip of the sunday X-back, so the line will a lot smoother and have a lot less wobbles.

I would favor a 4 week rolling sum over 30 days/1month, and 13 weeks over 3 months.
As most people typically exercise on the same day of the week.

That is such a great point, I would also like to see the 4-week rolling sum instead of 30 days. And BTW, I think you meant to write 12 weeks not 13 right?

@bkleingoldewijk @mathin You can choose period you want. Just multiply by number you need.

Excellent!

Bob

Sent from my iPhone

Op 12 feb. 2019 om 18:57 heeft Thomas Champagne <[email protected]notifications@github.com> het volgende geschreven:

@bkleingoldewijkhttps://github.com/bkleingoldewijk @mathinhttps://github.com/mathin You can choose period what you want. Just multiple by number you need.

[image]https://user-images.githubusercontent.com/151973/52657012-f395ee80-2ef7-11e9-81c4-5b43b4792c70.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/thomaschampagne/elevate/issues/760#issuecomment-462865891, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AtN0S2opo7-OK64kFII6bAM1C2Dc1tzRks5vMwCMgaJpZM4ako11.

I am also a big fan of the rolling 30 days and 365 days. I would however also second that a rolling 4 weeks and 52 weeks would be more informative as I tend to have the same cycling pattern in the week. Many thanks.

There are issues with color and contrast. Right now 2019 on my graphs is using a very dark color against a very dark background. Color selection needs to be more careful, or have options for selecting from a pallet.

@jfhaugh the "rolling" palette is defined here: https://github.com/thomaschampagne/elevate/blob/develop/plugin/app/src/app/year-progress/year-progress.component.ts#L43

You can give me your list ;)?

(should work also on light theme)

Might help: https://color.adobe.com/create/color-wheel/

Here's a first testable build of Rolling & Year to date progressions:

v6.9.2_stable_2019-02-23-14-06.zip

Note: To avoid a new sync, you can use a backup of your "official" elevate to restore it into that build.

Of course your help is very welcome to:

• Find bugs on common and twisted cases
• Provide me ideas/text to increase the understanding of the feature (especially the rolling progression which certainly complex for most users). E.g. "Under the button you should write this:", "Add a tooltip hover * and display **", etc...
• Provide me the content of the helper dialog (displayed when you click (?) button)
• Fix my english :)

Thanks for your help and testing :)

Been waiting for rolling metrics for a while — nice @thomaschampagne

Year Progressions Tab

• it would be even better if for the "Years" selection, one could..
  
  
  
  • select all
  
  
  • deselect all
  
  
  • invert selection
  
  
  • last 5 years (e.g.)
    
    (Note: my database goes back to 2003, but the data gets increasingly sparse as I go back in time. It creates a lot of distraction in the graphs. it also is laborious to select or deselect check boxes across almost 20 years)
  
  

• Rolling periods are one of the best features of this software. Kicks ass.
  
  
  
  • customise-able sliding time window would be perfect
  
  
  • or, include 4 weeks or 30 days
  
  

Keep up the good work!

I updated the feature helper if you could take a look at text improvements and english

The source file you can edit and post back: https://github.com/thomaschampagne/elevate/blob/9632d6b28a4a7cfe57b1099c031f9856ae8c2855/plugin/app/src/app/year-progress/year-progress-helper-dialog/year-progress-helper-dialog.component.html

@thomaschampagne thanks again for releasing this amazing new functionality!

I have a small issue to report. The other day, I set the rolling interval to 1-day and looked at my graphs. I was surprised to see values of 30mi+ which seemed rather odd as I am not an ultra guy. I never run more than a Marathon (only on a race day) and even including the pre-race warm-up (max 1mi) I would never exceed a maximum of 27-28mi on a single day, and never over 30mi. Upon further examination, I found our that the 30mi day occured when I had run a long run of 22mi and the previous day an easy run of 8mi for a total of 30 miles.

This made me realize that the rolling interval might be implemented on an hourly basis. Meaning, probably the 22mi and 8mi runs happened within less than 24 hours from each-other (but on distinct days) and so they were probably counted on the same 1-day rolling interval. The same principle seems to be applying on all rolling intervals regarding of the number of days/weeks etc. This sounds like the "correct" functionality to be implemented but in practice a "quantization" of the rolling interval would probably be more usable.

One suggestion would be to quantize the intervals on midnight so that lets say a 2 day interval counts midnight to midnight instead of rolling within the day. I hope that makes sense.

Thanks again and please let me know of your thoughts and if I need to clarify something.

@mathin You probably right. It could come from dates. Could you create a new ticket for this potential bug? And link me a elevate backup + activities id/dates where the problem could be.

@mathin You probably right. It could come from dates. Could you create a new ticket for this potential bug? And link me a elevate backup + activities id/dates where the problem could be.

Hi @thomaschampagne . I would do what you asked but I don't know how (backup+id/dates etc). If you get the time to fix the functionality that would be great but I don't expect you to do so as I understand it's your pet project. Thanks again for the great functionality!