ETQ futur mainteneurs et utilisateurs, je souhaite savoir ce que cela implique d'intégrer une mise à jour esthétique du DSE dans une app shiny existante si la méthode est {bslib}, afin de choisir la méthode adaptée

Critères d'acceptation

Un rapport / vignette avec :

• La présentation de deux composantes shiny existantes, une simple et une plus complexe (cf. le tableau de Exploration du processus de mise à jour)

  • Choisir les mêmes que #9 si possible

• ETQ mainteneur, Je sais comment modifier le CSS fourni par le DSE pour qu'il soit adapté à mes composants Shiny existantes avec l'option A: https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#option-a-shiny-bslib

• ETQ mainteneur, Je sais la complexité de modifier automatiquement ce CSS dans le package {shinygouv} avec un code R (pas forcément à développer dès maintenant) pour le jour où le fichier source est mis à jour côté DSE avec l'option A
  

• ETQ utilisateur, Je sais la complexité de passer le template d'une application Shiny déjà en production vers l'utilisation de {shinygouv} avec l'option A (même capture d'écran)
  

• ETQ mainteneur, Je sais comment modifier le CSS fourni par le DSE pour qu'il soit adapté à mes composants Shiny existantes avec l'option B: https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#option-b-shiny-et-replace_me

• ETQ mainteneur, Je sais la complexité de modifier automatiquement ce CSS dans le package {shinygouv} avec un code R (pas forcément à développer dès maintenant) pour le jour où le fichier source est mis à jour côté DSE avec l'option B
  

• ETQ utilisateur, Je sais la complexité de passer le template d'une application Shiny déjà en production vers l'utilisation de {shinygouv} avec l'option B (même capture d'écran)
  

Comment technique

• Comparer le CSS bootstrap classique VS modifié pour le DSE pour que les composantes soient le plus proche possible du DSE
• Indiquer comment ce serait utliisé avec {bslib} pour être appliqué à une Shiny existante
• Ecrire en toutes lettres, les étapes à réaliser pour la transformation d'une application Shiny existante déjà en prod
• Ecrire en toutes lettres, les étapes à réaliser pour mettre à jour le package si le DSE change (nouvelles polices, nouvelles couleurs, nouveau logos, ...)

=> Ces informations permettront aux commanditaires de choisir la méthode adaptée à leur besoin et leurs critères de succès à savoir

• 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

ETQ dev, je souhaiterai savoir par quels composants je commence à développer

Problème

Nous avons défini une liste de composants selon ce que nous avons repéré de plus utilisé dans les apps existantes et listé dans ce tableau: https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#les-inputs-recens%C3%A9s-dans-les-apps-ssm-%C3%A9cologie-par-option

• Sachant les temps de développement estimés dans le tableau, cette liste doit-elle être amendée ? Doit-il y avoir des retraits, une priorisation, des ajouts ?

### UI

- fluidPage
- tabPanel
- navbarPage

### UI et interactions server

- actionButton
- selectInput
- sliderInput
- radioButtons
- checkboxGroupInput
- numericInput
- checkBoxinput
- fileInput
- dateRangeInput
- showModal(modalDialog)
- pickerInput
- radioGroupButtons
- materailSwitch
- withSpinner

ETQ dev je souhaite connaître la liste des templates et composantes des app Shiny déjà déployées, afin d'orienter mes choix de développements vers des changements d'usages les plus réduits possibles

Critères d'acceptation

• Un accès à la liste d'application existantes est disponible: Murielle et Juliette y ont accès

• Un rapport (sous forme de vignette du package) fait l'état des lieux des templates utilisés: https://spyrales.github.io/shinygouv/articles/documentation-inventaire.html
  

• Le rapport fait état des composantes shiny les plus utilisées: https://spyrales.github.io/shinygouv/articles/documentation-inventaire.html#les-composantes
  

Comment technique

• Créer une vignette dans le package pour lister les observations
• Dans la liste d'app, présenter les outils de mise en page des apps: bootstrapPage, fluidPage, navbarPage, tabPanel, shinydashboard, ...
• Recenser de manière qualitative les composantes de {shiny} les plus utilisées pour l'interactivité : actionButton, modalDialog, selectInput, ...
  • Les noter de telle sorte qu'on puisse récupérer cette liste facilement pour mettre dans l'application de démo
