Diplôme Interuniversitaire d’Etudes Approfondies en Informatique

Espace de classification des méthodes etoutils d’évaluation de l’ergonomie des

systèmes à technologie WebCéline Mariage

Septembre 2001

2

3

Table des matières

1 INTRODUCTION ............................................................................................................................... 4

2 EVALUATION DE L’ERGONOMIE DES SYSTÈMES À TECHNOLOGIE WEB ................... 5

2.1 L’ÉVALUATION DANS LE PROCESSUS DE DÉVELOPPEMENT................................................................. 52.2 PRINCIPE DE L’ÉVALUATION .............................................................................................................. 62.3 L’ÉVALUATION DE L’ERGONOMIE ...................................................................................................... 7

3 MÉTHODES D’ÉVALUATION DES SITES WEB......................................................................... 8

3.1 INTRODUCTION................................................................................................................................... 83.2 CLASSIFICATION DES MÉTHODES ADAPTÉE DE LA CLASSIFICATION DE SENACH................................. 8

3.2.1 Approche empirique ................................................................................................................103.2.2 Approche analytique................................................................................................................11

3.3 CLASSIFICATION METROWEB ...........................................................................................................123.3.1 Méthodologie de travail...........................................................................................................123.3.2 Etat de l’art des classifications existantes ...............................................................................123.3.3 Classification et profil des méthodes d’évaluation..................................................................29

4 MÉTHODOLOGIE DE TRAVAIL ..................................................................................................31

4.1 OBJECTIF DE LA RECHERCHE.............................................................................................................314.2 ETAPES DE LA RECHERCHE................................................................................................................31

4.2.1 Etablissement d’un cadre de classification des méthodes et outils..........................................324.2.2 Etat de l’art des méthodes et outils d’évaluation existants......................................................324.2.3 Compréhension de la démarche d’évaluation .........................................................................324.2.4 Analyse de l’activité méthodologique de l’évaluateur en situation d’évaluation ....................324.2.5 Proposition d’un outil de support à l’activité d’évaluation.....................................................32

4.3 CONTRIBUTION DU PROJET METROWEB À LA RECHERCHE................................................................324.3.1 Objectif du projet MetroWeb ...................................................................................................334.3.2 Lien entre le projet et la recherche..........................................................................................37

5 RÉFÉRENCES BIBLIOGRAPHIQUES..........................................................................................38

6 ANNEXE 1 SCHÉMA ENTITÉS-ASSOCIATIONS DE L’OUTIL METROWEB ETSPÉCIFICATIONS .....................................................................................................................................41

6.1 SCHÉMA ENTITÉS-ASSOCIATIONS ......................................................................................................416.2 SÉMANTIQUE DES OBJETS DU SCHÉMA ..............................................................................................43

4

3. Organisation et exploitation des connaissances propres à l'évaluation de l'ergonomie dessystèmes à technologie web

1. Elaboration d'une classification des méthodes

4. Support à l'évaluation

2. Etat de l'art des méthodes et outils d'évaluation des systèmes à technologie web

1 IntroductionLa croissance exponentielle des sites web au cours des dernières années a permis une diffusion etun échange informationnels importants. Cependant, les interfaces Web peu utilisables, à savoir ennon-adéquation avec le profil cognitif de l’utilisateur [Grudin91, Lowgren95], sont tropnombreuses et amènent souvent le visiteur au désintérêt, voire à l’abandon du site. En effet, le sitedoit d’une part répondre aux besoins informationnels du visiteur mais également être conçu pourque ce dernier accomplisse sa tâche interactive de manière efficace et exploite le site au mieux etsans trop de difficulté, en fonction de ses capacités cognitives. Pour aider le concepteur à créer des sites web utilisables ont été créés des méthodes et outilsd’évaluation de l’interface, web ou autre, dont la fonction est de découvrir les défauts del’interface, ainsi que ses qualités. Cette découverte s’effectue sur une interface réalisée ou encours de conception, en détection mais aussi en prévention. Cependant, l’utilisation de ces outils et méthodes ne s’impose pas d’emblée dans le cycle dedéveloppement de l’application. En effet, certaines méthodes sont incertaines, leur apport nonprouvé, d’autres incomplètes, n’évaluant qu’une partie des critères d’une interface utilisable. Lesconcepteurs désirent également très souvent un support informatique, ce que chaque méthode nefournit pas. Enfin, certaines méthodes sont méconnues voire inconnues et de ce fait exploitéesinsuffisamment par les concepteurs de sites [Metzker01]. La méconnaissance de ces méthodes eten particulier de leur apport au cours du développement de l’interface nous intéresseparticulièrement. Face à ce problème, une solution vers laquelle nous tendons est de procéder àl’organisation et l’exploitation des connaissances propres à l’évaluation de l’ergonomie dessystèmes à technologie web, et ce en vue de mettre en évidence l’apport positif des méthodesexistantes. Par systèmes à technologie web, nous entendons les sites Intranet, Extranet, Internetou autre.

La Fig1 présente les étapes proposées en vue d’atteindre cet objectif (3). Nous allons en premierlieu effectuer un recueil des connaissances relatives aux méthodes et outils d’évaluation desinterfaces web (2). Une structuration adéquate de ce recueil permettrait un meilleur support auxutilisateurs des méthodes. Il est en effet essentiel de relever pour chaque méthode à qui elles’adresse, quand et comment. Chaque type d’utilisateur a en effet ses propres objectifsd’évaluation et par-là même des activités d’évaluation différentes.

Fig1 Etapes vers l’organisation et l’exploitation des connaissances relatives aux outils et méthodes d’évaluation de sitesweb

5

En vue de recueillir de façon structurée les méthodes et outils d’évaluation de sites web, nousétablirons une classification adéquate (1), contenant des critères pertinents de classification.L’élaboration de cette classification est proposée dans ce travail. Ensuite, notre objectif est de fournir à l’évaluateur un support (4) à l’évaluation ergonomique dessites web, par l’exploitation des connaissances relatives à cette évaluation (3). Ces connaissancesont trait aux règles ergonomiques à respecter, aux types d’interface qu’elles couvrent, auxmodèles alimentant ces règles, aux objets de l’interface web pris en compte par ces règles, auxméthodes d’évaluation les vérifiant, etc.

2 Evaluation de l’ergonomie des systèmes à technologie Web

2.1 L’évaluation dans le processus de développementL’évaluation fait partie intégrante du processus de développement d’une application interactive.Elle peut intervenir à différentes étapes du développement. Nous nous basons sur le cycle dedéveloppement de [Scapin99] qui présente l’avantage d’être appliqué au développement d’un siteweb. Dans ce cycle de vie en O d’une interactive particulière, le site web (Fig2), six étapes sontproposées :

� Expressiondes besoins

� Implanta-tion du site

� Spécifica-tions du site

� Concep-tion du site

� Utilisation etévaluation du site

� Mainte-nance du site

Fig2 Cycle de vie d’un site Web

1. L’expression des besoins, où sont identifiés les objectifs généraux du site et le contexted’utilisation global de celui-ci.

2. La spécification du site, où sont décrites des spécifications plus détaillées à partir des besoinset du contexte observés en 1.

3. La conception du site, où le site est conçu en fonction des spécifications.4. L’implantation du site, où sont programmés les pages HTML, applets et autres langages, puis

installées physiquement.5. L’utilisation et l’évaluation du site, où le site est d’abord soumis à une utilisation réelle puis

où l’on s’assure de l’adaptation du site aux besoins exprimés dans 1.

6

6. La maintenance du site, où l’on prévoit les modifications potentielles du site en prenant encompte les résultats d’évaluation obtenus en 5.

Ce processus est itératif [Balbo95] car le cycle peut être parcouru de multiples fois, de etl’évaluation en elle-même peut intervenir à toutes les étapes mais reste spécialement dédiée àl’étape 5.L'évaluation de la qualité d'une application porte sur un choix de dimensions pertinentesd'analyse, qui sont fonction d'objectifs globaux de l'évaluation (définis en 1). Ces objectifsdétermineront la cible de l'évaluation, à savoir les coûts, la sécurité, la production, lamaintenance, ou encore l’ergonomie de l’application. Notre travail s'applique à l'étude de ce typed'évaluation, plus largement appelée évaluation de l'utilisabilité [Nielsen90]. L'évaluation del'utilisabilité est elle-même un processus à part entière [Ivory00] qui regroupe diverses activités,depuis la spécification des objectifs d'évaluation, jusqu'à la réparation des défauts de l'interface,en passant par l'application de la méthode choisie.

2.2 Principe de l’évaluationLe processus d'évaluation consiste à comparer un modèle de l’objet évalué à un modèle deréférence [Senach90]. Ce processus est représenté dans la Fig3.

L’évaluation porte sur un système, constitué d’un utilisateur et d’une application interactiveengagés dans une tâche au sein d’un certain environnement [Balbo94], concept que nousévoquerons par le contexte d’utilisation. C’est pourquoi une évaluation complète de l’interactionhomme-machine au sein d’un système vise l’utilisateur et la manière dont il agit ainsi quel’application et la manière dont elle fonctionne. Au départ de l’évaluation, un ou plusieurs objectifs sont formulés, sous forme de questionsrelatives à la qualité ergonomique de l'application. Ainsi, l'évaluateur se penche par exemple surla qualité de la navigation ou du temps de réponse du téléchargement d'images. Ces objectifsdéterminent un modèle du système à évaluer, sous forme de dimensions pertinentes d’analyse.Les dimensions choisies sont contraintes par les objectifs mais aussi par le contexte, à savoir lescaractéristiques de la population et les exigences des tâches [Senach90]. Le choix de cesdimensions détermine ce qui permettra de porter un jugement sur l'IHM concernée[Grislin96]. La limite de l’évaluation s’impose d’emblée par la notion de modèle d’objet évalué.En effet l'évaluation porte sur un modèle du système, et non sur le système lui-même. Le ou lesobjectifs de l’évaluation contraignent ce processus d’évaluation. Ainsi, le système entier ne serajamais évalué dans son entièreté, seuls certains aspects du système seront soumis à l’évaluation.Ainsi des objectifs tels qu’étudier la satisfaction de l’utilisateur, vérifier le code en fonction derègles ergonomiques établies ou s’assurer des temps de téléchargement des pages permettront demettre en évidence certains aspects du système, et non le système en entier. C’est pourquoi seul

Domaines de valeurs

Dimensions d'analyse

COMPARAISON

Fig3 : Schéma de principe de l’évaluation

Utilisateur et applicationinteractive MODELISATION

MODELE DU SYSTEMEA EVALUER

SYSTEME REELA EVALUER MODELE DE REFERENCE

Facteurs

Critères

7

un modèle ou une abstraction du système sera évalué. Ces dimensions d'analyse représentant lesobjectifs sont progressivement décomposées. Nous distinguons deux grands niveaux dedécomposition, introduits par [Balbo94], les facteurs et les critères. Un facteur définit unepropriété du logiciel susceptible d'être requise par un client [Balbo94]. Le critère est quant à luiun attribut qui affecte la satisfaction d'un ou plusieurs facteurs [Balbo94]. Intervient ensuite la définition des variables cibles de l'évaluation, ainsi que les techniques derecueil de ces variables. Les variables d’évaluation définies par [Nielsen93] s’expriment entermes d’acceptabilité du système (Fig4).

Fig4 Variables pour l’évaluation selon [Nielsen93]

La technique de recueil est choisie en fonction de sa capacité à évaluer les variables cibles. Cettetechnique appartient à une méthode d’évaluation de l’interface, qui influencera également lesautres étapes. Chaque technique présente un ensemble de métriques, définies par [Balbo94]comme des moyens de mesure des critères. Les résultats obtenus seront dès lors comparés au modèle de référence, constitué d’ensemblesacceptables de valeurs, définis en tant que domaines de valeurs [Balbo94].

2.3 L’évaluation de l’ergonomieUne interface homme-machine est évaluée en fonction de son utilité et de son utilisabilité.L’utilité détermine si le produit permet à l’utilisateur d’atteindre ses objectifs de travail[Senach90]. L’utilisabilité concerne quant à elle la qualité de l’interaction homme-machine, c’est-à-dire la facilité d’apprentissage et d’utilisation [Senach90]. L’utilisabilité est également définiedans [ISO92] comme « […] l’efficience, l’efficacité et la satisfaction avec laquelle desutilisateurs spécifiques atteignent des objectifs spécifiques dans une environnement particulier ». L’évaluation de l’ergonomie d’une application interactive tente de cerner l’utilisabilité de cetteapplication et se fonde sur le principe décrit à la section 2.2. Les facteurs et critères déterminantle modèle du système évalué auront dans cet objectif particulier d’évaluation trait à l’ergonomiedu système. Les notions de facteurs d’utilisabilité et de critères ergonomiques exploités dans[Farenc95] sont proches de ces concepts. En effet, l’utilisabilité est formulée en termes defacteurs d’utilisabilité liés à des critères ergonomiques. Le respect d’une règle ergonomiqueinfluence la réalisation d’un critère ergonomique, celui-ci influençant le respect d’un facteurd’utilisabilité.

Ainsi, l’évaluation de l’ergonomie d’une application s’élabore en plusieurs étapes :� définition des objectifs de l’évaluation� choix les facteurs et critères permettant de mesurer les objectifs� définition des variables cibles � choix des techniques de recueil en vue d’étudier les variables (grâce à des métriques)� comparaison des résultats avec un modèle de référence

8

Les méthodes existantes d’évaluation des interfaces web constituent les techniques de recueil del’évaluation de l’ergonomie de ce type d’interface. Nous nous penchons sur ces méthodes dans lasection 3.

3 Méthodes d’évaluation des sites Web

3.1 IntroductionAfin de procéder à un recueil systématique des méthodes d’évaluation existantes des interfacesweb, il nous a semblé essentiel d’adopter une classification adéquate. Pour ce faire, nous avonsparcouru les classifications existantes, relevé leurs avantages et leurs inconvénients, et en avonsconstruite une, spécifique aux méthodes d’évaluation de sites web. Cette nouvelle classification aété élaborée dans l’objectif de faciliter l’état de l’art des méthodes, en proposant une analysesystématique de celles-ci, en regard de critères pré-établis.

