Ce retour d’expériences (REX) Power Apps est simple et direct, sans fioritures, ni considérations philosophiques :). C’est celui que j’aurais aimé trouvé quand j’ai débuté sur Power Apps.
Power Apps est une plateforme de Microsoft qui permet de créer des applications sans avoir besoin de coder. C’est un outil qui offre de nombreuses possibilités pour automatiser des processus, collecter des données, interagir avec d’autres services, etc.
Mais comment développer efficacement avec Power Apps ? Quelles sont les bonnes pratiques à suivre ? Quels sont les pièges à éviter ?
Nous allons partager avec vous notre retour d’expériences (REX) sur les développements Power Apps, basé sur nos projets réels.
Nous espérons que ces conseils vous seront utiles et vous feront gagner du temps et de la qualité.
Si vous rencontrez des erreurs dans les manipulations ci-dessous, lisez l’article qui explique comment débuguer les erreurs dans Power Apps.
Gardez à l’esprit que l’interface a pu évoluer fortement depuis que cet article a été rédigé.
Ne pas se lancer directement dans le développement !
La première étape avant de développer avec Power Apps est de définir clairement le besoin et le résultat attendu.
Pour cela, il est indispensable de créer une maquette 1:1 (« mock-up ») du design et du fonctionnement de l’application. La maquette doit être complète, détaillée et précise.
Elle doit montrer tous les écrans, les contrôles, les données, les enchaînements, les validations, etc. La maquette doit être validée par le client ou l’utilisateur final avant de passer au développement.
La maquette peut être réalisée avec n’importe quel outil : un crayon et du papier, PowerPoint, Visio, Balsamiq, etc. L’important est qu’elle soit fidèle à ce que sera l’application finale. L’avantage de faire une maquette est qu’elle permet de clarifier le cahier des charges, d’éviter les malentendus, de simplifier la communication et de réduire les risques de changements ultérieurs.
En effet, les changements sont coûteux et fastidieux une fois le développement démarré. Il vaut mieux les anticiper et les intégrer dès le début.
Retour d’expériences (REX) Power Apps : Définir les valeurs de base
Les valeurs de base sont les éléments qui vont définir l’identité visuelle et l’ergonomie de l’application.
Il s’agit principalement des couleurs, des polices et des tailles des contrôles.
Il est important de choisir ces valeurs avec soin et de les respecter lors du développement pour avoir une apparence cohérente et professionnelle.
Les couleurs
Les couleurs doivent être en harmonie avec le thème choisi et le logo du client ou de l’utilisateur. Il faut éviter les couleurs trop vives ou trop sombres qui peuvent nuire à la lisibilité ou à l’esthétique.
Il faut également respecter les conventions d’usage : par exemple, le rouge pour signaler une erreur ou une alerte, le vert pour valider ou confirmer, etc. Les couleurs doivent être exprimées en code RGBA (Red Green Blue Alpha) qui permet de définir la transparence en plus de la teinte.
Les polices
Les polices doivent être simples et lisibles. Il faut éviter les polices trop fantaisistes qui peuvent rendre le texte difficile à lire ou à comprendre.
Il faut également respecter les règles typographiques : par exemple, utiliser des majuscules pour les titres, des minuscules pour le texte courant, des italiques pour les citations, etc. Les polices doivent être exprimées en nom (Arial, Times New Roman, etc.) et en taille en points (pt).
Accessibilité
Les tailles des contrôles doivent être adaptées à la taille de l’écran et au type d’appareil utilisé. Il faut éviter les contrôles trop grands ou trop petits qui peuvent gêner la navigation ou la saisie.
Il faut également respecter les normes d’accessibilité. Par exemple, utiliser des boutons suffisamment larges pour être cliquables facilement avec un doigt sur un écran tactile, utiliser des contrastes suffisants entre le texte et le fond, etc.
Les tailles des contrôles doivent être exprimées en pixels (px).
Toutes ces valeurs de base doivent être stockées dans des variables globales qui seront utilisées dans les propriétés des contrôles. Cela permet de centraliser et de modifier facilement ces valeurs si besoin.
Par exemple, on peut créer une variable globale glbThemeColor qui contient le code RGBA de la couleur principale de l’application, et l’utiliser dans la propriété Fill des boutons ou des étiquettes.
Retour d’expériences (REX) Power Apps : Définir un plan de nommage
Le plan de nommage est la règle qui permet de nommer les contrôles, les variables et les collections de manière cohérente et explicite.
Il est essentiel d’adopter un plan de nommage dès le début du développement pour faciliter la compréhension, la maintenance et l’évolution du code.
Il n’y a pas de plan de nommage universel, mais il existe des recommandations et des exemples qui peuvent servir de base.
Le plan de nommage doit être simple, clair et logique
En effet, il doit permettre d’identifier facilement le type, la fonction et la portée du contrôle, de la variable ou de la collection.
Le plan de nommage doit éviter les abréviations ou les acronymes obscurs qui peuvent prêter à confusion ou à erreur.
Il doit respecter les conventions syntaxiques : par exemple, utiliser le préfixe « btn » pour les boutons, le suffixe « OnSelect » pour les actions au clic, etc.
Le plan de nommage doit être cohérent et uniforme
En effet, il doit utiliser la même règle pour tous les éléments du même type ou de la même catégorie.
Le plan de nommage doit éviter les variations ou les exceptions qui peuvent créer des incohérences ou des anomalies.
Il doit respecter les conventions sémantiques : par exemple, utiliser le singulier pour les variables et le pluriel pour les collections, utiliser le camel case pour les noms composés, etc.
Le plan de nommage doit être explicite et informatif
En effet, il doit permettre de comprendre le rôle et le contenu du contrôle, de la variable ou de la collection sans avoir besoin de consulter le code ou la documentation.
Le plan de nommage doit éviter les noms trop génériques ou trop ambigus qui peuvent induire en erreur ou en doute.
Il doit respecter les conventions lexicales : par exemple, utiliser des noms significatifs et descriptifs, utiliser des termes métiers ou techniques appropriés, etc.
Un exemple de plan de nommage basé sur les recommandations de Microsoft est le suivant :
- Bouton (button) : btn
- Etiquette (label) : lbl
- Entrée de texte (text input) : txt
- Collection (collection) : col
- Galerie (gallery) : gal
- Zone de liste déroulante (combo box) : cmb
- Forme (rectangle, cercle, …) : shp
Par exemple, on peut nommer un bouton qui permet d’ajouter un élément à une collection « btnAddToColItems », une étiquette qui affiche le nom d’un produit « lblProductName », une entrée de texte qui permet de saisir un commentaire « txtComment », etc.
Retour d’expériences (REX) Power Apps : Conclusion
Nous avons vu dans cet article quelques conseils pratiques pour développer avec Power Apps. Ces conseils sont issus de notre expérience personnelle et ne sont pas forcément exhaustifs ni universels. Ils ont pour but de vous aider à optimiser votre temps et votre qualité de développement.
Nous espérons qu’ils vous seront utiles. Nous vous invitons à nous faire part de vos propres retours d’expériences sur Power Apps.
En complément, lisez aussi En cas de problèmes avec PowerApps.
Laisser un commentaire