Validation d'une "application" Préférences / Configuration
J'ai une "application" de configuration/préférences système que je conçois dans le cadre d'une application plus grande basée sur un navigateur. Notre application globale a des "applications" (comme une application de développement, une application de gestion des utilisateurs, une application de catalogue, etc.) dont celle-ci.
Cette application de configuration système est (en arrière-plan) un objet de configuration géant divisé en plusieurs enfants logiques, chacun étant représenté par un menu de gauche (exemple: 'configuration générale', 'configuration de la base de données', etc.). Fondamentalement, chaque menu latéral contient une forme raisonnablement complexe (grilles, onglets, etc.) .
Il peut y avoir plusieurs de ces configurations, et l'utilisateur peut choisir lequel modifier en utilisant un menu déroulant en haut de la page (nommé "configurer").
Ma question est, quelle est la façon la plus logique/raisonnable/attendue de gérer l'enregistrement et la validation de cette application? Étant donné que l'API "save" est (derrière les scènes) universelles à l'ensemble du contenu de l'application?
Options que j'ai envisagées:
(1) enregistrer l'objet entier. Si l'utilisateur navigue dans les menus latéraux, lorsqu'ils quittent, leurs modifications sont conservées. Si les modifications ne sont pas valides, l'utilisateur est informé par avertissement, lorsqu'il appuie sur enregistrer, il est informé qu'il y a des erreurs de validation dans les onglets qui ne sont pas actuellement ouverts.
(2) enregistrer chaque "sous-objet" du menu latéral. Si l'utilisateur navigue dans les menus latéraux, il est informé que ses modifications seront effacées (s'il a effectué des modifications).
Nous validons normalement les champs lorsque l'utilisateur s'efface d'un champ, mais il peut également y avoir une validation côté serveur plus complexe.
* Remarque: ces menus latéraux sont utilisés dans d'autres applications de notre application, tout comme la barre "d'action" (où se trouve la sauvegarde, marquée en bleu ). Dans certaines applications, ils doivent clairement enregistrer avant de quitter le sous-menu.
Voici l'application:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Voici quelques recommandations liées à l'enregistrement et à la validation qui aideront les utilisateurs dans un scénario complexe comme celui-ci.
- Les commentaires sur les erreurs doivent être affichés le plus rapidement possible. Si vous pouvez valider le côté client, faites-le. J'apprécie que certaines erreurs ne soient détectables que du côté serveur (c'est bien), mais ne faites pas attendre un utilisateur jusqu'à ce que le bouton Soumettre soit pressé pour obtenir des commentaires sur tous les problèmes. Le faire en ligne dans la mesure du possible aidera les utilisateurs à traverser le processus plus rapidement.
- Les commentaires doivent être affichés aussi près que possible de l'erreur. C'est simple avec les erreurs de validation côté client où vous savez que l'utilisateur est sur le même écran que l'erreur. Cela devient un peu plus compliqué lorsque vous disposez de plusieurs écrans/sections différentes, et l'erreur n'est détectée que lorsque l'utilisateur clique sur Enregistrer. Je suggère d'aller dans la même direction que beaucoup d'IDE et d'afficher un panneau contenant une liste de problèmes. Cette liste fournit à l'utilisateur un aperçu de tous les problèmes et peut être consultable (c'est-à-dire qu'un utilisateur clique sur le problème pour accéder à la section/au champ pertinent) pour l'aider à les trouver et à les résoudre rapidement. Le panneau doit être facile à repérer (à côté de votre bouton d'enregistrement serait logique) et visible sur chaque écran.
- n utilisateur ne devrait pas perdre de travail en cas de problème. Si vous avez plusieurs écrans et qu'une sauvegarde échoue, vous devez vous assurer que tout le travail de l'utilisateur jusqu'à présent est conservé.
Pour faire les choses ci-dessus, vous aurez besoin d'un mécanisme pour enregistrer l'état des objets de configuration incomplets/incorrects. (Cela va quelque peu à l'encontre du paradigme du navigateur Web, qui est sans état.)