3.2 Classification des méthodes adaptée de la classification de SenachPour fonder notre classification, nous nous sommes basée sur celle établie par Senach[Senach90], car cette classification présente les avantages d’être fréquemment référencée etutilisée, avancée car englobe un nombre important de méthodes d’évaluation, structurée sur basede définitions claires et précises, et enfin permettant de positionner facilement les méthodesd’évaluation les unes par rapport aux autres.Cependant, cette classification sera revue en fonction des nouvelles méthodes apparues depuis1990 et sera adaptée afin de classer les méthodes spécifiques aux systèmes à technologie web.

[Senach90] part de la distinction entre les approches empiriques et les approches analytiques(Fig5). L’approche empirique vise l’évaluation de l’application a posteriori de l’implémentation,qu’elle soit partielle ou totale. L’approche analytique est définie quant à elle en tant qu’évaluationa priori de toute implémentation de l’application, s’appliquant en effet à une applicationreprésentée, ou à une modélisation de l’interaction. La classification proposée est adaptée aux méthodes propres aux systèmes à technologie Web.

9

Fig5 Classification des méthodes à partir de Senach

Tests deconception

Approcheanalytique

Approcheempirique

MéthodesformellesDiagnostic d'usage Méthodes

informelles

Questionnaires

Enregistreur/analyseurdynamiqued'activité

Sélectiond'alternatives

Banc d'essaifinal

Evaluationsitératives

Analyse statiquede code

Journalière

Ingéniériede

l'évaluationPrototypageMéthodologie

généraleStation

d'évaluation

Modèlesprédictifs

Modèles dequalité

Basées sur lesPropriétés

Basées sur lesconnaissances

d'un expert

P:Heuristique

P: Règlesde

conception

fonctionnel émissiond'hypothèseslocale heuristique

accessibilité

nonfonctionnel

àdistance

règlesergonomiques

critèresergonomiques

Incidentscritiques

Evaluation de sites Web

Survenanced'erreur

Sessioninteractive

10

3.2.1 Approche empiriqueLes méthodes classées au sein de cette approche visent l’évaluation de systèmes où l’applicationest réelle, déjà implémentée au moins partiellement. Deux types de méthodes se profilent au seinde cette approche: le diagnostic d’usage et les tests de conception. Le diagnostic d’usagedemande qu’il y ait déjà expérience de l’utilisation de l’application, ce que les tests de conceptionne présupposent pas.

3.2.1.1 Le diagnostic d’usageLe diagnostic d’usage se décompose en trois types de méthodes:� les incidents critiques, recueils de dysfonctionnements de l’application, observation de

l’interaction et entretiens auprès d’utilisateurs de l’interface web. Les incidents sont décrits sous forme de courts récits et font l’objet d’une classificationhiérarchique ascendante dans laquelle sont regroupées les instances d’un même problème.Ces problèmes sont également regroupés en classes plus générales. En identifiant ces classes,on vise à rechercher des solutions ayant une portée globale. [Senach90]

� les questionnaires, ensemble de questions posées à l’utilisateur destinées à récolter sesappréciations de l’interface web après utilisation. La forme des questionnaires est systématique et structurée, et donc propice à l’analyse.

� les enregistreurs et/ou analyseurs dynamiques d’activité, méthodes permettantl’enregistrement de l’activité effectuée au sein du système à technologie web et son analysedynamique. D’après la définition de [Seuren96], l’analyse dynamique du code d’un site web exécute lecode source en vue d’étendre les résultats produits par l’analyse statique. Par exemple, lesaspects du dialogue relatifs à l’utilisateur peuvent être évalués, à savoir les chemins préférésou la manière dont les utilisateurs interagissent. La troisième spécialisation du diagnostic d’usage chez [Senach90] est dénommée mouchardsélectroniques ou monitoring et porte sur les techniques de recueil automatique des actions desutilisateurs sur les dispositifs de commandes de l’application. Actuellement, certainesméthodes permettent d’à la fois enregistrer l’activité mais aussi de l’analyser. C’est pourquoile terme monitoring, se référant seulement à la capture de l’activité de l’utilisateur, estmodifié directement en enregistreurs et/ou analyseurs d’activité dynamique, qui devient parlà même une catégorie plus large que monitoring. Nous avons spécialisé cette catégorie entrois autres, précisant l’endroit où est enregistrée l’activité. L’enregistrement peut en effetêtre réalisé du côté serveur (Journalier), du côté client (Session interactive) ou partagée entreun client et le serveur (Hybride) [Vokar01].

3.2.1.2 Les tests de conceptionLes tests de conception ne nécessitent pas l’utilisation préalable de l’application. Ils sedécomposent en 4 types :� la sélection d’alternatives, qui détermine la meilleure conception d’une application à

technologie web, dans un ensemble de propositions alternatives qui sont évaluées tour à tourpuis aboutissent à une sélection.

� les évaluations itératives, qui portent sur différentes versions de l’application à technologieweb, avec ou sans contraintes de spécification des performances d’usage. L’étude peut êtreréalisée sur une maquette ou un prototype fonctionnel.

� les analyseurs statiques de code, proposant une analyse statique du code HTML del’application web. L’analyse statique du code selon la définition de [Rugaber95] citée dans [Seuren96] consisteà examiner le code source (HTML, Java) d’une application sans l’exécuter en vue d’en

11

obtenir des résultats utiles à une évaluation, par exemple le respect ou la violation de règlesergonomiques [Cooper99].La classification de Senach ne prenait pas en compte ce type d’analyse, spécifique auxsystèmes à technologie web et fortement exploitée ces dernières années par les outilsd’analyse de code.

� le banc d’essai final contrôle la qualité de l’application web finale en évaluant l’utilisationglobale de l’application implémentée. Le site web peut par exemple être visuellementinstrumenté [Scholtz98] afin d’observer les chemins des utilisateurs testant l’application eneffectuant des tâches précises, et ainsi obtenir des données quantitatives à propos desdifférentes stratégies prises par l’utilisateur ainsi que pointer les endroits de l’applicationinduisant en erreur l’utilisateur.

3.2.2 Approche analytiqueLes méthodes issues de cette approche visent l’évaluation de systèmes où l’application estreprésentée, modélisée. L’implémentation de l’interface web n’est pas nécessaire dans le cadre del’évaluation. Les méthodes émanant de cette approche sont formelles ou informelles, selonqu’elles utilisent un modèle formalisé ou non formalisé de l’application.

3.2.2.1 Les méthodes formellesDeux types de modèles sont utilisés au sein de ces méthodes:� les modèles prédictifs servent à prédire les performances d’utilisation à partir des

spécifications de conception.Ainsi, un modèle d’utilisateur standard de site web, doté de caractéristiques culturelles oupsychologiques, ainsi que de capacités cognitives, peut être élaboré et utilisé en vue demesurer la qualité interactive du site [Lynch99].

� les modèles de qualité permettent l’identification des propriétés formelles d’une applicationweb ayant un effet sur les performances des utilisateurs. Ces modèles, tels les modèles detâches, visent à établir la correspondance entre ces propriétés et les difficultés d’utilisation del’interface web [Paterno00].

3.2.2.2 Les méthodes informelles[Senach90] présente deux types d’approches informelles: l’expertise, où seules les connaissancesd’un expert sont sollicitées et la grille d’évaluation, présentant de manière exhaustive les bonnespropriétés de l’interface, à vérifier par l’évaluateur. Cette subdivision des méthodes informelles sefonde sur deux axes différents : les connaissances utilisées et le support de l’évaluation. Nousavons modifié cette subdivision en fonction des données de base de la méthode:

� les méthodes basées sur les connaissances d’un expert; ce type de méthode rejoint la notiond’expertise de [Senach90]. L’expert évalue la qualité ergonomique d’une interface web enfonction des ses connaissances personnelles.

� les méthodes basées sur des propriétés sur les objets constituants de l’interface qu’elles soientune heuristique, des critères ou des règles ergonomiques. Par exemple, l’outil ERGOVAL[Farenc97] manipule des règles ergonomiques intégrées à la base de connaissance.

La classification adaptée de Senach ne permet pas une analyse détaillée des méthodes et outilsd’évaluation existantes. En effet l’analyse des méthodes et outils ne permet pas, à partir de cetteclassification, de récolter des informations relatives aux données nécessaires en entrée de laméthode et obtenues après évaluation, au niveau d’expertise requis de l’évaluateur, au nombre etau type d’utilisateurs requis ou au matériel nécessaire au processus d’évaluation. C’est pourquoi

12

nous nous penchons dans la section 3.3 sur d’autres classifications de méthodes et outilsd’évaluation des interfaces homme-machine.

3.3 Classification MetroWeb

3.3.1 Méthodologie de travailEn vue de proposer une classification pertinente des méthodes d’évaluation de systèmes àtechnologie Web, nous allons procéder à un état de l’art des classifications existantes en matièrede méthodes d’évaluation du Web et, après avoir procédé à une étude critique des critères declassification, effectuer un choix parmi eux pour fonder notre classification. Nous ne perdrons pasde vue la classification adaptée de [Senach90] en raison des concepts véhiculés clairs etstructurants mais tenterons peu à peu de combler les failles de cette dernière grâce aux apportsdes autres classifications étudiées.

3.3.2 Etat de l’art des classifications existantesPlusieurs auteurs se sont lancés dans une classification des méthodes d’évaluation des interfaceshomme-machine. La plupart des classifications visent les méthodes d’évaluation des interfaceshomme-machine en général. Seul [Winckler01] présente une classification adaptée aux méthodesd’évaluation d’interfaces web. Nous allons analyser ces classifications une à une et relever leursavantages et leurs inconvénients. Les éléments pertinents de ces différentes classifications serontmis en exergue et retenus pour alimenter notre propre classification, la classification MetroWeb.

3.3.2.1 Whitefield, Wilson et Dowell La classification de [Whitefield91] (Fig6) est élaborée à partir des concepts d’utilisateur etd’application interactive. [Whitefield91] caractérise ainsi les méthodes d’évaluation selon laprésence réelle ou représentée de ces deux éléments constitutifs. Selon [Whitefield91], lasubdivision des méthodes d’évaluation au moyen de ces critères permet une structuration efficacede quatre grands types ou classes de méthodes d’évaluation, à savoir les méthodes analytiques, lesrapports d’utilisateurs, les rapports de spécialistes et les méthodes observationnelles.

Fig6 Classification de Whitefield

méthodesanalytiques

rapportsd'utilisateur

rapports despécialistes

méthodesobservationnelles

UtilisateurReprésenté Réel

Rep

rése

ntée

Rée

lle

App

licat

ion

13

Nous retrouvons les concepts catégorisants d’analyse et d’observation de notre classificationbasée sur Senach (3.2), où les deux grandes approches sont l’approche analytique et l’approcheempirique. Chez Whitefield, une méthode analytique s’applique lorsque le système entier,composé de l’application et de l’utilisateur, est représenté. L’approche analytique, selon[Senach90] concerne les applications représentées. Rien n’est spécifié à propos de l’utilisateur.Or, aucun exemple de méthode étudiée dans [Whitefield91] ne requiert la présence réelle del’utilisateur. Les deux vues se rejoignent donc. De même, la méthode observationnelle nes’applique qu’au système réel selon [Whitefield91]. Or une méthode observationnelle peuts’appliquer lorsque l’utilisateur est représenté, notamment par des techniques d’analyse du codeHTML. La Fig7 positionne la classification basée sur Senach à partir des notions catégorisantesde [Whitefield91], à savoir présence réelle ou représentée du système à évaluer et de sonutilisateur.

D’après [Whitefield91], les questionnaires et le banc d’essai final devraient se trouver en situationoù l’utilisateur est réel et l’application représentée. Au contraire, Senach les classe dans labranche empirique (là où l’application est réelle), respectivement dans Diagnostic d’usage (là oùl’utilisateur est réel) et Tests de conception (là où l’utilisateur est représenté). Après analyse, nousestimons qu’ils devraient être classés dans la branche prévue par Whitefield, à savoir utilisateurréel et application représentée. S’il n’y avait pas cette différence, il y aurait isomorphisme entreles deux sous-branches empiriques de Senach et les deux sous-branches système réel deWhitefield.

Les concepts d’utilisateur et d’application représentent les éléments constitutifs du systèmehomme-machine, dans la définition adoptée à la section 2.2. Le positionnement d’une méthode

APPROCHE EMPIRIQUE

banc d'essai final

UtilisateurReprésenté Réel

Rep

rése

ntée

Rée

lle

App

licat

ion

Fig 7 Classication selon Whitefield et Senach

APPROCHEANALYTIQUE

Méthodes formellesMéthodes informelles

Tests de conception

Sélection d'alternativesEvaluations itératives

Analyse statique de code

Diagnostic d'usage

Questionnaires

Incidents critiquesEnregistreurs/Analyseurs

d'activité dynamique

14

d’évaluation d’un système par rapport à la présence réelle ou représentée de l’utilisateur et del’application est par à même essentiel. C’est pourquoi, La classification proposée par[Whitefield91] constitue le point de départ de l’élaboration de notre classification. Ainsi, notreclassification sera basée sur les concepts de présence ou représentation du système.

En regard de ces critères de structuration choisis, la classification MetroWeb (Fig9) présentedifférents niveaux.Au premier niveau, elle part d’une différenciation entre application réelle et représentée. Ausecond niveau, la différenciation s’établit entre utilisateur réel et représenté. Au troisième niveau,la classification distingue le niveau de granularité de l’interaction évaluée. Ce niveau degranularité possède trois valeurs (faible, médian et élevé) et se réfère aux niveaux linguistiques de[Nielsen84] (Fig8) :

Monde Niveau Unités du niveau DéfinitionConceptuel But (7) Concepts du monde réel Extérieur au système d’information

