Publications

Réflexions et retours d'expérience.

Etude de cas : la rencontre entre l’op­ti­mi­sa­tion tech­nique et les utili­sa­teurs.

5min de lecture

Tandis que je réali­sais un audit ergo­no­mique sur un logi­ciel de statis­tiques consé­quent, j’ai rencon­tré de nombreux points de latence dans les parcours utili­sa­teurs. Or le feed­back immé­diat fait notam­ment partie des critères de Bastien & Scapin (p.16/45). Parmi ces latences, le délais entre la saisie et l’af­fi­chage des résul­tats d’un formu­laire de recherche impac­tait les utili­sa­teurs.


En l’oc­cu­rence, le précé­dent système néces­si­tait une saisie, suivie de la vali­da­tion avant la soumis­sion d’une requeête au serveur en vue d’ob­te­nir les résul­tats. Dans le cas présent, j’ai donc forte­ment recom­mandé la mise en place d’un système de recherche instan­ta­née en rempla­ce­ment de la recherche clas­sique.

La solu­tion envi­sa­gée

Un système de recherche basé sur le navi­ga­teur a donc été pensé afin de reti­rer les étapes entrai­nant la latence liée aux requêtes. Pour ce faire, l’évè­ne­ment JavaS­cript onchange a été utilisé afin de détec­ter un quel­conque chan­ge­ment dans le champ de recherche :

inputField.addEventListener('change', function(searchValue) {

    // Lancement de la recherche

}, false);

Or toute utili­sa­tion de cet évène­ment est parti­cu­liè­re­ment connue des déve­lop­peurs pour être consom­ma­trice de ressources sur le poste utili­sa­teur. En effet, chaque ajout ou retrait de carac­tère lançait une nouvelle recherche (sur près de 4000 valeurs). De ce fait, chaque chan­ge­ment ralen­tis­sait l’uti­li­sa­teur dans son action. Philip Walton a par ailleurs décrit et expliqué ce compor­te­ment tech­nique.

Nous nous retrou­vions donc avec un nouveau problème : le feed­back deve­nait de plus en plus tardif au fur et à mesure de la recherche de l’uti­li­sa­teur; Et le délai entre la pres­sion d’un carac­tère sur le clavier et la réponse visuelle en était lui aussi impacté.

L’op­ti­mi­sa­tion tech­nique

Du fait que de nombreux déve­lop­peurs aient déjà expé­ri­menté cette problé­ma­tique, la litté­ra­ture à ce sujet s’est avérée parti­cu­liè­re­ment abon­dante. Et l’une des solu­tions propo­sait de créer une latence entre la frappe d’un nouveau carac­tère et le lance­ment de la recherche. Cette solu­tion vise à attendre la fin de l’ac­tion de l’uti­li­sa­teur avant d’exé­cu­ter l’ac­tion.

var searchTimeOut = false;
inputField.addEventListener('change', function(searchValue) {

    // Empêcher toute recherche précédente non lancée
    clearTimeout(searchTimeOut);

    // Lancement de la recherche après 200ms
    searchTimeOut = setTimeout(function() {

        // ...

    }, 200);

}, false);

Dans la litté­ra­ture tech­nique, le délais de 200ms est le plus courant. Il est notam­ment basée sur une esti­ma­tion du délais maxi­mal avant percep­tion de la latence avant que celle-ci ne devienne systé­ma­tique.

Cepen­dant, bien que cette solu­tion se base sur la percep­tion de l’uti­li­sa­teur, elle ne réponds aucu­ne­ment au problème. Les ralen­tis­se­ments sont toujours présents malgré l’ab­sence de percep­tion du délais entre la frappe et l’af­fi­chage des résul­tats de recherche.

L’op­ti­mi­sa­tion avec l’uti­li­sa­teur

Bien souvent, nous nous posons les mauvaises ques­tions. Ci-dessus, nous voulions inhi­ber la percep­tion de la latence. Cepen­dant, le ques­tion­ne­ment des utili­sa­teurs met bien souvent en lumière des points de vue diffé­rents.

Ainsi, en lieu et place d’une opti­mi­sa­tion basée sur la latence entre la frappe et l’af­fi­chage des résul­tats, une autre stra­té­gie a été pensée. Il fallait bien entendu conser­ver cette opti­mi­sa­tion tech­nique afin de limi­ter les latences liées au nombre de recherches. Je me suis donc penché sur le délais opti­mal entre le dernier chan­ge­ment et l’af­fi­chage des résul­tats.

