Alternatives à la saisie / édition de données fortement basées sur Datagrid
Nous avons une base de logiciels bien établie ... c'est du côté daté ... et beaucoup de notre interface utilisateur repose sur de nombreux datagrids sur la même page/formulaire, etc. J'ai mentionné que je pense que cela rend notre application énormément non intuitif. Plutôt que de simplement me plaindre, j'essaie de solliciter des idées sur la façon de remplacer certains de ces formulaires destinés aux clients par des modèles plus intuitifs.
Mes problèmes avec ce type de modèle que nous avons établi jusqu'à présent sont les suivants:
- La corrélation entre les grilles elles-mêmes n'est pas toujours (la plupart du temps jamais) intuitive.
- De nouveaux enregistrements sont créés à l'aide de "dbnavigators", qui sont la petite barre de boutons gauche/droite/firstrecord/lastrecord/post/cancel, et reposent sur des éléments en place dans une grille avant que la grille suivante puisse ajouter un élément, etc.
- L'édition en ligne dans la grille de données semble toujours ajouter d'immenses couches de complexité
J'ai jeté des idées pour la navigation dirigée (assistants de base) vers des formulaires beaucoup plus contextuels avec des onglets ... par exemple, un formulaire de contexte client et un onglet pour les commandes dans lequel vous pouvez voir. Un bouton d'ajout pour ajouter une commande, etc.
Tout serait mieux cependant :(
La grille de données est logique lorsque vous traitez des entrées ou des modifications d'un grand nombre d'éléments à la fois.
L'une des raisons pour lesquelles cette mise en page semble compliquée est qu'il y a 4 grilles de modules sur la page. L'utilisateur doit-il traiter/référencer des informations dans les autres grilles lorsqu'il affiche ou modifie une seule grille?
Un moyen de vous faciliter la tâche pourrait être de n'afficher que les informations pertinentes. En d'autres termes, cachez ce qui n'est pas nécessaire dans un contexte donné.
Disons que lorsqu'un utilisateur modifie, il n'a pas besoin de voir les informations des autres grilles. Ensuite, envisagez peut-être de déplacer l'édition sur une page distincte ou de créer un mode d'édition pour réduire l'encombrement de l'écran.
Il n'y a vraiment pas de solution unique. Vous devrez donc regarder ce que l'utilisateur doit faire sur un écran donné pour déterminer ce que vous pouvez faire pour l'améliorer.
Le modèle d'édition de la "grille de données" n'est pas mauvais en soi. Le simple remplacement d'un motif par un autre pourrait
- Perturbe gravement les utilisateurs qui sont devenus efficaces avec le modèle actuel
- Introduisez un autre ensemble (ou même le même ensemble) de problèmes. Il n'y a aucune garantie qu'un nouveau modèle a une meilleure UX
Les problèmes que vous mentionnez peuvent être dus à des problèmes visuels ou d'implémentation - et non au "modèle de grille de données" en soi. par exemple. Voici des solutions potentielles aux problèmes tout en gardant
Les problèmes 1 et 2 affichent des types de données plus riches avec une modification sur place pour réduire les grilles déconnectées. De meilleurs visuels.
Problème 3 - certains modèles UX bien établis pour cela. Conception d'interfaces Web: principes et modèles pour des interactions riches par Bill Scott, Theresa Neil est bien considéré.
Le guide UX clé consiste à rechercher les problèmes des utilisateurs et à les résoudre. Travailler même une critique experte d'un modèle UX est connu pour ne pas fournir les meilleurs résultats. par exemple. une interface utilisateur peu intuitive pourrait nécessiter quelques ajustements visuels, pas un re-développement complet.