Pragmatique (6) Modèle conceptuel Objets du monde réelSémantique (5) Fonctionnalités détaillées Objets sémantiques issus du monde réel du

système et opérations spécifiques à ces objetsPerceptif Syntaxique (4) Phrases Séquences dans le temps ou l’espace des unités

d’informationLexical (3) Unités d’information Plus petit élément portant une information

significative : mots, nombres, coordonnéesd’écran, icônes, …

Physique Alphabétique (2) Lexèmes Symboles primitifs dépendants du matériel :lettres, couleurs, lignes, phonèmes, …

Physique (1) Information physiquementcodée

Lumière, son, mouvement

Fig8 Niveaux linguistiques de [Nielsen84]

� Le niveau des buts (7) exprime les buts de l’utilisateur indépendamment de tout systèmed’information.

� Le niveau pragmatique (6) concerne la représentation des concepts du monde réel du niveau7 dans le système.

� Le niveau sémantique (5) détermine le comportement du système en définissant les objets etleurs opérations associées.

� Le niveau syntaxique (4) a trait au dialogue et aux séquences d’unités informationnelleséchangées.

� Le niveau lexical (3) est le siège des entités, des symboles véhiculant une informationélémentaire pour l’interaction.

� Le niveau alphabétique (2) correspond à l’alphabet des unités élémentaires appelées lexèmes(caractères, lignes, couleurs).

� Le niveau physique (1) est celui où se place l’échange observable d’informations entrel’utilisateur et le système.

Notre classification (Fig9) est déterminée par ces trois niveaux hiérarchiques. Le niveau 3 part dutype de système évalué (réel, mixte ou représenté). Un système réel se compose d’une applicationréelle et d’un utilisateur réel. Un système mixte est formé d’un utilisateur réel et d’une applicationreprésentée ou d’un utilisateur représenté et d’une application réelle. Enfin, un systèmereprésenté désigne un utilisateur représenté interagissant avec une application représentée.

1. Le système réel

� Application réelle et utilisateur réelNous observons les 3 niveaux de granularité suivants.

15

- faible, lorsque l’évaluation porte sur une interaction du niveau physique au niveausyntaxique, p.ex. les mouvements occulaires (niveau physique), EMA [Balbo94] et AUS[Chang97] (niveau alphabétique), WebTrends [WebTrends01], Max [Lynch99] et WET[Etgen99], ANTS [Gon00], WebQuilt [Hong01] (niveaux lexical et syntaxique), ainsi que leslaboratoires d’utilisabilité (U-Lab).

- médian, lorsque l’évaluation porte sur une interaction allant du niveau sémantique au niveaupragmatique, p.ex RemUsine [Paterno00] et USAGE [Byrne94] (niveau sémantique)

- élevé, lorsque l’interaction porte sur le niveau but, p.ex les incidents critiques qui permettentde détecter les dysfonctionnements de l’interface tels que confusion de commande etinterprêtation erronée de l’affichage

2. Le système mixte

� Application réelle et utilisateur représenté :Nous observons les 3 niveaux de granularité suivants.- faible, lorsque l’évaluation porte sur le code (interaction au niveau syntaxique), p.ex : Bobby

[Cooper99], WebSAT [Scholtz98], WebLint [Weblint01] et HTML Validator[HTMLValidator01]

- médian, lorsque l’évaluation porte sur des principes/règles/heuristiques (niveau sémantique) ,p.ex : Design Advisor (Faraday), inspection heuristique, WebTango [Ivory01a]

- élevé, lorsque l’évaluation porte sur des choix de l’utilisateur (niveau des buts), p.ex : dans lasélection d’alternatives

� Application représentée et utilisateur réel:- faible: grille-répertoire (Hassenzahln et Trautmann) - médian: mesures d’agrément (Kappa) - élevée: questionnaires

3. Le système mixte

� Application représentée et utilisateur représenté:- faible: grille- médian: GOMS [Baumeister00], Trevis [Hamacher01]- élevé: simulation

16

Fig9 Classification MetroWeb

médian

Applicationreprésentéeréelle

Utilisateur Utilisateur

réel représenté réel représenté

niveau d'interactionévalué

niveau d'interactionévalué

niveau d'interactionévalué

niveau d'interactionévalué

faible faible faible faiblemédian médian élevéélevéélevéélevé

physique alphabétique lexical &

syntaxique

- mouvements occulaires

- EMA- AUS - WebTrends

- Max - WET

- U-Lab - ANTS

- WebQuilt

sémantique pragmatique

- RemUsine- USAGE

but

- incidentscritiques

syntaxique

code:- Bobby

- WebSAT - WebLint

- HTML Validator

médian

sémantique

- principes- règles

- heuristiques

but

- choix del'utilisateur

- grille - GOMS- Trevis

- simulation - grille-répertoire(Hassenzahln

&Trautmann)

- mesures d'agrément(Kappa)

-questionnaires

La classification MetroWeb (Fig9) positionne donc chaque méthode en fonction des composantsprincipaux du système évalué, à savoir l’application et l’utilisateur, ainsi que le niveaud’interaction que la méthode peut mesurer. Les notions d’application et d’utilisateur ontl’avantage d’être fortement catégorisantes et de positionner rapidement une méthode particulière.La classification inspirée de [Senach90] ne présentait pas cet avantage. De plus, les valeurs de cesvariables (réel/représenté) sont mutuellement exclusives. La notion de niveau d’interactionévalué est quant à elle moins catégorisante car une méthode peut évaluer plusieurs niveauxd’interaction. Cela nuit à la vitesse de classification mais exige une connaissance approfondie desvariables cibles évaluées par la méthode.Nous envisageons au troisième niveau de décomposition un profil caractérisant chaque méthodeclassée, de manière à structurer d’autres connaissances, plus précises, relatives à cette méthode,qui n’étaient pas prises en compte dans [Senach90]. En vue d’élaborer ce profil des méthodes,nous allons étudier d’autres critères de classification à travers des classifications existantes deméthodes d’évaluation d’interfaces.

3.3.2.2 Ivory

3.3.2.2.1 L’évaluation en tant que processus[Ivory00b] positionne l’évaluation de l’utilisabilité au sein d’un processus itératif de conception,contenant des cycles de développement, de prototypage et d’évaluation. L’auteur présentel’évaluation en tant que processus à part entière, regroupant différentes activités: la spécificationdes objectifs d’évaluation, l’identification des utilisateurs, la sélection de métriques, d’uneméthode et de tâches d’évaluation, d’expérimentations, de collecte des données et de l’analyse etl’interprêtation de données. Le processus que nous proposons (Fig10) se base sur le principe d’évaluation inspiré de[Senach90] et présenté en 2.2.

Fig10 Processus d’évaluation

Ainsi, 7 étapes dans le processus d’évaluation sont présentées :

� La spécification des objectifs de l’évaluation (1) � La spécification du contexte (2), à savoir les caractéristiques de la population et les exigences

des tâches [Senach90].

(2) Spécificationdu contexte

(1) Spécificationdes objectifs

(7) Conseils

(6) Comparaisonavec un modèle

de référence

(3) Elaboration d'unmodèle

- utilisateurs- tâches

- dimensions - facteurs- critères

métriques (5) Recueil desdonnées

(4) Choix de variableset de techniques

de recueil

- analyse - visualisation

- critique

18

� L’élaboration d’un modèle (3) de l’objet évalué, où seront définies les dimensions pertinentesd’analyse, contraintes par les objectifs et par le contexte. Ces dimensions se décomposent enfacteurs et en critères.

� Le choix de variables et de techniques de recueil (4), où la méthode d'évaluation est choisieen fonction de sa capacité à évaluer les variables cibles. Chaque méthode présente unensemble de métriques, destinées à mesurer les critères.

� Le recueil des données (5) grâce aux techniques choisies en (4)� La comparaison avec un modèle de référence (6), où les résultats obtenus en (5) sont

comparés au modèle de référence, constitué d’ensembles acceptables de valeurs, définis entant que domaines de valeurs [Balbo94]. A cette étape, les données seront analysées, parfoisvisualisées et critiquées.

� Les conseils (7), donnés en vue de l’amélioration du système, en fonction de l’analyseeffectuée en (6).

Les étapes (1) et (2) rejoignent les deux premières étapes d’[Ivory00b]: la spécification desobjectifs d’évaluation et l’identification des utilisateurs. Notre deuxième étape prend égalementen compte les tâches à effectuer au sein du système. Ensuite, les étapes (3) à (6) ne se basent passur les étapes d’[Ivory00b]: l’étape (3) est inexistante chez elle. Quant aux étapes (4) et (5), ellesne se présentent pas dans le même ordre chronologique que dans [Ivory00b]. L’étape (6) reprendles étapes d’analyse et d’interrpêtation des données mais considère explicitement la comparaisonà des valeurs prédéfinies du modèle de référence. Enfin, nous ajoutons l’étape (7) consacrée auxconseils données en vue d’améliorer le système.

Les méthodes existantes d’évaluation concernent tout ou partie de ce processus d’évaluation.Notre profil des méthodes permettra de cerner à quelle(s) étape(s) s’applique la méthode. De plus,le support informatique offert par la méthode pour réaliser certaines étapes d’évaluation seracaractérisé par une des ces trois valeurs: {nul, partiel, total}.

3.3.2.2.2 Les efforts à consentir lors de l’évaluationL’auteur propose 4 types d’effort à consentir :� l’effort minimal, qui ne requière pas de test ou de modélisation� l’usage informel, qui demande un usage normal de l’application à évaluer, à savoir

l’accomplissement de tâches non structurées par un utilisateur ou un évaluateur� le développement d’un modèle, qui demande à l’évaluateur le développement d’un modèle de

l’interface et/ou de l’utilisateur � l’étude formelle, qui demande à l’utilisateur ou à l’évaluateur d’accomplir un ensemble de

tâches structurées et/ou une procédure

Par rapport à cette classification, nous proposons la nôtre, qui sera ajoutée au profil MetroWeb:

� effort minimal, ne demandant pas de test ou de modélisation� effort modéré, à savoir un usage normal� effort élevé, ayant deux valeurs :

- informel (p.ex un modèle linguistique de l’interface comme CCT )- formel (p.ex. avec GOMS)

3.3.2.3 Calvary et Coutaz

3.3.2.3.1 Caractère sommatif-formatif

19

[Calvary99] introduit la distinction entre le caractère sommatif ou formatif d’une méthode.Adaptée aux étapes de l’évaluation présentées dans 3.3.2.2, nous découvrons que cette distinctionn’est pas pertinente pour le recueil de données (étape 5). Par contre, elle est pertinente pour lesétapes 1-4 et 6. La dernière étape, relative aux conseils, est d’emblée formative puisque il s’agitde l’objectif final. Par exemple, l’évaluation GOMS somme des résultats concrets (évaluationsommative) mais n’est intéressante que si elle est susceptible d’aider à améliorer l’interfaceétudiée ou une interface à réaliser dans le futur (évaluation formative). Nous ne retiendrons doncpas ces notions en tant que critères caractérisant une méthode ou un outil d’évaluation.

3.3.2.3.2 Support informatiqueDe plus, [Calvary99] introduit la notion de support informatique pour la réalisation des étapesd’évaluation. Cependant, la classification de [Calvary99], appelée ESPRIT, ne considère que troisdes étapes adoptées dans le profil MetroWeb, à savoir le recueil des données, la comparaisonavec un modèle de référence et les conseils et suppose que le support est automatique, de mêmeque dans [Ivory00].En regard de la classification ESPRIT, nous caractérisons le support informatique des méthodesau moyen de trois valeurs possibles: {manuel, assisté, automatique}. Par exemple,l’instrumentation de [Calvary99] est représentée dans notre espace par l’étape de collectesupportée par un outil logiciel assisté ou automatique. De même, l’observation de [Calvary99] estreprésentée dans notre espace par l’étape de collecte supportée méthodologiquement ou non.

3.3.2.3.3 Propriétés vérifiées[Calvary99] introduit la notion de propriétés vérifiées lors de l’évaluation. Ces propriétés sontprésentées suivant deux axes:� généricité-spécificité des propriétés

Les propriétés seront génériques ou spécifiques, à savoir indépendantes ou non de tout domaineou secteur d’activité. Le critère métier de [Calvary99] correspond au cas spécifique.� nature des propriétés

Cet attribut peut avoir une ou plusieurs valeurs : {ergonomique, psychologique, pédagogique oudidactique, marketing, …}

La section 3.3.2.4. présente d’autres caractéristiques de ces propriétés exploitées dans[Vanderdonckt01].

3.3.2.3.4 Résultats de l’évaluationPour une méthode ou un outil donné, ESPRIT indique également les résultats obtenus parl’évaluation. Sont ainsi précisées les métriques quantifiant la contribution de l’outil (par exemple,la proportion de critères satisfaits) et les justifications certifiant les résultats obtenus parl’évaluation. Ces données apportent une précision à l’évaluation.

Nous proposons dès lors proposer deux catégories de résultats: {qualitatif, quantitatif} etpositionner les justifications et métriques de [Calvary99] au sein de ces catégories :- résultats qualitatifs, résultats non numériques telles des justifications ou des explications- résultats quantitatifs, résultats numériques tels des métriques

3.3.2.4 Vanderdonckt, Eisenstein, Puerta et Mariage

Dans [Vanderdonckt01] sont présentées la prise en charge des propriétés à l’opérationnalisation,ainsi que la prise en charge des propriétés à l’évaluation. Les Fig 11 et 12 illustrent les différentespossibilités de prise en charge de ces propriétés, en développant chaque possibilité positive.

20

3.3.2.4.1 Prise en charge des propriétés à l’opérationnalisationAu sein d’un outil, les règles ergonomiques peuvent être incorporées différemment (Fig11):

passives actives

invisibles visibles

implicites explicites

internes externes

non modifiables modifiables

Fig11 Prise en charge des règles à l’opérationnalisation

� Les règles passives ne sont pas exécutables. Elles se retrouvent dans les outils dedocumentation, d’enseignement, ou d’évaluation manuelle des règles.