• Recenser les composantes hors {shiny} les plus utilisées : {shinyWidgets}, {bsplus}, {leaflet}, ...

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type [COMPOSANT]() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `[COMPOSANT]_dsfr()'
  • Avec la documentation dans le corps de la fonction

• La présentation dans une vignette

• Des tests unitaires

-> Développements à prévoir. Il s'agit d'un cas particulier pour lequel nous n'avons pas encore la méthodologie sous la main pour le tester

• Un exemple d'utilisation dans l'application de démonstration est disponible

https://ssm-ecologie.shinyapps.io/shinygouv-demo/#

-> onglet withSpinner_dsfr

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée aux responsables de projet lorsque c'est traité

Pseudo code :

with_spinner <- \(expr, session = shiny::getDefaultReactiveDomain()){
  showSpinner(session = session)
  force(expr)
  on.exit(hideSpinner(session = session))
}
# s'inspirer de shiny::withProgress
# Prendre un css de https://loading.io/css/

Mettre en hidden par défaut
Position du div est fixe et mettre au milieu de la page
https://colinfay.me/watch-r-shiny/

En fait le spinner est tout le temps là
showSpinner : affiche
hideSpinner : cache

• Remplir les Key Dates et le calendrier prévisionnel
• Ajouter chaque utilisateur au projet en tant que "Guest"
• Prévenir les chefs de projets de monter le niveau de Notification à "Watch" sur la page d'acceuil du projet pour recevoir toutes les notifications
• S'assurer que le Board est pret:https://github.com/spyrales/shinygouv/projects/1
• S'assurer que le Wiki Home est pret:https://github.com/spyrales/shinygouv/wiki/Home
• Indiquer aussi la méthode de partage de CR dans l'issue de Bienvenue du Client : #1
• Notifier chaque utilisateur en les mentionnant dans un commentaire de l'issue : #1 avec le texte suivant :

Merci de bien vouloir lire et valider le contenu de cette page.
Si vous lisez ce message dans un email, vous pouvez cliquer sur le lien suivant pour accéder à la page :
https://github.com/spyrales/shinygouv/issues/1
@mention, @mention, ...

• Mettre en place {renv} en suivant "dev/dev_history_renv.R"
• Si nécessaires, exécuter les étapes de "dev/dev_history.R". La plupart sont déja faites.

ETQ dev de {shiny.dsfr}, je souhaite avoir des retours sur l'utilisation de {charpente} pour savoir si cela répond au besoin de mise à disposition d'un template aux couleurs du DSE, et si non pourquoi

=> En attente de la fin de l'Exploration du processus de mise à jour

Critères d'acceptation

• Un rapport / vignette, en lien avec le contenu de l'Exploration du processus de mise à jour, indique ce qui répond ou ne répond pas au besoins suivants dans {shiny.dsfr} :

  • "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"

• J'ai lu et je valide le document complet ici

Comment technique

• S'il s'avère que l'Exploration du processus de mise à jour indique que la meilleure méthode, c'est {bslib}, reporter la discussion vers le rapport en question.
• Si c'est la méthode {charpente} qui est retenue, indiquer ce qui est à conserver dans le package actuel et ce qui est à améliorer
• Il est possible de faire quelques recommendations bientraitantes sur le code lui-même, sans entrer non plus dans les détails.

ETQ utilisateur, je souhaite avoir accès aux paramètres courants de radioButton() dans radioButton_dsfr()

Critère de validation

• Le paramètre selected est présent et focntionnel dans radioButton_dsfr()

## Only run examples in interactive R sessions
if (interactive()) {
ui <- fluidPage_dsfr(
  radioButtons_dsfr(inputId = "inRadioButtons", 
                    label = "Input radio buttons",
                    choices = c("Item A","Item B", "Item C")),
  actionButton_dsfr("go","Change")
)

server <- function(input, output, session) {
  
  observeEvent(input$go,{
    updateRadioButtons_dsfr(
      session = session, 
      inputId = "inRadioButtons",
      label = "Un nouveau label",
      choices = c("A" = "a"),
      selected = "a"
    )
  })
  
  observeEvent(input$inRadioButtons,{
    message(input$inRadioButtons)
  })
}

shinyApp(ui, server)
}

• Son utilisation est testée dans le package
  

ETQ utilisateur/utilisatrice, je souhaite pouvoir mettre à jour un composant de type radioButtons_dsfr() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `updateradioButtons_dsfr()'
  • Avec la documentation dans le corps de la fonction

• La présentation dans la vignette du radioButton déjà existante
• Des tests unitaires
• Un exemple d'utilisation dans l'application de démonstration est disponible

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée à @statnmap lorsque c'est traité

ETQ utilisateur/utilisatrice je veux savoir comment créer une nouvelle application Shiny utilisant le DSFR

Critère d'acceptation

• Avoir une vignette qui documente la procédure de création d'une nouvelle app shiny dsfr: https://spyrales.github.io/shinygouv/articles/comment-demarrer-une-nouvelle-application-shiny-dsfr.html
  

Comment technique

• nouveau flat indiquant la création d'un golem + convert_to_dsfr()
• y faire référence à la table des composants déjà implémentés ainsi que la documentation
• référence au DSFR pour les règles d'usage

ETQ developpeur, je suis alerté si des changements n'ont pas été pris en compte à la nouvelle version du dsfr.

Critère d'acceptation

• les fonctions des composants sont testées avec leurs paramètres d'entrée, et le HTML de sortie
  • Exemple pour radioButtion

• la procédure est complétée
  

Critère technique

• Ajout de tests unitaires pour chaque composant
• Procédure à revoir

