J’ai commencé ma carrière en 1990 chez Apsylog, et depuis cette époque j’ai eu l’occasion de développer et de commercialiser des logiciels à destination des entreprises. Ces logiciels orientés gestion de données et traitement de flux ont évidemment évolué dans leurs destinations et les fonctions prises en charge, mais aussi dans l’approche qu’ils avaient de la relation avec l’utilisateur.
Voici une série de billets sur les évolutions marquantes de ces 30 dernières années autour des différents aspects de ces logiciels.
Une partie essentielle de la conception d’un logiciel est celle de l’écran de saisie des données : il arrive toujours un moment où il faut demander à l’utilisateur de saisir un ensemble de données avant de les traiter.
L’approche des éditeurs a fortement évolué pendant ces années, indépendamment des technologies disponibles, ce sont ces étapes que je vais essayer de retracer ici.
Au commencement fut donc :
Le formulaire
La première version de la saisie d’un ensemble de données consistait en un formulaire, suivi d’un traitement automatisé.
Le défaut principal était une saisie libre, sans contrôle de validité des données (date invraisemblable ou montant absurde) ni même d’intégrité référentielle (double saisie de valeurs proches).
L’ordre de saisie n’était pas contraint (date de fin avant la date début) , pouvant mener à une incohérence du résultat ou au mieux une re-saisie partielle ou complète du formulaire lors de l’échec du traitement .
La seule contre-mesure était la mise à disposition d’un manuel papier décrivant les données à saisir qui, suivi pas à pas, permettait d’atteindre l’objectif voulu. Éventuellement, la touche F1 offrait le même manuel dans sa version numérique, mais avant Windows et le multifenêtres, il fallait tout mémoriser avant de revenir à l’écran initial.
C’est là qu’est né :
L’assistant
Apparu avec Windows 95, l’assistant a pour but de diviser un processus en étapes simples, documentées et disposant d’un contrôle entre chaque étape.
Il permet de guider l’utilisateur, autorise les corrections et valide les saisies pas à pas.
Il remplace efficacement le couple formulaire/ documentation, mais présente l’inconvénient d’être très scripté et très peu souple : chaque écran est fixe et doit être décrit, et il accepte assez peu les possibilités de choix optionnels.
On est donc revenu à l’écran unique mais doté d’annexes :
Les onglets
Le haut de l’écran comporte les informations indispensables, et tous les éléments annexes sont regroupés par sujet dans des onglets, activables à la demande.
On peut ainsi faire tenir de nombreuses données dans un écran de taille réduite, voire cacher certains onglets.
Cela reste une solution d’actualité mais encore faut il que l’utilisateur pense à chercher dans les onglets.
Une variante consiste à remplacer les onglets par une série de boutons qui ouvrent des fenêtres pop-up, mais celle-ci est vite devenue obsolète, les navigateurs n’appréciant pas les pop-up, et les utilisateurs leur caractère bloquant.
Nous en sommes donc arrivés à :
Un écran dynamique
Le premier écran reste simple et ne présente que les éléments initialement nécessaires. Il évolue ensuite en fonction des saisies en rajoutant des éléments pour autoriser la soumission quand tout est valide.
Pour que cela reste lisible, les ajouts doivent se faire clairement, par groupes et vers le bas de l’écran dans la zone de visibilité de l’utilisateur.
Bien sûr, il ne faut pas abuser du nombre d’étapes d’ajout au risque de frustrer l’utilisateur, et éviter les zones vides en plaçant les blocs optionnels sur la partie droite de l’écran.
On obtient ainsi un écran simple d’approche mais permettant des saisies complexes.
Olivier Piochaud, PDG d’Apsynet