� Les règles actives peuvent être exécutées par un outil utilisant des règles ergonomiques. Lesrègles actives seront visibles ou invisibles à l’utilisateur.� Les règles actives sont invisibles à l’utilisateur si l’outil compile complètement les règles

dans le code.� Les règles visibles à l’utilisateur sont implicites ou explicites.

� Les règles implicites sont visibles à l’utilisateur mais dans un format qui lui estincompréhensible.

� Les règles explicites sont, elles, compréhensibles par l’utilisateur. Cettecompréhension des règles dépend du type d’utilisateur: un langage de programmationsera compréhensible par un développeur de logiciel, tandis que le langage naturelsera préféré par un expert en ergonomie. Les règles explicites se décomposent enrègles internes et externes.� Les règles peuvent être internes au système.� Les règles externes au système sont contenues dans une portion identifiable de

l’outil. Elles sont divisées en règles modifiables ou non modifiables.� Les règles peuvent être non modifiables.� Les règles modifiables peuvent être modifiables manuellement ou

modifiables avec aide du système.

21

3.3.2.4.2 Prise en charge des propriétés à l’évaluationUne autre classification proposée dans [Vanderdonckt01] se réfère à la manipulation des règlespar l’utilisateur de l’outil (Fig12). Ainsi les règles peuvent être observables ou non observablespar l’utilisateur, observables si l’utilisateur peut ou non visualiser une partie ou tout le processusde manipulation des règles. Les règles observables se divisent en règles traçables ou nontraçables si le processus peut ou non être tracé étape par étape. Les règles traçables sont ensuiteraffinées en règles contrôlables ou non contrôlables si la traçabilité du processus peut être ou nonspécifiée ou contrôlée par l’utilisateur. Les règles sont contrôlables manuellement ou contrôlablesavec aide du système.

non observables observables

non traçables traçables

non contrôlables contrôlables

manuellement avec aide du système

Fig12 Prise en charge des règles à l’évaluation

En vue de positionner un outil d’évaluation ergonomique des sites web à partir de cetteclassification, nous avons choisi l’outil Bobby [Cooper99]. Cet outil vérifie automatiquement lerespect ou la violation au sein de pages Web de certaines règles ergonomiques. Il présente àl’utilisateur des règles observables car le rapport d’évaluation présente chaque règle violée enregard de la ou des pages étudiées. Cependant, les règles ne sont pas traçables car le rapportd’évaluation n’explicite pas les étapes d’évaluation parcourues.Par rapport à la prise en charge des règles à l’opérationnalisation, l’outil va assez loin dansl’arborescence. Les règles sont actives, car exécutées par l’outil. Ces règles sont visibles àl ‘utilisateur, explicites car présentées dans un format compréhensible. Elles sont internes ausystème car l’utilisateur ne peut identifier leur localisation au sein de l’outil. Aucune modificationdes règles n’est donc possible.

Ces deux classifications généralisent les 5 types de prise en charge de critères de [Calvary99], àsavoir {câblés non consultables, câblés consultables, personnalisables, langage dédié, langagenon dédié}.

22

expertiseergonomique

élevée

faible

aucune

descriptions

modèle de l'utilisateur

modèle de la tâche

spécifications externes

scénariosaucune

facteurssituationnels

connaissances résultats

ressourcesmatérielles

moyenshumains

3.3.2.5 Balbo[Balbo95] présente une classification conçue en vue d’aider la personne en charge de l’évaluationd’un système à choisir l’outil ou la méthode adéquate pour mener l’évaluation. Cetteclassification présente 5 dimensions (Fig13), chacune décomposée en un ensemble d’axes.

Fig13 Dimensions de base de la classification de [Balbo95]

3.3.2.5.1 Les connaissances

[Balbo95] considère deux types de connaissance requises au sein de l’évaluation (Fig14) : ladescription requise en entrée et le niveau d’expertise de l’évaluateur.

Fig14 Ressources matérielles requises au sein de l’évaluation selon [Balbo95]

Dans notre profil MetroWeb, nous retiendrons ces deux axes. Cependant, l’axe ‘Descriptions’ neprendra comme valeurs que les modèles requis (utilisateur, tâche, etc.)

3.3.2.5.2 Les ressources matériellesCes ressources recouvrent tous les moyens physiques impliqués dans l’activité d’évaluation[Balbo95]. Une distinction est faite entre les ressources utilisées dans la capture (ou collecte) etles ressources faisant l’objet de l’évaluation.

23

phase dudéveloppement

analyse des besoins

conception

implémentation

tests

localisation contraintesin the in the budget calendrierzoo wild

structure dudialogue type

d'applicationmono/multi-utilisateurs

multimédia/multimodale

manipulation directe

flexible

mixte

rigide

ce qui est

évaluéproduit final

prototypemockupmodèle de la tâche

modèle de l'utilisateur

instrumentsde capture

ordinateur

U-Lab

papier&crayonaucun

Fig15 Connaissances requises au sein de l’évaluation selon [Balbo95]

Notre profil des méthodes prendra en compte chaque point développé dans ces deux axes.Cependant, il étend le choix des modèles à l’ensemble des modèles impliqués en conceptiond’interfaces.

3.3.2.5.3 Les facteurs situationnelsCes facteurs définissent le contexte de l’évaluation [Balbo95], à savoir l’étape considérée dans leprocessus de développement, le lieu dans lequel se pratique l’évaluation, le type d’interface, lastructure de dialogue fournie par l’interface et les contraintes financière et temporelle del’application.

Fig 16 Contexte de l’évaluation selon [Balbo95]

Seul l’axe ‘Localisation’ est gardé tel quel dans notre profil MetroWeb. Nous modifions lesvaleurs de cet attribut en :{situation de travail réelle, situation de travail reconstituée, en-dehors}.L’axe de développement a déjà été défini, selon [Scapin99]. Les contraintes sont quant à ellesdifficilement associables à une méthode. Elles sont propres à une situation particulièred’évaluation. Les valeurs proposées pour la structure du dialogue ne s’applique pas aux systèmesà technologie Web, définis comme systèmes à très grand degré d’interaction. De même, lesdifférents types d’application proposés s’appliquent mal aux sites Web.

24

origine

externe

locale

types de sujet autres acteursreprésentatif/ niveaux culture culture en assuranceeffectif d'expertise ergonomique qualité

nombre desujets nombre

d'évaluateursn

0

n

0

typed'informationobjective/subjective

quantitative/qualitative

prédictive/explicative/

corrective

support derestitution

ordinateur

audio-visuel

papier&crayon

3.3.2.5.4 Les moyens humainsLes moyens humains (Fig17) désignent l’ensemble des acteurs impliqués directement ouindirectement dans l’actvité d’évaluation [Balbo95]. Trois types d’intervenants sont distingués :les sujets, les évaluateurs spécialistes et les autres acteurs, à savoir les développeurs, lesconcepteurs, les clients, etc.

Fig17 Moyens humains selon [Balbo95]

L’axe ‘Types de sujet’ a déjà été partiellement pris en compte grâce aux notions de systèmereprésenté et système réel développés dans [Whitefield91]. Nous gardons les notions de sujet etévaluateur, dont le nombre et l’origine sont précisés, ainsi qu’une rubrique ‘Autres acteurs’ pouréventuellement préciser l’intervention de personnes impliquée dans le développement du sytèmeinteractif, et cela au sein même de l’évaluation.

3.3.2.5.5 Résultats de l’évaluationLes résultats fournis sont de deux types (Fig18): le type d’information obtenue et le support derestitution des informations.

Fig18 Résultats de l’évaluation

Ces deux axes sont repris dans notre profil des méthodes.

La classification de [Balbo95] est très élaborée et relativement complète. Cependant, caractériserune méthode d’évaluation en fonction de tous ces paramètres peut s’avérer ardu (pas facile àtrouver), complexe (difficile à interprêter), voire impossible (à trouver, à interprêter), par ex. leslimites budgétaires ne sont pas nécessairement renseignés dans les documents descriptifs de laméthode.

25

3.3.2.5.6 Caractéristiques de l’automatisation[Balbo95b] propose 4 niveaux d’automatisation d’une méthode d’évaluation :� non automatique, à savoir aucun niveau d’automatisation� capture automatique, lorsque le logiciel capture automatiquement l’utilisation de l’interface� analyse automatique, où sont identifiés automatiquement des problèmes d’utilisabilité� critique automatique, constituée d’une analyse automatique couplée à des suggestions

automatisées d’améliorations

3.3.2.6 Grislin et Kolski

3.3.2.6.1 Variables ciblesIl s’agit des données de base à recueillir. Cette notion fait partie intégrante du principed’évaluation présenté en 1.2. Elle se rajoute au profil des méthodes construit.

3.3.2.6.2 Les intervenants de l’évaluationCette notion rejoint la notion de moyens humains développés dans [Balbo95]. Nous ajoutons lavaleur introduite dans [Grislin96], spécialiste des facteurs humains, que nous nommons‘Spécialiste de l’ergonomie’ en tant qu’attribut supplémentaire caractérisant l’évaluateur. Nous yajoutons ces valeurs possibles : {nulle/faible/modérée/élevée}. L’attribut de connaissance deModèles est également ajouté à l’évaluateur, avec comme domaine de valeurs les différentsmodèles utilisables lors de l’évaluation : {utilisateur, tâche,…}. C’est pourquoi nous enlevons duprofil la dimension Connaissances requises introduite par [Balbo95] car la dimension Moyenshumains recouvre désormais cette dimension (voir la section 3.3.2.5.1).

[Grislin96] introduit également la notion d’expert de l’application, que nous prenons commeattribut caractérisant l’axe des moyens humains repris dans notre taxonomie, et ce, dans larubrique Autres.

3.3.2.6.3 Types de connaissancesCes connaissances sont explicitement liées à un des acteurs de l’évaluation, à savoir le spécialistedes facteurs humains (ergonome), l’utilisateur (ou sujet), le concepteur ou l’expert del’application. Nous ne reprendrons pas ces notions dans notre critère ‘Connaissances’ car unmême type de connaissances [Balbo95] peut être partagé entre différents acteurs et nouspréférons nous focaliser sur la dimension développée dans [Balbo95].

3.3.2.6.4 Types de méthodes[Grislin96] présente trois approches d’évaluation: centrées sur les utilisateurs, sur une expertise(humaine ou papier) ou sur une modélisation de l’interface et/ou de l’interaction homme-machine. Ces notions sont implicitement contenues dans les distinctions reprises de [Whitefield91] :utilisateur réel/représenté et application réelle/représentée. Nous garderons dès lors celles-ci ausein de notre classification.

3.3.2.6.5 L’interface: existante ou nonCette notion rejoint également les notions application réelle/représentée de [Whitefield91].

26

3.3.2.6.6 Contraintes d’application de la méthodeCes contraintes sont relatives au temps, à la disponibilité de personnel, au coût, etc. Cette notionrejoint celle développée dans [Balbo95]. Nous ne la reprendrons pas pour les raisons précisées en3.3.2.5.4.

3.3.2.6.7 Positionnement dans le cycle de développement Le cycle en V est utilisé, mais n’est pas particularisé aux interfaces web, c’est pourquoi nous nel’exploitons pas et gardons le cycle en O, particularisé aux interfaces web.

3.3.2.7 Sweeney, Maguire et Shackel[Sweeney91] présentent une classification basée sur 3 dimensions, l’approche de l’évaluation, letype d’évaluation et le positionnement de l’évaluation dans le cycle de vie du produit.

3.3.2.7.1 L’approche de l’évaluationL’approche est relative à la source des données qui sont à la base de l’évaluation. [Sweeney91]subdivise cette catégorie en 3 autres :� basée sur l’utilisateurCela implique un ou plusieurs utilisateurs accomplissant une ou plusieurs tâches, dans unenvironnment approprié.� basée sur la théorie Un concepteur ou un évaluateur calcule le match entre la tâche ou le modèle de l’utilisateur et lesspécifications du système.� basée sur l’expertUn évaluateur utilise le système d’une manière plus ou moins structurée pour déterminer si lesystème correspond aux critères de conception prédéfinis.

Cette première catégorisation présente un problème de complétude.Cette classification se présente comme un sous-ensemble des autres, d’où se révèle moins précise.

3.3.2.7.2 Le type de l’évaluationCette dimension est fortement liée à la dimension temporelle. Elle se divise en 3:� Diagnostic Cherche à identifier des défauts de conception et à recommander des solutions de reconception.� Evaluation sommativeCherchent à déterminer comment le SI supporte l’utilisateur accomplissant sa tâche.� MétriqueCes tests génèrent des scores à partir de l’interaction. Scores à propos de la correspondance auxcritères.

Les catégories ne sont pas bien délimitées. Seules les deux premières, relative aux notions‘formatif’ et ‘sommatif’ développées dans [Calvary99] sont catégorisantes. La troisième(utilisation de métriques) ne se posent pas en catégorie mais ajoute de l’information aux deuxautres.

3.3.2.7.3 Positionnement de l’évaluation au sein du cycle de vie du produit� SpécificationEst-ce que les spécifications proposées pour le système rencontrent les besoins ?� Prototype rapide

27

Pour rendre compte des fonctionnalités ainsi que du look and feel (présentation et dialogue) dusystème proposé.� Prototypes de haute fidélité et ‘early marks’Evaluer certains facteurs comme l’acceptatbilité, facilité d’utilisation et apprentissage.

Notre profil MetroWeb utilise le cycle de vie d’un site Web proposé dans [Scapin99].

3.3.2.8 Holyer

3.3.2.8.1 Place de l’évaluation dans le processus de conceptionSelon [Holyer93], une catégorie de base dans la classification des méthodes d’évaluationd’interfaces est le positionnement de cette évaluation au sein du processus entier de conception.Les notions développées dans [Calvary99], évaluations formative et sommative, sontappréhendées suivant cet axe. En effet, selon [Holyer93], l’évaluation formative prend place dansle processus courant de conception, en suggérant des modifications potentielles de l’interface,tandis que l’évaluation sommative prend place lorsque la conception est terminée, en seprononçant sur la correspondance de l’objet évalué par rapport à un objectif particulier. Nousnous opposons à ces définitions car le caractère formatif ou sommatif de l’évaluation ne dépendpas de l’état de finition du produit à évaluer.