=> ETQ (En Tant Que) Contributeurice du projet je sais comment fonctionne le dépôt

Bonjour et bienvenue sur notre outil de suivi de projet.

Si vous lisez ce message depuis vos emails, merci de cliquer sur le lien en bas "View it on GitHub" ou "Lire sur GitHub".

Ce site web est l'outil de développement GitHub. Il nous permet de versionner notre code (conserver l'historique des modifications) et de communiquer sur les fonctionnalités en cours de développement.

Le message que vous lisez actuellement est un ticket de suivi (aussi appelé "issue"). C'est sous ce format que nous listons toutes les fonctionnalités demandées et bugs divisés en unités de développement. C'est aussi sous ce format que la totalité de nos échanges devront être stockés. Nous évitons les Emails pour conserver l'historique des échanges, rangés dans les tickets dédiés, pour ne rien perdre de vos besoins et demandes.

Au cours du développement, nous vous demanderons de :

• répondre à nos points de blocage. Pour cela, comme pour le présent ticket, vous serez notifiés par un Email qui contient un lien pour venir sur l'interface. Nous vous donnerons le plus d'informations possibles sur le problème. Pour nous répondre, vous pouvez écrire un message dans la partie dédiée ci-dessous, quand vous avez le temps de le faire. Nous vous demandons d'ailleurs de bien vouloir écrire un message dès à présent et de le valider. Merci.
• suivre l'avancement du projet dans le Kanban dédié. Ce Kanban se trouve à l'adresse suivante que vous pouvez ouvrir dès à présent dans un nouvel onglet : https://github.com/spyrales/shinygouv/projects/1
  • Vous verrez que le ticket que vous êtes en train de lire se trouve dans la colonne "Bloqué". Cette colonne de tickets vous est adressée. Tous les tickets qui s'y trouvent nécessitent des informations complémentaires pour être traités. En théorie, vous aurez reçu un email pour chacun d'entre eux, mais s'il y en a trop, vous savez maintenant où les retrouver.
• valider les tickets terminés. Dans le Kanban, vous avez une colonne en fin de Kanban nommée A valider. Il s'agit des tickets que nous considérons avoir implémentés et qui nécessitent validation de votre part.
  • Lorsque vous pouvez faire la validation sans assistance de notre part, nous vous donnerons toutes les instructions pour savoir comment valider. Vous pourrez écrire un message du type : "Je valide la fermeture de ce ticket."
  • En cas de ticket plus complexe ou plus technique, nous le validerons ensemble lors d'un point d'avancement en direct. Auquel cas, nous validerons la fermeture dans le compte-rendu de réunion.

Notez que nos échanges lors de réunions en direct seront rédigés et accessibles pour vous dans :

• Le Wiki de ce projet : https://github.com/spyrales/shinygouv/wiki
• La vision générale des livrables: https://github.com/spyrales/shinygouv/wiki/Key_Dates

