Je n'ai pas d'exemples à citer. En vérité, beaucoup de ces écrans peuvent être difficiles à trouver sur le web pour la simple raison que la plupart d'entre eux ont tendance à être "moches". Ces types d'écrans sont rarement beaux.
Je peux vous donner quelques conseils, grâce à ma longue expérience de travail avec ces choses.
-
Cohérence. Faites en sorte que tout "fonctionne de la même façon", et fonctionne de la même façon tout le temps. En gros, vous devez pouvoir effectuer votre saisie en regardant le formulaire, et non l'écran. Tous ces clignotements, sous-totaux et couleurs sont agréables après la saisie du formulaire, mais pas pendant la saisie elle-même. Dans ce cas, vous avez essentiellement besoin d'alertes audio pour leur faire savoir que "quelque chose ne va pas". Le scénario classique "ticky-ticky-ticky-ticky-beep-beep-beep-beep" lorsque l'utilisateur découvre qu'il s'est trompé de champ 4 fois en arrière. Les utilisateurs ne sont pas tout à fait aveugles, mais ils ne vont pas regarder votre écran. Les données sont sur le formulaire.
-
Il vaut mieux travailler de manière modérée et les arrêter en cas d'ERREURS plutôt que de les laisser continuer. Pour les grands formulaires, il est très difficile de scanner toutes ces informations et de rechercher les erreurs après coup. Arrêtez-les lorsqu'ils se trompent afin qu'ils puissent corriger leur erreur et aller de l'avant plutôt que de revenir la corriger à la fin. Plus il y a de règles de gestion, de validation et d'application sur le formulaire, mieux c'est. Des fenêtres contextuelles, des alertes, des sélecteurs, si cela nécessite leur attention, des modales. Ils ne travaillent pas avec de l'argile ici. Ils ne sont pas en train d'écrire le grand roman américain ou de modéliser l'économie mondiale.
-
Résumez les résultats des contrôles ponctuels. Par exemple, lorsqu'ils saisissent une commande, ils devraient pouvoir consulter le total de la commande et le nombre de postes pour voir s'ils ont saisi la commande "correctement", comme une sorte de somme de contrôle, plutôt que de devoir parcourir leur saisie champ par champ. La plupart des flux de travail comportent une phase inévitable de vérification croisée, au cours de laquelle les utilisateurs vérifient les données saisies, mais cette phase devrait avoir lieu après la "saisie brute" des données. Les gens travaillent plus vite lorsqu'ils sont en mode "saisie groupée" plutôt que de vérifier chaque donnée, à chaque fois qu'ils la saisissent. Cela casse leur rythme. Facilitez la détection et la correction des exceptions une fois la validation et la saisie de base effectuées. Si certains champs sont plus importants que d'autres (et vous savez lesquels), les mettre en évidence à l'écran ET sur le formulaire papier fait des merveilles.
Si les formulaires sont bien conçus (tant les formulaires informatiques que les formulaires papier), les erreurs devraient être difficiles à saisir (comme le mauvais client, le mauvais article, etc.). Vous pouvez avoir une erreur de frappe dans certaines notes ou instructions spéciales, mais pas partout ailleurs. S'ils se trompent dans la saisie d'un article ou d'un montant, il y a de fortes chances que le total de la commande ne soit pas correct, et le simple total de contrôle les aidera à le détecter.
-
Je reviens à la "cohérence", s'assurer que les choses comme les ramasseurs et autres fonctionnent de la même manière. Essayez de réduire au minimum les fonctions spéciales, car cela simplifie la formation et permet aux utilisateurs de se concentrer sur leur travail.
-
Les raccourcis clavier et la navigation sont une nécessité, pas une option. Les zones de détail (c'est-à-dire les structures de table) peuvent constituer un véritable point sensible. Vous pouvez avoir besoin d'un raccourci pour entrer et sortir des structures de tableau. Vous avez peut-être vu beaucoup d'exemples où vous pouvez "tabuler" dans le tableau, mais pas en sortir. Disposez d'une touche "méta-tab" dédiée pour entrer et sortir des sections. Il ne faut pas utiliser la souris pour sortir d'une section.
-
Disposer d'un seul raccourci clavier pour les sélecteurs. Idéalement, ils n'auront pas à les utiliser trop souvent. Peut-être pour la recherche de clients, la plupart des autres codes seront inévitablement mémorisés ou seront saisis sur le formulaire de saisie. Rendez les sélecteurs filtrables.
-
Le défilement est le diable. Le défilement est le mal. Pas de défilement ! La pagination est plus efficace que le défilement, car les "champs ne bougent pas", ils sont toujours "au même endroit" sur l'écran. Combien de fois avez-vous fait "défiler" et dû chercher à reprendre "où vous aviez commencé" avant le défilement pour retrouver le contexte. Même pour les listes de sélection, la pagination fonctionne très bien car le changement de page permet aux utilisateurs de savoir qu'ils ont réellement "fait quelque chose" visuellement. Souvent, vous faites défiler une ligne et vous vous dites : "J'ai vraiment fait quelque chose ?". Le défilement d'une seule ligne peut être trop subtil. Pour les grands formulaires de saisie, les pages multiples sont plus efficaces que les longs traités défilants, et ce tous les jours de la semaine. Si vos formulaires sont aussi volumineux, assurez-vous que vous disposez d'un raccourci clavier pour avancer et reculer dans le formulaire, et veillez à ce que chaque page contienne des informations contextuelles (nom du client, numéro de commande, etc.).
-
L'interrogation robuste. La "requête par l'exemple", comme on l'appelle, est l'un des meilleurs mécanismes (c'est-à-dire qu'ils remplissent le formulaire "ce qu'ils savent" et les formulaires reviennent). Les gens ont besoin de trouver des données selon des critères fous, si presque tous les champs sont interrogeables, cela leur permet de le faire sans que vous ayez à deviner ce dont ils auront besoin ou non. Informix 4GL disposait d'un système QBE spectaculaire ( > 04/01/09 pour les dates après le 1er avril 2009, 12345|23456 pour les codes articles 12345 ou 23456). Une bonne expression QBE ne sera très probablement pas validée dans un champ typique, c'est un cas spécial. (C'est pourquoi vous voyez rarement QBE aujourd'hui, cela demande trop de travail - mais c'est OH si agréable).
-
Rappelez-vous, les utilisateurs ne savent pas POURQUOI o COMMENT ils font des choses, ils savent seulement QUOI à faire. Ils savent "quand je veux faire A, j'appuie sur la touche Y " ils ne savent pas POURQUOI c'est Y, où se trouve Y, les touches X et Z pourraient faire des choses similaires à A parce qu'elles sont regroupées. Non, ils ne connaissent pas votre taxonomie de commande. Ils ne connaissent pas vos abstractions. Ils savent que pour faire A, il faut taper Y . Vous voulez mettre un mot en gras ? Tapez Ctrl - B . Peut-être Ctrl - I pour mettre un mot en italique est évident pour vous grâce au moyen mnémotechnique, il ne l'est pas pour la plupart des utilisateurs. Peut-être que le Ctrl - B y Ctrl - I sont sur le Format menu, joliment groupé. Ça n'a pas d'importance. Ctrl - B == Gras, comment faire pour l'Italique ?
L'inconvénient de ces interfaces est la formation. Il faut effectivement une formation pour pouvoir les utiliser. Mais, en vérité, pour toute entreprise raisonnablement complexe, l'utilisateur aura de toute façon besoin d'une formation sur bien plus que le simple processus de saisie. L'écran de saisie ne va pas lui apprendre les politiques et les règles de l'entreprise, etc. Vous pouvez les faire respecter dans l'application, mais l'utilisateur devra de toute façon les connaître par lui-même.
Mais ce n'est pas grave, car à long terme, c'est tout simplement plus efficace. Il s'agit ici d'obtenir efficacement les données de l'utilisateur et de les lui présenter de manière cohérente. Je ne dirai pas "logique", car si la logique est la logique, elle n'est pas forcément celle de l'utilisateur. Donc, vous pouvez être logique si vous voulez, appelez ça comme vous voulez, mais soyez cohérent avec vos utilisateurs.
Autre anecdote, nous avions l'habitude de 10 données clés de retour. Il s'agissait généralement de listes de chiffres, comme un code article et une quantité. Pour nos besoins, il est plus rapide de demander aux utilisateurs de saisir ces données deux fois de suite que n'importe quoi d'autre. Cela permet de détecter les erreurs de frappe, les transpositions, etc. Combiné avec les sommes de contrôle par lot, la saisie est d'autant plus rapide. Ces personnes ne regardaient les écrans que lorsqu'elles commençaient, lorsqu'elles terminaient et lorsqu'elles obtenaient une erreur.
Enfin, quoi qu'il en soit, vos écrans et procédures WILL le changement. Quel que soit le formulaire que vous utilisez cette année, il changera l'année prochaine. C'est la réalité, alors, pour info, préparez-vous à cela.
Bonne chance avec votre projet.