3.3.2.8.2 Discipline dont dérive la méthodeL’apport de [Holyer93] est de classer les différentes méthodes existantes en fonction de ladiscipline dont celle-ci est issue. Ainsi 4 disciplines de base sont présentées :� La psychologie cognitiveAu sein de cette approche se dégagent deux familles de méthodes: GOMS et l’analyse des tâches.Ces familles se basent toutes deux sur l’assomption que l’interaction homme-machine consiste enun ensemble de buts de haut niveau.� La psychologie socialeDe cette discipline dérivent les interviews et questionnaires.� Les sciences socialesAu sein de cette approche se distinguent trois familles de méthodes : le protocole à haute voix(talk-aloud protocol), les focus groups et l’évaluation coopérative. � Le génie logicielS’y trouvent l’évaluation heuristique ainsi que le cognitive walkthroughs.

Ces informations sont intéressantes mais ne sont pas souvent données avec la description d’uneméthode. Nous ne les reprendrons pas au sein de notre profil MetroWeb.

3.3.2.9 Winckler, Pimenta, Palanque et Farenc[Winckler01] présente une classification des méthodes d’évaluation de sites web. Cetteclassification a été établie à partir de ces dimensions :

3.3.2.9.1 La participation de l’utilisateur� Aucun utilisateur requis (par exemple pour l’inspection heuristique)� Utilisateurs requis pour une utilisation de l’interface en vue de fournir des données relatives à

l’interaction (tests utilisateurs)� Utilisateurs fournissent des commentaires a posteriori de l’utilisation de l’interface

(questionnaires)

28

La dimension de présence réelle ou représentée de l’utilisateur est caractérisante au sein de notreclassification MetroWeb.

� Nature de la tâche réalisée lors de l’évaluation: utilisation normale (log files) ou guidée par latâche (protocole de pensée à voix haute)

Cette nouvelle dimension est rajoutée au profil MetroWeb, comme nouvel attribut de Sujetutilisateur.

3.3.2.9.2 Identification du problème d’utilisabilitéCette identification s’effectue par les utilisateurs, les évaluateurs ou par les deux. Il est intéressant de connaître l’implication de l’utilisateur au sein du processus d’évaluation.C’est pourquoi nous ajoutons cet attribut au Sujet utilisateur dans notre profil.

3.3.2.9.3 Type de données collectées en vue de l’évaluationLes données peuvent être les suivantes : description du problème, enregistrement vidéo de lasession de test, commentaires verbaux de l’utilisateur, données de questionnaires, log files,données de simulation, données d’inspection. Les données à collecter sont à déterminer dans notre profil au sein de la dimension Variablescibles où une liste de variables, plus précises que les données présentées par [Winckler01], seraprogressivement élaborée, de manière empirique.

3.3.2.9.4 Le degré d’automatisation de la méthodeCet attribut peut avoir une de ces valeurs : {nul, capture, analyse, critique}.La dimension Etapes couvertes de notre profil couvre ces informations relatives à la méthoded’évaluation.

3.3.2.9.5 Le niveau d’expertise de l’évaluateurCet attribut peut avoir une de ces valeurs : {faible entraînement, certain entraînement, expert de laméthode}.Le profil MetroWeb prend déjà en considération cette information dans la dimensionConnaissances requises où l’attribut expertise ergonomique a pour domaine de valeurs {aucune,faible, élevée}, selon [Balbo95].

3.3.2.9.6 Evaluation à distanceCet attribut caractérise une méthode à condition qu’elle puisse être réalisée avec des utilisateurs etdes évaluateurs se trouvant à différents endroits et à différents moments.Nous ajoutons à notre profil l’attribut Evaluation à distance au sein de la dimension Contexted’évaluation, avec les valeurs {O/N}.

3.3.2.9.7 Type d’information fournieIl peut s’agir de différentes informations : besoins de l’interface, information subjective,organisation naturelle de l’information, respect de règles ergonomiques ou consistance avec desmodèles cognitifs.Le type d’information fournie se retrouve à travers le profil entier. Ainsi, nous précisons qu’uneméthode vérifie le respect de règles ergonomiques dans la dimension Résultats de l’évaluation ouque les besoins, ou objectifs, de l’interface sont revus dans la dimension Etapes couvertes.L’entièreté du profil tend à informer de manière précise à propos d’une méthode d’évaluationparticulière.

29

3.3.3 Classification et profil des méthodes d’évaluation

3.3.3.1 Classification MetroWebEn vue de caractériser une méthode d’évaluation particulière, ou un outil, nous proposons deuxétapes. La première étape est de distinguer la méthode ou l’outil au sein de la classification baséesur ces trois dimensions :� la représentation ou la réalité de l’application� la représentation ou la réalité de l’utilisateur� le niveau d’interaction évaluéCes trois dimensions sont à la base de la classification MetroWeb (Fig19).Méthode/

Outil

Système mixte [Whitefield91]Système réel [Whitefield91]

Utilisateur réel-Applicationreprésentée

Utilisateur représenté-Applicationréelle

Système représenté[Whitefield91]

Int.faible

Int.médian

Int. élevé

Int.faible

Int.médian

Int.élevé

Int.faible

Int.médian

Int.élevé

Int.faible

Int.médian

Int.élevé

abc

Fig19 Classification MetroWeb

3.3.3.2 Profil MetroWebEnsuite, la méthode est caractérisée par un ensemble de critères pertinents. Cela forme le profil dela méthode (Fig20), au sein de la classification.

Etapes couvertes - étapes {1, 2, 3, 4, 5, 6, 7}*- support informatique par étape {inexistant, partiel, total}- support méthodologique {inexistant, faible, médian, élevé}

Matériel requis Matériel de collecte [Balbo95]� ordinateur� U-Lab� papier&crayon� aucun

Matériel évalué [Balbo95]� produit final� prototype� mockup� modèle (utilisateur, tâche, …)

Moyens humains Sujets [Balbo95] utilisateurs� nombre [0..N]� origine : {externe, locale}� nature de la tâche :

{normale, guidée parla tâche}[Winckler01]

� identification duproblèmed’utilisabilité {O/N}

Evaluateurs [Balbo95]� nombre [0..N]� origine {externe,

locale}� expertise en

ergonomie [Grislin96]:{nulle/faible/modérée/élevée}� modèles

(utilisateur/tâche…}

Autres [Balbo95]� développeur� concepteur

Variables ciblesContexte del’évaluation

Lieu de l’évaluation [Balbo95]� situation de travail réelle � situation de travail reconstituée� en-dehors

Evaluation à distance : {O/N}

Effort à consentir - effort minimal [Ivory00]- effort modéré- effort élevé: {formel, informel [Ivory00]}

Propriétésvérifiées

Généricité/Spécificité[Calvary99]

Nature� ergonomique� psychologique� pédagogique ou didactique� marketing� …[Calvary99]

Si de nature ergonomique,� Prise en charge des règles ergonomiques à l’opérationnalisation{règles passives/actives, invisibles/visibles, implicites/explicites, internes/externes/nonmodifiables/modifiables}[Vanderdonckt01]� Prise en charge des règles ergonomiques à l’évaluation {règles non observables/

observables, non traçables/traçables, non contrôlables/contrôlables, contrôlablesmanuellement/avec aide du système}

[Vanderdonckt01]Résultats del’évaluation

Information : {description du problème,enregistrement vidéo, commentaires,…}Type d’information [Balbo95]� Qualitative/Quantitative� Objective/Subjective� Prédictive/Explicative/ Corrective

Support de restitution [Balbo95]� Ordinateur� Audio-visuel� papier&crayon

30

Fig20 Profil MetroWeb* 1 : spécification des objectifs, 2 : spécification du contexte, 3 : élaboration d’un modèle, 4 :choix de variables et de techniques de recueil, 5 : recueil des données, 6 : comparaison avec unmodèle de référence, 7 : conseils

3.3.3.3 Utilisation de la classification et du profil MetroWebLa classification et le profil MetroWeb ont pour objectif de structurer l’information des méthodesd’évaluation des systèmes à technologie web, en vue de pourvoir les exploiter au mieux.L’entièreté des méthodes et outils d’évaluation d’interfaces web sera dès lors présentée au sein denos travaux futurs. Nous nous limitons ici à la classification d’un outil d’évaluation particulier,l’outil WebTrends [WebTrends01]. La présence réelle ou représentationnelle de l’application etde l’utilisateur, ainsi que le niveau d’interaction évalué est en premier lieu présenté grâce à laclassification MetroWeb.

Méthode/Outil

Système mixte Système réel

Utilisateur réel-Applicationreprésentée

Utilisateur représenté-Applicationréelle

Système représenté

Int.faible

Int.médian

Int. élevé

Int.faible

Int.médian

Int.élevé

Int.faible

Int.médian

Int.élevé

Int.faible

Int.médian

Int.élevé

WebTrends X

Fig21 Classification de WebTrends

L’outil se situe dans la catégorie Système réel car l’application est réellement présente, de mêmeque l’utilisateur. De plus nous pouvons caractériser l’interaction évaluée comme faible car ellel’évaluation porte sur une interaction de niveau syntaxique et lexical. En effet, l’outil mesure à lafois nombre de pages visualisées ou d’utilisateurs visitant le site (interaction de niveau lexical)mais informe également de certains aspects du dialogue (niveau syntaxique), comme les cheminsles plus utilisés à travers le site. Le profil de l’outil est le suivant :

Etapes couvertes - Etape {recueil des données}- support informatique par étape {total}

Matériel requis Matériel de collecte � ordinateur

Matériel évalué � produit final

Moyens humains Sujets utilisateurs� nombre [N]� origine : {locale}� nature de la tâche :

{normale} � identification du

problèmed’utilisabilité {N}

Evaluateurs � nombre [1]� origine {externe}� expertise en ergonomie {nulle }� modèle {aucun}

Variables cibles � nombre d’accès, de visualisations de pages et de documents, de session, de nombre de visiteurs� groupes de pages les plus/les moins populaires, principales pages d’entrée/de sortie, chemins préférés, types de

fichiers les plus demandés� titre des bannières publicitaires affichées au cours de la période étudiée, nombre de fois que les visiteurs ont cliqué

dessus� niveau d’interaction avec le site par jour/heure� principales erreurs client ou serveur� sites référençant le plus souvent le site étudié, principaux services de recherche, mots–clés utilisés� etc.[Vokar00]

Contexte del’évaluation

Lieu de l’évaluation � situation de travail réelle

Evaluation à distance : {N}

Effort à consentir - effort minimal Propriétésvérifiées

Généricité/Spécificité[Calvary99]

Nature� ergonomique

Résultats del’évaluation

Type d’information � Quantitative� Objective� Prédictive

Support de restitution � Ordinateur

Fig22 Profil de WebTrends

31

4 Méthodologie de travail

4.1 Objectif de la recherche

Le manque d’aide à l’évaluation de l’ergonomie des applications web en cours ou en fin deconception de l’interface (section 1) nous a amenée à focaliser notre recherche sur l’organisationet l’exploitation des connaissances propres à l’évaluation de l’ergonomie des systèmes àtechnologie web, et ce en vue de mettre en évidence l’apport positif des méthodes existantes etde proposer une aide, sous forme de support informatique, à différents profils d’utilisateurs dansle processus d’évaluation de l’ergonomie des sites web.

4.2 Etapes de la recherchePour aboutir à cet objectif, des sous-problèmes doivent être traités (Fig23) :

- établissement d’un cadre de classification des méthodes et outils d’évaluationd’applications web

- état de l’art des méthodes et outils d’évaluation existants- compréhension de la démarche d’évaluation - analyse de l’activité méthodologique de l’évaluateur en situation d’évaluation- proposition d’un outil de support à cette activité d’évaluation

Fig23 Etapes de la recherche

Afin de rendre cette recherche réaliste, plusieurs variables sont à définir après avoir constituél’état de l’art des outils et méthodes:

- méthodes à appliquer- applications web à évaluer- outils à intégrer- tâches à supporter

Par rapport à l’état d’avancement et aux opportunités d’évaluation d’applications, les variableschoisies pourront être redéfinies.

Organisation etexploitation desconnaissances

Cadre declassification

Etat de l'art desméthodes & outils

Compréhension dela démarched'évaluation

Analyse del'activitéméthodologiquede l'évaluateur

Proposition d'un outil desupport à l'évaluation

32

4.2.1 Etablissement d’un cadre de classification des méthodes et outilsCette étape constitue l’objet de ce travail. Grâce à une revue de la littérature des classificationsexistantes des méthodes d’évaluation d’interfaces homme-machine, nous avons relevé les critèrescatégorisants et directement adaptables aux méthodes et outils d’évaluation d’interfaces homme-machine particulières, à savoir les interfaces web.L’espace de classification élaboré (section 3.3.3) propose un cadre des méthodes et outils (section3.3.3.1), qui permet une classification rapide vu le caractère fortement catégorisant des critèresemployés, et approfondie par le niveau d’interaction évalué. L’espace est également pourvu d’unprofil (section 3.3.3.2) détaillant la méthode ou l’outil selon des attributs pertinents relatifs àl’utilisation et aux résultats de la méthode ou de l’outil choisi, à savoir le nombre d’utilisateursrequis, le support informatique fourni ou les propriétés vérifiées.Cet espace de classification est directement utilisable dans la résolution du deuxième sous-problème.

4.2.2 Etat de l’art des méthodes et outils d’évaluation existantsUn état de l’art des méthodes et outils d’évaluation d’applications web existants sera élaborégrâce à l’espace de classification.Cet état de l’art permettra de valider l’espace de classification et d’analyser son caractèrecatégorisant. D’autre part, il mettra en relief l’apport de chaque outil et méthode au sein duprocessus d’évaluation, ainsi qu’au sein du processus global de conception.

