Bons exemples de conception d'interface graphique pour les applications de saisie de données lourde (CRUD) orientées métier

Question

Où puis-je trouver des exemples d'entreprises - y de logiciels très bien produits qui ont:

Bonne utilisation cohérente des raccourcis clavier.
Bonne navigation au clavier
Validation de formulaire standardisée
Utilisation standardisée de lookup / search screens. (L'utilisateur reçoit un ID de client mais ne le sait pas mais peut le rechercher dans une fenêtre contextuelle qui le renvoie.)
Convivialité standard/conventions LaF

Il serait agréable de voir des exemples allant de simples écrans CRUD à des interfaces utilisateur graphiques très complexes orientées processus pour des applications telles que CRM/ERP/évaluation financière/des risques, etc. -.

Will Hartung · Accepted Answer

Je n'ai aucun exemple à citer. En vérité, beaucoup de ces écrans peuvent être difficiles à trouver sur le Web en raison du simple fait que la plupart d'entre eux ont tendance à être "laids". Ces types d'écrans sont rarement jolis.

Je peux offrir quelques conseils, issus de la longue histoire de travail avec ces choses.

Cohérence. Faites en sorte que tout fonctionne "de la même manière" et travaillez de la même manière tout le temps. Fondamentalement, vous devriez être en mesure de faire votre entrée en regardant le formulaire, pas l'écran. Tous ces flashes, sous-totaux et couleurs sont sympas après avoir saisi le formulaire, mais pas pendant la saisie. Il vous faut essentiellement des alertes audio pour leur faire savoir que "quelque chose ne va pas". Le scénario classique "ticky-ticky-ticky-ticky-bip-bip-bip-bip-bip" lorsque l'utilisateur découvre qu'il a saisi un champ incorrect avec 4 champs en retour. Les utilisateurs ne sont pas tout à fait aveugles, mais ils ne vont pas regarder votre écran. Les données sont sur le formulaire.
Il est préférable de travailler de manière modale et de les arrêter pour les erreurs plutôt que de les laisser continuer. Pour les formulaires volumineux, il est très difficile de numériser toutes ces informations et de rechercher les erreurs ultérieurement. Arrêtez-les quand ils ont tort pour qu'ils puissent le réparer et aller de l'avant plutôt que de revenir le réparer à la fin. Plus vous pourrez avoir de règles métier, de validation et d’application sur le formulaire, mieux ce sera. Popups, alertes, pickers, si cela a besoin de leur attention, modal modal. Ils ne travaillent pas avec de l'argile ici. Ils ne sont pas en train de créer le grand roman américain ni de modéliser l’économie mondiale.
Résumez les résultats des contrôles inopinés. Par exemple, en saisissant une commande, ils devraient pouvoir consulter le total de la commande et le nombre d'éléments de campagne pour voir s'ils ont reçu la commande "correctement". de la somme de contrôle plutôt que d'avoir à analyser leur champ de saisie par champ. La plupart des flux de travail comportent une phase inévitable de vérification croisée, où ils vérifient les données saisies, mais cela devrait se faire après la "saisie brute" des données. Les gens travaillent plus vite quand ils sont en mode "entrée en bloc" plutôt que de vérifier chacun d'eux à chaque fois qu'ils le saisissent. Cela brise leur rythme. Facilitez la détection et la correction des exceptions après la validation de base et la saisie. Si certains champs sont plus importants que d'autres (et que vous connaissez ceux qui le sont), les surligner visuellement à l'écran ET sur le formulaire papier fait des merveilles.

Si les formulaires et autres sont bien conçus (les formulaires informatiques et les formulaires de saisie papier), les erreurs devraient être difficiles à saisir (comme le mauvais client, le mauvais article, etc.). Vous pourriez avoir une faute de frappe dans certaines notes ou instructions spéciales, mais pas autant partout ailleurs. S'ils saisissent mal un article ou un montant, les chances sont que la commande ne sera pas totalisée correctement, donc la simple somme de contrôle les aidera à l'attraper.
Pour en revenir à la "cohérence", assurez-vous que des éléments tels que les sélecteurs et autres fonctionnent de la même manière. Essayez de limiter les fonctions spéciales au minimum, car cela simplifie la formation et permet aux utilisateurs de simplement "passer" à leur compte. travail.
Les raccourcis clavier et la navigation sont une nécessité et non une option. Un réel problème peut être ici les zones de détail (c'est-à-dire les structures de table). Vous aurez peut-être besoin d'un raccourci pour entrer et sortir des strcutures de la table. Vous avez peut-être vu beaucoup d'exemples dans lesquels vous pouvez "insérer" dans la table, mais pas pour revenir en arrière. Avoir une clé "méta-onglet" dédiée pour entrer et sortir des sections. Demander à la souris de naviguer dans une section est un non non.
Ayez une seule touche de raccourci pour les sélecteurs. Idéalement, ils n'auront pas à les utiliser trop souvent. Peut-être que pour rechercher le client, la plupart des autres codes sont inévitablement mémorisés ou seront saisis sur le formulaire de saisie. Rendez les cueilleurs filtrables.
Le défilement est le diable. Le défilement est le mal. Aucun défilement! Pagayer mieux 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 avez dû chercher pour ramasser "où vous avez commencé" avant le défilement pour regagner le contexte. Même pour les listes de sélection, la pagination fonctionne très bien, car le changement de page leur permet de savoir qu’elles ont "fait quelque chose" visuellement. Plusieurs fois, vous faites défiler une ligne et "gee ai-je vraiment?" Le défilement d'une seule ligne peut être trop subtil. Pour les formulaires de grande taille, plusieurs pages font battre des traités longs tous les jours de la semaine. Si vos formulaires sont aussi volumineux, assurez-vous de disposer d'une touche de raccourci pour avancer et revenir en arrière dans le formulaire et assurez-vous qu'il y a des informations de contexte sur chaque page (nom du client, numéro de commande, peu importe ... en-tête simple).
Requête robuste. "Requête par exemple" est l’un des meilleurs mécanismes (c’est-à-dire qu’ils remplissent le formulaire "ce qu’ils savent" et que les formulaires reviennent). Les gens ont besoin de trouver des données uniquement selon des critères loufoques. Si la plupart des champs sont interrogeables, cela leur permet de le faire sans que vous ne deviniez en second lieu ce dont ils auront besoin ou non. Auparavant, Informix 4GL disposait d'un système QBE spectaculaire (> 04/01/09 pour les dates postérieures au 1er avril 2009, 12345|23456 pour les codes d'article 12345 ou 23456). Une bonne expression QBE ne sera 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 tellement beau.)
Rappelez-vous, les utilisateurs ne savent pas POURQUOI ou COMMENT ils font des choses, ils ne savent que CE QUE doit faire. Ils savent " quand je veux faire A, j'appuie sur la touche Y" ils ne savent pas POURQUOI c'est Y, où Y est situé, les touches X et Z peuvent faire la même chose que A car elles sont regroupées. Non, elles ne connaissent pas votre taxonomie de commande. Ils ne connaissent pas vos abstractions. Ils savent faire A, Y. Voulez-vous un mot en gras? Type Ctrl-B. Peut être Ctrl-I mettre en italique un mot vous semble évident à cause du code mnémonique, ce n’est pas le cas pour la plupart des utilisateurs. Peut-être le Ctrl-B et Ctrl-I sont dans le menu Format, joliment regroupés. Peu importe Ctrl-B == Gras, comment je fais en italique?