Merci de bien vouloir nous indiquer que vous avez lu et approuvé à la date d'aujourd'hui ce mode de fonctionnement en écrivant : "lu et approuvé, le {date du jour}" (Mettre la date du jour) dans un message ci-dessous (Emplacement "Write" ou "Ecrire") et valider l'envoi du message en cliquant sur le bouton vert "Comment" ou "Envoyer".
Suite à quoi, nous nous chargerons de fermer ce ticket.

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type selectInput() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `selectInput_dsfr()'
  • Avec la documentation dans le corps de la fonction

• La présentation dans une vignette

• Des tests unitaires

• Un exemple d'utilisation dans l'application de démonstration est disponible

https://ssm-ecologie.shinyapps.io/shinygouv-demo/#

-> onglet selectInput_dsfr

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée aux responsables de projet lorsque c'est traité

ETQdev, je veux un ci opérationnel de nouveau

Acceptation

• Le ci est tout vert

technique

Mettre la source du package xfun

ETQ utilisateur/utilisatrice je veux savoir comment transformer mon application Shiny existante pour qu'elle utilise le DSFR

Critère d'acceptation

• Avoir une vignette qui documente la procédure de transformation

https://spyrales.github.io/shinygouv/articles/convertir-une-app-shiny-en-app-shiny-dsfr.html

• Avoir une fonction qui permet de convertir une application shiny en application shiny dsfr

• Etre capable de le refaire soi-même

• utilisation de la fonction sur l'application de demo: (disponible dans 'inst\appshinydemo')
  

Après passage de convert_to_dsfr(version = "1.7.2")

Comment technique

• Création d'un tableur csv dans inst/vx.y.z qui reprendre les composants déjà implementer et leur correspondance (shiny <-> dsfr)
• Créer une fonction qui remplace toutes les composantes shiny en dsfr (quand elles ont été implémentée)
• faire le test sur l'appshinydemo

ETQ dev, je souhaite connaitre sous quel régime de licence le projet doit-il etre développé

Problème

Pour le moment, nous avons choisi de mettre la même licence que pour {gouvdown}: https://github.com/spyrales/shinygouv/blob/main/LICENSE

• Était-ce le choix adapté ?

ETQ utilisateurs, j'aimerais que mon package ne dépende pas de {stringr} car celui si nécessite l'installation de {stringi} qui met beaucoup de temps à compiler.

Critère d'acceptation

• le package stringr n'est plus en dépendance de shinygouv dans le fichier DESCRIPTION

Critère technique

• remplacer stringr par du rbase

Le composant fluidPage_dsfr a en dur la version de dsfr, actuellement elle est donc bloquée à 1.7.2.

Validation

• Lorsque je lance shinygouv::fluidPage_dsfr() toutes les mentions 1.7.2 ont été substituées par des 1.9.3

Dev

• Modifier la fonction fluidPage_dsfr_template() dans fluidpage_dsfr.Rmd pour prendre en compte un paramètre "dsfr_version"
• Dans shinygouv/inst/v1.9.3/composant/fluidpage.html substituer les numéros de version en dur par {{dsfr_version}}
• Adapter les tests unitaires si besoin

ETQ futur mainteneurs et utilisateurs, je souhaite savoir ce que cela implique d'intégrer une mise à jour esthétique du DSE dans une app shiny existante si la méthode est {charpente}, afin de choisir la méthode adaptée

Critères d'acceptation

• Je sais pourquoi nous n'avons pas directement retenu la méthode {charpente}:
  Utiliser {charpente} implique de recoder la partie HTML d'une composante avec les fonctions de {shiny} type tags$p(), tags$a(), ...
  Or, le DSFR fournit le code HTML brut, que l'on peut copier en l'état depuis le sources du DSFR dans un htmlTemplate() sans que cela ne réduise les possibilité de modification des composantes.
  Ainsi, sans repasser pas {charpente}, nous simplifions l'ajout et la maintenance des composants.

Un rapport / vignette avec :

• La présentation de deux composantes shiny existantes, une simple et une plus complexe (cf. le tableau de Exploration du processus de mise à jour)

  • Choisir les mêmes que #8 si possible

• ETQ mainteneur, Je sais comment créer et modifier les composantes sur-mesure et intégrer les nouveaux CSS/JS fournis par le DSE dans mon package pour l'option C:
  https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#option-c-from-scratch

• ETQ mainteneur, Je sais la complexité de modifier automatiquement ces composantes dans le package {shinygouv} avec un code R (pas forcément à développer dès maintenant) pour le jour où les fichiers sources sont mis à jour côté DSE pour l'option C
  

• ETQ utilisateur, Je sais la complexité de passer le template d'une application Shiny déjà en production vers l'utilisation de {shinygouv} pour l'option C (même capture qu'au-dessus)
  

• ETQ mainteneur, Je sais comment créer et modifier les composantes sur-mesure et intégrer les nouveaux CSS/JS fournis par le DSE dans mon package pour l'option D:
  https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#option-d-from-scratch-mais-pas-vraiement

• ETQ mainteneur, Je sais la complexité de modifier automatiquement ces composantes dans le package {shinygouv} avec un code R (pas forcément à développer dès maintenant) pour le jour où les fichiers sources sont mis à jour côté DSE pour l'option D
  

• ETQ utilisateur, Je sais la complexité de passer le template d'une application Shiny déjà en production vers l'utilisation de {shinygouv} pour l'option D (même capture qu'au-dessus)
  

Comment technique

• Définir comment pourraient être créé les HTML sur-mesure des composantes, et intégrer le CSS du DSE
• Indiquer comment ce serait utliisé avec {charpente} pour être appliqué à une Shiny existante
• Ecrire en toutes lettres, les étapes à réaliser pour la transformation d'une application Shiny existante déjà en prod
• Ecrire en toutes lettres, les étapes à réaliser pour mettre à jour le package si le DSE change (nouvelles polices, nouvelles couleurs, nouveau logos, ...)

=> Ces informations permettront aux commanditaires de choisir la méthode adaptée à leur besoin et leurs critères de succès à savoir

• 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

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type navbarPage() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `navbarPage_dsfr()'
  • Avec la documentation dans le corps de la fonction
  • La présentation dans une vignette
  • Des tests unitaires
• Un exemple d'utilisation dans l'application de démonstration est disponible

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée aux responsables de projet lorsque c'est traité

ETQ LeadDev, j'ai besoin de savoir qui est responsable de quoi sur ce projet, afin de savoir vers qui me tourner si j'ai des questions, des tickets à valider ou des priorisations à réaliser

Critères d'acceptation

ThinkR s'occupe de la mise en place du projet, des explorations du DSE en lien avec Shiny et des premiers développements.

• Je connais les personnes référentes pour les décisions d'orientation du projet: Juliette Engelaere-Lefebvre
• Je connais les personnes référentes côté ThinkR pour la gestion du projet: Sébastien Rochette, Margot Brard
• Je connais les développeurs côté ThinkR: Murielle Delmotte, Cervan Girard
• Je connais les personnes qui peuvent valider les livrables: Juliette Engelaere-Lefebvre, ...
• Je connais les personnes qui peuvent reprendre la maintenance du projet à l'issue de la mission ThinkR: Juliette Engelaere-Lefebvre , ...

