-
Notifications
You must be signed in to change notification settings - Fork 0
comptes rendus
- Juliette
- Daniel
- Colin
- Murielle
- Cervan
- Yohann
- Diane
Juliette, peux-tu nous présenter le contexte avec tes mots en 2 minutes chrono ? (attention Colin veille au grain)
CS de l'époque:
- surtout sur la méthode des composants et être autonome
accélerer le dev du package pour le design system
-
Valider l'accès à shinygouv pour l'équipe ThinkR (notamment Colin et Yohann) 🆗
- ColinFay
- ymansiaux
-
Valider la disponibilité de Juliette pendant la période de développement 🆗
Role de Daniel :
- Utilisateur final de {shinygouv}
- problème d'encodage : passer des accents doit être possible
- 15 composants sont implémentés
- usage soit simple et documenté
- restructurer la documentation pour l'onboarding de dev
- Utilisable sur le projet de la drieat
- Le nombre d'applications augmentent
- Un onboarding de dev facilité
- des exercices pendant l'été pour un retour en septembre
- Présentation en Meetup
- Présentation aux Rencontres R 2024 ou 2025 ?
- une présentation au réseau 10 % ?
- une présentation à uRos ?
- Issues : https://github.com/spyrales/shinygouv/issues
- PR : https://github.com/spyrales/shinygouv/pulls
À traiter : https://github.com/spyrales/shinygouv/pull/55
Regarder la PR de Juliette de 14h à 14h30
=> Note : tous les inputs doivent avoir leur contrepartie update
- tabPanel()*
- navbarPage()*
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/navigation-principale/
=> Partie Liens directs, menu déroulant en Nice to Have
- checkboxInput()*
- checkboxGroupInput()*
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/case-a-cocher
=> Vérifier dans shiny comment est l'agencement des checkboxs
- selectInput()*
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/liste-deroulante
- shinyWidgets::pickerInput()*
Pas dans le DSFR, et pas sûr de saisir ce qu'on peut apporter de plus par rapport au natif ? https://shinyapps.dreamrs.fr/shinyWidgets/
=> Nice to Have, pickerInput avec le DSFR => Pourquoi il y a une étoile, où est-ce dans la maquette de l'observatoire ?
- shinyWidgets::radioGroupButtons()*
https://shinyapps.dreamrs.fr/shinyWidgets/
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/groupe-de-boutons/
=> Regarder dans la maquette Observatoire les boutons exacts dont on a besoin
- showModal()*
- modalDialog()*
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/modale/
- shinyWidgets::materialSwitch()*
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/interrupteur
=> À noter que le switch de l'observatoire n'est pas un on/off mais un choix entre deux valeurs
- numericInput()
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/champ-de-saisie
- sliderInput()
Pas dans le DSFR
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range
- dateRangeInput()
Pas dans le DSFR
=> Coller à celui de shiny, voir https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/champ-de-saisie
- fileInput()
https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/ajout-de-fichier
- shinycssloaders::withSpinner()*
Pas dans le DSFR
=> Spinner simple avec les couleurs de la charte
Suggestion :
-
Mettre le repo au propre
-
MàJ de la version du dsfr
-
Bug sur l'encodage
- kickoff le lundi 2023-06-26
- Point de mi course vendredi matin à 09h15.
- Livraison de version 1.0.0 le 2023-07-06, l'après midi de 16h à 17h.
- Slack publique (@jengelaere)
- Utilisation de la salle de Juliette si besoin (https://webconf.numerique.gouv.fr/salleJuliette5244)
- Fonctionnement sur le repo :
- Juliette valide quelques PR vers main, certaines en codedev avec Cervan
- Juliette/Daniel valident les tickets
-
Déploiement en continu via GitHub Action ?
-
Quelle politique de numéro de version ?
- Version du dsfr est dans DESCRIPTION
- Quand on déploie dans production en fin de mission, on passe à 1.0.0
- Entre temps, dès qu'on merge dans main, augmenter version patch
- Prochaine personne qui merge dans main passe à 0.0.2
- Quelle plateforme ?
- en local, pour la pérennité du package
=> Pas de soucis de versions de R
- 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
- 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 composantcheckboxInput()
- Retour des développements sur
navbarPage()
et ses spécificités
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
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}
- 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} 🇬🇧
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
Présents :
- Murielle
- Cervan
- Sébastien
- Margot
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.
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
Sébastien et Margot se relaient pour gérer le projet :
- Déplacer les tickets dans le kanban : https://github.com/spyrales/shinygouv/projects/1
- Faire les Weekly en début de semaine et envoyer le mail à Juliette
- Planifier les travaux
- Cervan, Diane, Sébastien, Margot, Murielle côté ThinkR
- Juliette Engelaere
- Mikael Truchon
- Jean-Daniel Lomenede
- Mise en place d'un package R permettant d'implémenter le Design System de l'État dans les applications Shiny
-
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
- 75% le produit est utilisable et bien documenté
-
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 ?
- https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-pdl/csd/shinygouv
- https://github.com/MTES-MCT/dseshiny
- 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}
- 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)
- 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}
- 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
-
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
- ThinkR propose de parcourir les recommendations du DS pour donner des recommendations sur la façon d'implémenter les Shiny
-
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
- C'est très utilisé, mais peut-être ça peut être donné à l'équipe 10%.
- Un create_golem() avec le template
-
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
- Regarder ce qu'il se passe en appliquant {thematic} pour le thème ggplot2 de {gouvdown}
- shiny 1.6.0 minimal