Cómo manejar los botones "guardar" y "cancelar" y la tecla de retroceso

Me pregunto cómo manejar los formularios de entrada de usuario en mi aplicación. (Presupuesto real). Ahora mismo esto es lo que estoy haciendo, pero no estoy seguro si esta es la mejor práctica:

Tengo dos botones de software en la mayoría de mis actividades que toman la entrada del usuario: "guardar" y "cancelar".

"Guardar" captura la entrada del usuario y luego termina la actividad actual "cancelar" abandona cualquier entrada del usuario y termina la actividad actual Golpear el botón de retroceso en el dispositivo hace lo mismo que "guardar"

Todavía me molesta un poco que el botón de nuevo realiza la función "guardar y volver". Los usuarios que son nuevos en los teléfonos android probablemente se utilizan para los navegadores web, donde el botón de retroceso significa "olvidarse de esta página y volver a la página anterior". Si usted estaba comprando algo en línea y llegó a la página final de "compra", no esperaría que el botón de vuelta para completar la compra, ¿verdad? Pero parece que ese comportamiento es la forma en que funcionan las aplicaciones integradas, así que no estoy inclinado a hacerlo de manera diferente.

De todos modos, he mirado a través de la documentación oficial y no puedo encontrar este comportamiento explícitamente explicado. ¿Puede alguien señalarme al lugar correcto, o por lo menos proporcionar alguna orientación en cuanto a la mejor práctica?

Las opciones como las veo son:

  1. Hazlo de la manera que lo estoy haciendo ahora.
  2. Deshacerse del botón "Guardar" y contar con los usuarios sabiendo que la parte de atrás es igual a guardar.
  3. Deshágase de ambos botones y proporcione una función de cancelación desde la tecla de menú.

La aplicación de contactos de Google proporciona los botones "hecho" y "revertir", por cierto. Supongo que "revertir" significa cancelar; ¿Hay una diferencia? Tal vez debería tener mis botones etiquetados "hecho" y "revertir" en lugar de "guardar" y "cancelar"? En gmail, el botón de menú proporciona las opciones "guardar borrador" y "descartar". Me parece que estaríamos haciendo un favor a los usuarios si tuviéramos algo de consistencia aquí.

Gracias por adelantado.

Pero parece que ese comportamiento es la forma en que funcionan las aplicaciones integradas, así que no estoy inclinado a hacerlo de manera diferente.

La única aplicación integrada que hace esto, que puedo pensar, es la aplicación de contactos, y me parece que UX a ser pésimo. Estaba maldiciendo ayer, como sucede.

Quizás otras aplicaciones incorporadas lo hacen también, pero no lo he encontrado todavía, por lo menos no que recuerde.

De todos modos, he mirado a través de la documentación oficial y no puedo encontrar este comportamiento explícitamente explicado.

No hay ninguna guía UX de esta naturaleza en la documentación. Desafortunadamente.

Me parece que estaríamos haciendo un favor a los usuarios si tuviéramos algo de consistencia aquí.

No tendrías ningún argumento de mí.

Personalmente, pienso en el botón BACK como comportarse como una "cancelación", o lo que sea la elección negativa sería. Los diálogos típicamente se comportan de esta manera en Android, por ejemplo.

Si usted tiene usuarios existentes, y ha establecido comunicaciones con ellos (boletín de noticias, el apoyo de Grupo de Google, etc), yo los encuesta y ver lo que piensan. Al final, es lo que más te gusta de tus usuarios.

En una pizca, que sea configurable. Idealmente, para algo como esto, hay una respuesta correcta verdadera, y por lo tanto la configurabilidad sería inútil. Sin embargo, si su encuesta indica una votación por división, y en ausencia de directrices de la plataforma Android UX, un ajuste podría ser la solución adecuada para usted.


ACTUALIZACIÓN: Escribí una entrada en un blog sobre este tema, ya que creo que es razonablemente importante y vale la pena un poco más de prosa.

Le recomiendo que siga el modelo utilizado por el estándar de Android y las aplicaciones, donde la edición siempre sucede en su lugar. Es decir, no hay botón "guardar" – los cambios que está realizando se están ahorrando efectivamente a medida que se están haciendo. (La implementación puede ser, por supuesto, ligeramente diferente, pero para el usuario esto no debe ser visible.) Siguiendo ese modelo, los botones deben ser algo en la línea de "hecho" y "revertir". Esto ayuda con el modelo mental del usuario de lo que está pasando, que dejar la actividad no es probable que se convierta en una operación de "revertir".

