dégradation élégante dinterfaces- utilisateur. description du problème construction...

Dégradation élégante d’interfaces-utilisateur

Description du problème

Construction d’interfaces-utilisateur pour:

• des systèmes d’information 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

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 d’entrée (clavier, écran tactile, stylet, …)

• boîte(s) à outils graphique(s) disponible(s)

• langage(s) de programmation / de scripting disponible(s)

• …

Description du problème (3)

240 pixels

320 pixels 257 pixels

229 pixels

240 pixels

320 pixels 257 pixels

229 pixels

?

Plan de l’exposé

1. Description des approches existantes pour les interfaces-utilisateur multiplate-formes

2. Description de l’approche 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

Approches existantes

1) Développement d’une interface spécifique pour chaque plate-forme

2) Développement d’une IU portable unique au moyen d’une boîte à outils graphiques virtuelle

3) Utilisation de clients génériques (navigateurs)

4) Développement d’une description unique pour la partie commune et de descriptions supplémentaires pour les parties de l’IU spécifiques à la plate-forme (approches basées sur XML)

5) Les approches basées modèle

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 d’apprentissage)

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

2ème approche:Boîtes à outils graphiques virtuelles

Description:• Utilisation d’objets 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 programmeurLimitations:• Adaptation minimale à la plate-forme (portabilité, parfois

« look-and-feel »)• Convient surtout pour systèmes sur ordinateur traditionnel

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

3ème approche: Utilisation de clients génériques

Description:

• Spécification de l’IU au moyen d’un 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

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

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

l’apparence)• Contrôle important pour le concepteur / le programmeur• IU adaptée à la plate-formeLimitation:• Requiert le développement d’une feuille de style / d’un

document XSLT par plate-forme

5ème approche: Approches basées modèles

Description:• Spécification de l’IU à un niveau d’abstraction plus ou moins

élevé, indépendant de l’implémentation• Spécification souvent partagée entre plusieurs composants,

appelés modèles, chaque modèle représentant une facette particulière de l’IU.

• Différents types d’approches basées modèles répondent au problème du multiplate-forme:1. génération multiplate-forme2. langages de spécification multiplate-forme3. approches par rétro-ingénierie

Approches basées modèles (suite)

Génération multiplate-forme (description): • Génération d’IUs spécifiques aux différentes plate-formes à

partir de spécifications exprimées à un niveau d’abstraction élevé (typiquement: tâches et domaine)

• Ex: TERESA, ArtStudioAvantages:• Spécification unique de l’IU génération de multiples

versions• Pas de programmation• IU adaptées à leur plate-forme (dépend des heuristiques de

l’outil)Limitations:• Très peu de contrôle humain sur le processus• Produit seulement des IUs très simples


Langages de spécification multiplate-forme (description): • Spécification de l’IU au moyen d’un 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: UIMLAvantages:• Bon niveau de contrôle pour le concepteur (interface

spécifiée à un niveau plus concret que dans l’approche précédente)

• Pas de programmationLimitation:• N spécifications pour N familles de plate-formes


Approches par rétro-ingénierie (description): • Rétro-ingénierie d’IUs existantes, non conçues dans une

approche basée modèles, afin d’en extraire une spécification. Cette spécification peut alors servir de base à la génération de versions de l’IU pour d’autres plate-formes

• Ex: VaquitaAvantages:• Tire parti des interfaces pré-existantes• Permet certaines adaptations (dépend des heuristiques de

l’outil)Limitations:• Contrôle du concepteur limité (choix de certaines options)

Plan de l’exposé









Approche par dégradation élégante

• Approche basée modèle

• Spécificité par rapport aux autres approches:

Générationmultiplate-forme

Spécificationmultiplate-forme

Rétro-ingénierie Dégradation élégante

1 spec. abstraite

N codes

N spec. plus concrètes

N codes 1 code

1 spec.

N codes

1 spec. N spec. adaptées

Approche par dégradation élégante = approche transformationnelle

Interface source

Cible

?

design pré-existant

plate-forme plus contrainte

Règles de transformation


• transformation d’interfaces-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 d’utilisabilité des IU cibles

dégradation élégante


Intérêt:• Compromis entre exigences d’adaptation à 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 d’une IU existante et application des règles de transformation) et/ou une approche générative (interprétation des spécifications produites par l’application des transformations)

Plan de l’exposé









Règles de dégradation élégante: étude exploratoire

Les règles de dégradation élégante ont été

• identifiées à partir de l’examen d’un grand nombre de petites applications disponibles sur plusieurs plate-formes

• testées « à la main » sur le système ARTHUR (système d’information pour les services d’urgences d’hôpitaux belges avec version PC, PDA et écran mural)

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

Règles de dégradation élégante Niveau tâches et concepts

Modèle de la tâche

Modèle du domaine

Modèle de la tâche: définition

• description des tâches que l’utilisateur pourra effectuer en interaction avec le système

• hiérarchie

• contraintes temporelles entre tâches

Modèle de la tâche: exemple

Exemple de règle de transformation (1)


>>>> >>

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 l’IU (objets dont l’information sera affichée ou modifiée par l’utilisateur, ou objets dont les méthodes seront appelées

de l’IU, ou qui peuvent modifier l’IU)

Modèle du domaine: exemple

Règles de dégradation élégante Niveau abstrait

Description de l’IU en termes d’ Unités de présentation (UPs)

= liste de tâches même conteneur (fenêtre, panneau, carte,…)

Unités de présentation: exemple

Exemple de règle de transformation (scission)

Règles de scission

• Applicables automatiquement

• A partir:

1. d’un modèle des tâches CTT

2. d’une UP conçue pour la plate-forme source

déduction d’UPs correctes pour la plate-forme cible

Règles de dégradation élégante Niveau interface concrète

Description de l’IU en termes de • objets graphiques ou interacteurs• relations entre objets graphiques

Interface concrète: exemple

<fenêtre f1><libellé l1 texte=titre ><boîte d’édition e1 longueur = 30><libellé l2 texte = éditeur>--------------------------------------------------------------------------f1 contient l1, e1, …l1 à la gauche de e1l1, l2 alignés à droite…

Règles de transformation: exemples (1)


Add all >>

Add >

<< Remove all

< Remove

>>

>

<<

<

>

<

Item 1Item 2Item 3Item 4Item 5Item 6Item 7

Item 1

Group box

Item 1Item 2Item 3Item 4

Item 5Item 6Item 7Item 8

Item 1

Item 2

Item 3

Item 4

Item 5

Item 6

Item 7

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

Code source

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

Ex. substitution d’une 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 d’une approche orientée modèle

Plan de l’exposé









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

Travail futur

2 directions:

• Travail d’évaluation: études d’utilisabilité

• Application assistée de certaines règles dans un outil d’aide à la conception multiplate-forme

Travail futur : évaluation

But des études d’utilisabilité:

• évaluation de la qualité des interfaces produites avec la méthode (manuellement / automatiquement)

• évaluation de la qualité de l’outil

Travail futur : l’outil

• Construction d’un outil de support à la conception d’interfaces multiplate-formes

• Outil basé sur une approche orientée modèle

• Propose au concepteur l’application de règles de dégradation élégante sur une interface préexistante / sur une interface nouvellement créée avec le système

dégradation élégante dinterfaces- utilisateur. description du problème construction...

Documents