Critère de validation

• La table de correspondance dans inst/v1.9.3/table_correspondance_shiny_dsfr.csv est à jour pour les nouveaux composants

table_correspondance_shiny_dsfr.csv

ETQ dev, nous avons besoin de savoir dans quelle langue documenter le package

Critères de validation

• L'information sur la langue est passée auprès des dev
  

• Les dev ont mis à jour leurs templates de commit
  

• La documentation pour les développeureuses informe des langues à utiliser: https://github.com/spyrales/shinygouv/tree/15_francisation/dev/documentation
  

• Le template de commit par défaut est en français: https://github.com/spyrales/shinygouv/blob/15_francisation/.github/template_commit
  

• Le template de Pull request par défaut est en français: https://github.com/spyrales/shinygouv/blob/15_francisation/.github/pull_request_template.md
  

• Le guide de Contribution est en anglais et dirige vers la documentation des développeureuses: https://github.com/spyrales/shinygouv/blob/15_francisation/.github/CONTRIBUTING.md
  

Problèmes à résoudre

Le package contient plusieurs sources de documentation. Pour certaines, la rédaction en français nécessite des ajustements liés à l'encodage et à l'utilisation des caractères ASCII.
Pourriez-vous nous indiquer, pour chacune des sources de documentation suivantes, quelle langue utiliser ?

• Rapports d'exploration (présentés en vignettes) : Français
• 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}

Validation

• L'app déployée sur https://ssm-ecologie.shinyapps.io/shinygouv-demo/ possède des caractères spéciaux
  • Dans le header
  • Dans les boutons

Dev

ETQ utilisateur windows de la fonction header_dsfr(), je ne sais pas comment ajouter un "é" dans "préfet" au niveau du paramètre intitule pour que l'encodage soit traité correctement

ETQ utilisateur, je visualise l'image sous le chunk de la partie Option B dans la vignette recommandation pour l'implementation.

Critère d'acceptation

• Visualisation de l'image sous le chunk:

https://spyrales.github.io/shinygouv/articles/Dev-E-recommandation-pour-l-implementation-de-dsfr.html

Comment technique

Pour les images, vous pouvez les mettre depuis la racine du projet dans
![](reference/figures/image.png)
C'est le seul dossier me semble-t-il qui est récupéré en l'état par {pkgdown}.
C'est ce que vous pouvez utiliser pour mettre des images dans le Readme aussi par exemple.
Ça marche aussi dans "man/figures/", sachant que {pkgdown} les déplacera dans "reference/figures" pour son propre usage, en changeant les url.

ETQ commanditaire, j'aimerai pouvoir suivre au mieux l'évolution du projet et de pouvoir avoir un code lisible entre chaque développeur

Critère de validation

• Avoir un template de commit identique pour chaque dev, calqué sur le "conventional commit" et qui permet notamment de suivre la qualité de développement d'un projet
  https://github.com/spyrales/shinygouv/blob/9a4b93ba3e326d74c7cd16d6b5852fe23d79ec87/.github/template_commit

• Avoir un workflow permettant de gommer le style de chaque développeur⋅se afin de faciliter la maintenance
  https://github.com/spyrales/shinygouv/tree/add_tags_to_git/dev/documentation

Comment technique

• [ x] Ajouter un template de commit et expliquer comment le mettre en place
• [ x] Ajouter un workflow avant de commit et expliquer comment le mettre en place

ETQ utilisateur du package, j'aimerai savoir quel composants Shiny je peux utiliser de telle sorte qu'ils soient compatibles avec le DSE

Critères d'acceptation

• Un tableau présenté dans une vignette du package indique les différents ponts possibles entre des composants du Design System et des composants Shiny courants (cf. liste des composants de l'Observation "terrain" - faire l'inventaire) avec un tableau comparatif et des niveaux de complexité à mettre en oeuvre

https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#comparaison-entre-les-diff%C3%A9rentes-possibilit%C3%A9s-pour-r%C3%A9pondre-au-besoin-dutilisation-du-framework-dsfr

Comment technique

• Une colonne avec le composant Shiny (ou {shinywidgets}, {bsplus}, ...), une colonne avec le composant équivalent du DSE, une colonne niveau de complexité à mettre en oeuvre (une explication indiquera ce que ce niveau de complexité signifie - complexe pour les dev du package, complexe pour les utilisateurs, ... ?)
  • Note: Cette table de correspondance doit etre pensée pour faciliter le choix de la méthode de développement ({bslib} ok ou {charpente} ok, ...) (cf. Exploration du processus de mise à jour) . Peut-être des composantes pourront directement être utilisable avec du CSS seulement, d'autres auront à être créés sur-mesure.
