Dégradation élégante dinterfaces- utilisateur. Description du problème Construction dinterfaces-utilisateur pour: des systèmes dinformation multiplate-formes.

Présentation au sujet: "Dégradation élégante dinterfaces- utilisateur. Description du problème Construction dinterfaces-utilisateur pour: des systèmes dinformation multiplate-formes."— Transcription de la présentation:

1 Dégradation élégante dinterfaces- utilisateur

2 Description du problème Construction dinterfaces-utilisateur pour: des systèmes dinformation multiplate-formes = systèmes disponibles sur différentes plate-formes (matériel + logiciel) à la fois lorsque les plate-formes supportées possèdent des capacités très différentes

3 Description du problème (2) Diversité des plate-formes en terme de capacités: taille de lécran qualité de lécran (résolution, nombre de couleurs, …) dispositifs dentrée (clavier, écran tactile, stylet, …) boîte(s) à outils graphique(s) disponible(s) langage(s) de programmation / de scripting disponible(s) …

4 Description du problème (3) 240 pixels 320 pixels 257 pixels 229 pixels 240 pixels 320 pixels 257 pixels 229 pixels ?

5 Plan de lexposé 1.Description des approches existantes pour les interfaces- utilisateur multiplate-formes 2.Description de lapproche par dégradation élégante 3.Etude exploratoire des règles de transformation pour la dégradation élégante 3.1 niveau tâches et concepts 3.2 niveau interface abstraite 3.3 niveau interface concrète 3.4 niveau interface finale 4.Conclusion / travaux futurs

6 Approches existantes 1)Développement dune interface spécifique pour chaque plate- forme 2)Développement dune IU portable unique au moyen dune boîte à outils graphiques virtuelle 3)Utilisation de clients génériques (navigateurs) 4)Développement dune description unique pour la partie commune et de descriptions supplémentaires pour les parties de lIU spécifiques à la plate-forme (approches basées sur XML) 5)Les approches basées modèle

7 1ère approche: Développement spécifique Avantages: Contrôle maximal pour le concepteur / programmeur IU parfaitement adaptée à la plate-forme Limitations: Requiert des capacités de programmation dans plusieurs langages / une connaissance de plusieurs boîtes à outils graphiques Temps de conception /développement / maintenance de plusieurs versions Cohérence entre versions (temps dapprentissage)

8 1ère approche: Développement spécifique exemple

9 2ème approche: Boîtes à outils graphiques virtuelles Description: Utilisation dobjets virtuels liés aux objets natifs de chaque boîte à outils (ou émulation de ces objets) le même code tourne sur différentes plate-formes. Ex: Java AWT, Java Swing, Tk Avantages: Une seule interface à concevoir et à programmer Contrôle maximal pour le concepteur / le programmeur Limitations: Adaptation minimale à la plate-forme (portabilité, parfois « look-and-feel ») Convient surtout pour systèmes sur ordinateur traditionnel

10 2ème approche: Boîtes à outils graphiques virtuelles: exemple Windows UI code Platform 1: Personal Computer Platform 2: Macintosh Mac OS Macintosh UI code Platform 3: Workstation OSF/Motif OSF/Motif UI code

11 3ème approche: Utilisation de clients génériques Description: Spécification de lIU au moyen dun langage à balises (HTML, WML, etc.). Ce code est interprété par un programme client, le navigateur, disponible sur de nombreuses plate-formes. Avantages: Une seule interface à concevoir et à programmer Contrôle important pour le concepteur / le programmeur Limitation: Adaptation limitée, malgré quelques outils de transcodage (HTML WML) et quelques outils adaptatifs

12 3ème approche: Utilisation de clients génériques (exemple)

