Elevate: Année de progression de la migration de la somme glissante vers l'application Elevate

Je suis d'accord, j'adore la tendance fitness mais la moyenne mobile sur 30 jours est inestimable !

Je suis venu ici pour dire juste ça ! La moyenne mobile sur 30 jours était l'une des fonctionnalités les plus utiles pour comparer le volume des saisons. De plus, la distance de l'année dernière était assez instructive pour ceux qui se concentraient sur l'accumulation de miles.

Il serait très utile d'ajouter les 30 derniers jours et la distance/temps/altitude moyenne de l'année dernière si possible.

J'en profite également pour remercier Thomas pour son projet incommensurable

@ashdriver @DCunnama @fjavipm Je comprends ce retour. En fait, cette fonctionnalité héritée avait été codée par quelqu'un d'autre (par pull request & merci à lui !!). J'ai rencontré de nombreux bugs avec de nombreux utilisateurs et je n'ai pas pu maintenir la fonctionnalité dans le code hérité. C'est pourquoi j'ai déplacé (ou forcé pour vous...) l'ancienne fonctionnalité vers la nouvelle.

Je vais ramener cette fonctionnalité et la signaler d' urgence . Pour être honnête, je n'ai jamais vraiment compris le concept de moyenne glissante sur distance/temps/altitude moyenne de l'année dernière pour mes propres besoins. Je peux donc imaginer que beaucoup d'utilisateurs (à l'exception de vous) ne pourront pas l'utiliser correctement. Je garde à l'esprit que les fonctionnalités doivent être accessibles à tous.

Alors, pourriez-vous me réexpliquer le "besoin", le "cas d'utilisation", les "problèmes résolus" derrière la moyenne glissante sur 30 jours et la distance/temps/altitude moyenne de l'année dernière ? Je peux donc le recoder dans la progression de la nouvelle année ? Cette compréhension est requise pour moi et pour tous les autres utilisateurs aussi.

Si vous souhaitez récupérer l'ancienne fonctionnalité, vous pouvez toujours télécharger une ancienne version ici : https://thomaschampagne.github.io/elevate/#/builds (avec la branche filtres

Salut Thomas,

Merci pour la réponse et l'explication. Je vais donner mes propres besoins et utilisation pour cela, mais j'espère que d'autres pourront en ajouter plus s'il y en a :

Avoir besoin:
Un moyen de comparer les charges d'entraînement récentes et prolongées (mesurées par la distance ou l'altitude) d'une année à l'autre.

Cas d'utilisation:
L'utilisateur peut choisir d'afficher des tracés de moyenne mobile d'altitude ou de distance sur 30 ou 365 jours (affichés sur l'axe des y) et la date sur l'axe des x à partir du 1er janvier. Chaque année avec les données disponibles peut être superposée dans une couleur différente, et idéalement également la possibilité de sélectionner/désélectionner des années spécifiques pour des comparaisons directes entre elles.

Problème résolu:
Cela donne un moyen raisonnablement efficace de comparer l'effort d'entraînement mesuré par la distance et l'altitude à des moments particuliers de l'année par rapport aux années précédentes. Souvent, les athlètes s'entraînent pour des événements annuels spécifiques qui tombent à peu près à la même date chaque année, et pouvoir comparer facilement les moyennes mobiles sur 30 jours (et dans une moindre mesure 365 jours) est un excellent moyen de comparer la préparation pour de tels événements.

Demande de fonctionnalité supplémentaire facultative : la possibilité d'ajuster la fenêtre moyenne mobile entre/inférieure à 30 jours et 365 jours peut également être utile, bien que 30 jours soient une assez bonne valeur fixe, je pense. Ajuster la taille de la fenêtre peut être utile pour comparer des blocs d'entraînement plus longs (ou plus courts) que 30 jours d'une année à l'autre - par exemple, les programmes d'entraînement de marathon sont souvent établis sur 3 mois.

Alors, pourriez-vous me réexpliquer le "besoin", le "cas d'utilisation", les "problèmes résolus" derrière la moyenne glissante sur 30 jours et la distance/temps/altitude moyenne de l'année dernière ? Je peux donc le recoder dans la progression de la nouvelle année ? Cette compréhension est requise pour moi et pour tous les autres utilisateurs aussi.

« 30 derniers jours » est utile pour comprendre les variations du volume d'entraînement spécifiquement par sport. Dans les sports de longue endurance, le volume et l'intensité sont les clés du succès. Mis à part l'intensité, qui peut être obtenue en HRSS, le volume est la partie la plus simple de l'équation mais souvent très difficile à obtenir. Par exemple, la fonction des 30 derniers jours vous aide à obtenir votre taux de montée en charge jusqu'aux six à huit dernières semaines de votre événement de pointe.

