Critères ergonomiques

Les critères d'ergonomie sont un raffinement d'un des critères de qualité de Génie Logiciel : l'utilisabilité. Ceux-ci sont très largement employés dans la conception des systèmes en IHM. Ces critères s'organisent autour de trois familles de facteurs : apprentissage, souplesse et robustesse.

Dans ce point, nous nous intéressons à des critères d'ergonomie spécifiques aux collecticiels. Cependant, certains critères applicables aux systèmes mono-utilisateurs doivent être aussi vérifiés.

L'Observabilité publiée : Dans une activité de groupe, l'observabilité se heurte au concept de

protection de l'espace privé. L'espace privé se définit comme l'ensemble des variables d'état "personnelles" (par exemple, le fait qu'un membre est dans son bureau en train de lire son courrier électronique). Le caractère personnel d'une variable se définit dès l'analyse du problème. A l'évidence, l'observabilité des variables personnelles peut être pertinente pour le groupe mais potentiellement contraire au principe du respect de l'intimité. Aussi convient-il d'introduire la notion d'observabilité publiée : les variables d'état personnelles pertinentes pour autrui sont rendues observables seulement si le propriétaire en autorise la publication. L'autorisation de publication peut être statique ou dynamique. Dans notre cas, ce critère est très important. Des informations observables de l'utilisateur, nous considérons trois concepts importants :

o Observable : ce qui doit être perçu par tout utilisateur,

o Publiable : ce qu'un utilisateur décide de rendre observable de lui même,

o Filtrage : la forme de ce qui est observable. Les informations ainsi filtrées donnent de l'utilisateur l'apparence qu'il a choisie.

La différence entre un filtrage et une information publiée se situe dans la véracité des informations : quand on publie une information, celle-ci est a priori exacte, quand on la filtre, on la modifie, on la modèle à sa propre façon.

Figure 38 : Quatre niveaux d'observabilité (Laurillau, 2002).

L’observabilité peut être définis par quatre niveaux (Laurillau, 2002) comme présente la Figure 18 : les quatre niveaux sont définis suivants deux axes orthogonaux, Filtrage et Publication. Pour chaque entité, le concepteur doit décider quel niveau d’observabilité est nécessaire pour que l’utilisateur puisse réaliser sa tâche tout en préservant son espace privé et celui des autres.

Nous distinguons les informations concernant les membres d'un projet de simulation : • Informations caractérisant un membre :

o Une forme (représentation visuelle) : avatar, photographie, etc.,

o Des informations d'identification : ensemble des données propres au membre telles que le nom& prénom, l'adresse, l'e-mail, qualification scientifique et professionnelle, etc.,

o Des informations concernant son statut dans le projet : responsabilités, rôles, etc., o Le(s) groupe(s) auquel(s) il appartient.

o Liste des travaux réalisés dans le cadre d'un projet

• Informations caractérisant un groupe : o Nom du Groupe,

o Responsable du groupe. o Liste des membres,

o Statut dans le projet : spécialité, mission, etc., o Liste des travaux réalisés dans le cadre d'un projet.

Seul ^{Associe a} _groupe

Photographie 1 1

Nom de l'Utilisateur 4 4

Travaux (personnel) 1 1

Travaux (groupe) N/A 4

Informations (personnel) 3 3

Informations (groupe) N/A 4

Statut (personnel) N/A 4

Statut (groupe) N/A 4

Tableau 8 : Matrice des concepts observables.

Suivant les quatre niveaux d’observabilité, nous détaillons, dans le Tableau 5, les informations publiables et filtrables pour un membre et pour les groupes auxquels il appartient, en fonction de son appartenance à un groupe et en fonction du rôle au sein du groupe. L’affectation de la valeur 4 dans le tableau traduit que toutes ces informations doivent être observables car elles assurent la validité de la propriété d’awareness, quelque soit le statut du membre ou du groupe. Quelque soit son statut, l'utilisateur a la possibilité de contrôler totalement la publication et le filtrage des informations concernant son activité, ce qui justifie la valeur 1 pour toute la ligne “travaux personnel”. En ce qui concerne les informations personnelles propres à un membre, nous jugeons qu’il est nécessaire qu’elles soient observables, mais filtrables. Ce qui se traduit par la valeur 3 pour toute la ligne “informations (personnel)”.

Awareness : Dans un collecticiel, à la différence d'une application mono-utilisateur, plusieurs personnes peuvent agir en même temps sur les mêmes objets. L'utilisateur unique a naturellement conscience des actions qu'il entreprend. Par contre, dans un environnement partagé, les acteurs n'ont pas spontanément connaissance des agissements d'autrui. Dans le domaine du TCAO, on généralise cette connaissance par la notion de «sensation de présence », ou encore par la notion de « conscience». On a conscience d'un individu, ou d’un groupe d’individus, si on connaît la position et l’activité courante de cet individu, ou de chaque membre du groupe, dans l’espace partagé. Cette notion traduit la possibilité pour chaque utilisateur d’être informé de l’état ou des actions des autres utilisateurs de façon périphérique. Cette notion est une information critique pour l'établissement du succès d'un projet de simulation. Elle permet, en effet, de réguler et de coordonner les comportements de chaque membre. Dans toutes les situations, le collecticiel future doit garantir la cohérence des données et fournir à chacun des utilisateurs une représentation de l’activité du groupe sous les trois formes suivantes :

o Conscience de la présence des membres du groupe et leur disponibilité dans le travail coopératif,

o Conscience des actions réalisées par le membre du groupe, o Conscience des effets consécutifs à ces actions.

Contrôle d’accès : Cette propriété se traduit par la possibilité de gère les droits d’utilisation des

outils et le droit d’exécution de certaines fonctionnalités. Les droits d’accès sont définis en fonction des rôles assignés aux différents participants. Dans le cas d'un projet de simulation, le chef de projet a le pouvoir de géré les droit ou de délégué un autre membre du projet.

WYSIWIS et couplage de l’interaction : se traduit en principe par une vue identique entre plusieurs utilisateurs ; dès qu’un utilisateur apporte une modification à la vue courante (par exemple, le déplacement d’une barre de défilement). Cette notion ne se limite pas à l’interface car cette propriété impose que toutes modifications, que ce soit au niveau de l’interface ou au niveau fonctionnel, soient diffusées à tous les autres utilisateurs. La modification apportée à la vue courante est répercutée dans les autres vues avec un délai plus ou moins important suivant le degré de couplage (fortement couplé ou faiblement couplé). Il existe deux modes WYSIWIS qui ont un impact direct sur la nature du couplage de l’interaction : le mode WYSIWIS strict et le mode relâché. Dans le premier cas, cela signifie que l’interaction est fortement couplée et que tous les utilisateurs disposent nécessairement d’une vue unique. En l’occurrence, l’espace privé est très limité. Par exemple, certains collecticiels ne disposent que d’un seul pointeur de souris soumis à une politique de partage. Dans le second mode, l’interaction est plus souple et les utilisateurs disposent de leur propre vue et de leur propre espace privé. Dans notre cas, le collecticiel futur doit permettre la possibilité de paramétrage de cette contrainte selon les différentes modes de coopération dans un projet de simulation.