Les interfaces web de saisie rapide

La désynchronisation des activités est l’essence même de Ajax, c’est le « A » dans « Ajax ». Ces derniers temps, on commence a utiliser le terme « Ajax » pour dire « XMLHttpRequest » ce qui était prévisible : personne ne peux dire « XMLHttpRequest » sans attraper le hoquet.

Comme vous le savez déjà nous sommes en train de développer un Progiciel de Gestion Intégré (PGI) pour un grossiste en pharmaceutiques en Tunisie. L’activité de grossiste pharmaceutique est très particulière pour deux raisons :

  1. le secteur pharmaceutique est relativement ancien et bien développé ce qui fait qu’il y a des « traditions »
  2. le secteur pharmaceutique est très régulé pour des raisons de santé publique évidents

L’une des particularités du secteur c’est le traitement d’un nombre de commandes élevé dans une plage horaire très restreinte. Pour vous donner un ordre d’idée, ici, on traite à peu prés 900 commandes par jour dont 400 entre 11h et 13h. Il faut donc une logistique adéquate.

L’une des difficultés évidentes que nous avons identifiée depuis le début de projet, c’est l’interface de prise de commande qui allait être utilisée par les commerciaux. Les commerciaux sont généralement très peu connaisseurs en informatique : ils sont là pour appeler les clients au téléphone et saisir leurs commande le plus rapidement possible, par conséquent le niveau d’instruction est secondaire. Cela dit, vu la nature de leurs activité, ils maîtrisent parfaitement le logiciel qu’ils utilisent maintenant. Ils ont même développé des réflexes et des automatismes liés aux touches de fonction.

Quand nous avons présenté l’interface de prise de commande la première fois, nos interlocuteurs avaient des doutes. Pourtant la nouvelle interface etait loin devant l’ancienne en terme de fonctionnalités et même en terme d’ergonomie. Nous avons donc corrigé quelques détails par-ci par-là et donné l’application aux utilisateurs finaux pour la tester.

Le verdict fut unanime : la recherche des articles est trop lente. Quand vous cherchez un article dans les 7991 références, notre système met 300ms à répondre. Ce qui était beaucoup trop. Après avoir observé pendant une heure le plus expérimenté des commerciaux travailler sur l’ancienne application, j’ai été convaincu.

Après avoir étudié le problème et essayé différentes solutions, il n’y avait rien à faire : toute l’interface était à refaire. La seule solution était de grignoter sur les 300ms et pour cela il fallait reconcevoir l’interface.

La saisie d’une ligne de commande se passe comme suit :

  1. L’utilisateur saisi les premières lettres de l’article recherché
  2. Le système lui présente une liste d’articles qui correspondent à sa recherche
  3. Il sélectionne l’article qu’il veut
  4. Il saisi la quantité commandée
  5. Il recommence

Pour bien faire son boulot l’utilisateur a aussi besoin de feedback. Il a besoin de savoir quelle est la quantité disponible en stock et d’être notifié en cas d’erreur (article mal saisi, etc…). Dans le système tel qu’il était conçu, il y avait une seule requête, ce qui nous avait semblé être un bon choix quand on avait conçu l’interface. La logique étant que 1 seule requête (Ajax) prend toujours moins de temps que plusieurs. Mais à y regarder de plus prés, l’activité pour laquelle on conçoit l’interface a une particularité qu’on peut exploiter : quand l’utilisateur veut vraiment (vraiment!) aller rapidement, il ne regarde pas la quantité disponible, il n’a pas le temps.

Ce que nous avons fait c’est séparer la consultation de la disponibilté en stock de la recherche d’article. En fesant cela nous avons gagné du temps doublement :

  • d’abord nous n’affichons la quantité disponible que pour l’article séléctionné et non plus pour tous les articles retournés par la recherche, ce qui décharge le serveur.
  • ensuite nous avons désynchronisé cette activité (remarquez les barres de synchro dans le diagramme) ce qui fait qu’elle se fait maintenant en parallèle avec la saisie de la quantité et donc ne prends plus de temps.

Cette nouvelle conception nous a permis de faire tomber la réponse du système à 30ms, et de réduire la responsivité perçue par l’utilisateur par – a vue de nez – un facteur 100. Notez aussi que nous n’avons pas fait que désynchroniser la consultation de la disponibilité en stock, nous avons aussi désynchronisé tous les autres feedbacks du système y compris l’affichage de la ligne saisie elle même (remarquez les 3 points de fin d’activité).

