MODULE No 21

Titre : Radio et baignoires

But : Introduire via des analogies les modèles d’ingénierie et fonctionnels pour les interfaces personne-machine (IPM)

Antécédents : Aucun

Corps :

Incipit

Pourquoi parler de IPM (interface personne-machine) et non IPS (interface personne-système) comme dans bien des livres et des documents des entreprises ? Comme nous l’avons déjà vu le terme « système » est trop ambigu et, pendant quelques années au moins, les ingénieurs du logiciel devraient en limiter l’usage, surtout dans le contexte de la conception de systèmes informatiques.

·         Machine : une construction des humaines qui obéit à des lois plus ou moins rigides. Caractéristique principale : rigidité, impossibilité de raisonnement analogique et absence d’autonomie.

·         Personne : un être dont la caractéristique principale est la capacité d’inventer des corrélations et de raisonner par analogie.

·         Interface : ce qui met en relation deux entités : dans notre cas la machine et l’humain. L’interface appartient donc en partie à l’humain et en partie à la machine. Il est clair que dans notre culture il est encore plus facile (et moralement plus acceptable) de modifier la partie dans la machine pour l’adapter à l’humain que d’adapter l’humain à la machine !

Définition de « boîte fermée » (black box en anglais), tirée de IEEE Std 610.12) : « Un système ou un composant dont les entrées, les sorties et la fonction générale sont connus mais dont le contenu ou la mise en œuvre sont inconnus ou non pertinents. » 

Radio

La majorité des utilisateurs, lorsqu’ils emploient un récepteur radio, le considère comme une boîte fermée dont le contenu est sans importance pourvu que le récepteur fonctionne. Mais, même si le récepteur ne fonctionne pas, il est rare que quelqu’un ouvre « la boîte » pour voir ce qui se passe à son intérieur pour, éventuellement, la réparer. Ce qui suffit, à un utilisateur normal, c’est de connaître ce que l’on peut faire en agissant sur les éléments manipulables que le récepteur nous présente (boutons, manettes, interrupteurs…), en regardant les afficheurs et, surtout, en écoutant ce que le récepteur reçoit et nous renvoie via les haut parleurs.

Nul besoin de savoir comment les ondes hertziennes transportent la musique de l’émetteur au récepteur pour changer de poste ou augmenter le volume. Et pourtant ! Et pourtant dans la majorité des récepteurs la fréquence sur laquelle le récepteur est syntonisé est affichée.

Pourquoi afficher la fréquence si la majorité des utilisateurs ne sait pas ce qu’elle est ?

Pourquoi choisir entre FM et AM quand ces deux acronymes ne disent pratiquement rien à un utilisateur qui ne connaît pas les télécommunications ?

Voici deux questions qui sont loin d’être anodines quand on aborde la conception des interfaces personne-machine. Une réponse qui n’est sans doute par très éloignée de la vérité est la suivante : « Il est (et surtout "il était") plus facile de montrer un élément qui caractérise le fonctionnement interne de la « boîte noire » récepteur que de le cacher. » Ceci est lié à l’histoire de la technique des récepteurs radio : dans les premiers récepteurs il n’y avait pas d’afficheurs numérique ! Il est sans doute utile de rappeler que la première transmission sans fils (radio) est réalisée par Marconi en 1895.

Le fait que l’utilisateur moyen sache, éventuellement, que la fréquence FM 93.5 à Montréal correspond à la station émettrice xyz est un apprentissage mnémonique de mise en correspondance entre un nombre réel et le nom de la station. Cette mise en correspondance, qui était une contrainte dans les premiers récepteurs à cause du support physique disponible pour donner une rétroaction outre qu’audio à l’utilisateur,

 

 

est encore utile si on veut un affichage concis et si on veut savoir si on va dans la bonne direction dans notre recherche de la station émettrice. Mais avec la technologie actuelle, est-ce une bonne solution ? Il est clair que si on affiche les noms des stations émettrices en ordre alphabétique on a les mêmes informations sous une forme plus proche des « besoins » de l’utilisateur. Si en plus, on peut choisir une station émettrice avec une simple commande, à la limite vocale, on rendrait la vie de l’utilisateur encore plus facile et donc on satisferait encore mieux ses besoins.

Pour synthétiser tout cela on pourrait dire qu’un récepteur qui cache les fréquences et la modulation est un récepteur qui a été conçu en pensant à la représentation qu’un utilisateur « normal » a dans sa tête quand il interagit avec un récepteur radio. Dans le cas où on affiche les fréquences la représentation qui a piloté la conception des interactions est celui de l’ingénieur. Si on appelle les deux représentations « modèles », on peut faire une première grande division entre IPM :

1.      IPM conçues selon un modèle d’ingénierie : des éléments de la « tuyauterie » apparaissent sur l’IPM ;

