Projections de vues et UXfc

Statut documentaire : guide — voir Maturité et preuves.

Une vue logiCells est une projection d’un concept, d’une classe, d’un objet, d’une relation, d’un processus ou d’un service dans un contexte d’interaction donné. Elle ne possède pas le modèle de domaine et n’est pas définie par une boîte à outils graphique particulière.

Concevoir une vue dans cet ordre

1. Identifier la cible conceptuelle projetée.
2. Identifier l’intention utilisateur : exploration, sélection, consultation, édition, validation, navigation, comparaison, séquencement ou autre objectif d’interaction stable.
3. Choisir les composants fonctionnels nécessaires à cette intention.
4. Déclarer les surfaces de données de page et les contrats d’événements.
5. Lier les composants fonctionnels à ces surfaces.
6. Sélectionner ou enregistrer l’implémentation concrète pour la plateforme cible.
7. Garder apparence, styles et layout exact hors du contrat fonctionnel réutilisable.

Vues de classe et vues d’objet

Une vue de classe reçoit normalement un contexte de concept et convient à la navigation, recherche, sélection, création ou listes d’instances. Une vue d’objet reçoit un contexte d’instance et convient aux détails, édition, validation, étapes de workflow ou dashboards propres à un objet.

Composants fonctionnels et intentionnels

Un composant fonctionnel exprime la fonction d’interaction requise : champ, liste, vue tabulaire, vue scindée, vue à onglets, statut, consultation, sélection, panneau d’actions ou région réactive. Un composant UXfc intentionnel exprime pourquoi l’interaction existe : explorer, sélectionner, consulter, éditer, valider, naviguer, comparer ou séquencer.

Le contrat réutilisable est donc :

activité utilisateur
 -> intention d’interaction
 -> contraintes fonctionnelles
 -> composant UXfc/fonctionnel
 -> implémentation concrète enregistrée
 -> interface rendue

Paramètres non visuels

Préférer les paramètres fonctionnels : nom de DataSource, identifiant sélectionné, curseur courant, mode de navigation, politique d’historique, prérequis de validation, cardinalité de sélection et contrats d’événements. Éviter d’intégrer au modèle conceptuel les couleurs, noms de classes propres à un toolkit, pixels ou détails d’implémentation.

Événements

Les événements doivent décrire leur sens plutôt que l’implémentation. SelectionChanged, ResourceLoaded, ValidationRequested, Reload ou Browse sont de meilleurs contrats réutilisables que des événements nommés d’après un contrôle ou une instance particulière.