Comment gérer les boutons "enregistrer" et "annuler" et la touche arrière

Je me demande comment traiter les formulaires d'entrée utilisateur dans mon application. (Budget réel lite). À l'heure actuelle, c'est ce que je fais, mais je ne sais pas si c'est la meilleure pratique:

J'ai deux boutons-poussoirs sur la plupart de mes activités qui prennent l'entrée des utilisateurs: "enregistrer" et "annuler".

  • Les plugins ne sont pas toujours ajoutés après que cordova ajoute une plate-forme Android et iOs
  • Redimensionnement de DatePicker dans Android
  • Comment puis-je faire un débogage de cette exception NullPointer?
  • Comment certaines applications bloquent / remplacent les notifications heads-up?
  • Un problème mettant à jour Android SDK Tools rev 19 à rev 20 à l'aide de Windows 7- 64 bits
  • Erreur: le programme "/ndk-build.cmd" n'est pas trouvé dans PATH
  • "Enregistrer" capture l'entrée de l'utilisateur, puis finit l'activité actuelle "annuler" abandonne toute entrée utilisateur et finit l'activité actuelle Le fait de frapper le bouton arrière sur le périphérique fait la même chose que "enregistrer"

    Cela me dérange encore un peu que le bouton arrière effectue la fonction "sauvegarder et revenir en arrière". Les utilisateurs qui sont nouveaux sur les téléphones Android sont probablement utilisés pour les navigateurs Web, où le bouton arrière signifie "oublier cette page et revenir à la page précédente". Si vous achetiez quelque chose en ligne et que vous avez obtenu la page finale d'achat, vous ne vous attendez pas à ce que le bouton "Retour" pour terminer l'achat soit vous? Mais il semble que le comportement est la façon dont les applications intégrées fonctionnent, donc je ne suis pas enclin à le faire différemment.

    Quoi qu'il en soit, j'ai examiné la documentation officielle et je ne peux pas trouver ce comportement explicitement expliqué. Quelqu'un peut-il me diriger vers le bon endroit ou, au moins, donner des conseils sur les meilleures pratiques?

    Les choix tels que je les vois sont:

    1. Faites-le comme je le fais maintenant.
    2. Débarrassez-vous du bouton "Enregistrer" et comptez sur les utilisateurs en sachant que le retour est égal à sauvegarder.
    3. Débarrassez-vous des deux boutons et fournissez une fonction d'annulation à partir de la touche de menu.

    L'application de contacts google fournit les boutons "fait" et "revenir", soit dit en passant. Je suppose que "revenir" signifie annuler; Y a-t-il une différence? Peut-être que je devrais avoir mes boutons étiquetés «fait» et «revenir» au lieu de «enregistrer» et «annuler»? Dans Gmail, le bouton de menu propose les options "Enregistrer le brouillon" et "Jeter". Il me semble que nous ferions une faveur aux utilisateurs si nous avions une certaine cohérence ici.

    Merci d'avance.

    4 Solutions collect form web for “Comment gérer les boutons "enregistrer" et "annuler" et la touche arrière”

    Mais il semble que le comportement est la façon dont les applications intégrées fonctionnent, donc je ne suis pas enclin à le faire différemment.

    La seule application intégrée qui fait cela, que je peux penser, est l'application de contacts, et je trouve que UX est généreux. Je l'ai juste maudit hier, comme cela se produit.

    Peut-être que d'autres applications intégrées le font aussi, mais je ne l'ai pas encore rencontré, du moins pas ce que je me souviens.

    Quoi qu'il en soit, j'ai examiné la documentation officielle et je ne peux pas trouver ce comportement explicitement expliqué.

    Il n'existe aucune directive UX de cette nature dans la documentation. Malheureusement.

    Il me semble que nous ferions une faveur aux utilisateurs si nous avions une certaine cohérence ici.

    Vous ne recevriez aucun argument de ma part.

    Personnellement, je pense que le bouton BACK se comporte comme un "annulation" ou quel que soit le choix négatif. Les dialogues se comportent généralement de cette façon sur Android, par exemple.

    Si vous avez des utilisateurs existants et que vous avez établi des communications avec eux (newsletter, support Google Group, etc.), je les interrogeons et voyez ce qu'ils pensent. En fin de compte, c'est ce que vos utilisateurs veulent le plus important.

    Dans un pincement, le rendre configurable. Idéalement, pour quelque chose comme ça, il y a une seule réponse à droite, et donc la configurabilité serait inutile. Cependant, si votre sondage indique un vote partagé, et en l'absence des lignes directrices de l'UX de la plate-forme Android, un paramètre pourrait être la bonne solution pour vous.


    MISE À JOUR: J'ai écrit une publication sur ce sujet, car je pense qu'il est raisonnablement important et vaut la prose un peu plus.

    Je vous recommande vivement de suivre le modèle utilisé par l'Android et les applications standard, où l'édition se produit toujours. C'est-à-dire qu'il n'y a pas de bouton "enregistrer" – les modifications que vous faites sont effectivement enregistrées au fur et à mesure de leur réalisation. (La mise en œuvre peut bien sûr être légèrement différente, mais pour l'utilisateur, cela ne devrait pas être visible.) À la suite de ce modèle, vos boutons devraient être quelque chose selon les termes "fait" et "revenir". Cela aide avec le modèle mental de l'utilisateur de ce qui se passe, que laisser l'activité ne serait pas susceptible de se transformer en une opération "rétablir".

    L'une des raisons de l'utilisation de ce modèle d'édition de données est que vous rencontrerez plusieurs cas de mauvaise qualité. Si vous essayez de présenter un modèle plus traditionnel où l'utilisateur enregistre explicitement, tout chemin que l'utilisateur peut retirer de votre activité est une cause potentielle de perte de données, ce qui vous amène à vouloir les protéger contre cela et essayer ainsi Afficher les dialogues pour confirmer qu'ils veulent vraiment perdre leurs données. C'est une bataille perdue, et vous ne serez jamais en mesure d'attraper tous les trous, et votre UX en souffrira. (Considérons, par exemple, s'ils reçoivent un appel entrant, ce n'est pas le moment de mettre en place une boîte de dialogue pour leur demander d'abord s'ils veulent enregistrer leurs données, et vous ne pourriez toujours pas.)

    Commencez donc par que votre modèle de base soit en cours d'édition. Ceci est conforme à la convention utilisée par la plate-forme standard, ce qui a été délibérément choisi dans la conception de la plate-forme car, dans l'ensemble, il en résulte un UX beaucoup plus simple et plus cohérent et compréhensible. Concevez votre flux d'interface utilisateur pour souligner ce modèle, en évitant les actions explicites de "sauvegarde".

    Pour moi, je me sens toujours «dangereux» sans option de sauvegarde. Par exemple, dans GTask, lorsque vous créez une nouvelle tâche, en appuyant sur 'retour' (bouton dur), vous sauvegarderez les choses et retourneront à l'écran précédent. Il n'y a pas de bouton-poussoir BTW. Mais j'ai toujours été frustré à ce sujet.

    Pour votre application, je pense que vous devez considérer deux choses avant de décider de quelle manière le bouton de retour a-t-il fonctionné:

    1. Dans quelle mesure votre opération de sauvegarde est-elle essentielle (comme cela va placer des commandes!)
    2. Votre utilisateur s'attendait-il à annuler des choses?

    Évidemment, si l'enregistrement est long-traité et critique, un contrôle explicite doit être pris. (Et le retour ne serait pas enregistré); Et pour le deuxième point, je pense que GTask a considéré que les notes de jappage devraient être simples et rapides, et il devrait avoir l'impression de faire des notes sur le papier – c'est sauvé, une fois que vous avez écrit.

    En vous référant à ce que vous avez dit, revenir sur le navigateur internet est de revenir en arrière et tout oublier. Mais en même temps, Google (par exemple, Google Docs) fait aussi automatiquement, sauvegarde d'arrière-plan, qu'il n'est pas «oublié» lorsque vous retournez.

    Essayer de décider d'une action universelle lorsque l'utilisateur appuie plus tard rend cette question beaucoup plus difficile (sinon impossible).

    Une approche beaucoup plus simple consiste à penser au contexte, et je vois deux situations principales: l'utilisateur interagit avec une boîte de dialogue et l'utilisateur interagit avec une activité régulière.

    Interagir avec un dialogue

    Si un utilisateur réapparaît dans une boîte de dialogue (par exemple, la boîte de dialogue de l'heure de la date), c'est parce qu'il ne veut pas voir cette boîte de dialogue ou modifier cette information.

    Dans une boîte de dialogue, l'utilisateur ne s'attend pas à ce que des modifications s'appliquent jusqu'à ce qu'il le dise (en appuyant sur "OK").

    Interagir avec une activité

    Par exemple, l'utilisateur voit les détails d'un élément que votre application fournit (informations de contact). En appuyant en arrière après quelques modifications, cela pourrait signifier "maintenant me ramener à la liste des contacts". Quoi qu'il en soit, ce n'est pas clair à 100%. Donc, y compris les options pour sauvegarder et éliminer les modifications (appeler ce que vous voulez) pourrait être une bonne option.

    Mes pensées en tant qu'utilisateur Android

    Le comportement dans une boîte de dialogue est simple et clair. Je pense que nous n'en avons aucun doute.

    Dans les activités, j'ai l'habitude d'avoir la clé arrière pour enregistrer les données et m'envoyer à la dernière activité. Chaque fois que je souhaite jeter mes modifications, je me trouve en appuyant sur le bouton de menu et en recherchant un bouton pour annuler.

    Si vous voulez quelque chose de mieux, incluez le comportement par défaut comme préférence et / ou affichez un toast lorsque vous annulez ou enregistrez les informations.

    Annuler avant de revenir

    Dans la pratique, ils font la même chose. Annuler devrait annuler ce que vous faites en ce moment (modifier quelque chose). Cela devrait / pourrait vous amener à ce que vous faisiez avant (liste d'activité).

    Revenir changera l'état de ce que vous voyez comme il était avant de commencer à modifier. Cela peut ne pas vous conduire à l'activité précédente. Il pourrait simplement mettre à jour l'interface utilisateur sur les valeurs d'origine.

    Expériences avec l'application des contacts

    1. En appuyant vers l'arrière lors de l'édition d'un contact, vous économiserez les modifications.
    2. Appuyer sur la maison tout en éditant un contact supprimera les changements
    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.