Guide editor : utiliser l’éditeur visuel d’application
Publié le · Mis à jour le
Le editor est l’espace de travail où vous examinez et modifiez une application après sa première création. Un bon éditeur visuel permet de comprendre ce qui est sélectionné, de maîtriser la mise en page, le contenu, les composants, l’affichage adaptatif et les actions liées aux données, puis de vérifier chaque changement avant publication.
Comprendre l’espace de travail avant de modifier
Commencez par identifier les différentes zones de l’éditeur : la page ou le canevas, la navigation entre les écrans, la hiérarchie des composants, le panneau de propriétés et les commandes de prévisualisation. Avant toute modification, vérifiez quelle page est ouverte et quel élément est réellement sélectionné.
Il faut également savoir si l’élément est local ou partagé. Modifier une instance de bouton sur une seule page n’a pas le même effet que modifier un composant réutilisé dans toute l’application. Un changement sur un conteneur parent peut aussi déplacer plusieurs éléments enfants. Comprendre cette hiérarchie évite les effets inattendus.
Prenez l’habitude de repérer le parent, les éléments voisins et les éventuelles autres occurrences d’un composant avant de le modifier. Cette méthode facilite ensuite le diagnostic, car vous saurez si un problème vient du composant, de la mise en page qui l’entoure ou d’un réglage propre à la page.
- Vérifiez la page active
- Distinguez composant local et partagé
- Repérez les relations parent-enfant
- Prévisualisez avant publication
Construire une mise en page claire et cohérente
Une modification visuelle doit servir un objectif. Déterminez ce que l’utilisateur doit voir en premier, quelle action est prioritaire et comment les informations doivent être parcourues. Les espacements servent à regrouper ou séparer les contenus ; ils ne sont pas seulement décoratifs.
Lorsque vous changez largeur, hauteur, marge, alignement ou grille, testez aussi du contenu plus long. Un titre court peut masquer un problème qui apparaîtra avec trois lignes de texte. Une hauteur fixe peut couper une traduction. Pour des données variables ou plusieurs langues, des règles de mise en page flexibles sont généralement plus robustes.
Gardez une cohérence entre les pages. Les boutons principaux, cartes, formulaires et titres similaires devraient conserver des principes visuels communs. Les composants réutilisables sont utiles pour cette cohérence, sans obliger chaque écran à avoir exactement la même structure.
- Donnez la priorité à l’action principale
- Utilisez l’espace pour structurer
- Testez du texte long
- Uniformisez les composants répétés
Modifier le contenu et choisir les bons composants
L’éditeur doit permettre de travailler sur le contenu réel. Relisez les titres, libellés, aides, états vides, confirmations et messages d’erreur. Chaque texte doit aider l’utilisateur à comprendre ce qui vient de se produire et ce qu’il peut faire ensuite.
Choisissez les composants selon la tâche. Un tableau convient à des données structurées à comparer. Des cartes facilitent souvent le parcours visuel. Une fenêtre modale fonctionne pour une décision courte, tandis qu’un processus important en plusieurs étapes est généralement plus clair sur un écran dédié.
Si Infera Agent est utilisé pour générer ou modifier une partie de l’interface à partir d’une demande en langage naturel, examinez ensuite le résultat dans l’éditeur. Vérifiez les données utilisées, l’apparence avec le reste de l’application et le comportement réel des actions.
- Réécrivez les libellés imprécis
- Choisissez le composant selon la tâche
- Vérifiez les données reliées
- Testez chaque interaction
Adapter l’interface au mobile et aux différents écrans
Une interface adaptative ne consiste pas à réduire mécaniquement la version ordinateur. Sur un écran étroit, deux colonnes peuvent devenir une seule colonne, une navigation horizontale peut se transformer en menu et un tableau peut nécessiter une présentation différente.
Recherchez les problèmes fréquents : boutons qui se chevauchent, texte coupé, champs trop étroits, éléments fixes qui couvrent le contenu et défilement horizontal involontaire. Vérifiez aussi la taille des zones tactiles et le comportement des formulaires lorsque le clavier mobile est ouvert.
Pour une application multilingue, testez la traduction avec les règles adaptatives. La longueur des mots change selon les langues, donc une interface correcte en français peut nécessiter davantage d’espace dans une autre langue. L’adaptation et la localisation doivent être testées ensemble.
- Testez plusieurs largeurs
- Adaptez les colonnes
- Contrôlez les zones tactiles
- Testez du contenu traduit
Relier les changements visuels aux données et à la logique
Un composant d’interface peut afficher une donnée, lancer une action, modifier un enregistrement ou appeler un service. Après un changement visuel, vérifiez toujours ce que le composant lit, ce qu’il écrit et ce qui doit se produire lorsque l’utilisateur agit.
Si vous modifiez un champ de formulaire, contrôlez la validation, la valeur initiale, le caractère obligatoire, le stockage et les automatisations qui dépendent de cette valeur. Pour un filtre, vérifiez le résultat de la requête. Pour une action déplacée dans un autre composant, retestez les permissions et les erreurs.
Pour chaque contrôle important, identifiez le déclencheur, les données utilisées et le résultat attendu en cas de réussite ou d’échec. Cette discipline évite qu’une interface visuellement correcte masque une erreur fonctionnelle.
- Contrôlez les lectures et écritures
- Retestez la validation
- Vérifiez les permissions
- Contrôlez succès et échec
Prévisualiser, tester et versionner avant de publier
Utilisez la prévisualisation pour parcourir l’application sans les outils d’édition. Testez la navigation, le défilement, les saisies, les validations, les états de chargement et les messages d’erreur. Si plusieurs rôles existent, testez les parcours avec leurs permissions respectives.
Avant une modification importante concernant un composant partagé, l’authentification, les données ou un flux principal, créez un point de restauration. Effectuez ensuite un changement cohérent à la fois afin d’identifier facilement la cause d’une éventuelle régression.
Après publication, contrôlez aussi la version réelle. Les données, le domaine, le cache, la configuration ou un service externe peuvent produire un comportement différent de la prévisualisation. La vérification en production est donc une étape finale du travail dans l’éditeur.
- Prévisualisez les parcours critiques
- Conservez un point de restauration
- Testez les rôles importants
- Contrôlez la version publiée
Questions
Qu’est-ce qu’un editor dans un constructeur d’application ?
C’est l’espace permettant d’examiner et de modifier pages, composants, contenu, styles, comportement adaptatif et souvent les actions ou données liées à l’interface.
Faut-il modifier directement un composant partagé ?
Seulement si vous souhaitez que la modification touche tous les écrans qui utilisent ce composant. Sinon, privilégiez une modification locale quand elle est disponible.
Que tester après une modification visuelle ?
Testez la mise en page, le mobile, la navigation, les interactions, les données, la validation, les permissions et les erreurs.
Pourquoi contrôler la version publiée ?
La production peut différer à cause des données réelles, du domaine, du cache, de la configuration ou des intégrations externes.