2.      IPM conçues selon un modèle fonctionnel : pas de tuyauterie qui apparaît mais seulement des éléments qui favorisent la tâche de l’utilisateur.

Note Vous reconnaissez ici l’encapsulation que vous employez avec tant de finesse dans la conception des vos classes. Le récepteur radio comme une classe ou une classe comme un récepteur radio ? Il est historiquement plus correct de dire « La classe comme la radio ». En introduisant une généralisation on peut dire : la classe et le récepteur radio comme des boîtes noires. Fin de la note.

Mais pas besoin d’aller dans des domaines techniques si modernes pour comprendre la différence entre modèle d’ingénierie et modèle fonctionnel. Vu qu’on a parlé de « tuyauterie » on peut considérer votre salle de bain (ou celle de votre amie ou de votre arrière grand-mère). Considérons en particulier la fonction « obtenir eau chaude » et trois solutions selon leur ordre d’apparition dans nos maisons :

  1. Deux robinets avec deux manettes croisillons.
  2. Un seul robinet avec deux manettes croisillons.
  3. Un seul robinet avec un mélangeur.

Dans les deux premiers c’est clairement le modèle d’ingénierie (il y a deux tuyaux, un pour l’eau chaude et l’autre pour l’eau froide) qui a piloté la conception de l’interface robinet-personne :

  1. Deux robinets et deux manettes pour régler la quantité d’eau. L’eau se mélange dans la baignoire
  2. On met un seul robinet mais on laisse deux manettes : l’humain exécute la fonction de mélangeur. L’eau se mélange avant de sortir du robinet.
  3. Un seul robinet avec une seule manette qui a deux fonctions :
    1. Régler la quantité d’eau
    2. Obtenir le bon mélange d’eau chaude et d’eau froide.

Est-ce que les trois solutions sont fonctionnellement équivalentes ? Est-ce qu’elles satisfont le besoin de l’utilisateur ? Oui… et non. Pour trouver la réponse on va prendre le taureau par les cornes et progresser, comme il faudrait progresser dans une approche techniquement valable en GL : des besoins vers la solution.

Note. Il est évident que nous avons « oublié » une solution qui a encore beaucoup de réalisations dans le monde, même si elle est pratiquement disparue de l’Occident : verser dans la baignoire de l’eau avec des seaux. Disparition qui, dans certains régions et dans certains milieu, ne date pas d’il y a très longtemps. Dans les années 1950 dans les Alpes et, sans doute, dans les petits villages du Québec… Fin de la note.

Mais quel besoin doit-elle satisfaire la fonction « obtenir eau chaude » ? Permettre à une personne de se laver tout le corps sans geler et sans se brûler. Si le besoin est celui que nous venons d’énoncer il est clair que les trois solutions sont satisfaisantes (les quatre solutions, si on considère les seaux). On pourrait même dire : équivalentes, en ce qui concerne le besoin essentiel.

Note. À ce niveau nous ne aborderons pas le fait que « se laver » n’est pas un besoin en soi mais un moyen pour satisfaire quelque chose d’autres : se rendre socialement acceptables et éviter certaines maladies — quitte à en favoriser d’autres ! Fin de la note

Donc si on veut comparer les trois solutions on ne peut pas se fonder sur ce besoin. Y a-t-il d’autres besoins liés à la propreté de la personne ? Certes, mais il s’agit de besoins plus qualitatifs :

·         Avoir l’eau dès que l’on en a besoin sans attendre ;

·         Faciliter le réglage ;

·         Minimiser la consommation d’eau ;

·         Prendre une douche (ce que la première solution empêche tandis que la solution des « seaux » permettait). Voilà un exemple de pas en arrière fonctionnel résultat d’une avancé technique. Pas en arrière qui a été rattrapé dans les solutions deux et trois.

·         Résister aux erreurs. Dans bien de cas la solution trois est moins robuste que la solution deux : plus facile de se brûler (ou de geler) en déplaçant du mauvais côté.

·         Etc.

Le danger qui guette les informaticiens dans la conception des IPM est celui de se faire piloter par le modèle d’ingénierie : je connais les tables de la BD et donc… voilà la fenêtre

Maintenant que l’on a les idées claires sur les baignoires on peut abandonner cet exemple et passer à un nouveau module où l’on abordera brièvement la conception des IPM pour les machines informatisées (celles qui nous intéressent.)

 

Conséquent :

1.      Pas de doutes sur le fait que l’on a plusieurs choix possibles pour les IPM pour une même fonctionnalité et que le choix est dicté par des éléments qui relèvent de la « qualité »

Note : Est-ce que le modèle d’ingénierie a des avantages ? Bien sûr. Il facilite la maintenance et donne une compréhension plus approfondie des éléments qui constituent la machine et permet ainsi des réactions plus solides (moins désemparées) devant les nouveautés.