La sonification des interfaces homme/machine : typologie des signaux sonores !

Il s’agit des sons marquants le défilement d’un curseur au sein d’une liste, ou des sons de survol (rollover) dans le cas d’une navigation avec un périphérique de type souris. Ces sons très brefs ont pour seul intérêt, mais non le moindre, d’indiquer une incrémentation au sein d’une liste d’items sélectionnables. De nature abstraite, ils se rapprochent des earcons, dont nous parlerons plus bas, à la différence que leur apprentissage est quasiment instantané, grâce au caractère « primitif » et répétitif de leur fonction. Ils ont une place privilégiée dans les derniers niveaux hiérarchiques d’un menu, là où le nombre d’items se montre généralement le plus important (Menu communication>appeler>contacts). A la racine d’un menu à structure thématique en revanche, les sons bénéficieront d’une relation son/signifiant plus explicite, qui renseignera de manière figurative ou métaphorique sur la nature du contenu sous-jacent.

Dans les interfaces exclusivement sonores, ou celles étant susceptibles d’être utilisées sans le recours à l’interface graphique, un autre type de son simple s’avère utile : les sons de butée. Ils renseignent l’utilisateur qui arrive en bout de course d’une liste (défilement vertical).

Quand l’utilisateur arrive au dernier niveau d’une arborescence (défilement horizontal), autrement dit quand il n’y a plus de sous-menu atteignable, un son de « liste vide » peut être utilisé. Déclinant sur l’axe horizontal la fonction qu’occupe le son de butée sur l’axe vertical, il pourra être identique à ce dernier. C’est le cas dans le prototype réalisé par l’équipe design sonore de l’IRCAM sur le projet de guidage sonore d’un système embarqué évoqué dans le billet précédent.

Grâce à ces trois familles de sons, l’utilisateur est capable d’appréhender la « géographie » du menu, territoire « discret » dont le pas est représenté par le son de défilement et ses frontières par l’emploi du son de buté et du son de liste vide. A ce stade cependant, l’utilisateur n’est pas capable d’identifier ni le contenu ni la fonction des items qu’il survole.

Issu des travaux d’analyse musicologique de Philip Tagg, ce concept renvoie à l’utilisation de motifs musicaux instrumentaux pour représenter une unité de sens. Il s’agit donc d‘évoquer de manière métaphorique, dans un contexte musical, le contenu ou la fonction d’un item.

Une illustration familière, dans l’environnement Windows, est présente sous la forme d’un motif musical d’intervalle de quinte descendante joué en pizzicato (par un instrument rappelant le violoncelle) quand un périphérique, tel qu’un disque dur externe est déconnecté. Cette intervalle, correspondant à la cadence parfaite du système tonal (enchainement V-I), évoque de façon plus ou moins consciente à l’utilisateur la nature conclusive de l’action à laquelle ce message renvoie.

Malgré tout le talent et l’intuition dont peut faire preuve le designer sonore ou le compositeur dans l’élaboration de ces motifs, un temps d’apprentissage sera requis jusqu’à ce que l’utilisateur identifie l’item sans se tromper.

La facilité de déclinaison du motif selon ses caratéristiques musicales représente le principal avantage du musème : en modulant les paramètres de celui-ci, on pourra établir une parenté au sein d’une branche de l’arborescence et également indiquer le niveau dans la hiérarchie. Dans le prototype proposé par l’IRCAM, l’entrée dans un niveau inférieur de la hiérarchie d’un menu se caractérise par une « simplification » du motif. L’article ne précise malheureusement pas comment elle est opérée (nombre de notes successifs ou simultanées décroissant, simplification rythmique, durée ?…)

Un exemple simplifié de l’utilisation des musèmes pourrait être celui-ci : au survol du menu « musique » de mon téléphone portable, 3 notes de piano successives sont jouées. Lorsque je suis amené à sélectionner un artiste, le motif musical n’est plus constitué que de deux notes. Enfin, lorsque je suis invité à choisir un morceau, le musème n’est plus constitué que d’une seule note.

Le caractère abstrait et la nature arbitraire de la relation son/signification suffit, selon les lectures antérieures que j’ai pu avoir sur le sujet, à définir un earcon. Si l’origine de la matière sonore et sa forme non musicale au sens strict le différencie du musème, l’earcon procède du même principe : des cycles d’apprentissage précédent inévitablement la reconnaissance sans risque d’échec de l’item représenté.

Comme le musème, la modulation des caractéristiques sonores (plutôt que musicales dans ce cas), permet d’établir des liens de parenté et une perception de la hiérarchie, introduisant ainsi une certaine homogénéité sonore dans la sonification de l’IHM.

Les icônes sonores représentent le niveau le plus figuratif et le plus explicite des signaux acoustiques non-verbaux. Elle établissent un « lien direct ou métaphorique avec l’objet ou le concept qu’elles représentent, en faisant référence à un son de notre environnement, et donc de fait quasi-directement compris par l’utilisateur ».

Un exemple familier nous est donné, dans l’OS d’Apple, par la mise à la corbeille d’un fichier. Ce son, qui peut être identifié comme les courts rebonds successifs d’une boule de papier jetée dans une corbeille métallique, est particulièrement explicite. Les icônes sonores montrent cependant leur limite dans leur aptitude à être modulées pour représenter les différents niveaux d’une hiérarchie. L’IRCAM a contourné de façon astucieuse le problème en créant des sons hybrides, associant earcon et icône sonore.

Associant simultanément ou successivement dans un court intervalle temporel earcon et icone sonore, les sons hybrides associent les qualités figuratives de l’icone sonore à la déclinabilité des earcons. Cette hybridation favorise en outre une homogénéité du rendu. Le procédé de modulation sonore de la composante « earcon » utilisée pour représenter la hiérarchie peut ainsi être identique quelle que soit la branche du menu explorée.

Nous avons fait le tour d’horizon des signaux sonores non-verbaux susceptibles d’être utilisés dans la sonification d’une IHM.

Pour être exhaustif, nous verrons dans le prochain billet la place et le rôle que peut prendre la synthèse vocale dans la sonification d’une IHM. Les lecteurs attentifs auront noté là un contresens, car la définition habituelle de la sonification exclut les signaux verbaux. L’article mentionné n’hésite cependant pas à utiliser le terme de sonification, alors que celle-ci fait usage de synthèse vocale et de spearcons. Nous ne soulèverons pas de débat sur cette contradiction mais explorerons en quoi la synthèse vocale peut prendre le relais des signaux non-verbaux, notamment lorsque les items du menu peuvent être mis à jour dynamiquement (requète envoyée vers une base de données) ou modifiés par l’utilisateur (bibliothèque multimédia par exemple).

PS : J’essaye de faire preuve d’un maximum de clarté dans l’exposition des concepts parfois sans doute un peu obscurs de la sonification. Vos questions, commentaires et impressions sont les bienvenus afin de rendre ce panorama accessible à tout ceux que le sujet intéresse.