Actualités

3 bonnes pratiques d'IHM dans Panorama

, Paul de Poix

Trois choix de conception qui séparent une IHM moderne d’une IHM figée dans les années 90, sans plug-in ni ligne de code

Une IHM de supervision se juge sur la durée : ce qui compte n’est pas seulement son rendu le jour de la recette, mais ce qu’il en coûte de la faire évoluer pendant dix ans. Voici trois choix de conception qui séparent une IHM moderne d’une IHM figée dans les années 90, sans plug-in, sans une ligne de code. Leur point commun : ils sont déclaratifs, donc relisibles, modifiables et réutilisables d’un projet à l’autre.

1. Un menu latéral dynamique, pas un mur de boutons

Années 90 : des boutons codés en dur dans une seule vue. Le choix Avalon : un assemblage de vues dynamiques, formant un menu adaptable, chaque entrée du menu est une vue incrustée qui vit dans son propre dossier métier.

En pratique dans Panorama : pour ajouter un métier, on duplique le dossier, on renomme sa ligne de menu, et on l’incruste par glissé-déposé dans la vue menu centrale. Au clic, une commande « Envoie une valeur » écrit le chemin de la vue dans la propriété Reference View Name de la zone d’incrustation. La vue affichée change sans avoir à modifier la vue cible, grâce à un chemin relatif.

Pattern 1, le menu latéral dynamique : chaque entrée est une vue incrustée dans son dossier métier, ajoutée par duplication et glissé-déposé

Le gain se mesure à la première évolution : le menu se construit par catégorie métier, en lignes copiables, ajouter un équipement ou une zone prend quelques minutes, sans rouvrir le reste de l’application.

2. Des boutons réactifs comme du web

Années 90 : des boutons figés, aucun retour au survol. Le choix Avalon : animations au survol + ombre portée, tout natif, au survol, trois animations se déclenchent ensemble, toutes déclarées dans le synoptique.

En pratique dans Panorama : le bouton est un groupe Rectangle + Texte (pas le bouton natif). Une commande « Tant que dans le symbole » maintient la connexion Survol à 1 sous le curseur. Remplissage, opacité et contour se branchent dessus : 0 = repos, 1 = survolé. Et un rectangle en dégradé posé dessous simule une ombre portée, sans image.

Pattern 2, boutons réactifs : groupe Rectangle + Texte, connexion Survol pilotant remplissage, opacité et contour, aucun bitmap, que du vectoriel animé

Aucune image bitmap, que du vectoriel animé : le bouton reste net sur tous les écrans, et son comportement se lit directement dans sa définition.

3. Une palette pilotée par un thème centralisé

Années 90 : des couleurs en dur, une reprise de charte, c’est 50 vues à éditer. Le choix Avalon : un thème central, bascule clair/sombre instantanée, toute l’IHM tient sur une poignée de teintes décrites une seule fois, au même endroit.

En pratique dans Panorama : les teintes sont déclarées en couleurs nommées du thème graphique (TextColor, etc.). Chaque animation « Couleur sur 1 Tor » référence ces couleurs, pas un code RGB. Basculer le thème actif fait passer toute l’IHM en clair ou sombre, sans rouvrir une seule vue, le mode nuit pour la conduite en salle de contrôle devient clé en main.

Pattern 3, palette centralisée : couleurs nommées du thème graphique référencées par les animations, bascule clair/sombre en un changement

À retenir

Une IHM Panorama qui vieillit mal, c’est un choix de méthode, pas une limite de l’éditeur.

  • Le menu se construit par catégorie métier, en lignes copiables ;
  • Hover, opacité, ombre : tout est natif et déclaratif, zéro image ;
  • Charte centralisée par thème : mode clair / sombre clé en main.

C’est le niveau d’exigence que nous appliquons sur les applications que nous concevons ou reprenons, et que nous transmettons en formation aux équipes des intégrateurs.

Cet article prolonge un post publié sur LinkedIn, suivez-nous-y pour les prochains.

← Toutes les actualités