système de tarification semi-automatique UX / UI
Je travaille sur un projet où le système détermine un certain nombre de gagnants en fonction de leurs scores. Ils sont marqués par le système comme l'or, l'argent et le bronze. L'administrateur doit pouvoir sélectionner manuellement les gagnants après un certain nombre de gagnants sélectionnés par le système.
Donc, je pensais générer une liste d'utilisateurs et implémenter la méthode suivante
- fournir 3 cases à cocher pour le rendre or, argent ou bronze contre chaque utilisateur
- fournir une liste déroulante d'or, d'argent et de bronze à sélectionner dans chaque liste d'utilisateurs.
Les deux méthodes fonctionnent, mais j'hésite à utiliser les deux méthodes. Quelqu'un peut-il suggérer une meilleure expérience utilisateur pour faire un tel processus semi-automatisé? Ou du moins, quelle est la meilleure pratique parmi les deux méthodes que j'ai spécifiées? Tnx
Lorsque vous sélectionnez une seule option sur trois, vous devez utiliser les boutons radio. Vous voyez toutes les options à la fois (à l'exception d'une liste déroulante) et vous ne pouvez sélectionner qu'un seul élément (à l'exception d'une case à cocher).
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Il ne peut y avoir qu'un seul utilisateur d'or, un argent et un bronze, et ils ne peuvent évidemment pas être la même personne. Les boutons radio, étant la commande standard "il ne peut y en avoir qu'un" est le choix évident.
Tout d'abord, vous ne pouvez pas "désactiver" un bouton radio. Dans le cas de choisir accidentellement un gagnant "Gold", un ensemble de boutons radio ne fournit aucun moyen clair de donner la contribution de "whoopsie, je ne voulais pas sélectionner cette personne comme gagnant!
Deuxièmement, le choix doit être verrouillé en deux dimensions. Vous ne pouvez pas avoir deux gagnants Gold et vous ne pouvez pas avoir un seul gagnant avec plus d'un type de gain. Cela signifie que nous avons besoin d'une grille de puzzle logique, où un seul choix peut être fait dans une colonne et une ligne.
(extrait de logic-puzzles.org )
Ce qui précède est un "contrôle" de puzzle logique commun, où lorsqu'un élément dans une boîte est vrai, aucun des autres éléments de la même ligne ou colonne ne peut être vrai. Si nous adaptons ce contrôle à un écran de sélection de prix, nous obtenons quelque chose comme ceci:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Dans cette maquette, la sélection d'un élément désactive les cases à cocher dans la même colonne (un seul prix Or) et la même ligne (un seul prix par entrée); remarquez comment les autres cases à cocher de la même ligne et colonne sont désactivées (décolorées) lorsque l'une est choisie. Si vous faites une erreur, vous pouvez décocher la case qui réactivera les cases à cocher bloquées.
Cette interface indique clairement lorsqu'un choix est empêché en raison d'une sélection conflictuelle qui a déjà été effectuée. Cela devient plus important lorsque votre liste de gagnants potentiels ne peut pas être affichée sur un seul écran. Le contexte est perdu lorsque vous faites défiler vers le bas, mais les boutons désactivés empêchent un utilisateur de faire accidentellement un choix conflictuel.
Je pense que la liste déroulante est supérieure car elle prend moins d'espace et fait moins d'encombrement. Vous pouvez également le faire apparaître uniquement lorsque vous survolez le nom et que l'arrière-plan de l'utilisateur sélectionné et la div du menu déroulant sont de la même couleur que s'ils ne forment qu'un bloc:
User1 [Gold]
User2 [Silver] [Dropdown]
User3 [Bronze]
Le fait que la liste déroulante n'apparaisse qu'en survol vous donnera un aperçu agréable lorsque vous aurez terminé vos modifications.