4.2.3 Compréhension de la démarche d’évaluation

La démarche d’évaluation sera étudiée, en vue d’établir un processus d’évaluation. Pour ce faire,nous nous focaliserons a priori sur une méthode d’évaluation particulière, l’inspectionheuristique, qui a pour objet de vérifier le respect ou la violation d’un ensemble de règlesergonomiques donné au sein de l’interface évaluée. En effet, cette méthode présente l’avantaged’être facilement utilisée, peu coûteuse et ne requérant pas nécessairement d’utilisateurs. Cette étape aboutira à l’établissement d’un processus d’évaluation.

4.2.4 Analyse de l’activité méthodologique de l’évaluateur en situationd’évaluation

L’étude de l’activité méthodologique de l’évaluateur en situation d’évaluation sera prise encharge dans cette étape, grâce à l’observation d’évaluateurs en situation réelle d’évaluation.Ainsi, l’utilisation des méthodes et outils sera précisée le long du processus d’évaluation. Celapermettra de mettre en évidence les manques en matière d’aide à l’évaluation dont les évaluateurssouffriraient. Les besoins en matière de connaissances relatives aux méthodes seront établis etpermettront une structuration adéquate des connaissances existantes, en vue d’une aide à fourniraux évaluateurs.

4.2.5 Proposition d’un outil de support à l’activité d’évaluationLa connaissance récoltée par la quatrième étape sera directement exploitée dans l’élaborationd’une aide à l’évaluation des interfaces web, en fonction des besoins des évaluateurs.

4.3 Contribution du projet MetroWeb à la recherche Pour contribuer à cette recherche a été mis sur pied le projet MetroWeb.

33

4.3.1 Objectif du projet MetroWebCe projet a pour objectif la structuration des connaissances liées aux règles ergonomiques, en vuede l’aide à l ‘évaluation. Un prototype a été élaboré en vue de supporter cette aide. Lesconnaissances et les fonctionnalités prises en charge par l’outil sont actuellement cellesprésentées à la Fig24. De plus, les associations entre entités sont représentées dans la Fig25.

EntitéNom Explication

Fonctionnalité

règleergonomique

principe de conception et/oud’évaluation à observer dans lebut d’assurer l’ergonomie d’uneinterface homme-machine[Vanderdonckt99]

� Ajout/ modification/ suppression d’une règle� Recherche d’une règle sur base de son titre, de la

base, de la section .� Lien entre cette entité et les modèles, phases de

développement, niveaux linguistiques, contextes,références, méthodes d’évaluation et critères

référence référence bibliographique de larègle ergonomique

� Ajout/modification/suppression de références� Recherche d’une référence sur base du titre, des

auteurs et de son type

niveaulinguistique

niveau linguistique auquel estreliée la règle. Sept niveauxlinguistiques existent[Nielsen84] : buts, pragmatique,sémantique, syntaxique, lexical,alphabétique et physique.

� Définition des 7 niveaux linguistiques� Gestion des 7 niveaux linguistiques.

critère critère auquel appartient la règleergonomique. Il peut s’agir d’uncritère ergonomique, marketing,pédagogique ou autre.

� Ajout/modification/suppression de critères

méthoded’évaluation

méthode d’évaluation contientl’information relative auxméthodes et outils d’évaluation del’utilisabilité d’interfaces.

� Ajout/modification/suppression d’une méthoded’évaluation

phase dedéveloppement

phase de développement del’interface, à laquelle est reliée larègle ergonomique

� Ajout/modification/suppression d’une phase dedéveloppement

modèle modèle auquel est rattachée larègle ergonomique

� Ajout/modification/suppression de modèles

contexte contexte caractérisant la règle(utilisateur, tâche, environnementet domaine d’activité).

� Ajout/modification/suppression de contextes

Fig24 Données et fonctionnalités gérées par MetroWeb 1.0

Le projet MetroWeb vise en premier lieu l’aide à l’inspection heuristique, basée sur des règlesergonomiques. Cependant des informations relatives à l’évaluation des règles au moyen d’autresméthodes et outils seront également collectées grâce à l’outil. L’annexe 1 contient l’entièreté duschéma entités-associations, ainsi que ses spécifications, à implémenter dans MetroWeb.

35

Fig25 Schéma entités-associations implémenté dans MetroWeb 1.0

0-N

0-N

utilisation

0-N

0-NSource

1-1

0-N

Situation

0-N

0-N

Relation

1-N

0-N

Influence

0-N

1-N

documentation

0-N

0-N

Destination

0-N

0-N

consideration

0-N1-Ncitation1

0-N0-N

caractérisation

0-N

0-N

besoin

référencerègle ergonomique

phase de développement

niveau linguistique

méthode d'évaluationmodèle

critère

contexte

4.3.2 Ecrans du prototype MetroWeb 1.0La Fig26 présente la page d’accueil du prototype. L’utilisateur introduit son login et son password pouraccéder au menu de gestion (Fig27).

Fig26 Page d’accueil du prototype

A partir du menu de gestion (Fig27), l’utilisateur peut gérer les règles ergonomiques, les bases et sections derègles, les niveaux linguistiques, les modèles, les phases de développement, les critères, les contextes, lesméthodes d’évaluation ainsi que les références.

Fig27 Menu de gestion du prototype

Si l’utilisateur choisit la gestion des règles ergonomiques, il parvient à l’écran illustré par la Fig28.

37

Fig28 Gestion des règles ergonomiques

L’utilisateur introduit grâce à cet écran (Fig28) les valeurs des attributs propres à la règle (Titre, Enoncé,etc.), en français et en anglais. De plus, il peut lier la règle à d’autres entités (menu du haut), à savoirExceptions, Contexte, etc.

4.3.3 Lien entre le projet et la recherche Les bases de connaissances élaborées au moyen de cet outil alimenteront directement les connaissancesprésentées au point 4.1.

38

5 Références bibliographiques

[Balbo94] Balbo S. (1994) Evaluation ergonomique des interfaces utilisateur: un pas vers l'automatisation,Thèse de doctorat, Université Joseph Fourier, Grenoble 1.

[Balbo95] Balbo S. (1995) Software Tools for Evaluating the Usability of User Interfaces. Proc. of the 6th

International Conference on HCI, Pacifico Yokohama (Japan), 9-14 July, Anzai and Ogawa.

[Balbo95b] Balbo S. (1995) Automatic Evaluation of User Interface Usability: Dream or Reality? Proc. ofQCHI'95 symposium, Bond University (Australia), Sandrine Balbo (Eds), 21 August.

[Baumeister00]Baumeister L., John B. and Byrne M. (2000) A Comparison of Tools for Building GOMSmodels, in CHI’2000 Proceedings, pp.502-509.

[Bauer99] Bauer C. and Scharl A. (1999) A classification framework and assessment model for automatedweb site evaluation. Proc. Of 7th Conf. On Information Systems, Copenhagen, 23-25 June, vol.3.

[Byrne94] Byrne M., Wood S. and Sukaviriya P. (1994) Automating Interface Evaluation, CHI’94Proceedings, Boston, April, pp.232-237.

[Calvary99] Calvary G. and Coutaz J. (1999) Outils de construction: espace de classification ESPRIT, revuecritique et enseignements. Proc. of IHM’99, Montpellier, November.

[Chang97] Chang, E. and Dillon, T.S., Automated Usability Testing, in Proceedings of IFIP TC. 13International Conference on Human-Computer Interaction Interact’97 (Sydney, June 1997), S. Howard, J.Hammond, G. Lindgaard (eds.), Chapman & Hall, London, 1997, pp. 77–84.

[Cooper99] Cooper M. (1999) Evaluating accessibility and usability of web pages. In Computer-AidedDesign of User Interfaces II, CADUI, J.Vanderdonckt and A.Puerta (Eds), Kluwer Academic Publishers,The Nederlands, pp.33-42.

[Dowell89] Dowell J. and Long J.B. (1989) Towards a conception for an engineering discipline of humanfactors. Ergonomics, 32, 1513-1535.

[Etgen99] Etgen M. and Cantorn J. (1999) What does getting Wet (Web Event-logging Tool) mean for WebUsability ? , in Proceedings of 5th International Conference on Human Factors and the Web, Gaitherburg,June, accessible at http://zing.ncsl.gov/hfwe/proceedings/etgen-cantor/index.html

[Farenc95] Farenc C., Palanque P. and Vanderdonckt J. (1995) User Interface Evaluation: is it Ever Usable?Proceedings of 6th International Conference on Human-Computer Interaction HCI International'95(Yokohama, 9-14 July 1995), Y. Anzai, K. Ogawa and H. Mori (Eds.), Advances in HumanFactors/Ergonomics Series, Vol. 20B Symbiosis of Human and Artifact: Human and Social Aspects ofHuman-Computer Interaction, Elsevier Science B.V., Amsterdam, 1995, pp. 329-334

[Farenc97] Farenc C. (1997) ERGOVAL : une méthode de structuration des règles ergonomiques permettantl’évaluation automatique d’interfaces graphiques, Thèse de doctorat, Université de ToulouseI, janvier 1997.

[GON 00] GONZÁLEZ RODRÍGUEZ M., «ANTS: An Automatic Navigability Testing Tool forHypermedia», in Proceedings of Eurographics Workshop on Multimedia Multimedia’99 (Milan, 1999),Springer-Verlag, Vienne, 2000.

[Grislin96] Grislin M. and Kolski C. (1996) Evaluation des interfaces homme-machine lors dudéveloppement des systèmes interactifs. Technique et science informatiques, vol.15, n°3, 265-296.

39

[Grudin91]Grudin J. (1991) Utility and Usability : Research Issues and Development Contexts, I. GeneralPrinciples, Metacomments, in Proceedings of the First Moscow International HCI’91 Workshop (Moscou,juillet 1991)

[Hamacher01] Hamacher N. and Marrenbach J. (2001) Analytical Evaluation of Interacting Systemsregarding the Ease of Use, Proc. of 9th Int. Conf. on Human-Computer Interaction HCI International’2001(La Nouvelle Orléans, 5-10 août 2001), M.J. Smith, G. Salvendy, D. Harris & R.J. Koubek (éds.), Volume 1,Lawrence Erlbaum Associates, Mahwah, 2001, pp.585-589.

[Hong01]Hong J.I. and Landay J.A, WebQuilt : A Framework for Capturing and Visualizing the WebExperience, available at http://www10.org/cdrom/papers/602/.

[ISO92] ISO 9241 part 11 : forthcoming standard giving guidance on usability on requirements for officework with visual display terminals, available athttp://www.lut.ac.uk/research/husat/inuse/f_usability_standards.html

[Ivory01a] Ivory M. (2000) Web TANGO : Towards Automated Comparison of Information-centric WebSite Designs. Student Poster, in CHI’2000 Extended Abstracts Proceedings, pp.329-332.

[Ivory00b] Ivory M. (2000) State of the Art in Automated Usability Evaluation of User Interfaces. WorkingPaper, available at http://www.cs.berkeley.edu/~ivory/research/web/papers/survey/survey.html

[Lynch99] Lynch G., Palmiter S. and Tilt C. (1999) The Max Model : a standard Web Site User Model, inProceedings of the Conference on Human Factors and the Web, Gaithersburg, June 3, available athttp://zing.ncsl.nist.gov/hfweb/proceedings/lynch/index.html

[HTMLValidator01] http://www.htmlvalidator.com

[Lowgren95] Lowgren J. (1995) Perspectives on Usability. Lectures Notes LiTH-IDA-R-95-23, Dept. ofComputer Science, Linköping University, available at http://www.ida.liu.se/~jlo/repr.publ.fm.html.

[Mariage99] Mariage C. and Vanderdonckt J. (1999) Rapport MetroWeb n°1 : Prise en charge de la situationproblématique du projet MetroWeb, Décembre, Université Catholique de Louvain.[Mariage00a] Mariage C. and Vanderdonckt J. (2000) Rapport MetroWeb n°2 : Etat de l’art des mesures, outilset méthodes d’évaluation des sites web, Avril, Université Catholique de Louvain.[Mariage00b] Mariage C. and Vanderdonckt J. (2000) Rapport MetroWeb n°3 : Utilisation des mesures, outils etméthodes existants, Juin, Université Catholique de Louvain.[Mariage00c] Mariage C. and Vanderdonckt J. Vers une méthode d’évaluation des sites Web à partir de règles ergonomiques, 2èmes journées Multimédia, FUNDP, Namur, 11-12 septembre 00, to be published.[Mariage00d] Mariage C. and Vanderdonckt J. (2000) Rapport MetroWeb n°4 : Cahier des charges de l’outilMetroWeb, Octobre, Université Catholique de Louvain.[Mariage01] Mariage C. and Vanderdonckt J. Mechanization of Web Design Guidelines Evaluation, in Proc. of1st Int. Conf. on Universal Access in Human-Computer Interaction UAHCI’2001: Towards an InformationSociety for All, C. Stephanidis (éd.), Lawrence Erlbaum Associates, Vol. 3, Mahwah, 2001, pp. 190-194,available at http://uahci.ics.forth.gr/index.html[Metzker01] Metzker E. (2001) Supporting Organizational Learning in Usability Engineering : Requirementsof Software Development Organizations and Implications for Tool Support, in «Usability Evaluation andInterface Design», Proc. of 9th Int. Conf. on Human-Computer Interaction HCI International’2001 (LaNouvelle Orléans, 5-10 août 2001), M.J. Smith, G. Salvendy, D. Harris & R.J. Koubek (éds.), Volume 1,Lawrence Erlbaum Associates, Mahwah, 2001, pp. 430-434

[Nielsen84] Nielsen J. (1984) A Virtual Protocol Model for Computer-Human Interaction, Thèse de doctorat,Université d’Aarhus, Aarhus.

[Nielsen93] Nielsen J. (1993) Usability Engineering. Academic Press, Boston, MA.

40

[Paterno00] Paternò F. (2000) Model-Based Design and Evaluation of Interactive Applications, Springer-Verlag, London.