Juste une petite correction - j'ai parlé de "moyennes glissantes" sur 30 et 365 jours, mais en fait, la distance/l'altitude/le temps total accumulés sur la fenêtre sont probablement plus utiles et c'est ainsi que cette fonctionnalité a été précédemment implémentée.

Je voulais aussi intervenir et aller jusqu'à dire que les moyennes glissantes sur 30 et 365 jours ont en fait été la principale raison pour laquelle j'utilise votre plugin, alors s'il vous plaît, s'il vous plaît, ramenez-le :)

Pour répondre à la question de l'utilité, les moyennes mobiles sont de bons moyens d'avoir une mesure plus raisonnable des "stries" que les coureurs adorent suivre. Par exemple, je sais que j'ai au moins 3000 km de moyenne glissante sur mes jambes depuis plus d'un an maintenant (pour être exact 424 jours comme vous le voyez ci-dessous). Ces calculs que j'effectue sur une feuille de calcul Google distincte, mais il est assez facile de les convertir en un tracé à inclure dans votre plugin.

Seuil | Par semaine | Sperme. milles | Date atteinte | Plus de jours | Plus de mois
-- | -- | -- | -- | -- | --
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

C'est plus clair pour moi désormais... Je suis resté de longues minutes sur mes progressions pour l'attraper. J'avais une mauvaise visualisation de la fonctionnalité avant... Cela ne m'a pas aidé... Mais à partir de maintenant, ce n'est pas sorcier :)

Je vais donc fournir ces 2 modes:

• Le « mode cumulatif standard » qui existe actuellement dans l'application
• Et le "Rolling Streak Mode" => Besoin de votre aide pour la bonne formulation marketing ;)

Le "Rolling Streak Mode" aura une valeur de jour glissant personnalisable de 1 à 365 . Doit-on restreindre cela à des valeurs fixes ? Je veux dire 1 semaine , 2 semaines , 1 mois , 3 mois , .. 6 mois , 1 an . Certains utilisateurs peuvent ne pas savoir quel nombre de jours est le meilleur, je suppose.

Le "Rolling Streak Mode" s'appliquera à tous les types de progression : distance , temps , dénivelé et décompte .

Je ne sais toujours pas ce qu'on peut afficher dans le tableau (côté droit) ? Le delta roulant entre les années ? Et les cibles ?

Bien sûr, les choses que j'ai écrites ici ne sont pas scellées. Vous pouvez déposer vos suggestions, idées, avertissements, ... ;) Je vais lier quelques builds ici. Vous pourrez donc tester la fonctionnalité. Je vais travailler principalement là-dessus maintenant, d'autres fonctionnalités sont en attente.

Merci Thomas, je suis également d'accord pour dire que c'était l'une de mes parties préférées du plugin. Personnellement, je pense qu'il est défini par défaut sur 1 mois, mais permettre à l'utilisateur de le définir manuellement serait formidable.

J'alternais souvent entre 1 mois et 1 an pour comparer facilement mes charges d'une année à l'autre et voir comment se déroulait mon entraînement, principalement pour des événements tels que le marathon en course à pied, où la quantité d'entraînement est vraiment bon à voir sur la fatigue etc.

À votre santé!

Je dirais que les valeurs fixes sont bonnes pour la plage - 1 semaine, 2 semaines, 1 mois, 3 mois, 6 mois, 1 an.
Peut-être ajouter 2 mois aussi?

Pour les valeurs du tableau et la vue d'ensemble, je pense qu'il reste le même que les tableaux de progression existants - c'est-à-dire delta avec l'année précédente et en cours, comme vous le suggérez.

"Rolling Streak Mode" semble être un nom décent pour l'appeler pour moi - au moins je ne peux pas penser à quelque chose de mieux !

Merci encore pour tout le temps et l'expertise que vous consacrez à ce projet - c'est très apprécié.

• Et le "Rolling Streak Mode" => Besoin de votre aide pour la bonne formulation marketing ;)

J'ai mis le mot "strie" entre guillemets dans mon message d'origine, car les séquences signifient quelque chose de spécifique aux coureurs et ce sont des jours consécutifs de course. Certains coureurs croient au NDO (pas de jour de congé) et les séquences sont la durée pendant laquelle vous pouvez passer sans un jour de pause. Donc, dans ce sens, l'appeler "Rolling Streak Mode" peut prêter à confusion. Je suggérerais quelque chose comme "Rolling Cumulative Mode" ou "Windowed Cumulative Mode" impliquant une fenêtre de temps où l'accumulation a lieu.