• Tous les composants du DSE doivent apparaître dans ce tableau
• Tous les composants listés dans l'Observation "terrain" - faire l'inventaire devrait apparaître dans ce tableau

ETQ LeadDev, je souhaite prioriser les tâches de développement afin que la reprise et l'adoption du package se fassent dans les meilleures conditions

Problèmes

Etant donné le temps imparti pour la mission, il faut choisir entre l'implémentation de nouvelles fonctionnalités, et le guide de développement pour une bonne prise en main des développeurs et utilisateurs.

Il y a plusieurs choses à traiter. Voici le choix de priorisation que nous avons fait:

1. Expliquer aux développeuses et développeurs du package comment ajouter une nouvelle composante et comment la documenter. Sachant qu'il y a des composantes plus complexes que d'autres. Exemples avec fluidPage(), actionButton() et radioButton().
2. Expliquer aux utilisatrices et utilisateurs de {shinygouv} comment transformer leurs applications Shiny existantes pour qu'elles utilisent le DSFR. Exemple avec l'application Shiny de démonstration du package {shinygouv}.
3. Expliquer aux utilisatrices et utilisateurs de {shinygouv} comment créer une application Shiny depuis une page blanche en utilisant le DSFR directement. Documentation des composantes incluses et de leur utilisation.
4. Indiquer ce qui est possible ou non avec les composantes du DSFR, avec la liste des composantes déjà incluses
5. Inclure les autres composantes

Validation

• @jengelaere peux-tu nous confirmer que l'aide au développement et à l'utilisation est plus important que d'ajouter le plus possible de composantes dans le package ?

Note qu'il est peu probable que nous n'irons pas beaucoup plus loin que ces 3 composantes: fluidPage(), actionButton() et radioButton(). Mais une fois que tous les templates et doc seront prêts, ça ira beaucoup plus vite pour vous.

ETQ dev, nous avons besoin de savoir où trouver les changelogs de DSFR et Shiny

Critères de validation

• Les liens vers les changelogs de DSFR et Shiny sont présents dans la vignette https://spyrales.github.io/shinygouv/articles/trouver_css_js.html

Comment technique

• Ajouter un $ "comment savoir ce qui a été mis à jour." dans la vignette "trouver_css_js", pour y intégrer les liens vers les changelos (cf vignette "Recommandation pour l'implementation de DSFR")

ETQ dev, j'aimerai avoir un accès clair à la doc de dev, pour savior si je m'implique ou pas, et comment ça va se passer.

acceptation

