Skip to content

comptes rendus

Jump to bottom
Sébastien Rochette edited this page Sep 7, 2022 · 13 revisions

2022-09-07 - Livraison - Retours

  • L'implémentation des composantes du DSFR pour {shiny} nécessite une base technique importante.
  • Il a été décidé que la prestation ThinkR devait se concentrer sur la rédaction de guides permettant à d'autres dev de prendre le relai
  • Il y a un peu de nettoyage à réaliser dans le package pour rendre la doc développeurs plus visible, mais il y a déjà une base solide de documentation utilisateurs et développeurs
  • L'utilisation du template {fusen} rend l'implémentation plus facile pour l'ajout d'une nouvelle composante

La suite

  • Dans un premier temps, Juliette et Jean-Daniel remettent en forme les guides de développement
  • Puis, création du composant selectInput() et finalisation du composant checkboxInput()
  • Retour des développements sur navbarPage() et ses spécificités

Deliverables

deliverables.zip

2022-07-20 - Point ThinkR

Nous avons rédigé les rapports pour aider à choisir la méthode de développement. Ce sont les articles (vignettes) du site web {pkgdown} du projet: https://spyrales.github.io/shinygouv/index.html
Juliette étant très rapide à la validation, elle est déjà approuvé notre recommandation, à savoir une solution hybride entre le sur-mesure complet et les fonctionnalités existantes de {shiny}: la proposition D de la vignette: https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html

Pour la suite

La reprise est le 8 août.

Nous allons :

  • Réaliser les retours sur le package {shiny.dsfr} et voir si on pourrait éventuellement récupérer des composants
  • Créer une application Shiny en mode {shinipsum} représentant une app "moyenne" de ce qui se fait actuellement et qui sera notre point de départ pour notre documentation et nos tests
  • Créer des functions qui permettent de transformer l'app "moyenne" en app avec le DSFR
  • Les deux apps pourront cohabiter dans un {brochure} pour la démo sur shinyapps.io
  • Commencer l'écriture des composants selon la liste des composantes les plus utilisées: https://github.com/spyrales/shinygouv/issues/22
    • Murielle et Cervan développent chacun de leur côté avec une méthode différente, la documente, et passe le document à l'autre pour implémenter l'autre méthode et tester la doc.
  • Créer un tableau de correspondance entre les fonctions {shiny} habituellement utilisées et les fonctions de {shinygouv}

2022-07-18 - Informations complémentaires

[documentation] Quelle(s) langue(s) utiliser pour la documentation ?

https://github.com/spyrales/shinygouv/issues/15

  • Rapports d'exploration (présentés en vignettes) : 🇫🇷
  • Vignettes utilisateurs: les vignettes qui expliquent comment utiliser les fonctions du package 🇫🇷
  • Contenu du Readme 🇫🇷
  • Documentation {roxygen2} des fonctions 🇫🇷
  • Messages de commit (de préférence en anglais, par habitude chez nous) 🇫🇷
  • Description des tests unitaires (de préférence en anglais) 🇫🇷
  • Code of Conduct: template par défaut de {usethis} en anglais déjà présent comme pour {gouvdown} 🇬🇧
  • Contributing: template par défaut de {usethis} en anglais peut être ajouté comme pour {gouvdown} 🇬🇧

[documentation] Quelle licence utiliser ?

https://github.com/spyrales/shinygouv/issues/13

Pour le moment, nous avons choisi de mettre la même licence que pour {gouvdown}: https://github.com/spyrales/shinygouv/blob/main/LICENSE
Mais il faudra peut être vérifier au fur et à mesure sa compatibilité avec les licences des packages qu'on va utiliser ? https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-find-and-compare-software-licenses

2022-07-18 - shinygouv - Lancement des travaux chez ThinkR

Présents :

  • Murielle
  • Cervan
  • Sébastien
  • Margot

Travaux prévus pour la semaine

Murielle et Cervan ont des issues qui leur sont assignées sur le dépôt GitLab : https://github.com/spyrales/shinygouv

  • Faire un état des lieux de l’existant, même si Juliette a déjà attaqué le travail : Quelles sont les composantes les + utilisées ? -> Murielle, 1/2 journée

  • Faire un état des lieux de où sont les fichiers web sources et comment les récupérer lors des mises à jour -> Cervan, 1/2 journée

Murielle et Cervan vont devoir travailler ensemble sur certains points, notamment choisir 2 composants à prendre en exemple (1 facile à utiliser / 1 plus compliqué) -> mimer comment cela se mettrait en place avec {bslib}, et avec {charpente}

Cette semaine va surtout être dédiée à la création de rapports.

A la fin de la semaine, Juliette doit avoir les billes pour choisir la voie qui sera empruntée : {bslib} ou {charpente}.

C’est cette décision qui va impacter la suite des travaux.

Méthode de dev

Il s'agit d'un projet open-source. Donc il faut se mettre dans les mêmes conditions que les futurs utilisateurs.

Pas de {renv}, on développe en local sur des systèmes différents.

  • Cervan développe sur Linux
  • Murielle développe sur Windows
  • Margot pourra essayer de temps en temps sur Mac