Le "Rolling Streak Mode" aura une valeur de jour glissant personnalisable de 1 à 365 . Doit-on restreindre cela à des valeurs fixes ? Je veux dire 1 semaine , 2 semaines , 1 mois , 3 mois , .. 6 mois , 1 an . Certains utilisateurs peuvent ne pas savoir quel nombre de jours est le meilleur, je suppose.

Je suggérerais de donner une option pour les unités (jours, mois, années) et un nombre. Par exemple, j'aimerais avoir mon cumul de 2 ans, car courir est un jeu de longue haleine. De plus, il serait bien de donner la possibilité de superposer 2-3 paramètres différents, par exemple 30 jours et 1 an les uns sur les autres, car ce dernier est une version plus "lissée" du premier. Bien sûr, pour que l'axe des y ait un sens, il faudrait tracer une valeur moyenne non totale car les totaux sont radicalement différents. La moyenne pourrait être affichée sur une base hebdomadaire que beaucoup de coureurs suivent. Donc, dans mon tableau au-dessus de 3000mi/an correspond à 58/semaine. Donc, si vous deviez tracer 30 jours et 1 an les uns sur les autres, vous verriez de combien vous vous écartez de l'objectif de 58 mi/semaine.

Le "Rolling Streak Mode" s'appliquera à tous les types de progression : distance , temps , dénivelé et décompte .

Ça sonne bien et c'est logique.

Je ne sais toujours pas ce qu'on peut afficher dans le tableau (côté droit) ? Le delta roulant entre les années ? Et les cibles ?

Je n'ai pas inclus cela dans le tableau ci-dessus, mais je surveille également le temps qu'il faut pour atteindre le prochain seuil ou delta comme vous le dites. On ne veut pas passer d'un seuil à l'autre trop rapidement car c'est la recette des blessures/épuisement professionnel. Ce que je peux offrir ici, c'est qu'il sera agréable d'avoir les seuils réglables par l'utilisateur soit au total (1000, 2000, 3000mi, etc.) ont dépassé le seuil, ce qui augmentera chaque jour.

Je garderai un œil sur le fil et merci encore d'être prêt à réintroduire cette fonctionnalité géniale !

• Le « mode cumulatif standard » qui existe actuellement dans l'application

Je suggérerais également dans le mode standard d'ajouter l'option pour l'option mensuelle et pas seulement annuelle. De nombreux coureurs courent la même course année après année, il serait donc bien d'avoir une "réinitialisation" par mois afin de comparer la façon dont l'accumulation de janvier 2019 s'est comparée à l'accumulation de 2018 si cela a du sens. À ce stade, tout cela est un fluage de fonctionnalités :) donc je serais plus qu'heureux si vous rétablissiez simplement la fonctionnalité précédente :)

En fait, qu'en est-il d'un simple "Rolling Sum" ? Le mode standard ressemble plus à "YTD Sum" (Year To Date). Juste une pensée.

J'ai donc commencé le développement il y a 2 jours.

J'ai utilisé ça pour le moment :

export enum ProgressionMode {
    STANDARD_CUMULATIVE,
    ROLLING_CUMULATIVE
}

@mathin "Rolling Sum" & "Year To Date Sum" semble en effet beaucoup plus simple. Je peux les activer. Que pensez-vous des autres?

Quelques résultats ici !! :) J'ai fini de coder la logique grand public via TDD. Et après quelques contournements dans l'interface utilisateur, voici quelques résultats :

"Somme glissante 30 jours"

"Somme glissante sur 3 mois" :

"Somme glissante sur 1 an" :

La « Somme cumulée de l'année » associée :

Et l'héritage "Last 30d distance" à comparer avec "30 days Rolling Sum" :

Cela a l'air parfait, merci beaucoup d'avoir mis en œuvre quelque chose si rapidement !

Vous pouvez valider le comportement actuel avec des tests unitaires ici : https://github.com/thomaschampagne/elevate/blob/1f48cd28c5c111c6fe826ae6da6b79d8050c583e/plugin/app/src/app/year-progress/shared/services/year-progress.service.spec .ts#L537

Et méthode ici : https://github.com/thomaschampagne/elevate/blob/1f48cd28c5c111c6fe826ae6da6b79d8050c583e/plugin/app/src/app/year-progress/shared/services/year-progress.service.ts#L200

Quelques résultats ici !! :) J'ai fini de coder la logique grand public via TDD. Et après quelques contournements dans l'interface utilisateur, voici quelques résultats :

C'est absolument incroyable ! Merci beaucoup, j'ai hâte de commencer à utiliser les nouvelles métriques !

Une petite question/commentaire. Quand je compare (uniquement visuellement bien sûr) l'héritage "Last 30d distance" avec le nouveau "30 days Rolling Sum", il me semble que le "Rolling Sum" est plus "déchiqueté" ou à l'inverse que l'héritage "Last 30d" semble un peu plus lisse. S'agit-il simplement d'un artefact des fonctions de traçage ou y a-t-il un lissage des données supplémentaire en cours sur le code hérité ?

Merci encore!!!

@mathin C'est juste le mode d3 curveLinear que j'utilise : https://github.com/d3/d3-shape#curveLinear

En utilisant _curveNatural_, cela donne :

@mathin encore. A propos de vos demandes :

De plus, il serait bien de donner la possibilité de superposer 2-3 paramètres différents, par exemple 30 jours et 1 an les uns sur les autres, car ce dernier est une version plus "lissée" du premier. Bien sûr, pour que l'axe des y ait un sens, il faudrait tracer une valeur moyenne non totale car les totaux sont radicalement différents. La moyenne pourrait être affichée sur une base hebdomadaire que beaucoup de coureurs suivent.

Cela semble beaucoup plus difficile de le faire "rapidement", peut-être le suivre dans un nouveau numéro à faire plus tard.

Donc, dans mon tableau au-dessus de 3000mi/an correspond à 58/semaine. Donc, si vous deviez tracer 30 jours et 1 an les uns sur les autres, vous verriez de combien vous vous écartez de l'objectif de 58 mi/semaine.

Tu m'as perdu :)

Quelques mises à jour de l'interface utilisateur et "6 Weeks Elevation Rolling Sum" :

Cela a l'air très joli et prometteur !
Je privilégierais une somme glissante de 4 semaines sur 30 jours/1 mois et de 13 semaines sur 3 mois.
Comme la plupart des gens font généralement de l'exercice le même jour de la semaine.
En utilisant le rythme de la semaine, chaque trajet du dimanche remplace le trajet du X-back du dimanche, de sorte que la ligne sera beaucoup plus fluide et aura beaucoup moins de vacillements.

Je privilégierais une somme glissante de 4 semaines sur 30 jours/1 mois et de 13 semaines sur 3 mois.
Comme la plupart des gens font généralement de l'exercice le même jour de la semaine.

C'est un si bon point, j'aimerais aussi voir la somme glissante de 4 semaines au lieu de 30 jours. Et BTW, je pense que vous vouliez écrire 12 semaines, pas 13, n'est-ce pas?

@bkleingoldewijk @mathin Vous pouvez choisir la période que vous voulez. Il suffit de multiplier par le nombre dont vous avez besoin.

Excellent!

Bob

Envoyé de mon iPhone

Op 12 fév. 2019 à 18:57 heeft Thomas Champagne < [email protected] [email protected] > het volgende geschreven:

@bkleingoldewijk https://github.com/bkleingoldewijk @mathin https://github.com/mathin Vous pouvez choisir la période que vous voulez. Juste plusieurs par numéro dont vous avez besoin.

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

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/thomaschampagne/elevate/issues/760#issuecomment-462865891 , ou coupez le fil https://github.com/notifications/unsubscribe-auth/AtN0S2opo7- OK64kFII6bAM1C2Dc1tzRks5vMwCMgaJpZM4ako11 .

Je suis aussi un grand fan des 30 jours et 365 jours glissants. Cependant, je soutiendrais également qu'un cycle de 4 semaines et 52 semaines serait plus informatif, car j'ai tendance à avoir le même cycle de cyclisme au cours de la semaine. Merci beaucoup.

Il y a des problèmes de couleur et de contraste. À l'heure actuelle, 2019 sur mes graphiques utilise une couleur très sombre sur un fond très sombre. La sélection des couleurs doit être plus prudente ou comporter des options de sélection à partir d'une palette.

@jfhaugh la palette "roulante" est définie ici : https://github.com/thomaschampagne/elevate/blob/develop/plugin/app/src/app/year-progress/year-progress.component.ts#L43

Tu peux me donner ta liste ;) ?

(devrait également fonctionner sur le thème de la lumière)

Pourrait aider : https://color.adobe.com/create/color-wheel/

Voici une première version testable des progressions Rolling & Year to date :

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

Remarque : Pour éviter une nouvelle synchronisation, vous pouvez utiliser une sauvegarde de votre élévation "officielle" pour la restaurer dans cette version.

