Répondre à: Transfert de connaissances

  • R3dKap

    Membre
    15 juillet 2022 à 17h12

    Salut Geoffroy WAGNER, ne te ronges pas trop quand même… 😅

    La question de la documentation des applications Power Apps revient souvent… Et moi-même je me suis déjà challengé sur le sujet…

    J’ai récemment trouvé un outil que quelqu’un a développé pour générer automatiquement la documentation d’une application Power Apps. Mais, comme on peut s’en douter, tout système automatique qu’il est il ne fait que générer des pages et des pages de documents Word qui ne font que mettre à plat sur le papier ce qui existe dans l’application : liste des écrans et leurs contrôles, les bouts de codes associés, etc. Mais ce genre d’outil automatique n’est pas capable d’expliquer les subtilités et la logique d’une application comme le peut faire un être humain.

    Je considère donc que c’est le rôle du développeur de décrire de lui-même comment son application est architecturée et surtout d’en décrire ses subtilités. Reste à voir sous quelle forme et de quelle manière…

    Je vais décrire ici 2 techniques que j’ai personnellement utilisées pour documenter mes applications Power Apps…

    Le composant de documentation directement intégré à l’application

    L’idée consiste à stocker la documentation dans une liste SharePoint (ou une table du Dataverse selon l’application). Côté application, un composant ajouté à chaque écran permet de créer/éditer la documentation associée à l’écran en question.

    Gros avantage : le développeur peut documenter son application directement depuis le Studio au fur et à mesure qu’il la construit. Mais faut être assidu.

    Inconvénient : impossible d’incruster des images au milieu du texte car le composant d’édition HTML de Power Apps ne le permet pas.

    Je viens de faire un p’tit article ici pour expliquer comment utiliser ce composant :

    Le document PowerPoint

    Il s’agit ici simplement de documenter l’application dans un document PowerPoint en décrivant ses caractéristiques et ses différents écrans.

    Gros avantage : on peut formaliser la documentation comme on le veut (avec des flèches, des graphiques, etc.) + on peut y adjoindre d’autres éléments comme l’architecture de l’application.

    Inconvénient : le document est “séparé” de l’application à contrario du composant décrit précédemment qui est directement intégré à l’application.

    Par exemple, pour une application qui permet de gérer des demandes je l’ai documentée ainsi :

    • Une slide pour décrire l’architecture de l’application : indication de la source de données, présence de flux Power Automate,

    • Une slide pour décrire le contenu du App.OnStart : les variables globales, les préchargement de données en collections locales, …

    • Une slide pour expliquer à quoi sert chacun des écrans de l’application

    • Plusieurs slides pour chaque écran. Par exemple pour l’écran d’accueil qui affiche la liste des demandes, permet de filtrer les demandes, permet de trier les demandes :

      • Une slide pour expliquer comment je construis la liste des demandes (en gros, le Items de la galerie)

      • Une slide pour expliquer le fonctionnement du tri des colonnes

      • Une slide pour expliquer comment les boutons de la barre d’actions sont visibles ou pas en fonction de certains critères liés à la demande sélectionnée

      • etc.

    • etc.

    Comme tu le vois, l’idée c’est vraiment d’aborder ce document Power Point comme si tu faisais un cours à une personne pour lui expliquer l’application. Il y a très souvent plusieurs slides pour chacun des écrans de l’application afin de bien détailler les différentes fonctionnalités ou caractéristiques qui leur sont propres.

    Voilou…

    CommentID=64evX2ZnFVy4ys7, PostID=dmMRgV3ikUdjXI6