Interface d'un logiciel d'affichage de la météo

IFT2905

Interface personne machine

TP1

Interface d'un logiciel d'affichage de la météo

présenté à M. Sébastien Roy

par

Nicola Grenon [GREN30077303] (grenonni) et

Patrick Paul [PAUP30038301] (paulpatr)

le dimanche 18 février 2007

Introduction

Nous avions à définir puis implémenter trois interfaces utilisateurs pour traiter les informations disponibles au moyen du logiciel «meteo». Ces interfaces doivent être les plus pertinentes que possibles aux fins de l'utilisateur désigné, à savoir, respectivement, un enfant, un utilisateur pressé et un utilisateur professionnel. Afin de définir ces interfaces, il fallait également prévoir un traitement des données reçues en lot de même que prévoir un mécanisme de choix de ville.

Choix de ville

Dans le but de permettre une certaine uniformité au niveau des interfaces d'un même groupe de programme, de même que dans un esprit de réutilisation de code, nous avons décidé d'uniformiser l'interface primaire de choix de ville. On peut voir cette étape comme un mal nécessaire, à savoir que même pour un enfant dont les capacités de lecture sont limités, il faudra de toute façon faire un choix à ce niveau. Toutefois, il est important de comprendre que dans un cas de production, il serait aisé de limiter, par exemple pour l'interface enfant ou celle du client pressé, la perte de temps ou la complexité liée à cette étape en notant le choix effectué par l'utilisateur dans un fichier de configuration (par exemple) se souvenant du choix la fois suivante. Bien entendu, il faudrait alors ajouter un bouton offrant le choix de changer de ville. Pour des raisons pratiques (il nous semble peu probable que le ou les correcteurs testent nos programmes plus d'une fois chacun), cette option est laissée pour le moment de côté.

Gardons donc à l'esprit que, et dans le cas de l'enfant et dans celui du client pressé, seule la fenêtre «après le choix de ville» est réellement optimisée pour un usage quotidien. L'effet qu'aura dans les faits le correcteur est celui d'une première utilisation où il faudrait de toute façon faire un premier choix de ville.

En ce qui a trait à l'interface de choix de ville comme telle, elle est optimisée au sens qu'elle permet un choix dynamique de la ville. Afin de donner une liberté plus grande à l'usager, il a la possibilité de faire sa recherche au moyen de la liste triée alphabétiquement ou au moyen d'une entrée manuelle dans la case de recherche ou par un mélange des deux, ce qui offre une grande flexibilité. De plus, le bouton OK est un standard reconnu permettant de confirmer notre choix. Une touche de prévention est également incluse ici en le rendant inaccessible tant qu'il n'y a pas un choix valide à

son côté et la case d'entrée manuelle ne permet pas d'entrer des caractères invalides (ne se retrouvant pas dans la liste).

Interface «Enfant»

La visibilité est le premier point visé par cette interface en y utilisant des dessins idéographiques suffisamment grands pour attirer le regard, le tout dans une fenêtre très grande afin de centrer l'attention de l'utilisateur. Il y a de la correspondance naturelle qui est exploitée lorsque nous utilisons un fond bleu clair ou noir (étoilé) comme fond aux informations fournies pour une période donnée en cela que cela précise s'il s'agit du moment présent, de la nuit prochaine ou de demain. L'interface étant de format fixe (3 volets représentant maintenant, plus tard et demain) et limitant la quantité d'information disponible (4 types de données représentées uniquement) permet d'obtenir une plus grande clarté, une plus grande facilité d'assimilation des données rendues disponibles.

En diminuant la quantité d'interactions possibles avec l'utilisateur, nous évitons ici en bloc le problème de complexité, toutefois, nous avons ajouté à la flexibilité en permettant à l'utilisateur de cliquer sur un des dessins (action naturelle) pour en obtenir le détail si désiré. Cette fonction n'est pas visible à prime abord, mais elle s'adresse clairement à un utilisateur plus avancé. La rétroaction est ceci dit instantanée.

Interface «Client pressé»

Ici aussi la visibilité est le principal objectif recherché: les infos désirées par l'utilisateur sont au centre de la fenêtre, ce qui est un point de focus naturel. En ayant une interface minimaliste et petite, nous aidons à améliorer son utilisabilité, l'usager ayant le choix de conserver la fenêtre en avant de ses autres fenêtres de travail. Les seuls boutons entraînant une interaction sont ceux pour changer de moment, qui utilisent un mapping naturel en utilisant la métaphore reconnue de triangles noirs pour avancer ou reculer et leur position à gauche et à droite. Évidemment, pour en clarifier l'usage, ces boutons arborent également le moment vers lequel ils nous dirigeraient. Il est à noter ici que pour à nouveau augmenter l'utilisabilité, nous avons pris en compte le fait que l'utilisateur moyen pourrait se trouver dans la tranche d'âges utilisant les Celsius ou celle utilisant les fahrenheits. Un bouton exprimant clairement un «toggle»

d'une situation à l'autre permet d'effectuer cette opération en offrant une rétroaction

directe (en changeant les valeurs affichées sur le champ). De la flexibilité est également ajoutée en permettant à l'utilisateur, au moyen d'un bouton «long terme»/«court terme».

Interface «Pro»

La visibilité, dans le cadre de l'interface «Pro» est surtout présente dans le fait qu'on s'est assuré qu'un maximum d'information y était accessible en même temps, de façon concise. Bien sûr l'interface est chargée, mais l'accès en est rapide et naturel puisqu'il s'agit d'une suite d'éléments ordonnés dans le temps. Le côté pratique d'avoir toujours à l'œil au haut les informations du moment présent, la possibilité de faire rafraîchir les informations depuis la source ou de choisir une nouvelle source au moyen de deux boutons permet d'assurer la versatilité et la fonctionnalité de l'application.

Finalement, lorsqu'on se sert du bouton de choix d'une nouvelle ville, le fait que part défaut, dans la fenêtre de choix de ville, la ville où l'on se trouvait soit déjà sélectionnée permet d'augmenter la liberté de l'utilisateur permettant ainsi de changer d'avis (reprendre la même ville aisément) ou de choisir une ville proche (au sens que les noms similaires désignent souvent des villes proches) en ne modifiant que partiellement le nom affiché.

Conclusion

Bien que nous ayons tenté au d'adhérer au mieux aux concepts de réalisation d'une bonne interface tels que définis par Donald A. Norman et Jakob Nielsen, force est de constater que le fait que nous n'avions pas une connaissance approfondie du langage à utiliser nous a amenés à tricher quelque peu sur les étapes d'élaboration de nos modèles. Ainsi, par exemple, étant limités quant à l'utilisation de canevas, il nous a été impossible d'utiliser, pour l'interface «Pro», le modèle que nous avions d'abord élaboré dans notre prototype papier. Nous avons donc dû revoir la conception de l'interface «à la baisse», c'est-à-dire en sacrifiant (un peu) la valeur de certains attributs, à savoir la clarté et la constance, ne pouvant utiliser de menu déroulant facilement pour afficher les jours à venir.

Ceci dit, il appert que c'est là un détail puisque le concept grossier de l'interface est tout de même clairement défini et que dans une implantation réelle (langage compilé plus performant) nous ne serions pas confrontés à ces limitations. D'où le fait qu'on ne parle réellement ici que d'un prototype de programme.