[Rugaber95] Rugaber S. (1995) Program comprehension : Draft. Technical Report, Georgia Institute ofTechnology, Georgia, Atlanta.

[Scapin99] Scapin D.L., Garrigues S., Farenc C., Vanderdonckt J., Palanque P., Bastide R., Bastien J.M.C.and Leulier C. (1999) Conception ergonomique d’interfaces web : démarche et outil logiciel de guidage et desupport, Projet EvalWeb, Rapport d’avancement, Décembre.

[Scapin00] Scapin D., Leulier C., Vanderdonckt J., Mariage C., Bastien C., Farenc C., Palanque P. and BastideR., Towards Automated Testing of Web Usability Guidelines, in Proc. of 6th Int. Conf. on Human Factors and the Web HFWeb’2000 (Austin, May 2000), Ph. Kortum & E. Kunzinger (eds.).[Scholtz98] Scholtz J., Laskowski S. and Downey L. (1998) Developping usability tools and techniques fordesigning and testing web sites, 4th Conference on Human Factors and the Web, Bashing Ridge, June,available at http://www.research.att.com/conf/hfweb/proceedings/scholtz.

[Senach90] Senach B. (1990) Evaluation ergonomique des interfaces homme-machine: une revue de lalittérature. Rapport n°1180, INRIA.

[Seuren96] Seuren M. (1996) Design and Implementation of an Automatic Event Abstraction Tool, Thesis inComputer Science, Waterloo, Ontario, Canada.

[Sweeney93] Sweeney M., Maguire M. and Shackel B. (1993) Evaluating user-computer interaction: aframework. Int. J. Man-Studies, 38, 689-711.

[Vanderdonckt00] Vanderdonckt J. and Mariage C., Introduction à la conception ergonomique de pages Web.Tutoriel, Ergo-IHM 2000, 3 octobre, Biarritz.[Vanderdonckt01] Vanderdonckt J., Eisenstein J., Puerta A., Mariage C., User-Interface Design Assistants:Past, Present, Future. Working Paper.

[Vokar00] Vokar S. (2000) Analyse de l’Utilité et de l’Utilisabilité d’un Intranet à partir de mesuresquantitatives de son Utilisation, Mémoire présenté en vue de l’obtention du titre de licencié en Sciences deGestion, UCL, Louvain-la-Neuve.

[Vokar01] Vokar S., Mariage C., Vanderdonckt J., Log Files Analysis to Measure the Utility of an Intranet,in « Usability Evaluation and Interface Design », Proc. of 9th Int. Conf. on Human-Computer InteractionHCI International’2001 (La Nouvelle Orléans, 5-10 août 2001), M.J. Smith, G. Salvendy, D. Harris & R.J.Koubek (éds.), Volume 1, Lawrence Erlbaum Associates, Mahwah, 2001, pp. 1185-1189.

[WebTrends01] http://www.webtrends.com

[Weblint01] http://www.ews.uiuc.edu/cgi-bin/weblint.

[Winckler01] Winckler M., Pimenta M., Palanque P. and Farenc C. (2001) Usability Evaluation Methods :What is still missing for the Web ? in «Usability Evaluation and Interface Design», Proc. of 9th Int. Conf. onHuman-Computer Interaction HCI International’2001 (La Nouvelle Orléans, 5-10 août 2001), M.J. Smith,G. Salvendy, D. Harris & R.J. Koubek (éds.), Volume 1, Lawrence Erlbaum Associates, Mahwah, 2001, pp.883-887.

[Whitefield91] Whitefield J., Wilson F. and Dowell J. (1991) A framework for human factors evaluation.Behaviour and Information Technology, 10 (1), January, 65-79.

41

6 Annexe 1 Schéma entités-associations de l’outil MetroWeb etspécifications

6.1 Schéma entités-associations

Ce schéma est présenté dans la Fig30.

42

Fig30 Schéma entités-associations de l’outil MetroWeb

0-NIs-Used-In

0-NUsesUtilization

HandingType

0-NIs-Structured-Into

0-NStructures

STRUCTURINGStruct-Name

0-NIs-Informed-By

0-NInforms

Source

1-1Is-Situated-on

0-NSituates

Situation

0-NConsists-Of

0-NIs-Part-Of

SectionComposition

0-NRight-For

1-NHas-Rights

RightStatus[1-N]

0-NRequires

0-NIs-Required-By

Requirement

0-NIs-Related-To

0-NRelates-To

RelationshipRelationshipType

0-N

0-N

Relation

0-NMeasures

0-NAllows

1-NIS-Measured-By

MeasurementMeasuredValueEvaluationTime

1-NInfluences

0-NIs_Influenced_by

InfluenceInfluenceLevel

0-NIs-Indexed-By

0-NIndexes

Indexation

1-NIncludes

0-1Is_included_in

Inclusion

0-NIs-Ilustrated-By

1-NIllustrates

IllustrationIllTypeIllStatus

1-N

1-N

Has-Type

0-NEvaluates

0-NIs-Evaluated-By

Evaluation

0-NIs-Documented-By

0-NDocuments

Documenting2

0-NDocuments

1-NIs_documented_by

Documenting

0-NIs-Targeted-By

0-NTargets

Destination

0-NIs Controled by_C

0-NControls_C

Control_C

0-NIs Controled by_A

0-NControls_A

Control_A1-N

Is-Contained-Into

1-NContains

ContainmentPathURL

1-NConsumes

0-NAre-Consumed-By

Consumptionnumber

0-NIs-Considered-By

0-NConsiders

Consideration

0-NIs-Concretised-Into

1-1Concretised-Of

Concretisation

0-NBelongs-To

0-NIs-Composed-Of

Composition

0-NCites

0-NIs_cited_by

Citation2

0-NCites

1-NIs_Cited_by Citation1

0-NAggregates

0-NIs-Aggregated-Into

CIOAggregation

0-NIs-Characterized-By

0-NCharacterizesCharacterization

0-NConsists-Of

1-NBelongs-To

BelongingBelongingOrder

1-NIs-Based-On

0-NBase-Of

Base

1-NIs-Applied-To

0-NIs-Applied-For

Application

0-NIs-Aggregated-Into

0-NAggregates

AIOAggregation

0-NAchieves

1-NIs-Achieved-ByAchievement

T

TT

D

WEB-SITEWebSiteGenre

WEB-PAGEID_PagePageURLPagePathFileNamePageTitlePageDescriptionid: ID_Page

VUI

VOLUMEID_VolumeDescriptionid: ID_Volume

Vocal

USER-PROFILEID_UPid: ID_UP

USERExpLevel

UI-TypeUINameUIDescriptionid: UIName

UIID_UIid: ID_UI

TARGET-BASE

SUPRANET

SOURCE-BASE

SECTION-GUIDEID_SectionSectionNameSectionIntroductionSectionAuthor[1-N]id: ID_Section

REFERENCEID_ReferenceAuthor[1-N]YearTitleid: ID_Reference

PHYSICAL

MODELModelNameDefinitionObjectivesid: ModelName

METRICMetricNameDataTypeMetricTypeMetricUnitDataDomainid: MetricName

LINGU-LEVELLingLevelLevelUnitLevelWorld

INTRANET

INTERNET

HUMAN HARD-SOFT

GUIDELINE-BASEID_GuidelineBaseAuthor[1-N]DateLocationid: ID_GuidelineBase

GUIDELINEID_GuidelineTitleStatementRationaleException[0-N]GLCommentid: ID_Guideline

GUI

GLOSSARY-WORDGlossaryWordNameGlossaryWordDefinitionIsaKeyWordid: GlossaryWordName

FACTORID_FactorFactorNameFactorDefinitionid: ID_Factor

EXTRANET

EXAMPLEID_ExampleEx-CommentImageFileNameCodeFilenameid: ID_Example

EVALUATORActivitySectorUsabilitySystem

EVAL-RESOURCEID_EvalResDescriptionid: ID_EvalRes

EVAL-METHODMethodTypeMethodProtocol

DEVELOP-PHASEPhaseNamePhaseDescriptionOrderingid: PhaseName

CUI

CRITERIACritTypeObjectivesCritComment

CONTEXTID_ContextUserTypeTaskTypeEnvironTypeActivityDomainid: ID_Context

CIOID_CIOCIONameid: ID_CIO

AUDIOAIO

AIONameAIODescriptionid: AIOName

Guideline/1

43

6.2 Sémantique des objets du schéma

1.1. GuidelineUne règle ergonomique (Guideline) est un principe de conception et/ou d’évaluation à observer dans le butd’assurer l’ergonomie d’une interface homme-machine.

1.1.1. ID_Guideline Chaque règle ergonomique est identifiée par un numéro qui dénote la position de la règle au sein du corpustotal de règles.

1.1.2. TitleLe titre de la règle est une phrase courte et représentative utilisant un style de phrase simple. Il est fortementrecommandé qu’il soit aussi court que possible, en préservant la signification de la règle.

1.1.3. StatementL’explication décrit le principe à suivre lorsque l’on conçoit l’interface.

1.1.4. RationaleLa justification consiste en une ou deux phrases justifiant la règle.

1.1.5. ExceptionCas où la règle ne s’applique pas, avec référence à des exemples négatifs et positifs.

Fig 31 Home Page www.ftpn.be

1.1.6. GLCommentTout autre commentaire relatif à la règle est à mettre dans ce champ.

Cette image n’apas de textealternatif. Dansce cas, un textealternatif seraitune redondancecar il y a deuximages pourexprimer lemême concept etla premièreimage a déjà untexte alternatif.

44

1.2. RelationshipUn ensemble de relations entre règles ergonomiques sont établies en accord avec une topologie des liens:

45

� liée à� est l’inverse de� hérite de � est héritée par� généralise� spécialise� précède� suit� est un� inclut� est inclus dans� est un exemple de� est fourni par� utilise� est utilisé par� …

1.3. Citation1Association reliant Guideline et Reference. Une occurrence de Guideline est citée par 1 à Noccurrences de Reference et une occurrence de Reference cite 0 à N occurrences de Guideline.

1.4. Reference

1. ID_ReferenceL’identifiant de la référence est un numéro.Simple et obligatoire.

2. AuthorCe champ spécifie le ou les auteur(s) de la référence.Multiple et obligatoire.

3. YearDate de la référence.Simple et obligatoire.

S’il y a plus d’une référence par auteur et par année, alors une lettre doit être rajoutée à l’année.Si le nombre de références est supérieure à 26, une autre séquence de lettres peut être aajoutée auA, comme Nielsen00aa; Nielsen00ab, et ainsi de suite.

Les références multiples seront séparées par le symbole “;” suivi d’un espace.

La référence this document devrait être utilisée provisoirement lorsque la règle est définie parune personne effectuant la collecte (lorsqu’il n’y a pas d’autre référence).

Simple et obligatoire.

4. TitleTitre de la référence.

46

1.5. VolumeVolumes contenant les références bibliographiques.

1.5.1. ID_VolumeIdentifiant de Volume. Autonumber. Simple et obligatoire.

1.5.2. DescriptionDescription du volume. Simple et obligatoire.

1.6. InclusionAssociation entre Reference et Volume. Une occurrence de Reference est contenue dans 1 à Noccurrences de Volume et une occurrence de Volume contient de 0 à 1 occurrence de Référence.

1.7. GlossaryWordLe glossaire contient des mots définis pour l’indexation des règles.

1. GlossaryWordNameMot du glossaire. Il s’agit de l’identifiant de l’entité.Simple et obligatoire.

2. GlossaryWordDéfinitionDéfinition du mot.Simple et obligatoire.

3. IsaKeyWordLa valeur de l’attribut IsaKeyWord est Vrai ou Faux. Ceal signifie qu’il est Descripteur ou Non-Descripteur. Le mot peut indexer la règle si la valeur est vraie. GlossaryWord est le supertype deEval-Method, Criteria et Lingu-Level. Les occurrences de Criteria, Eval-Method et Lingu-Levelreliées à la règle doivent aussi être reliées à la règle par la relation Indexation. Si une règle estindexée avec une occurrence de Criteria, Eval-Method et/ou Ling-Level, cette règle doit avoir unerelation directe avec ce Criteria, Eval-Method et/ou Lingu-Level.

Actuellement ce glossaire comporte +/- 400 mots. Voici un extrait du glossaire:

6.3 screen fontA part of the font suitcase (of Adobe Type 1 fonts), describes the shape of each character to theoperating system so that the font can be seen on screen.

secondary document A document following or dependent on a primary document. Running headers frequently identifysuch pages. You may also omit embedded image headers from the top of secondary documents,perhaps using a colored rule instead. search engineA search engines is a program that searches documents (i.e. web pages, which are HTML-documents) for specified keywords and returns the list of documents. A search engine has twoparts, a spider and an indexer. The spider is the program that fetches the documents, and theindexer reads the documents and creates an index based on the words or ideas contained ineach document.

47

scrollingAn orientation for display framing in which a user conceives of data as moving behind a fixeddisplay frame. The opposite of panning.

6.4 search engine registration process of submission of one's site url to an Internet service that indexes web pages.

Fig 32 Extract of the glossary

1.8. StructuringCette relation récusrive s’applique à GlossaryWord. Elle permet d’établir des relations entre motsdu glossaire dans le but d’établir un thésaurus.

1. Struct-NameNom de la relation. Cinq valeurs sont possibles : {EP, TG, TS, VA, V}

2. Struct-DefinitionDéfinition de la relation.

EP: Employé PourCette relation lie un Descripteur à un Non-Descripteur.TG : Terme GénériqueCette relation lie un Descripteur à un Terme qui lui est Générique.TS : Terme spécifiqueCette relation lie un Descripteur à un Terme qui lui est Spécifique.VA : Voir AussiCette relation lie un Descripteur à un Terme qui lui est lié sémantiquement.V : VoirCette relation lie un Non-Descripteur à un Descripteur de même signification.

1.9. Linguistic levelLe niveau linguistique auquel est liée une règle [Nielsen84]. Il s’agit d’un sous-type de Glossary-Word, et hérite donc de ses 3 attributs.