13 4ème approche: Approches basées sur XML Description: Spécification de la structure / du contenu du document de base dans un document XML + description de la partie présentation dans une feuille de style CSS ou XSL ou transformations XSLT vers XHTML ou WML. Avantages: Cohérence au niveau du contenu (mais pas au niveau de lapparence) Contrôle important pour le concepteur / le programmeur IU adaptée à la plate-forme Limitation: Requiert le développement dune feuille de style / dun document XSLT par plate-forme

14 5ème approche: Approches basées modèles Description: Spécification de lIU à un niveau dabstraction plus ou moins élevé, indépendant de limplémentation Spécification souvent partagée entre plusieurs composants, appelés modèles, chaque modèle représentant une facette particulière de lIU. Différents types dapproches basées modèles répondent au problème du multiplate-forme: 1. génération multiplate-forme 2. langages de spécification multiplate-forme 3. approches par rétro-ingénierie

15 Approches basées modèles (suite) Génération multiplate-forme (description): Génération dIUs spécifiques aux différentes plate-formes à partir de spécifications exprimées à un niveau dabstraction élevé (typiquement: tâches et domaine) Ex: TERESA, ArtStudio Avantages: Spécification unique de lIU génération de multiples versions Pas de programmation IU adaptées à leur plate-forme (dépend des heuristiques de loutil) Limitations: Très peu de contrôle humain sur le processus Produit seulement des IUs très simples

16 Approches basées modèles (suite) Langages de spécification multiplate-forme (description): Spécification de lIU au moyen dun langage générique et de vocabulaires spécifiques pour chaque famille de plate- formes. La spécification est alors compilée ou interprétée pour être rendue dans différents langages. Ex: UIML Avantages: Bon niveau de contrôle pour le concepteur (interface spécifiée à un niveau plus concret que dans lapproche précédente) Pas de programmation Limitation: N spécifications pour N familles de plate-formes

17 Approches basées modèles (suite)

18 Approches par rétro-ingénierie (description): Rétro-ingénierie dIUs existantes, non conçues dans une approche basée modèles, afin den extraire une spécification. Cette spécification peut alors servir de base à la génération de versions de lIU pour dautres plate-formes Ex: Vaquita Avantages: Tire parti des interfaces pré-existantes Permet certaines adaptations (dépend des heuristiques de loutil) Limitations: Contrôle du concepteur limité (choix de certaines options)

19 Plan de lexposé 1.Description des approches existantes pour les interfaces- utilisateur multiplate-formes 2.Description de lapproche par dégradation élégante 3.Etude exploratoire des règles de transformation pour la dégradation élégante 3.1 niveau tâches et concepts 3.2 niveau interface abstraite 3.3 niveau interface concrète 3.4 niveau interface finale 4.Conclusion / travaux futurs

20 Approche par dégradation élégante Approche basée modèle Spécificité par rapport aux autres approches: Génération multiplate-forme Spécification multiplate-forme Rétro-ingénierieDégradation élégante 1 spec. abstraite N codes N spec. plus concrètes N codes1 code 1 spec. N codes 1 spec. N spec. adaptées

21 Approche par dégradation élégante = approche transformationnelle Interface source Cible ? design pré- existant plate-forme plus contrainte Règles de transformation

22 Approche par dégradation élégante transformation dinterfaces-utilisateur conçues pour une plate-forme moins contrainte vers des interfaces plus contraintes dégradation souci de minimiser lécart entre les versions du système + souci dutilisabilité des IU cibles dégradation élégante

23 Approche par dégradation élégante Intérêt: Compromis entre exigences dadaptation à la plate- forme / de contrôle humain / de cohérence entre versions / de limitation des efforts en termes de conception et programmation Peut être couplée avec une approche par rétro-ingénierie (récupération des spécifications dune IU existante et application des règles de transformation) et/ou une approche générative (interprétation des spécifications produites par lapplication des transformations)

24 Plan de lexposé 1.Description des approches existantes pour les interfaces- utilisateur multiplate-formes 2.Description de lapproche par dégradation élégante 3.Etude exploratoire des règles de transformation pour la dégradation élégante 3.1 niveau tâches et concepts 3.2 niveau interface abstraite 3.3 niveau interface concrète 3.4 niveau interface finale 4.Conclusion / travaux futurs