La désynchronisation des activités est l’essence même de Ajax, c’est le « A » dans « Ajax ». Ces derniers temps, on commence a utiliser le terme « Ajax » pour dire « XMLHttpRequest » ce qui était prévisible : personne ne peux dire « XMLHttpRequest » sans attraper le hoquet. Certains disent même qu’on fait tout et n’importe quoi avec Ajax et en fait ils veulent dire qu’on fait tout et n’importe quoi avec « XMLHttpRequest ». Je ne le pense pas. Je pense que « XMLHttpRequest » ne peux pas faire de mal, même s’il est utilisé n’importe comment.

Nous sommes actuellement en train de tester la nouvelle interface avec les utilisateurs et vous savez quoi? Aucun feedback. Ils disent rien les utilisateurs. Ils utilisent l’application comme si tout allait de soi. Comme s’ils l’utilisaient depuis toujours. Et je me dis que faire des logiciels pour entreprise a cette différence par rapport à faire des applications grands public : l’efficacité prime sur l’effet. On n’est pas la pour faire du buzz, on ne veut impressionner personne. Et effectivement les utilisateurs ne sont pas impressionnés … mais ils ne se plaignent pas. Et c’est ça notre récompense.

4 comments so far

  1. Ahmed JERBI on

    Est ce que tu as pensé à une interface auto enrichie, je prends ton exemple de saisi de commande, est ce que tu as pensé à afficher les articles non pas par les premières lettres de son libellé mais suivant la manière dont l’utilisateur le saisi.

    Launchy un keystroke que j’adore propose cette fonctionnalité si je tape « il » il me propose d’abord les applications avec « il » puis vu que je click plusieurs fois sur « illustrator », il me le présente directement.

    je ne sais pas si j’ai su passé mon idée🙂
    bonne continuation,

    PS: je travaille aussi sur logiciel de gestion pour industrie si tu veux qu’on partage nos expériences je suis dispo🙂

  2. slim on

    Le cas d’utilisation ici est un peu différent. L’une des erreurs que nous avons faite à la première conception c’est justement de faire une interface utilisateur trop sophistiquée (« intelligente »). En fait les utilisateurs sont habitués saisir : « effer » puis 4 fois FLECHE BAS pour trouver « EFFERALGAN CODEINE ». Et ils font ça en 700ms (!!!). En fait ce dont ils ont besoin c’est un CLI web – interface dos comme ils disent – ce que nous avons fait et c’était une réussite totale. Ils utilisent l’interface avec beaucoup de satisfaction depuis 6 mois.

    Je suis ravi de partager les expériences avec toi. Je suis ton blog. Blog un peux plus sur ton boulot😉

  3. Trinoo on

    Je suis vraiment étonné qu’ une recherche d’un article dans les 7991 références demande 700ms, c’est vraiment beaucoups.

    De même je suis étonné que le fait de ne plus afficher la quantité des produits des resultats de recherche ainsi que la désynchro sur la quantité du produit selectionné fait chuter la réponse par un facteur de 10 !!, il s’agit uniquement de 8000 références quand même!!!

    Il faut peut-être tester la réactiviter des appels AJAX sur different type de navigateur, on peut avoir des surprises à ce niveau là.

    et faire des tests sur la base de données avec des outils genre MySQLSlap ou bien SuperSmack pour trouver les goulot d’étranglement dans la structure de la base. (dans le cas ou c’est du MySQL)

    Voir de même si la fonction de CACHE sous MySQL est activée ou pas. Et si nécessaire essayer d’utilise InnoDB à la Place de MyIsam comme moteur sous MySQL.

    L’ergonomie est un des aspect qui m’interesse le plus dans le développement. Observer les manips des utilisateurs avec leurs outils est une expérience fort intéressante et révélatrice qui peut nous surprendre et nous remettre en cause sur nos idées mal fondée.

  4. slim on

    En fait il y avait un petit menu de recherche qui apparaissait dés qu’on commençait a écrire dans le champ texte (script.aculo.us). Et la requète qui durait 700ms calculait l’état du stock et l’affichait pour tous les articles affichés dans le menu. C’est pour cela que cela durait aussi longtemps et que nous avons reconcu l’interface.

    Généralement MyIsam est beaucoup plus rapide que InnoDB, en fait notre base de production est hétérogène : les tables qui sont utilisée d’une manière transactionelle sont Innodb, les autres sont MyIsam.

    P.S. Et tu a raison même comme ça 700ms c’est beaucoup en fait c’est 300ms😉 je viens de relire l’article


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :