5.2 Convention de nom des apps

Au fur et à mesure de l’écriture de votre matériel pédagogique, vous aurez potentiellement beaucoup d’exercices implémentés sous forme d’applications H5P, Shiny ou learnr. Pour s’y retrouver, nous vous conseillons très fortement d’adopter dès le début une convention pour le nom de ces applications telle qu’il est facile de déterminer à quel cours, à quel module et dans quel ordre ces apps apparaissent. D’ailleurs, ce nommage sera utilisé, par exemple, dans le rapport de progression (voir le chapitre 14) si vous en utiliser un par la suite. La convention que nous vous proposons est la suivante :

• Les noms commencent par A00Ha_... avec :
  • La première lettre en majuscule correspond au cours ou à la formation (A = cours x, B= cours y, etc.). Si vous prévoyez plus de 25 formations, utilisez alors deux lettres majuscules au lieu d’une seule. Pour les applications non attribuées à des cours en particulier, vous pouvez utiliser . pour toutes les applications utilisées dans la présentation générale, et sinon, Z pour tout le reste.
  • Deux chiffres indiquant le module ou chapitre où l’application s’intègre, par exemple 01 (le zéro devant le un est important pour obtenir un classement adéquat lorsque ces noms sont triés par ordre alphabétique). Utilisez 00 s’il n’y en a pas ou si l’application apparaît dans le préambule du bookdown, ou encore 99 pour une application qui s’intègre dans les appendices ou dans une section complémentaire optionnelle.
  • Une lettre majuscule qui indique le type d’application ou d’item (H pour H5P, S pour Shiny, L pour learnr, I pour projet GitHub individuel, G pour projet GitHub en groupe, C pour challenge -approche ludique-, V pour vidéo, P pour podcast, W pour Wooclap, X pour examen ou interrogation, et enfin, . tout autre type d’application d’utilisation occasionnelle). Les autres lettres sont réservées pour d’autres types de contenus développés ultérieurement.
  • Une lettre minuscule sert à ordonner les applications d’un même module. Ceci est surtout utile pour les learnrs afin qu’ils apparaissent dans le bon ordre dans l’onglet ‘Tutorials’ de RStudio. Pour les autres, c’est utilisable mais non nécessaire. On peut aussi utiliser le point . pour ne rien spécifier ici. Naturellement, si vous prévoyez plus de 26 exercices du même type, utilisez alors deux lettres minuscules au lieu d’une seule.
  • Le trait souligné qui sépare le code d’identification du reste dans le nom de l’application.
• La seconde partie indique l’année ou la version de la formation au choix, par exemple ..._23A_.... Elle n’apparaît que si différentes versions sont implémentées ou réalisées selon les années (typiquement, les projets GitHub), mais n’apparaît pas autrement. Elle se présente comme suit :
  • Deux chiffres utilisés soit pour l’année (s’il s’agit d’une annéé académique ou universitaire, utilisez les chiffres correspondant à la première année civile concernée, par exemple pour l’année académique 2023-2024, utilisez 23). Vous pouvez aussi choisir d’indiquer un numéro de version ici, mais respectez toujours les deux chiffres strictement, donc par exemple 01, 18, mais pas 1, ni 18.0.2.
  • Une lettre majuscule utilisable pour différencier des variantes selon votre propre contexte. Par exemple, si un même cours se donne plusieurs fois ou sur plusieurs campus différents, ils peuvent être différencies par cette lettre. Si vous utilisez un numéro de version mais que cette lettre ne vous est pas utile autrement, vous pouvez indiquer ici une indication complémentaire au numéro, par exemple A pour une version alpha, B pour une version beta ou D pour une version effectivement ’D’éployée et ’D’ispensée.
• Après ces codes, le nom de l’application doit être court et informatif. Séparer les mots par des tirets. Voici quelques exemples de noms corrects :
  • A01Hb_markdown pour le second exercice H5P du premier module du cours A, année 2023-2024, pour le campus C, et consacré à Markdown. Cet exercice est réutilisé d’une année à l’autre et donc, le code d’année n’est pas utilisé
  • B10Lc_23D_pca pour le troisième tutoriel learnr du chapitre 10 du cours B, pour l’année 2023-2024, à destination des étudiants du site D et consacré à l’ACP (analyse en composantes principales). Dans ce cas, vous prévoyez d’écrire un learnr différent chaque année et pour chaque site (en pratique, nous vous le déconseillons, car l’écriture d’un learnr demande beaucoup de temps, mais c’est pour l’exemple).
  • C06Ia_23B_iris pour le premier projet individuel GitHub du chapitre 6 du cours C, pour l’année 2023-2024, pour les étudiants du campus B, et consacré à l’analyse du jeu de données iris (on peut choisir d’indiquer ici soit le jeu de données analysé, soit la technique mise en œuvre, par exemple, ttest pour un projet individuel consacré au test t de Student). Le code d’année est indispensable si un projet est récurrent annuellement, mais le template peut, lui être réutilisé. Dans ce dernier cas, le template se nommera C06Ia_iris pour bien montrer qu’il est réutilisé.
• Dans le cas particuliers des “sous-contenus” de H5P (des widgets à l’intérieur d’autres widgets, exemple : une question à choix multiple à l’intérieur d’une présentation ou une vidéo), on utilisera le même code et nom que le widget principal, suivi du slash / et du nom attribué au sous-contenu. Par exemple, la question 1 dans une présentation pourrait s’appeler B02Ha_presentation/question1 si la présentation est dans le cours SDD II (B), module 2 (02), première position a, et qu’elle se nomme elle-même présentation.

Ce système de nommage des applications et autres items est un peu compliqué, mais avec l’habitude, il permet d’identifier instantanément les données par rapport à leur contexte ! Il s’avère très rapidement indispensable.