V - RECOMMANDATIONS
Dans ce qui va suivre, les recommandations seront présentées en fonction des trois éléments importants de l'IHO:
- A - le dialogue, c'est-à-dire la communication dans les deux sens entre l'utilisateur et l'ordinateur.
- B - les entrées, i.e., la communication de l'utilisateur vers l'ordinateur.
- C - les sorties, i.e., la communication de l'ordinateur vers l'utilisateur.
Dans la section réservée au dialogue, après avoir discuté des propriétés générales des dialogues, on présentera les types de dialogue les plus répandus, ainsi que des considérations sur les procédures de dialogue.
La section sur les entrées concernera respectivement l'entrée d'informations, la dénomination, et les séquences de commandes.
Dans la section consacrée aux sorties, on évoquera le temps de réponse, les étapes de la conception des écrans, les problèmes de codage, pour terminer sur des recommandations plus spécifiques sur les affichages.
A - LE DIALOGUE
1 - Propriétés générales des dialogues
a - Initiative
L'initiative fait référence au fait que c'est l'utilisateur ou bien l'ordinateur qui dirige les transactions au sein du dialogue. Si l'ordinateur pose des questions, présente des alternatives, et que l'utilisateur y répond, c'est un dialogue à l'initiative de l'ordinateur. Si au contraire l'utilisateur entre directement des commandes sans un tel guidage, le dialogue est alors à l'initiative de l'utilisateur. Bien entendu il existe divers degrés d'initiative.
On peut dire cependant de façon générale que des dialogues à l'initiative de l'ordinateur sont préférables pour des utilisateurs inexpérimentés ou occasionnels. De tels dialogues permettent en effet de mettre en oeuvre des processus de reconnaissance, plus aisés que des processus de rappel. Ils fournissent à l'utilisateur un modèle du système, et permettent donc l'utilisation du système par des opérateurs qui n'ont pas encore intériorisé ce modèle.
Par contre, un tel type de dialogue, qui ne permet pas d'anticiper, de sauter des étapes, ne peut être acceptable pour un utilisateur expérimenté que dans la mesure où le nombre de transactions est relativement réduit et que le temps de réponse est court. Un dialogue lent à l'initiative de l'ordinateur est en effet très perturbateur pour un utilisateur expérimenté.
En fait, pour la plupart des systèmes, il est souhaitable de permettre aux utilisateurs de choisir l'un de ces modes.
b - Flexibilité
La flexibilité peut se référer à deux notions différentes. La première est celle qui a été utilisée auparavant et qui correspond en fait à la capacité d'adaptation du logiciel à diverses sous-populations différenciables selon leur niveau d'expérience. Ce type de flexibilité, comme il a été dit, est souhaitable.
La seconde est plutôt une flexibilité "interne" et correspond au nombre de façons différentes (procédures, options, commandes, etc.) mises à la disposition de l'utilisateur pour atteindre un même objectif. Une grande flexibilité peut être obtenue par exemple en fournissant de nombreuses commandes, en permettant à l'utilisateur de définir ou redéfinir de nouvelles commandes. Des résultats montrent que les utilisateurs peu expérimentés tendent à utiliser des méthodes bien connues pour effectuer leurs opérations plutôt que des méthodes parfois plus efficaces mais moins bien connues et que l'existence de dialogues très flexibles diminue la performance (notamment en augmentant le nombre d'erreurs) chez des utilisateurs naïfs. En conséquence, des dialogues très flexibles ne sont pas recommandés, excepté pour des utilisateurs expérimentés.
En somme, il est bon qu'un dialogue comporte plusieurs niveaux d'expérience, mais il est souhaitable que certains de ces derniers ne soient flexibles (au sens ci-dessus) que s'ils sont destinés à des utilisateurs expérimentés.
c - Complexité
La complexité est liée à la flexibilité: elle se caractérise en effet par le nombre d'options disponibles à l'utilisateur à un point donné de la transaction. Une complexité faible peut être obtenue en utilisant peu de commandes ou bien en subdivisant ces commandes de façon à ce que l'utilisateur n'ait à en sélectionner qu'une sous-partie à tout instant du dialogue. On peut penser qu'il existe un niveau optimal de complexité, pour une tâche et un utilisateur particuliers. Des études montrent qu'un nombre important de commandes redondantes ou non pertinentes handicape la performance, mais qu'une extrême simplification du dialogue par hiérarchisation à outrance est également mauvaise. C'est semble-t-il une propriété difficile à définir à l'avance, notamment en raison de ses fortes interactions avec les caractéristiques des utilisateurs et celles de la tâche. Ceci est un exemple des limites de ce guide: en effet, la complexité se règle en fonction d'éléments spécifiques d'une transaction particulière, au sein d'une tâche particulière.
d - Puissance
La puissance représente le volume de traitements effectués par l'ordinateur en réponse à une seule commande de l'utilisateur. Dans un dialogue avec des commandes puissantes, l'utilisateur peut accomplir avec une seule commande ce qui nécessiterait plusieurs commandes moins puissantes. Dans un certain nombre d'applications, des commandes puissantes peuvent être souhaitables (e.g., opérateurs matriciels pour un logiciel de mathématiques). Le problème est qu'en général l'existence de commandes très puissantes (et donc par extension, souvent très spécifiques), réduit la généralité d'un système, son adaptabilité à d'autres tâches. Ceci est un facteur prépondérant dans le rejet des systèmes par les managers et le personnel technique (notamment du fait que leurs activités n'étant pas routinières, ils peuvent avoir besoin de faire appel à des fonctionnalités légèrement différentes). De plus, fournir des commandes puissantes en plus d'un ensemble de commandes de base, plus simples, tend à augmenter la complexité du dialogue. Une solution possible est de faire une partition du dialogue de telle sorte que par exemple les utilisateurs peu expérimentés disposent seulement d'un sous-ensemble des commandes, à un instant donné.
e - Charge informationnelle
La charge informationnelle est le degré selon lequel l'interaction sollicite les ressources de mémoire et de traitement de l'utilisateur. Dans la plupart des tâches, la performance des utilisateurs est influencée négativement quand la charge informationnelle est trop élevée ou trop faible. Bien entendu, une part importante de cette charge est fonction de la tâche elle-même et de la familiarité de l'opérateur vis-à-vis de sa tâche. Cependant la charge informationnelle est aussi influencée par les caractéristiques du dialogue. On peut mesurer cette charge de façon empirique ou bien l'estimer. Il est possible de la faire varier en intervenant sur les modalités d'affichage, les types de canaux sollicités, la puissance des commandes, l'utilisation de valeurs par défaut, le type et la structure des langages de commande et d'autres aspects de l'interface sur lesquels on reviendra.
