Le meilleur des logiciels est inutile si son fonctionnement n’est pas compris de ses utilisateurs. Le défi se révèle fort complexe. Comment rendre un logiciel facilement compréhensible, même lorsqu’il décrit un domaine complexe ? Cette question a amené de nombreuses réponses de la part des informaticiens.
La première réponse est de faire que les interfaces d’entrées et de sorties de l’application se décrivent elles-mêmes. Des écrans simples et qui décrivent le domaine. La réponse semble naturelle. Mais cette situation n’est pas évidente. Si vous décrivez trop vos écrans, l’utilisateur lira-t-il réellement tous les éléments pour pouvoir utiliser votre logiciel ? Lisez-vous les petits caractères avant d’autoriser les cookies des sites webs ? Non.
De plus, cette réponse est valable aujourd’hui pour une application affichée sur un grand écran. Mais, il y a 30 ans, sur des écrans aux définitions faméliques, ce n’était pas possible. À l’époque, la solution appliquée était la documentation utilisateur. Il s’agissait d’un ouvrage de plusieurs centaines de pages qui accompagnait le logiciel et décrivait le logiciel, fonctionnalité par fonctionnalité.
Cela implique toutefois que les équipes de développement pensent à écrire cette bible. Quand on sait que la documentation est la première étape d’un projet qui est sacrifiée en cas de retard, les documentations utilisateurs ne sont pas toujours très claires. Afin de contrer cette difficulté, les éditeurs de logiciels ont proposé des hotlines pour répondre aux questions des utilisateurs perdus.
Devant les appels désespérés des utilisateurs, une nouvelle technologie a émergée : le RTFD. Les développeurs ne font pas forcément l’effort de se placer au niveau des utilisateurs. Ce n’est pas non plus leur métier et le temps passé à répondre aux questions est du temps en moins pour développer le logiciel. La réponse fuse alors, parfois injustement : “Lisez cette p***n de documentation ! (C’est écrit !)” Ou en anglais “Read This F***ing Doc”. RTFD.
Afin de ne pas épuiser leurs développeurs, les sociétés éditrices de logiciels ont mis en place des mesures. Ce seront des cellules spécialisées dans le support qui répondront aux utilisateurs perdus et, si nécessaire, feront remonter les remarques pertinentes aux développeurs. En principe, le développeur est le dernier échelon contacté en cas de difficulté insoluble. En principe 🙂
Avec l’évolution des technologies, il est devenu possible d’afficher plus d’informations sur un écran. L’augmentation de la définition et les nouveaux composants graphiques ont permis de repenser les applications. Pour un champ de saisie, en plus de son libellé, il est possible de définir un infobulle qui détaillera son rôle lorsque l’utilisateur le sélectionnera. Les documentations ont peu à peu disparues.
Enfin presque. En pratique, les documentations ont évolué. Elles s’intègrent dans l’application. C’est la touche ‘F1’ qui va ouvrir un écran de recherche vous demandant de poser votre question. Mais tout cela doit être pensé en amont par le concepteur et intégré dans le logiciel par le développeur. La technologie RTFD a évolué et a été complété par la technologie RTFS (“Read This F***ing Screen”, “Lisez ce p***n d’écran” en français).
Cela ne fait pas disparaître les équipes de support, mais des écrans plus détaillés facilitent la compréhension de l’utilisateur final, jusqu’à un certain point. Un paradoxe arrive alors. Si l’écran est trop détaillé, il peut rapidement devenir illisible. On demande donc aux concepteurs de définir des écrans plus simples. Mais cela ne marche pas non plus.
On ne peut simplifier l’implémentation du besoin de l’utilisateur final. Si son métier n’est pas correctement pris en compte dans l’application, il ne pourra pas toujours l’utiliser. Le concepteur doit donc arbitrer pour décrire les écrans de l’application finale. Des écrans simples mais complets. S’il y a trop d’écrans, l’utilisateur final perdra du temps. Les écrans doivent donc évoluer suivant les réponses de son utilisateur.
L’arbitrage des concepteurs est donc un exercice difficile. Aujourd’hui, il existe de nombreux composants graphiques qui permettent de proposer des interfaces évolutives, détaillées et facilement lisibles. Mais si le concepteur n’y pense pas, son application sera pénible pour l’utilisateur final. Et les développeurs énervés invoqueront la technologie RTFS face aux questions dont les réponses sont évidentes.
L’informatique est présent dans nos vies. Il en est de même pour la technologie RTFS. L’utilisateur qui se plaint des bugs a-t’il compris comment l’application fonctionne ? Le développeur qui râle contre les questions stupides a-t’il fait en sorte de rendre son application compréhensible ? Le défi est de taille …