• Je sais ou trouver le doc de développeur pour la mise en place
• Je sais ou trouver le doc de développeur pour la création d'un nouveau template
• Je sais ou trouver le template_flat_new_one pour démarrer mon développement
• Contributing => Je sais comment réformer un flat_file (c'est écrit que je ne doit plus le modifier...)
• Contributing => Je sais comment maintenir les fonctions existantes

comment technique

• On utiliser le flat template pour la creation d'un nouveau composant
• Quand le composant est fini en première version fonctionnelle, on réforme le flat_template dans "dev/dev_history"
• Le flat template dun composant ne produit pas de vignette (ce qui va alléger le dossier dev/documentation)
• Le dossier dev/documentation est supprimé
• flat_new_one.Rmd => template_flat_new_one.Rmd, à mettre à la racine de dev
• Comment creer un composant, est plutôt une vignette de dev, nommé "dev - ", Réservée aux dev
• Le Readme de dev/documentation est mis en vignette de "dev-"

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type navbarPage_dsfr conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `navbarPage_dsfr()'
  • Avec la documentation dans le corps de la fonction https://github.com/spyrales/shinygouv/blob/main/R/navbarpage_dsfr.R#L98
  • Des tests unitaires https://github.com/spyrales/shinygouv/blob/main/tests/testthat/test-navbarpage_dsfr.R
• Un exemple d'utilisation dans l'application de démonstration est disponible https://ssm-ecologie.shinyapps.io/shinygouv-demo/
  • La fonctionnalité de navbar est fonctionnelle : quand je clique sur un onglet, le contenu change et la réactivité fonctionne
  • Je peux pointer vers un onglet avec l'url : https://ssm-ecologie.shinyapps.io/shinygouv-demo/#with_spinner_dsfr

Validation

• La version de DSFR présent dans le package est 1.9.3

Dev

Suivre process dans la vignette correspondante

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type showModal/modalDialog/hideModal conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `modalDialog_dsfr()'
  • Avec la documentation dans le corps de la fonction https://github.com/spyrales/shinygouv/blob/main/R/modaldialog_dsfr.R#L43
  • Des tests unitaires https://github.com/spyrales/shinygouv/blob/main/tests/testthat/test-modaldialog_dsfr.R#L3
• Un exemple d'utilisation dans l'application de démonstration est disponible https://ssm-ecologie.shinyapps.io/shinygouv-demo/#modal_dialog_dsfr
  • Quand je clic sur le bouton, le modal s'ouvre
  • Le modal contient un input shiny qui met à jour le texte sur la droite

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée aux responsables de projet lorsque c'est traité

https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/modale

=> https://github.com/ThinkR-open/w3css/blob/master/R/w3css_modal.R, https://github.com/ThinkR-open/w3css/blob/master/inst/srcjs/handlers.js, https://github.com/ThinkR-open/w3css/blob/master/inst/htmltemplates/modal.html

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type tabPanel_dsfr() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `[COMPOSANT]_dsfr()'
• Un exemple d'utilisation dans l'application de démonstration est disponible

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée aux responsables de projet lorsque c'est traité

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type selectInput() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `selectInput_dsfr()'
  • Avec la documentation dans le corps de la fonction
  • La présentation dans une vignette
  • Des tests unitaires
• Un exemple d'utilisation dans l'application de démonstration est disponible

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée aux responsables de projet lorsque c'est traité

ETQ utilisateur/utilisatrice, je souhaite pouvoir mettre à jour un composant de type actionButton_dsfr() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `actionButton_dsfr()'
  • Avec la documentation dans le corps de la fonction
  • La présentation dans la vignette du actionButton déjà existante
  • Des tests unitaires
• Un exemple d'utilisation dans l'application de démonstration est disponible

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée à @statnmap lorsque c'est traité

Utiliser updateActionButton_dsfr <- shiny::updateActionButton est suffisant

Critères d'acceptation des développements effectués

• Le GA passe
• L'app est déployée

Comment technique

So far, nous avons passé la partie déploiement sur dev afin de pouvoir poursuivre l'implémentation.

Il va falloir passer du temps pour régler : https://github.com/spyrales/shinygouv/actions/runs/5379386198/jobs/9760533769

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type switch conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `switch_dsfr()'
• Un exemple d'utilisation dans l'application de démonstration est disponible

https://ssm-ecologie.shinyapps.io/shinygouv-demo/
voir section toggleSwitch_dsfr

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée aux responsables de projet lorsque c'est traité

ETQ client, je souhaite avoir accès aux différents rapports de qualité de la livraison

Critères d'acceptation

• J'ai récupéré un dossier de livrables: deliverables.zip
• Le livrable contient le rapport de couverture de code (codecoverage) + l'explication des indicateurs
• Le livrable contient le rapport des messages de commit associés au issues GitHub (gitdown)
• Le livrable contient le rapport de tests unitaires par fichier de test (testdown)
• Le résumé du code coverage est dans une vignette: https://spyrales.github.io/shinygouv/articles/tests_and_coverage.html
• La version du dépôt git est taguée v0.0.1: https://github.com/spyrales/shinygouv/releases/tag/v0.0.1

Comment technique

• Executer le code dans "dev/dev_history_deliverables.R"

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un header conforme au dsfr à mon application shiny dsfr

Critère d'acceptation

• une fonction implementée, documentée, testée : `header_dsfr()'

• Exemple d'utilisation dans l'application de demo

https://ssm-ecologie.shinyapps.io/shinygouv-demo/

Comment technique

• Utilisation du workflow 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Modifier le fluidPage_dsfr pour qu'il prenne, si nécessaire, le header

ETQ dev, j'ai un problème sur le CI avec {gert} sur windows

Critère d’acceptation

• Avoir un CI de nouveau opérationnel

Comment technique

• Pour l'instant on va attendre un correctif de la part de rstudio

ETQ dev, j'aimerai suivre la procédure "comment recoder un composant de dsfr avec une interaction {shiny}", pour coder le radioButton

Critère d'acceptation

• une fonction implementée, documentée, testée : `radioButton_dsfr()'
  - voir doc : https://github.com/spyrales/shinygouv/blob/main/dev/documentation/radiobuttons_dsfr.Rmd

Comment technique

• Utilisation du workflow 'dev/documentation/comment-faire-un-composant-shiny.Rmd'

ETQ dev, je veux pouvoir initier une nouvelle application avec fluiPage_dsfr ou navbarPage_dsfr

Critère d'acceptation

• une fonction pour fluidpage
  

Disponible sur l'url : https://ssm-ecologie.shinyapps.io/shinygouv-demo/

Comment

• ajouter les dépendances
• gérer le javascript

ETQ utilisateurs, la fonction convert_to_dsfr ne doit pas remplacer tous les ( par header_dsfr(

Critère d'acceptation

• Une conversion d'une appli basique type 'Old Faithful Geyser Data' réussie. c'est à dire que seul les composants ayant un équivalent shiny <> dsfr sont remplacés.

Après conversion:

Critère techniques

• rajouter na.string=c("","NA") dans la lecture de la table de correspondance.
• ajouter un test unitaire

ETQ dev, j'ai besoin de savoir quel fichiers de configuration je peux utiliser comme source pour le développement du package, afin de pouvoir mettre à jour son contenu en lien avec le DSE

Critères de validation

• Je sais où sont stockés les éventuels fichiers CSS / JS du DSE
  - Ils sont maintenant stockés dans "inst/dsfr-v1.6.0" pour la dernière version: https://github.com/spyrales/shinygouv/tree/main/inst/dsfr-v1.6.0/dist
  

• Je sais comment je peux les récupérer manuellement ou automatiquement
  - Une vignette a été rédigée en ce sens pour clarifier comment télécharger et quels fichiers garder: https://spyrales.github.io/shinygouv/articles/trouver_css_js.html
  

Comment technique

• Le site du DES est : https://gouvfr.atlassian.net/wiki/spaces/DB/pages/193003540/COMMENT+UTILISER+LE+DSFR

ETQ dev, je veux une page qui explique ou se situe les fichiers

Acceptation

• des liens vers les différents md pour le développement

• Le readme indique comment créer une issue et une branche

• Il y a un template d'issue pour l'ajout de nouveau composant
  

Comment

Reprendre le dossier documentation et le structure. Ajotuer les liens dans le README

ETQ utilisateur, je souhaite voir un exemple de comment transformer une application Shiny existante vers le DSFR, afin de pouvoir le reproduire sur mon application

En attente

• Quelles composantes intégrer pour commencer: #22

Critère d'acceptation

• je vois sur la capture d'écran ci-dessous que le package inclut une application Shiny de démonstration contenant les composantes utilisées classiquement, sans DSFR

Comment technique

• Créer une base d'app Shiny UI/Server avec modules, qui servira pour la doc et les tests unitaires
• Y mettre les composantes couramment utilisées listée dans la vignette

=> Cette application Shiny servira de base pour faire les tests et la documentation de migration d'une app Shiny. Ce n'est pas l'application en démonstration sur Shinyapps.io, mais la base qui servira à la démo en ligne.

ETQ utilisateur/utilisatrice, je souhaite pouvoir ajouter un composant de type checkBoxInput() conforme au dsfr à mon application shiny dsfr

Critères d'acceptation des développements effectués

• Une fonction implementée, documentée, testée : `checkBoxInput_dsfr()'
  • Avec la documentation dans le corps de la fonction
  • La présentation dans une vignette
  • Des tests unitaires
• Un exemple d'utilisation dans l'application de démonstration est disponible

Comment technique

• Je crée une branche pour développer la fonctionnalité
• Utilisation du workflow décrit dans 'dev/documentation/comment-faire-un-composant-shiny.Rmd'
• Utiliser le flat file fourni pour développer avec {fusen}
• J'ouvre une PR assignée à @statnmap lorsque c'est traité

ETQ dev, je voudrai voir une application qui met en avant l'avancement des composants

Critère d'acceptation

• une url avec l'application shiny

en dev : https://ssm-ecologie.shinyapps.io/shinygouv-demo-dev/
en prod : https://ssm-ecologie.shinyapps.io/shinygouv-demo/

• un déploiement automatique avec le CI

voir les fichiers : https://github.com/spyrales/shinygouv/blob/main/.github/workflows/deploy.yaml, https://github.com/spyrales/shinygouv/blob/main/.github/workflows/deploy-dev.yaml et https://github.com/spyrales/shinygouv/blob/main/dev/deploy.R

Comment technique

• Reprendre le script suivant

rsconnect::setAccountInfo(name   = Sys.getenv("shinyapps_name"),
                          token  = Sys.getenv("shinyapps_token"),
                          secret = Sys.getenv("shinyapps_secret"))

rsconnect::deployApp(appDir = ".",appName = "jeanjean")

• Adapter le CI pour l'exécution de ce script

ETQ dev, j'aimerai avoir une procédure à suivre pour savoir comment recoder un composant de dsfr avec une interaction {shiny}, par exempel le actionButton

Critère d'acceptation

• Avoir une documentation dans le dossier dev
  https://github.com/spyrales/shinygouv/blob/main/dev/documentation/comment-faire-un-composant-shiny.md
• Comprendre l'intérêt des classes déjà existantes dans shiny
  https://github.com/spyrales/shinygouv/blob/main/dev/documentation/comment-faire-un-composant-shiny.md
• Etre capable de le refaire soi-même

Comment technique

• Utilisation des templates html et de la fonction html_template
• Utilisation des classes existantes dans shiny

Ticket ouvert suite aux retours de @jengelaere le 28/06/2023

Validation

• toggleSwitch_dsfr a été ajouté dans l'app de démo

https://ssm-ecologie.shinyapps.io/shinygouv-demo/
voir section toggleSwitch_dsfr

• le news a été incrémenté avec les nouvelles fonctionnalités
  - [ ] un commit propre d'implem d'un composant est cité

https://github.com/spyrales/shinygouv/blob/main/NEWS.md

• les branches mergées ont été supprimées
• [ ]
  https://github.com/spyrales/shinygouv/branches

Dev

• toggleSwitch_dsfr a été ajouté dans l'app de démo
• le news a été incrémenté avec les nouvelles fonctionnalités
  - [ ] un commit propre d'implem d'un composant est cité
• supprimer les branches mergées