6.1.les interfaces de communication
logiciel - utilisateur


Plan du chapitre:

Introduction

1. Une interface homme machine
 

1.1 Les objets d’entrée-sortie (Delphi et VB)
1.2 Les temps d’attente
1.3 Le pilotage de l’utilisateur
1.4 Les types d’interaction
1.5 L’enchaînement des opérations
1.6 La résistance aux erreurs


Introduction

Nous énumérons ici quelques principes utiles à l’élaboration d’une interface associée étroitement à la programmation événementielle. Le lecteur qui connaît le sujet peut passer au chapitre suivant.

Notre point de vue reste celui du pédagogue et non pas du spécialiste en ergonomie ou en psychologie cognitive qui sont deux éléments essentiels dans la conception d’une interface homme-machine (IHM). Nous nous efforcerons d’utiliser les principes généraux des IHM en les mettant à la portée d’un débutant avec un double objectif :

1° Faire écrire des programmes interactifs. Ce qui signifie que le programme doit communiquer avec l’utilisateur qui reste l’acteur privilégié de la communication. Les programmes sont Windows-like et nous nous servons du RAD visuel Delphi pour les développer. Une partie de la spécification des programmes s’effectue avec des objets graphiques représentant des classes(programmation objet visuelle).

2° Le programmeur peut découpler pendant la conception la programmation de son interface de la programmation des tâches internes de son logiciel (pour nous généralement ce sont des algorithmes ou des scénarios objets).

Nous nous efforçons aussi de ne proposer que des outils pratiques qui sont à notre portée et utilisables rapidement avec notre système de développement RAD visuel.
 

