Dégradation harmonieuse d'interfaces utilisateur - UsiXML

A chaque phase du traitement, on vérifie que la nouvelle présentation candidate à une taille
qui satisfait à la résolution souhaitée. Si c’est le cas, on choisit cette dernière (on prend
toujours celle en cours et pas une des suivantes car c’est celle-ci qui nécessite le moins de
réorganisation). Sinon, on compare la différence de taille obtenue entre la fenêtre candidate et
la fenêtre de résolution souhaitée et celle pour la fenêtre précédente. En effet, si la différence
diminue, on prendra la nouvelle présentation et on gardera l’ancienne dans le cas contraire.
Cette technique, bien qu’originale, pose parfois quelques problèmes. Le premier repose sur la
vitesse d’exécution. En effet, si le nombre de niveaux et de tâches par niveaux de l’arbre
augmentent, le temps de calcul augmentera également car nous devons envisager tous les cas
possibles.
Une solution serait peut-être de transformer ce problème de sélection en problème
d’optimisation. Nous utiliserions alors une heuristique qui suggérerait à quel moment on
arrête le choix.
Le deuxième problème réside dans le fonctionnement de la technique. En effet, si deux
groupes de tâches feuilles indépendants se situent à un même niveau dans la hiérarchie de
tâches, toutes deux seront réorganisées, ce qui n’est pas toujours souhaitable. De plus, elles
partageront le même nombre de colonnes. Ainsi, même si le comportement général reste
acceptable, certains résultats ne sont pas du tout optimaux.
Aussi, une solution encore plus complète serait de réaliser un mélange entre la première
solution proposée et l’algorithme de Wong [Wong 2002]. En effet, l’algorithme de Wong ne
réorganise les tâches que lorsque la largeur du groupe de tâches est supérieure à celle de la
résolution choisie. Aussi, dans notre cas, ceci serait totalement inutile car notre méthode de
génération automatique d’interfaces semi-concrètes se base sur l’usage d’une seule colonne
par défaut.
Alors, plutôt que de calculer la meilleure combinaison possible dès le départ, nous pourrions
également partir du facteur de coût des tâches pour savoir quel groupe (niveau) réorganiser en
premier (ceci en additionnant les différentes valeurs obtenues). Et ensuite, nous nous
chargerions de continuer la transformation jusqu’à ce que la taille de la présentation soit la
plus proche de celle souhaitée.
Le module Widget Resizing Helper
Ce module a pour but de déterminer une liste de tâche pour lesquelles les OIAs seront
redimensionnés pour atteindre les objectifs de résolution d’écran attendus. Cette
détermination passe par plusieures étapes.
La première consiste à déterminer quels sont les OIAs qui sont redimensionnables et donc,
quelles tâches seront à traiter par la suite. Remarquons que nous n’avons pas admis la
possibilité de redimensionnement pour le widget Canvas car si celui-ci doit afficher des
éléments graphiques, ceux-ci ne seront pas redimensionnés (à moins que la fonction
sémantique d’affichage ne prenne en compte la résolution de l’écran, cas extrême que nous
avons décidé d’ignorer). La deuxième consiste à créer la présentation complète et déterminer
la taille des différents widgets qui la composent. De manière parallèle, nous construisons une
liste de tâches organisées, de manière décroissante cette fois, en fonction de leur importance
relative et récupérons les tailles admissibles pour les widgets de la présentation.
91