L'inconvénient de ces interfaces est la formation. Ils suivent une formation pour pouvoir être utilisés. Mais, en réalité, pour toute entreprise raisonnablement compliquée, l'utilisateur aura de toute façon besoin d'une formation beaucoup plus poussée que le processus de saisie. L'écran de saisie ne leur apprend pas les stratégies commerciales, les règles commerciales, etc. Vous pouvez les appliquer dans l'application, mais l'utilisateur devra quand même les connaître par lui-même.

Mais ce n'est pas grave, car à long terme, c'est tout simplement plus efficace. Le jeu consiste à obtenir efficacement les données de l'utilisateur et à les lui présenter de manière cohérente. Je ne dirai pas "logique", car si la logique peut être logique, ce n'est peut-être pas la logique des utilisateurs. Vous pouvez donc être logique si vous voulez, appelez-le comme vous voulez, mais soyez cohérent avec vos utilisateurs.

Une autre anecdote, nous avions l'habitude de 10 données de retour clé. Cela avait tendance à être simplement des listes de nombre, comme un code d'article et une quantité. Pour nos besoins, il est plus rapide de simplement demander aux utilisateurs de saisir ces données deux fois de suite. Il capture les fautes de frappe, les transpositions, etc. Combiné à des sommes de contrôle par lots, la saisie est beaucoup plus rapide. Ces gars-là ont seulement regardé les écrans quand ils ont commencé, quand ils ont fini et s'ils ont eu une erreur.

Enfin, quoi qu’il en soit, vos écrans et procédures VONT changer. Quelle que soit la forme que vous utilisez cette année, elle changera l’année prochaine. C'est juste la réalité, alors, FYI, sois prêt pour cela.

Bonne chance pour votre projet.

superUntitled · Answer

Je suis fan de la http://www.37signals.com/ suite. Je trouve que leurs formes et leurs interfaces graphiques sont bien pensées.

linjunhalida · Answer

Vous savez, il y a Openerp que vous pouvez obtenir programme, source, doc gratuitement.

ps: ce lien m'est OK, si vous ne pouvez pas l'ouvrir, recherchez openerp dans google.

James Anderson · Answer

J'en ai utilisé beaucoup - mais il est difficile de se souvenir d'une application spécifique, car de très bonnes interfaces utilisateur sont souvent très négligeables.

Je me souviens de beaucoup de mauvais. Quiconque s'acharne sur Lotus Notes n'a évidemment jamais utilisé d'applications basées sur des formulaires SAP ou Oracle.

Pour plus d’efficacité, je vous suggère de consulter l’ancienne application de réservation de billets d’avion SABRE. Deux lignes de texte sans espaces ni autre ponctuation

La première ligne du vol, la deuxième ligne, les détails de paiement, par exemple, réserveraient et paieraient un vol:

123109BA176Y 276.00GBPAM1122123412341234

les agents de voyages y ont été accoutumés et ont refusé pendant des années d’accepter le remplacement de l’interface utilisateur graphique de super duper windows allumant l’émulateur de terminal à écran vert. Je pense que les compagnies aériennes ne sont mortes que lorsque les compagnies aériennes ont adopté le code à trois lettres et le numéro de vol à quatre chiffres.