1. Une interface homme-machine

  Les spécialistes en ergonomie conceptualisent une IHM en six concepts :
 

  • les objets d’entrée-sortie,
  • les temps d’attente (temps de réponse aux sollicitations),
  • le pilotage de l’utilisateur dans l’interface,
  • les types d’interaction (langage,etc..) ,
  • l’enchaînement des opérations,
  • la résistance aux erreurs (ou robustesse qui est la qualité qu'un logiciel à fonctionner même dans des conditions anormales).
    •       
    Un principe général provenant des psycho-linguistes guide notre programmeur dans la complexité informationnelle : la mémoire rapide d’un humain ne peut être sollicitée que par un nombre limité de concepts différents en même temps (nombre compris entre sept et neuf). Développons un peu plus chacun des six concepts composants une interface.
     
     

    1.1 Les objets d’entrée-sortie

    CONCEPT
    Une IHM présente à l’utilisateur un éventail d’informations qui sont de deux ordres : des commandes entraînant des actions internes sur l’IHM et des données présentées totalement ou partiellement selon l’état de l’IHM.

      


    Voici avec un RAD visuel des objets visuels associés aux objets d’entrée de l’information : les exemples sont en Delphi et en Visual Basic, ils sont très proches car en fait ce sont des surcouches logiciels de contrôles de base du système Windows.

    Delphi :
      un bouton 
     
     


    Un menu
    une boîte de saisie mono-ligne
     


    une boîte de saisie multi-ligne
     

    Visual Basic :


    un bouton de commande


    Un menu
     
    une boîte de saisie mono-ligne et multi-ligne

     

    Ci-dessous quelques objets visuels associés à des objets de sortie de l’information :

    Delphi :

    un TstringGrid (tableau)
     


    un Timage(image,bmp,ico,...)
    un TlistBox (liste)
     


    un Touline (arbre)

    Visual Basic :

    un MSFlexGrid (tableau)
     


    un Image(image,bmp,ico,...)
    un ListBox (liste)
     


    un TreeView (arbre)

     
     

    1.2 Les temps d’attente

    CONCEPT
    Sur cette question, une approche psychologique est la seule réponse possible, car l’impression d’attente ne dépend que de celui qui attend selon son degré de patience. Toutefois, puisque nous avons parlé de la mémoire à court terme (mémoire rapide), nous pouvons nous baser sur les temps de persistance généralement admis (environ 5 secondes).

      
    Nous dirons qu’en première approximation, si le délai d’attente est :


    Exemples de telles classes d’objets visuels  :

    Delphi :

    TProgressBar
    TTrackBar

    Visual Basic :

    ProgressBar
    Slider

    Delphi :

    TStatusBar (avec deux panneaux ici)


    Visual Basic :

    StatusBar (avec deux panneaux ici)
     
     

    1.3 Le pilotage de l’utilisateur

    CONCEPT
    Nous ne cherchons pas à explorer les différentes méthodes utilisables pour piloter un utilisateur dans sa navigation dans une interface. Nous adoptons plutôt la position du concepteur de logiciel qui admet que le futur utilisateur ne se servira de son logiciel que d’une façon épisodique. Il n’est donc pas question de demander à l’utilisateur de connaître en permanence toutes les fonctionnalités du logiciel.

      
    En outre, il ne faut pas non plus submerger l’utilisateur de conseils de guides et d’aides à profusion, car ils risqueraient de le détourner de la finalité du logiciel. Nous préférons adopter une ligne moyenne qui consiste à fournir de petites aides rapides contextuelles (au moment ou l’utilisateur en a besoin) et une aide en ligne générale qu’il pourra consulter s’il le souhaite.

    Ce qui revient à dire que l’on accepte deux niveaux de navigation dans un logiciel :
     


    Il faut admettre que le niveau de surface est celui qui restera le plus employé (l’exemple d’un logiciel de traitement de texte courant du commerce montre qu’ au maximum 30% des fonctionnalités du produit sont utilisées par plus de 90% des utilisateurs).

    Pour permettre un pilotage plus efficace on peut établir à l’avance un graphe d’actions possibles du futur utilisateur (nous nous servirons du graphe événementiel) et ensuite diriger l’utilisateur dans ce graphe en matérialisant (masquage ou affichage) les actions qui sont réalisables. En application des notions acquises dans les chapitres précédents, nous utiliserons un pilotage dirigé par la syntaxe comme exemple.
     
     

    1.4 Les types d’interaction

    CONCEPT
    Le tout premier genre d’interaction entre l’utilisateur et un logiciel est apparu sur les premiers systèmes d’exploitation sous la forme d’un langage de commande. L’utilisateur dispose d’une famille de commandes qu’il est censé connaître, le logiciel étant doté d’une interface interne (interpréteur1 de cette famille de commandes). Dès que l’utilisateur tape textuellement une commande (exemple MS-DOS " dir c: /w "), le système l’interprète (dans l’exemple : lister en prenant toutes les colonnes d’écran, les bibliothèques et les fichiers du disque C).
         
      Nous adoptons comme mode d’interaction entre un utilisateur et un logiciel, une extension plus moderne de ce genre de dialogue, en y ajoutant, en privilégiant, la notion d’objets visuels permettant d’effectuer des commandes par actions et non plus seulement par syntaxe textuelle pure.

      Nous construisons donc une interface tout d’abord essentiellement à partir des interactions événementielles, puis lorsque cela est utile ou nécessaire, nous pouvons ajouter un interpréteur de langage (nous pouvons par exemple utiliser des automates d’états finis pour la reconnaissance).
       
       

      1.5 L’enchaînement des opérations

      CONCEPT
      Nous savons que nous travaillons sur des machines de Von Neumann, donc séquentielles, les opérations internes s’effectuant selon un ordre unique sur lequel l’utilisateur n’a aucune prise. L’utilisateur est censé pouvoir agir d’une manière " aléatoire ". Afin de simuler une certaine liberté d’action de l’utilisateur nous lui ferons parcourir un graphe événementiel prévu par le programmeur. Il y a donc contradiction entre la rigidité séquentielle imposée par la machine et la liberté d’action que l’on souhaite accorder à l’utilisateur. Ce problème est déjà présent dans un système d’exploitation et il relève de la notion de gestion des interruptions.

     
    Nous pouvons trouver un compromis raisonnable dans le fait de découper les tâches internes en tâches séquentielles minimales ininterruptibles et en tâches interruptibles.

    Les interruptions consisteront en actions potentielles de l’utilisateur sur la tâche en cours afin de :

      
    Il faut donc qu’existe dans le système de développement du logiciel, un mécanisme qui permette de " demander la main au système " sans arrêter ni bloquer le reste de l’interface, ceci pendant le déroulement d’une action répétitive et longue. Lorsque l’interface a la main, l’utilisateur peut alors interrompre, quitter, interroger...

    Ce mécanisme est disponible dans nos RAD visuels pédagogiques (Delphi et Visual Basic), nous verrons comment l’implanter. Terminons ce tour d’horizon, par le dernier concept de base d’une interface : sa capacité à absorber certains dysfonctionnements.
     
     

    1.6 La résistance aux erreurs

    CONCEPT
    Il faut en effet employer une méthode de programmation défensive afin de protéger le logiciel contre des erreurs comme par exemple des erreurs de manipulation de la part de l’utilisateur. Nous utilisons plusieurs outils qui concourent à la robustesse de notre logiciel. La protection est donc située à plusieurs niveaux.

      
    1°) Une protection est apportée par le graphe événementiel qui n’autorise que certaines actions (activation-désactivation), matérialisé par un objet tel qu’un menu :

    l’item " taper un fichier " n’est pas activable.
     

    2°) Une protection est apportée par le filtrage des données (on peut utiliser par exemple des automates de reconnaissance de la syntaxe des données).
     

    3°) Un autre niveau de protection est apporté par les composants visuels utilisés qui sont sécurisés dans le RAD à l’origine. Par exemple la méthode LoadFromfile de Delphi qui permet le chargement d’un fichier dans un composant réagit d’une manière sécuritaire (c’est à dire rien ne se produit)lorsqu’on lui fournit un chemin erroné ou que le fichier n’existe pas.
     

    4°) Un niveau de robustesse est apporté en Delphi par une utilisation des exceptions (semblable à Ada ou à C++) autorisant le détournement du code afin de traiter une situation interne anormale (dépassement de capacité d’un calcul, transtypage de données non conforme etc...). Le programmeur peut donc prévoir les incidents possibles et construire des gestionnaires d’exceptions. Visual Basic ne possède qu'un objet interne Err et des gestionnaires provenant de Basic du type ON Error Goto ...