L’im­por­tant était de ne déclen­cher l’évè­ne­ment qu’a­près que l’uti­li­sa­teur ait finit d’écrire. Il fallait donc déter­mi­ner le meilleur délai entre la frappe du dernier carac­tère et le lance­ment de la recherche.

Des études sur la dacty­lo­gra­phie évoquent la vitesse en mots par minutes. C’est d’ailleurs ce type d’études qui ont permis la créa­tion des claviers que nous connais­sons aujourd’­hui. Et rien de plus simple que de conver­tir un nombre de mots en nombre de carac­tères. Encore fallait-il dispo­ser de résul­tats actuels utili­sables.

Grâce à quelques recherches précises, et je trou­vais deux ressources inté­res­santes :

  1. Quelqu’un s’est posé la ques­tion de « En combien de temps puis-je apprendre à tapper 100mots/minute ». L’in­for­ma­tion qui nous inté­resse ici, c’est le nombre de mots/minute qu’il pouvait écrire initia­le­ment.
  2. Un utili­sa­teur d’un forum de litté­ra­ture s’est demandé quelle était la longueur moyenne des mots en français. Et d’autres membres ont eu la gentillesse de répondre à sa ques­tion en lui four­nis­sant des données.

Nous savions donc que :

  • la vitesse moyenne de frappe était de 45mots/minute (valeur amoin­drie ici)
  • la longueur moyenne d’un mot était de 5signes/mot

Donc nous pouvions faire le calcul suivant :

Soit `mpm` le nombre de mots par minute (=45),
     `spm` le nombre de signes par mot (=5),
     `sps` le nombre de signes par seconde (à déterminer)
     `dms` le délai entre deux signes (en millisecondes)

sps = mpm * spm  / 60;
    = 45 * 5 / 60
    = 3.75

dms = 1000 / sps
    = 1000 / 3.75
    ≃ 266.66

Le délais opti­mal avant le lance­ment de la recherche doit par consé­quent tour­ner aux alen­tours des 266ms.

On obtient alors un résul­tat plus précis que ce que nous pouvions trou­ver aupa­ra­vant. Ce résul­tat est tel que la latence n’est aujourd’­hui quasi­ment plus ressen­tie, si ce n’est entre le dernier carac­tère et l’af­fi­chage du résul­tat. Le délai est d’ailleurs perçu comme court.

Critiques de la solu­tion

Il est bien évident que par manque de temps et de moyens, ces résul­tats sont haute­ment critiquables. En effet, il nous faut prendre en consi­dé­ra­tion plusieurs choses :

  • Les sources des infor­ma­tions dont je dispo­sais ne sont pas véri­fiées;
  • Le critère de la langue n’est pas pris en compte : j’ai ici utilisé un nombre de mots par minutes en anglais, et un nombre de signes par mots en français;
  • Aucune de ces deux infor­ma­tions ne sont issues de mes propres utili­sa­teurs, or la vitesse de frappe moyenne ne sera pas forcé­ment la même pour tous;
  • Le support de frappe (type de clavier : AZERTY, QWERTY, BEPO, physique, virtuel, … ?) n’est pas non plus spéci­fié;
  • Nous sommes ici dans le cadre d’une recherche, et non de la saisie conti­nue de texte. Par consé­quent nous igno­rons l’in­fluence de la tâche sur la vitesse de frappe.

On obtient cepen­dant un résul­tat rela­ti­ve­ment correct. On peut par consé­quent consi­dé­rer que les données issues de la litté­ra­ture et de sources approxi­ma­tives apportent une solu­tion alter­na­tive appli­cable par fortes contraintes.

Pour des résul­tats plus précis et spéci­fiques à ce projet, il nous faudra mettre en place un système de tracking du délais entre deux carac­tères saisis. Ces infor­ma­tions nous permet­trons alors d’ajus­ter notre moyenne pour des résul­tats plus précis et spéci­fiques à ce système de recherche.

Que peut-on en conclure ?

Nous pouvons tirer trois conclu­sions de cette étude de cas :

  • Il est impor­tant de se poser les bonnes ques­tions, et d’adop­ter le point de vue de l’uti­li­sa­teur;
  • La vali­dité des données à dispo­si­tion est parti­cu­liè­re­ment impor­tante et il est primor­dial de détec­ter l’in­fluence des variables;
  • Des déve­lop­peurs n’ayant aucun moyen de faire des études utili­sa­teurs peuvent tout de même s’ap­puyer à minima sur la litté­ra­ture afin de répondre à des problé­ma­tiques.
Sébastien ALEXANDRE