1. LingName7 valeurs possibles : {Objectif, Pragmatique, Sémantique, Syntaxique, Lexical, Alphabétique,Physique}Identifiant, simple et obligatoire.

2. LingDefinitionDéfinition du niveau linguistique.

3. IsaKeyWordValeurs: {Vrai, Faux}

4. LingLevel7 valeurs possibles : {7, 6, 5, 4, 3, 2, 1}

48

Simple et obligatoire.

5. LevelUnitUnité de mesure en vigueur au niveau linguistique. A chaque niveau correspond une unité.7 valeurs possibles : {Concepts du réel, Concepts du Système d’Information, Fonctions duSystème d’Information, Phrases, Unités d’information, Lettres de l’alphabet, Apparence}Simple et obligatoire.

6. LevelWorldMonde auquel s’attache un niveau linguistique.3 valeurs possibles : {Conceptuel, Perceptif, Physique}Simple et obligatoire.

1.10. CriteriaSous-type de Glossary-Word.

1. CritNameNom du critère.Identifiant, simple et obligatoire.

2. CritTypeDes critères ergonomiques, marketing ou pédagogiques peuvent être reliés aux règles.

1. Guidance1.1. Prompting (EC)1.2. Grouping / Distinction of Items

1.2.1. Grouping / Distinction by location (EC)1.2.2. Grouping / Distinction by format (EC)

1.3. Immediate feedback (EC)1.4. Legibility (EC)

2. Workload2.1. Brevity

2.1.1. Concision (EC)2.1.2. Minimal actions (EC)

2.2. Information density (EC)3. Explicit control

3.1. Explicit user action (EC)3.2. User control (EC)

4. Adaptability4.1. Flexibility (EC)4.2. Experience of the user (EC)4.3. Accessibility (EC)

5. Error management5.1. Error protection (EC)5.2. Quality of error messages (EC)5.3. Error correction (EC)

6. Consistency (EC)7. Significance of codes (EC)

49

8. Compatibility8.1. Task compatibility (EC)8.2. User compatibility (EC)8.3. Environment compatibility (EC)

Fig 33 Ergonomic criteria’s

Seuls les critères élémentaires (EC) devraient être utilisés.

Multiple et obligatoire.

3. ObjectivesObjectifs poursuivis par le critère, ce que le critère essaie de mesurer.Par exemple, la cohérence tente de mesurer une homogénéité dans la conception et l’évaluation.

4. CritCommentCommentaires libres relatifs au critère. En particulier, il s’agit des conseils d’utilisation du critère.

1.11. CompositionAssociation récursive de Criteria. Une occurrence de Criteria est composée de 0 à N occurrencesde Criteria et compose de 0 à N occurrences de Criteria.

1.12. InfluenceAssociation reliant Criteria et Guideline. Une occurrence de Criteria est liée à 0 à N occurrencesde Guideline et une occurrence de Guideline est liée à 1 à N occurrences de Criteria.

1.12.1. InfluenceLevelNiveau d’influence.

1.13. Eval-MethodSous-type de Glossary-Word. Une ou plusieurs méthodes peuvent être liées à une règle.

1.13.1. EvalMethodNameNom de la méthode d’évaluation.Identifiant, simple et obligatoire.

1.13.2. EvalMethodDefinitionDéfinition de la méthode d’évaluation.Simple et obligatoire.

1.13.3. IsaKeyWordValeurs: {Vrai, Faux}Simple et obligatoire.

50

1.13.4. MethodTypeType de famille de méthode. Le type sera le plus précis possible.Simple et obligatoire.

1. Empirical approach1.1. Usage diagnostic

1.1.1. Critical incidents1.1.2. Questionnaires1.1.3. Dynamic record/analysis of activity

1.1.3.1. Interactive session1.1.3.2. Log files1.1.3.3. Error occurrence

1.2. Design tests1.2.1. Alternatives selection1.2.2. Final testbed

1.2.2.1. General methodology1.2.2.2. Evaluation lab

1.2.2.2.1. Local1.2.2.2.2. Remote

1.2.3. Static analysis of HTML code1.2.4. Iterative evaluation

1.2.4.1. Prototyping1.2.4.1.1. Functional1.2.4.1.2. Non functional

1.2.4.2. Evaluation engineering 1.2.4.2.1. Hypothesis assumption

2. Analytical approach2.1. Formal methods

2.1.1. Predictive models2.1.2. Quality models

2.2. Informal methods2.2.1. Based on expert knowledge2.2.2. Based on properties

2.2.2.1. Heuristic properties2.2.2.1.1. Heuristic2.2.2.1.2. Ergonomic criteria2.2.2.1.3. Guidelines

2.2.2.1.3.1. Accessibility2.2.2.2. Design guidelines

Fig 34 Evaluation methods: list

1.13.5. MethodProtocolProtocole de conduite de la méthode d’évaluation. Résultats attendus. Discussion de ces résultats.

51

1.14. RequirementAssociation reliant Eval-Method et Guideline. Une occurrence d’Eval-Method est liée à 0 à Noccurrences de Guideline et une occurrence de Guideline est liée à 0 à N occurrences d’Eval-Method.

1.15. DocumentingAssociation reliant Eval-Method et Reference. Une occurrence d’Eval-Method est documentéepar 1 à N occurrences de Reference et une occurrence de Reference documente 0 à N occurrencesd’Eval-Method.

1.16. ConsumptionAssociation reliant Eval-Method et Eval-Resource. Une occurrence d’Eval-Method consomme de1 à N occurrences d’Eval-Resource et une occurrence d’Eval-Resource est consommée par de 0 àN occurrences d’Eval-Method.

1.16.1. NumberCet attribut caractérise le nombre de Ressources d’évaluation de même définition consommée parune Méthode d’évaluation.

1.17. Eval-Resource

1.17.1. ID_EvalResIdentifie l’entité Eval-Resource. Autonumber. Simple et obligatoire.

1.17.2. DescriptionDescription de la Ressource.

1.18. HumanSous-type d’Eval-Resource. Ressource humaine.

1.19. UserSous-type de Human. Utilisateur du système.

1.20. EvaluatorSous-type de Human. Evaluateur de l’interface.

1.20.1. ActivitySectorSecteur d’activité de l’évaluateur : {Métallurgie, Enseignement, Traitement de l’eau, etc.}

1.20.2. UsabilityDegré de connaissance en utilisabilité des interfaces homme-machine.

1.20.3. SystemDegré de connaissance d’utilisation du système d’information étudié.

52

1.21. Hard-SoftSous-type d’Eval-Resource. Ressource matérielle ou logicielle.

1.22. PhysicalSous-type d’Eval-Resource. Ressource physique : {papier, vidéo, enregistreur, etc.}

1.23. MetricMesure d’une qualité ou d’un défaut de l’interface étudiée.

1.23.1. MetricNameNom de la mesure. Identifiant, simple et obligatoire.Ex : Nombre d’erreurs par session.

1.23.2. DataTypeType de donnée mesurée (numérique, réel, etc.).

1.23.3. MetricTypeType de métrique : {qualitatif, quantitatif}.

1.23.4. MetricUnitUnité de mesure.Ex : Nombre d’erreurs par heure

1.23.5. DataDomainDéfinition du domaine des valeurs possibles de la donnée.

1.24. FactorEnoncé d’une dimension d’évaluation générale qui peut être exprimée de manière tangible pardes qualités et des défauts intrinsèques, pouvant être mesurées et/ou estimées.Ex : facteurs de Scheiderman : {temps d’apprentissage, taux d’erreur, satisfaction subjective del’utilisateur, rétention dans le temps, …} ; facteurs ISO9241 : {contrôlabilité, conformité, etc.}

1.24.1. ID_FactorIdentifiant de Factor. Autonumber. Simple et obligatoire.

1.24.2. FactorNameNom du facteur. Simple et obligatoire.

1.24.3. FactorDefinitionDéfinition du facteur. Simple et obligatoire.

1.25. MeasurementAssociation entre Eval-Method, Factor et Metric. Une occurrence de Metric permet de mesurer de0 à N occurrence d’une association entre une occurrence de Factor et une occurrence d’Eval-Method. Une occurrence d’Eval-Method mesure de 0 à N occurrence d’une association entre uneoccurrence de Factor et une occurrence de Metric. Une occurrence de Factor est mesurée par 1 à

53

N occurrences d’une association entre une occurrence d’Eval-Method et une occurrence deMetric.

1.25.1. MeasuredValueValeur effective mesurée.

1.25.2. EvaluationTimeTemps pris pour la mesure.

1.26. Documenting2Association reliant Factor et Reference. Une occurrence de Factor est documentée par 0 à Noccurrences de Reference et une occurrence de Reference documente 0 à N occurrences deFactor.

1.27. AchievementAssociation reliant Factor et Criteria. Une occurrence de Factor est liée à 1 à N occurrences deCriteria et une occurrence de Criteria est liée à 0 à N occurrences de Factor.

1.28. Example

1.28.1. ID_ExampleIdentifiant de Example. Autonumber. Simple et obligatoire.

1.28.2. Ex-CommentCommentaire relatif à l’exemple. Description textuelle qui explique pourquoi et comment la règlea-t-elle été violée. Si possible indiquer la bonne solution.

1.28.3. ImageFileNameCette image illustre et documente l’explication. Nom du fichier .gif ou .jpeg contenant l’image illustrant l’exemple.

1.28.4. CodeFileNameNom du fichier source contenant l’interface (ex : C:/celine /examples/HomePageFTPN.html)

1.29. Citation2Association reliant Example et Reference. Une occurrence d’Example est citée par 0 à Noccurrences de Reference et une occurrence de Reference cite 0 à N occurrences d’Example.

1.30. IllustrationAssociation reliant Example et Guideline. Une occurrence d’Example illustre 1 à N occurrencesde Guideline et une occurrence de Guideline est illustrée par 0 à N occurrences d’Example.

1.30.1. IllTypeType de l’exemple. Deux valeurs possibles: {positif, négatif}. Un exemple positif est une référence à une interface respectant la règle.Un exemple négatif est une référence à une interface violant la règle.

54

Exemple positif :

Chaque image doit avoir un texte alternatif.

55

Fig 35 Invitation Page FTPN

Les icônes relatives au choix linguistique ont un texte alternatif.

Exemple négatif : Fig36.

Chaque image doit avoir un texte alternatif.

Fig 36 Home Page www.ftpn.be

1.30.2. IllStatusStatut de l’exemple. Deux valeurs possibles: {normal, exceptionnel}.Un exemple est normal par défaut, et est exceptionnel quand cet exemple illustre une exceptionpour la règle.

Exemple exceptionnel : Fig31

1.31. CIOObjet interactif concret.

56

1.32. AIOObjet interactif abstrait.

1.33. Develop-Phase

1.33.1. Phase-NameNom de la phase de développement. Identifiant de l’entité. Simple et obligatoire.Ex :� requirements specification� design� implementation� evaluation � training � education.

Ce champ peut aussi avoir ces attributs:

� indéfini� indépendant de la phase de développement

1.33.2. PhaseDescriptionDescription de la phase. Simple et obligatoire.

1.33.3. OrderingOrdre de la phase au sein du cycle de développement.

1.34. ConsiderationAssociation entre Develop-Phase et Guideline. Une occurrence de Develop-Phase considère de 0à N occurrences de Guideline. Une occurrence de Guideline est considérée par 0 à N occurrencesde Develop-Phase.

1.35. UI typesIl s'agit du type d'interface pour lequel une règle est valide.

1.35.1. UINameIdentifiant de UI-Type. Simple et obligatoire.� GUI � CUI � web� virtual� tactile� audio

Ce champ peut aussi avoir ces attributs:

� indéfini� indépendant du type d'interface

57

1.35.2. UIDescriptionDescription du type d’interface.

1.36. VocalSous-type de UI-Type. Interface vocale.

1.37. VUISous-type de UI-Type.

1.38. GUI Sous-type de UI-Type. Interface graphique.

1.39. CUISous-type de UI-Type.

1.40. AudioSous-type de UI-Type. Interface audio.

1.41. Web-SiteSous-type de UI-Type. Interface Web.

1.41.1. WebSiteTypeType de site Web.

1.42. SupranetSous-type de Web-Site.

1.43. IntranetSous-type de Web-Site.

1.44. ExtranetSous-type de Web-Site.

1.45. InternetSous-type de Web-Site.

1.46. Web-Page

1.46.1. ID_PageIdentifiant de Web-Page. Autonumber. Simple et obligatoire.

1.46.2. PageURLURL de la page Web.

58

1.46.3. PagePathChemin de la page enregistrée dans le système.

1.46.4. FileNameNom du fichier relatif à la page, au sein du répertoire.

1.46.5. PageTitleTitre de la page.

1.46.6. PageDescriptionDescription de la page.

1.47. ContainmentAssociation entre Web-Site et Web-Page. Une occurrence de Web-Site contient de 1 à Noccurrences de Web-Page et une occurrence de Web-Page est contenue dans 0 à N occurrences deWeb-Site.

1.48. Activity domainsLes domaines d'activité auxquels est reliée la règle. Multiples occurrences possibles.� e-commerce� e-banking� e-documents� CAD

� …

Ce champ peut aussi avoir ces attributs:

� indéfini� indépendant du domaine d'activité

3.1 Tasks

Les tâches des utilisateurs sont porteuses de sens au sein d’un domaine d’activité précis.

Pour un site web de commerce électronique, la tâche peut être classée dans les catégoriessuivantes.

a) user support� knowing the site� understanding return policies� understanding shipping conditions� contacting � looking for help

b) product navigation� choosing a store� choosing a product category� choosing a brand (or a designer)� specifying a display � product examination

59

� detailed product examination

c) product picking� add to wish list� examining the wish list� add to shopping cart� examining the shopping cart

d) checking out� checking the order� specify payment details� tracking an order

Ce champ peut aussi avoir ces attributs :

� indéfini� indépendant de la tâche