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 à 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, 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
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 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 :
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 :
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 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
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 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. |