On fait attention aux dépendances. Moins il y aura de dépendances, moins l'utilisation future du package risque de poser problèmes sur des versions de R différentes, des OS différents, etc.

On se fixe une version minimale de {shiny} : 1.6.0

Méhode de gestion de projet

Sébastien et Margot se relaient pour gérer le projet :

2022-07-07 - shinygouv - Kick Off

Ordre du jour

Tour de table :

  • Cervan, Diane, Sébastien, Margot, Murielle côté ThinkR
  • Juliette Engelaere
  • Mikael Truchon
  • Jean-Daniel Lomenede

Objectifs du projet

  • Mise en place d'un package R permettant d'implémenter le Design System de l'État dans les applications Shiny

Besoins / Succès

  • Eviter d'avoir des fonctions spécifiques pour ne pas gêner le passage d'un template à un autre si possible

  • Le package doit être maintenable par les utilisateurs et peut être mis à jour rapidement s'il y a des mises à jour des fichiers css/js/polices/images du côté Design System de l'Etat

  • Avoir la possibilité de suivre le développement pour comprendre comment sont construites les fonctions

    • 75% le produit est utilisable et bien documenté
      • Documenter avec le lien vers le Design System
    • 25% Les traces écrites au cours du développement sont compréhensibles: messages de commit, MR

  • Respect des workflow du guide pratique PROPRE

  • Est-ce qu'il faut que le package soit plus orienté pour les utilisateurs (=dev shiny) ?

    • Ou orienté pour que les mainteneurs puissent mettre à jour rapidement ?

le Design System - la commande

L'existant

Les échanges du "10%"

  • Le projet {shinygouv} fait partie d'une liste plus longue de projets
  • Discuté avec Romain: La partie Shiny, c'est DREAL Pays de La Loire + ThinkR qui démarre les travaux
    • Notamment démarrage {shinydashboard}
  • Eux s'occupent de {gouvdown}

Les travaux de Jean-Daniel (DDTM76)

  • inspiré du livre de David Granjon (parti de {charpente})
  • ok pour discuter de ses choix techniques
  • Hors cadre de la prestation
  • Jean-Daniel expérimente de nouvelles façons de travailler
  • revient de congés dernière semaine de juillet (du 25 au 29 juillet) pour repartir ensuite
  • preneur d'un retour n'importe quand (à l'écrit ou à l'oral)

Observation "terrain" - faire l'inventaire

  • ThinkR a besoin d'une liste d'applications Shiny déjà développées pour savoir quelles sont les pratiques existantes, pour éviter de trop changer les pratiques avec le nouveau package.
  • Juliette a déjà fait un premier inventaire de ces besoins,
    • ce qui permet à ThinkR de passer à la suite
  • ThinkR examine le code de Jean-Daniel pour lui faire un retour sur son code, et sur si et pourquoi on garde le même fonctionnement ou non (fonctions dédiées, ou plutôt template css/js uniquement)

=> 0.5 jour consacré aux retours sur le package {shiny.dsfr}

La connaissance des sources du Design System

  • Quels sont les fichiers produits, comment, où les trouver ?
  • Les composants du design system
    • Lequels peuvent être du bootstrap / bsplus directement avec du css only ?
    • Documenter comment les utiliser
    • Lister les composantes du Design System qui ne sont pas pris en charge avec le package
    • Lister les composants Shiny existants qui n'existent pas dans le DS, et donc mal pris en charge par le package
      • Sachant qu'on peut demander à en ajouter dans le DS

=> Faire une table des composantes disponibles

Expliquer les règles d'utilisation du Design System d'un point de vue Shiny ?

  • Comment utiliser les composantes ensemble ?

    • ThinkR propose de parcourir les recommendations du DS pour donner des recommendations sur la façon d'implémenter les Shiny
      • Par exemple: Vous pouvez mettre le titre 2 en rouge, si le titre 1 est en bleu

  • Ce n'est pas le job du package d'expliquer comment utiliser la charte graphique. Il y a des formation pour cela.

=> 2 jours sont consacré à cela: validé par Juliette

shinydashboard ?

  • C'est très utilisé, mais peut-être ça peut être donné à l'équipe 10%.

Un bouton RStudio qui permet de créer un nouveau projet avec le template existant

  • Un create_golem() avec le template

Dev

  • dark mode => {bslib} ok

    • Il y a un css pour le 'white' et un css pour le 'dark'
    • A conserver si c'est pour l'accessibilité

  • Faire en sorte que ce soit développé en mode "open-source", c'est à dire pas de {renv}: Le package doit être fonctionnel sur toutes versions (récentes)

    • Peut-être devons-nous aussi développer volontairement avec des OS différents pour anticiper les potentiels problèmes utilisateurs
    • Le CI doit être testé sur windows/linux/macos - R devel
    • Le CD est envoyé sur shinyapps.io pour l'app de démo

  • Sur Github, il y a déjà {gouvdown}

  • Nom du projet : {shinygouv} sur spyrales (github)

TODO : demander droits et depôt à Romain

ggplot2

  • Regarder ce qu'il se passe en appliquant {thematic} pour le thème ggplot2 de {gouvdown}
    • shiny 1.6.0 minimal
Clone this wiki locally