Conception d'un ruban fluide pour une application CRUD
Je travaille sur la conception d'une UX de style Fluent ("Ribbon") pour une application CRUD fonctionnant sur une base de données.
Il existe de nombreuses informations sur la conception d'un ruban pour les applications basées sur des documents. Les directives Microsoft spécifient même des onglets et des groupes standard.
Cependant, ces groupes standard ne semblent pas convenir parfaitement aux situations non documentaires. La commande "Rechercher", par exemple, doit se trouver dans un groupe "Edition":
Tout à fait pertinent pour rechercher dans un document, mais pas pour rechercher pour un enregistrement.
Quelles ressources et/ou exemples existe-t-il pour utiliser le ruban pour des applications non documentaires?
Mis à jour le 27/9: Oui, je suis sûr qu'un ruban est approprié pour l'application que je développe. Ce n'est pas axé sur les documents, mais ce n'est pas non plus du CRUD pur - c'est une application complexe avec beaucoup de comportement professionnel. Il sera plus facile pour moi d'organiser un atelier sur l'organisation du ruban si je peux fournir des conseils à l'avance - j'espère donc avoir des réponses à ma question initiale sur les ressources et les exemples.
Je pense que le meilleur exemple que vous pourriez regarder est MS Access. Toutes les commandes CRUD sont dans un groupe Records et la commande Find est dans le groupe Find!
Le ruban a été conçu pour les programmes avec beaucoup de commandes, l'application CRUD a tendance à n'avoir que quelques commandes, alors peut-être que le ruban n'est pas la bonne interface utilisateur pour commencer.
Vous pouvez faire ce que MS a fait lors de la conception du ruban, prendre autant de personnes que vous le pouvez (qui connaissent le domaine, de préférence des clients), puis donner une liste d'onglets/groupes et quelques commandes et leur laisser choisir l'emplacement le plus logique pour le commander.
Et surtout, ne suivez pas aveuglément les directives (mais ne les ignorez pas non plus sans raison) et ne confondez pas vos préférences personnelles avec ce que les utilisateurs trouvent intuitif.
Je suis presque dans la même situation que vous avec mon application et la conception d'une interface "Ruban". J'ai envisagé une situation où je regrouperais les commandes dans le ruban en fonction de l'objet "métier" principal. En d'autres termes, si mon application permettait aux utilisateurs de gérer les clients et les fournisseurs, aurait-il un sens d'avoir un groupe de ruban dédié aux clients, avec toutes les commandes que vous invoqueriez généralement, puis un autre groupe de ruban dédié aux fournisseurs avec les différentes commandes qui font sens de courir contre ces objets\enregistrements?
Comme je l'ai esquissé, il est devenu évident (du moins pour moi) que la gestion de l'écran deviendrait très délicate avec ce style si je ne fournissais qu'un seul ruban et frustrerait probablement les utilisateurs plus que leur aide.
À propos de la meilleure interface utilisateur que j'ai rencontrée et qui traite au moins tangentiellement ce problème est l'interface Outlook 2010. Outlook s'appuie sur un élément de navigation distinct, mais lorsque vous passez de Messages à Contacts par exemple, le ruban change pour afficher les commandes prises en charge pour l'interface avec laquelle vous travaillez à l'époque.
Pour revenir à votre exemple, il semblerait que la recherche d'un enregistrement particulier impliquerait que l'utilisateur connaît le type d'enregistrement qu'il recherche. Il peut être judicieux d'avoir d'abord un système de navigation en place afin que l'utilisateur puisse naviguer vers l'objet principal (par exemple, la vue Clients) et ensuite être présenté avec un ensemble de commandes dans le ruban qui concernent uniquement les clients. Find peut en effet être dans le groupe "Editing", mais son contexte ne concerne que la vue Customers. Vous pouvez également avoir une autre commande Rechercher située dans un groupe d'édition qui se rapporte à une autre entité dans l'application.
J'y ai pensé aussi, et l'idée principale que j'ai trouvée est similaire à ce que Tim Lentine a décrit: avoir un onglet pour chacun de mes principaux objets métier. Je mettrais les commandes les plus couramment exécutées pour cet objet dans l'onglet correspondant, par exemple et l'objet "Commander" pourrait avoir des commandes pour changer le statut (par exemple, annuler, expédier, etc.), facturer, envoyer une facture, etc.
Cependant, j'ai également pensé au fonctionnement du ruban dans la Galerie de photos Windows Live. D'une certaine manière, il gère une base de données (de photos et de métadonnées). Les onglets Accueil, Rechercher et Afficher étaient particulièrement intéressants. J'ai également aimé l'idée de la boîte de recherche/filtre qui apparaît.
Ce sont donc les deux principales idées de ruban pour une application CRUD sur lesquelles j'ai réfléchi. Cependant, je n'ai encore rien décidé.
Dans le sens de la galerie de photos, je pourrais faire un onglet pour récupérer une liste particulière de données et les supprimer, etc. (je prévoyais de faire en sorte que le panneau principal de ma fenêtre affiche une liste d'objets). Je pourrais en avoir un autre pour le filtrage/regroupement (similaire à l'onglet "Affichage" de WLPG). J'aurais probablement un autre onglet pour les rapports. Je pourrais également utiliser des onglets contextuels pour exécuter des commandes courantes sur l'objet sélectionné comme je l'ai décrit dans le premier paragraphe.
Je n'ai pas une grande expérience dans une application CRUD avec un ruban, mais voici quelques idées ...
Lire - Avoir un ou plusieurs onglets engagés dans la manière standard dont un utilisateur trouverait les objets particuliers. Par exemple, s'il s'agissait d'une base de données collégiale, un onglet pour les étudiants/professeurs, un pour les classes, un pour les bâtiments. Regroupez les objets dans les onglets par niveaux plus fins, comme un pour les étudiants et un pour le personnel. S'il s'agit d'une simple requête de champ, vous pouvez placer directement le contrôle de texte brut ou afficher la boîte de dialogue de recherche complexe.
Créer - avoir un seul onglet à supprimer, ou le mettre dans les onglets de lecture. Si vous créez un onglet de création distinct, faites correspondre les groupes aux onglets et ajoutez des séparateurs pour créer des mini-groupes.
pdate - Je considérerais sérieusement les onglets contextuels pour cela. Un contexte par type d'objet. Si un formulaire a plusieurs types, vous devrez piloter le contexte par focus clavier. Pas tellement amusant. Vous pouvez également souhaiter ces tâches de mise à jour dans les formulaires eux-mêmes, surtout si elles correspondent bien aux options de "commande" de la boîte de dialogue telles que Appliquer et autres.
Supprimer - Bien enterré dans la commande, pas sur le ruban par défaut. La destruction des données est à décourager. Au lieu de cela, encouragez l'utilisateur à "archiver" ou "déprécier" ou "graduer" les données afin qu'elles n'apparaissent que dans des requêtes spécifiques. Et ces actions sont généralement spécifiques à l'objet afin qu'elles vivent dans les formulaires ou les onglets contextuels. Laissez les tâches de sauvegarde, d'archivage et de maintenance hebdomadaires effectuer la suppression.