25 Règles de dégradation élégante: étude exploratoire Les règles de dégradation élégante ont été identifiées à partir de lexamen dun grand nombre de petites applications disponibles sur plusieurs plate-formes testées « à la main » sur le système ARTHUR (système dinformation pour les services durgences dhôpitaux belges avec version PC, PDA et écran mural)

26 Typologie des règles de dégradation élégante Les règles de dégradation élégante ont été classifiées un cadre de référence en 4 niveaux

27 Règles de dégradation élégante Niveau tâches et concepts Modèle de la tâche Modèle du domaine

28 Modèle de la tâche: définition description des tâches que lutilisateur pourra effectuer en interaction avec le système hiérarchie contraintes temporelles entre tâches

29 Modèle de la tâche: exemple

30 Exemple de règle de transformation (1)

31 Exemple de règle de transformation (2) >>

32 Modèle du domaine: définition Description des objets du domaine et de leurs relations (diagramme de classes UML, diagramme entité- association, etc.) Limitation aux objets ayant un impact sur lIU (objets dont linformation sera affichée ou modifiée par lutilisateur, ou objets dont les méthodes seront appelées de lIU, ou qui peuvent modifier lIU)

33 Modèle du domaine: exemple

34 Exemple de règle de transformation (1)

35 Exemple de règle de transformation (2)

36 Règles de dégradation élégante Niveau abstrait Description de lIU en termes d Unités de présentation (UPs) = liste de tâches même conteneur (fenêtre, panneau, carte,…)

37 Unités de présentation: exemple

38 Exemple de règle de transformation (scission)

39 Règles de scission Applicables automatiquement A partir: 1. dun modèle des tâches CTT 2. dune UP conçue pour la plate-forme source déduction dUPs correctes pour la plate-forme cible

40 Règles de dégradation élégante Niveau interface concrète Description de lIU en termes de objets graphiques ou interacteurs relations entre objets graphiques

41 Interface concrète: exemple -------------------------------------------------------------------------- f1 contient l1, e1, … l1 à la gauche de e1 l1, l2 alignés à droite …

42 Règles de transformation: exemples (1)

43 Règles de transformation: exemples (2)

44 Règles de transformation: exemples (3)

45 Règles de transformation: exemples (4)

46 Règles de dégradation élégante Niveau interface finale Code source

47 Règles de dégradation élégante Niveau interface finale Ex. substitution dune image par une image dans un format comprimé, réduction du nombre de couleurs, réduction des tailles de police,... à ce niveau, les règles ne bénéficient pas dune approche orientée modèle

48 Plan de lexposé 1.Description des approches existantes pour les interfaces- utilisateur multiplate-formes 2.Description de lapproche par dégradation élégante 3.Etude exploratoire des règles de transformation pour la dégradation élégante 3.1 niveau tâches et concepts 3.2 niveau interface abstraite 3.3 niveau interface concrète 3.4 niveau interface finale 4.Conclusion / travaux futurs

49 Conclusion Résultats actuels: Un cadre conceptuel pour la dégradation élégante Une collection de règles de transformation Une formalisation de certaines de ces règles

50 Travail futur 2 directions: Travail dévaluation: études dutilisabilité Application assistée de certaines règles dans un outil daide à la conception multiplate-forme

51 Travail futur : évaluation But des études dutilisabilité: évaluation de la qualité des interfaces produites avec la méthode (manuellement / automatiquement) évaluation de la qualité de loutil

52 Travail futur : loutil Construction dun outil de support à la conception dinterfaces multiplate-formes Outil basé sur une approche orientée modèle Propose au concepteur lapplication de règles de dégradation élégante sur une interface préexistante / sur une interface nouvellement créée avec le système