Alternative aux boutons radio
Contexte: Je suis en train de concevoir (application mobile) une action dans laquelle l'utilisateur doit sélectionner un statut pour un élément du système.
Sur la page principale, ils ont 2 options "Accepter" ou "Délai" (illustrées ci-dessous). 
90% du temps, les utilisateurs appuieront sur "Accepter", cependant, ils devront occasionnellement appuyer sur "Délai". Le bouton "Délai" a plus de 1 état (par exemple, délai de x, y, z).
Quand ils tapent sur le bouton "Délai" pour sélectionner un état, ils sont confrontés à une boîte de dialogue modale. L'utilisateur doit ensuite sélectionner un état parmi les options disponibles, ce qui les replace automatiquement dans l'écran principal sans aucune confirmation car il est facile de changer cet état.
Le problème auquel je suis confronté est qu'en ce moment pour l'interaction de la sélection des états de retard, j'utilise des boutons radio avec des étiquettes de texte. Voir ci-dessous:
Cependant, comme il n'y a aucune confirmation, il semble étrange et inutile d'utiliser des boutons radio. En d'autres termes, les boutons radio sont généralement utilisés lorsque vous pouvez modifier votre sélection avant de confirmer. Dans ce cas, l'utilisateur n'a qu'à appuyer une fois sur l'option pour effectuer la sélection.
La question est , y a-t-il une interaction plus appropriée pour ce cas plutôt que des boutons radio?
Informations supplémentaires: il peut y avoir jusqu'à 15 options à sélectionner, il doit donc être dynamique en ce sens qu'il peut afficher 2, 15 ou n'importe où entre les quantités d'options.
Comme Michael l'a suggéré, j'allais de l'avant et j'utilisais le deuxième écran avec des boutons de commande pour les choix de retard et une étiquette en haut leur disant de choisir.
Si c'est gênant ou déroutant pour l'utilisateur, je doute que ce soit après un ou deux parcours dans votre interface utilisateur.
Edit: J'ai fouetté cela sous forme de formulaire Windows, mais je pense que cela donne l'idée. (Soit dit en passant, vous avez dit qu'il peut y avoir jusqu'à 15 sélections. Je pense que vous devriez utiliser une barre de défilement verticale pour cela, plutôt que de modifier la taille des boutons.)
Je pense que beaucoup d'autres réponses offrent de bons conseils généraux, et je vais peut-être répéter certaines d'entre elles ici. Avec les applications mobiles, plus simple est toujours mieux. Vous avez dit que c'est une opération assez courante que l'utilisateur doit effectuer dans votre application, et je pense que vous avez dit (ou laissé entendre) que ce n'était pas grave s'il se trompait - il suffirait de refaire la sélection. Donc, utiliser des boutons comme ceux-ci est simple et facile.
De plus, s'ils ferment le modal sans sélection (vous n'avez probablement pas de X de fermeture en haut à droite, mais disons qu'ils frappent Retour), vous devez par défaut choisir ce qui a le plus de sens, par exemple "Pas de statut".
Qu'en est-il d'une liste déroulante a.k.a combobox ?
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Il peut y avoir autant d'options que vous le souhaitez (il est dimensionné dynamiquement), si les options ne tiennent pas dans l'écran, vous obtenez une barre de défilement et après avoir sélectionné une option, l'utilisateur voit immédiatement son choix.
Editer après l'OP
Vous pouvez toujours l'avoir à portée de clic, mais il doit y avoir plus d'action derrière l'écran, à savoir:
L'action derrière l'écran est:
- si l'utilisateur vérifie accepte, la combobox "delay by" est réglée sur "-"
- si l'utilisateur sélectionne une option (sauf "-") dans la zone de liste déroulante, la case n'est pas cochée
- si l'utilisateur sélectionne un "-" dans la zone de liste déroulante, la case à cocher ne change pas l'état.
- l'utilisateur peut continuer si: la case est cochée ou non la première option de la combobox est sélectionnée.
Pour répondre à votre préoccupation spécifique:
Puisqu'il n'y a aucune confirmation, cela semble étrange…. Les boutons radio sont généralement utilisés lorsque vous pouvez modifier votre sélection avant de confirmer.
La solution consiste à utiliser des boutons de commande pour chaque état, pas des boutons radio. Les utilisateurs sont plus susceptibles de s'attendre à ce qu'un clic sur un bouton de commande exécute une action et ferme la boîte de dialogue.
Cependant, la critique implicite dans conception de Mike est correcte que le fait d'avoir une boîte de dialogue la rend assez gênante, forçant l'utilisateur à se réorienter vers une nouvelle fenêtre pour n'en faire qu'une rare (10% du temps). De plus, jusqu'à 15 options sont plus que recommandées pour les boutons radio de toute façon, donc une liste déroulante est logique.
D'un autre côté, la conception de Mike prend un peu plus de terrain que la vôtre, et vous pensiez probablement que cela ne valait pas la peine d'afficher les commandes pour quelque chose qui n'est fait que 10% du temps.
La solution consiste à combiner le choix Accepter vs Délai, avec l'état du retard. Avoir un menu déroulant unique avec les options:
Statut:
Acceptez
Retard d'une heure
Retarder 2 heures
Délai jusqu'à l'année 2525
Ou peut-être que c'est:
Accepter:
Maintenant
En 1 heure
Dans 2 heures
En l'an 2525
Cela prend encore moins de place que la conception de Mike et évite le problème de l'action "derrière l'écran".
Sauf si l'acceptation est particulièrement dangereuse, je recommande que la liste déroulante par défaut soit Accepter, étant donné qu'elle est correcte dans 90% des cas. Pourquoi lui donner un accès en un clic alors que vous pouvez en faire zéro clic? Cela vous donnera la conception la plus rapide: 0,2 clics par interaction en moyenne, contre 1,1 clics par interaction dans votre conception d'origine ou celle de Mike.
Pour moi, j'envisagerais de faire apparaître l'option "délai" dans une liste, et la sélection d'un élément dans la liste ferait disparaître la liste.
Ensuite, sous "délai", j'aurais un petit texte pour montrer le délai sélectionné. Ou, ajoutez éventuellement le retard sélectionné dans le bouton lui-même - peut-être comme une superposition.
Chaque fois que vous appuyez sur "Délai", la liste s'affiche à nouveau pour permettre aux utilisateurs de modifier leur sélection.
La sélection de "Accepter" effacerait toute connaissance de "retard"
D'après mon expérience de développement pour mobile, les options sont maladroites, les listes déroulantes sont pires (voir la molette de défilement iOS pour référence), les menus coulissants sont viables mais implémentés différemment sur différentes plateformes et les popups modaux ne sont pas excellents, surtout si le nombre d'options nécessite un défilement.
Un autre contrôle UX que j'ai utilisé pour définir des durées dans une situation similaire consiste à utiliser un contrôle de curseur étiqueté. Le curseur commence à une extrémité et est étiqueté avec la durée minimale (c'est-à-dire Accepter maintenant dans cette situation) et lorsque vous faites glisser, l'étiquette indique la durée affectée associée à la position du curseur.
Cette approche a certains avantages: compact, réglable dynamiquement, ne nécessite qu'un seul contrôle, etc. et certains inconvénients: bref apprentissage par l'utilisateur, ne peut pas voir toutes les durées en un coup d'œil.
Votre situation peut rendre cela intenable, mais cela a bien fonctionné pour moi dans un certain nombre de situations.
Remplissez le contenu de la même zone de dialogue utilisée pour Accepter/Délai avec les options de délai sous forme de boutons. En fait, cela devient comme un modèle "sorcier".
Cela permet d'indiquer (avec un signal fort) que la sélection d'une suite continue immédiatement le flux d'exécution, et le fait loin de cet écran, plutôt qu'une autre action sera nécessaire pour continuer le flux et que la personne utilisant l'application pourra rester sur le courant écran et gaufre entre plusieurs options radio avant de continuer (par exemple quelque chose comme en sélectionner une, changer d'avis, en sélectionner une autre, puis enfin enregistrer leur sélection pour continuer le flux).
Tout comme une radiocommande, cela maintient la compréhension qu'un seul choix peut être sélectionné (en raison du signal que la sélection d'un choix continuera à naviguer dans cet écran).
qui les remet ensuite automatiquement dans l'écran principal sans aucune confirmation car il est facile de changer cet état.
Remarque: C'est bien, mais je recommanderais généralement de vous assurer que le bouton de retour peut revenir à l'état et renvoyer la personne utilisant l'application à ce dialogue. Je ne considérerais pas cela comme une priorité en soi dans une situation où l'état représenté par le dialogue peut encore être modifié plus tard facilement, mais cela permet de maintenir une interaction cohérente avec l'interface utilisateur et de réduire les frictions au sein de ce paradigme commun.
L'interaction accidentelle avec l'interface utilisateur n'est pas tout à fait rare sur mobile, et au-delà, il est généralement toujours préférable de rendre les actions réversibles d'une manière ou d'une autre, à moins que leur résultat nécessaire ne crée une situation irréversible (auquel cas une confirmation secondaire doit être utilisée, mais vous avez que ce n'est pas une situation de ce type). Tout en étant en mesure de modifier à nouveau l'état compte certainement, lorsque les gens font des erreurs, ils essaient fréquemment de "sauvegarder", et devoir à la place "avancer" vers une nouvelle tâche d'édition peut ajouter de la frustration pour certains. C'est le mieux pour fournir des tolérances pour les deux modèles d'interaction, mais aussi pas nécessaire en soi tant que l'un ou l'autre est disponible (en cas de doute, je choisirais personnellement de pouvoir encore modifier l'état de l'élément associé ultérieurement, s'il ne s'agissait que de l'un ou l'autre).
Informations supplémentaires: il peut y avoir jusqu'à 15 options à sélectionner, il doit donc être dynamique en ce sens qu'il peut afficher 2, 15 ou n'importe où entre les quantités d'options.
Cette stratégie basée sur les boutons fonctionne toujours bien dans une situation où vous vous retrouvez avec une grande liste, car vous pouvez fournir des contrôles d'interface utilisateur appropriés qui changent en fonction de la taille de la liste pour faciliter la tâche de sélection. De toute évidence, le conteneur de dialogue doit être conçu de manière à pouvoir se développer verticalement.
Le premier avantage de cela par rapport à une liste déroulante est qu'il évite les pièges fréquents des listes déroulantes sur mobile en termes d'implémentations incohérentes et parfois même hostiles entre les OS/versions d'OS, et vous permet de placer un espacement approprié autour de vos contrôles de bouton. Si vous avez besoin de plus d'informations à côté de chaque bouton ou uniquement avec certains boutons, vous pouvez créer quelque chose qui le fait de manière propre.
La seconde est que si vous vous retrouvez avec une liste excessivement longue, vous pouvez avoir un champ de filtre en haut pour permettre aux utilisateurs de réduire la liste visible à quelque chose de gérable.
Enfin, une liste déroulante n'est pas meilleure qu'une radiocommande en impliquant que l'interaction avec elle entraînera un événement de navigation de flux. Les boutons sont généralement considérés comme signalant que l'interaction avec l'un entraînera une sorte de flux ou de navigation depuis l'application. On pourrait certainement affirmer qu'un contrôle radio ou une liste déroulante sans aucun autre contrôle visible simultanément peut être déduit comme entraînant un événement de flux d'application lors de la sélection, mais je voudrais mettre en garde que bien que ce soit une inférence logique à faire en voyant cela, ce n'est pas cohérent avec la façon dont ces contrôles sont plus couramment utilisés et peuvent donc créer un sentiment de frustration. Personnellement, je fournirais une sorte de bouton d'intention de flux supplémentaire (par exemple, "soumettre", "continuer", etc.) si vous utilisez une radio ou un contrôle déroulant.