Una de las razones para usar este modelo de edición de datos es que se ejecutará en muchos casos menos malas. Si intenta presentar un modelo más tradicional en el que el usuario salve explícitamente, entonces cualquier ruta que el usuario pueda sacar de su actividad es una posible causa de pérdida de datos, lo que le lleva a querer protegerlos de eso y, por tanto, tratar de Muestran diálogos para confirmar que realmente quieren perder sus datos. Esta es una batalla perdida, y nunca será capaz de atrapar todos los agujeros, y su UX sufrirá por ello. (Considere, por ejemplo, si reciben una llamada telefónica entrante, no es el momento de escribir un diálogo para preguntarles si quieren guardar sus datos, ni tampoco serían capaces de hacerlo).

Así que empezar con su modelo básico de ser editar en su lugar. Esto es consistente con la convención que la plataforma estándar utiliza, y esto fue elegido deliberadamente en el diseño de la plataforma porque en general resulta en un UX mucho más simple y más coherente y comprensible. Diseñe su flujo de interfaz de usuario para enfatizar este modelo, evitando acciones explícitas de "guardar".

Para mí, siempre me siento 'inseguro' sin una opción de guardar. Por ejemplo, en GTask, al crear una nueva tarea, al pulsar 'atrás' (botón duro) se guardarán las cosas y volverán a la pantalla anterior. No hay ningún botón suave BTW. Pero siempre me frustraba por esto.

Para tu aplicación, creo que necesitas considerar dos cosas antes de decidir de qué manera realizó el botón de retroceso:

  1. ¿Qué tan importante es su operación de "guardar" (como si fuera a realizar pedidos)
  2. ¿Su usuario esperaba cancelar las cosas?

Obviamente, si el ahorro es largo procesado y crítico, debe tomarse un control explícito. (Y la espalda no ahorraría); Y para el segundo punto, supongo GTask consideró anotar notas debe ser rápido y simple, y debe sentir como anotar en el papel — se guarda, una vez que escribió.

Refiriéndose a lo que usted dijo, volver en el navegador web es volver atrás y olvidarse de todo. Pero al mismo tiempo, Google (por ejemplo, Google Docs) también está haciendo auto, fondo de ahorro, que no es "olvidado" cuando vuelve.

Tratar de decidir una acción universal para cuando el usuario presiona hace que esta pregunta sea mucho más difícil (si no imposible).

Un enfoque mucho más simple es pensar en el contexto, y veo dos situaciones principales: el usuario está interactuando con un diálogo y el usuario está interactuando con una actividad regular.

Interacción con un diálogo

Si un usuario presiona de nuevo en un cuadro de diálogo (por ejemplo, el cuadro de diálogo de selección de fecha) es porque no quiere ver ese diálogo o cambiar esa información.

Mientras está en un diálogo, el usuario no espera que los cambios se apliquen hasta que lo diga (pulsando "Ok").

Interactuar con una actividad

Por ejemplo, el usuario está viendo los detalles de algún elemento que su aplicación proporciona (información de contacto). Presionar de nuevo después de algunos cambios podría significar "ahora me llevan de nuevo a la lista de contactos". De todos modos, esto no está 100% claro. Así que incluir opciones para guardar y descartar cambios (llámalo lo que quieras) podría ser una buena opción.

Mis pensamientos como usuario de Android

El comportamiento en un diálogo es simple y claro. Creo que no tenemos dudas al respecto.

En actividades, estoy acostumbrado a tener la tecla de regreso para guardar datos y enviarme a la última actividad. Cada vez que quiero descartar mis cambios, me encuentro presionando el botón de menú y buscando un botón para cancelar.

Si desea algo mejor, incluya el comportamiento predeterminado como preferencia y / o muestre un brindis al cancelar o guardar la información.

Cancelar vs revertir

En la práctica, hacen lo mismo. Cancelar debe, herr, cancelar lo que está haciendo ahora (edición de algo). Esto debería / podría llevarle a lo que estaba haciendo antes (actividad de la lista).

Revertir cambiará el estado de lo que está viendo a la forma en que era antes de empezar a hacer cambios. Esto no le llevará a la actividad anterior. Podría simplemente actualizar la interfaz de usuario a los valores originales.

Experimentos con la aplicación de contactos

  1. Al pulsar durante la edición de un contacto se guardarán los cambios.
  2. Al pulsar la tecla de inicio durante la edición de un contacto se descartarán los cambios
FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.