Bien sûr, votre aide est la bienvenue pour :

• Trouver des bugs sur des cas courants et tordus
• Fournissez-moi des idées/textes pour augmenter la compréhension de la fonctionnalité (en particulier la progression glissante qui est certainement complexe pour la plupart des utilisateurs). Ex : " Sous le bouton vous devez écrire ceci : ", " Ajouter une infobulle survolée * et afficher * * ", etc...
• Fournissez-moi le contenu de la boîte de dialogue d'aide (affichée lorsque vous cliquez sur le bouton (?))
• Corrige mon anglais :)

Merci pour votre aide et vos tests :)

J'attendais des métriques glissantes depuis un moment — sympa @thomaschampagne

Onglet Progression de l'année

• ce serait encore mieux si pour la sélection "Années", on pouvait..
  
  
  
  • tout sélectionner
  
  
  • tout déselectionner
  
  
  • inverser la sélection
  
  
  • 5 dernières années (par exemple)
    
    (Remarque : ma base de données remonte à 2003, mais les données deviennent de plus en plus rares à mesure que je remonte dans le temps. Cela crée beaucoup de distraction dans les graphiques. Il est également laborieux de cocher ou de décocher des cases sur près de 20 ans)
  
  

• Les périodes glissantes sont l'une des meilleures fonctionnalités de ce logiciel. Donne un coup de pied au cul.
  
  
  
  • une fenêtre de temps glissante personnalisable serait parfaite
  
  
  • ou, inclure 4 semaines ou 30 jours
  
  

Continuez votre bon travail!

J'ai mis à jour l'assistant de fonctionnalité si vous pouviez jeter un œil aux améliorations du texte et de l'anglais

Le fichier source que vous pouvez modifier et publier : https://github.com/thomaschampagne/elevate/blob/9632d6b28a4a7cfe57b1099c031f9856ae8c2855/plugin/app/src/app/year-progress/year-progress-helper-dialog/year-progress- helper-dialog.component.html

@thomaschampagne merci encore pour la sortie de cette nouvelle fonctionnalité incroyable !

J'ai un petit problème à signaler. L'autre jour, j'ai défini l'intervalle glissant sur 1 jour et j'ai regardé mes graphiques. J'ai été surpris de voir des valeurs de 30mi+ qui semblaient assez étranges car je ne suis pas un gars ultra. Je ne cours jamais plus qu'un marathon (uniquement un jour de course) et même en incluant l'échauffement d'avant course (max 1mi), je ne dépasserais jamais un maximum de 27-28mi en une seule journée, et jamais plus de 30mi. Après un examen plus approfondi, j'ai découvert que la journée de 30 milles s'était produite lorsque j'avais couru une longue course de 22 milles et la veille une course facile de 8 milles pour un total de 30 milles.

Cela m'a fait réaliser que l'intervalle glissant pourrait être mis en œuvre sur une base horaire. Cela signifie que probablement les courses de 22mi et 8mi se sont produites à moins de 24 heures l'une de l'autre (mais à des jours distincts) et elles ont donc probablement été comptées sur le même intervalle glissant d'un jour. Le même principe semble s'appliquer à tous les intervalles glissants en ce qui concerne le nombre de jours/semaines, etc. Cela semble être la fonctionnalité "correcte" à mettre en œuvre, mais en pratique, une "quantification" de l'intervalle glissant serait probablement plus utilisable.

Une suggestion serait de quantifier les intervalles à minuit de sorte qu'un intervalle de 2 jours compte de minuit à minuit au lieu de rouler dans la journée. J'espère que cela à du sens.

Merci encore et s'il vous plaît laissez-moi savoir de vos pensées et si j'ai besoin de clarifier quelque chose.

@mathin Vous avez probablement raison. Cela peut venir des dates. Pourriez-vous créer un nouveau ticket pour ce bug potentiel ? Et associez-moi une sauvegarde élevée + des identifiants/dates d'activités où le problème pourrait être.

@mathin Vous avez probablement raison. Cela peut venir des dates. Pourriez-vous créer un nouveau ticket pour ce bug potentiel ? Et associez-moi une sauvegarde élevée + des identifiants/dates d'activités où le problème pourrait être.

Salut @thomaschampagne . Je ferais ce que vous avez demandé mais je ne sais pas comment (sauvegarde + identifiant/dates, etc.). Si vous avez le temps de corriger la fonctionnalité, ce serait formidable, mais je ne m'attends pas à ce que vous le fassiez, car je comprends que c'est votre projet favori. Merci encore pour la grande fonctionnalité!