design - propiedades - navegar entre fragments android studio
Interfaz de usuario estática frente a UI dinámica (25)
En alguna aplicación con UI, qué es mejor (fácil, amigable, etc.) para un usuario:
- La IU es estática (no depende del estado del usuario). Por ejemplo, si el usuario ve algún botón, pero está atenuado o cuando se hace clic en él, se muestra un mensaje de que esta acción no es aplicable en este momento.
o
- La IU es dinámica (depende del estado del usuario). Por ejemplo, el usuario no ve botones, que no son aplicables en este momento. Pero después de alguna acción, los botones pueden aparecer / desaparecer.
Lo siento por mis francés:)
¿Por qué no hacer ambas cosas y dejar que las pruebas A / B le digan qué prefieren sus usuarios?
Ambos estilos tienen sus usos. Recuerde que siempre debe usar la herramienta adecuada para el trabajo y que hay (casi) inexistentes en la creación de software.
En la mayoría de los casos, es preferible utilizar una IU estática con elementos atenuados. Al proporcionar un mensaje simple y no molesto (por ejemplo, no mostrar un cuadro de mensaje modal) cuando el usuario hace clic o intenta interactuar con los elementos atenuados, puede entrenar a sus usuarios.
Lo que realmente ocurre en la mayoría de los casos es que hay un menú atenuado y sus usuarios se preguntan qué necesitan arreglar para poder hacer clic en ese elemento. Este es un mal diseño de UI.
Una interfaz de usuario dinámica también es relevante si tiene una sección de administración extensa que NUNCA debería poder usar el usuario que inició sesión. Al ocultar la sección de administración, se evita la confusión y la "sobrecarga" de la interfaz para los usuarios que NUNCA interactuarán con los elementos de la interfaz oculta.
Se requiere una interfaz de usuario dinámica en aplicaciones como Adobe Photoshop. Hay literalmente miles de comandos y elementos de menú posibles en Adobe Photoshop. La única forma en que cualquier usuario puede comprender la interfaz es ocultando y mostrando los elementos de la interfaz de usuario dependiendo del estado de la aplicación.
Ambos pueden tener sentido, siempre y cuando uses paradigmas con los que los usuarios estén familiarizados.
El control de pestañas es básicamente una IU dinámica que cambia según el estado.
Bueno, esa es la idea detrás de la última MS Office, ¿verdad? Controles que están alrededor basados en el contexto. Eso, frente a versiones anteriores con muchos menús atenuados y botones de la barra de herramientas.
Trabajé durante varios años en sistemas de control y en esos entornos, imitamos los controles de hardware (conmutadores, diales, botones) que, por supuesto, eran estáticos aunque no siempre utilizables. Este era un requisito del cliente y su posición era que el operador que usaba el sistema esperaba que el botón X siempre estuviera en el mismo lugar. Pero desde el punto de vista del diseñador y desarrollador, me sentí frustrado por la interfaz de usuario desordenada y no me gustó cuando el 95% de los botones de una pantalla estaban atenuados.
Creo que dependerá de su audiencia y del dominio y los requisitos del cliente. En mi tienda, hago que las cosas sean dinámicas y ofrezco controles que tienen sentido según el contexto. Normalmente, no mostramos botones atenuados u opciones de menú que no están disponibles en el contexto actual. Una vez que los usuarios reconocen que siguen ciertos flujos de trabajo y aquellos involucran elementos de IU particulares cuando corresponde, no tienen problemas con (y probablemente prefieren) una IU dinámica.
Menos es mejor.
Casi siempre mantengo la UI estática y simplemente desactivo (gris) los componentes que no son aplicables en este momento. Puede ser discordante para el usuario y confuso si los componentes se mueven a medida que los muestra / oculta a medida que cambia el estado.
Creo que depende de qué usuarios quieras ocultar el diseño, pero en general, optaría por la versión estática. No olvide que una interfaz de usuario no solo proporciona funcionalidad sino también información. Si agotas un botón, informa al usuario sobre su estado (por lo que puede hacer y lo que no) con mayor claridad que al quitar los botones.
El enfoque del botón de eliminación puede funcionar para los usuarios que, en general, tienen una buena comprensión del sistema, como los administradores. Pero creo que deberías usar esto con causion
Creo que es mejor enfocarse en la productividad del usuario y en el negocio que el software está implementando.
Mostrar operaciones que no tiene sentido para un usuario específico o en un momento específico no ayudará, deshabilitado o no.
Por ejemplo, si tiene un software que se usa en varios departamentos de una organización, cada usuario / departamento solo estará interesado en la parte del software que implementa la parte de la empresa en la que está involucrado. Cualquier otra cosa es inútil para él y solo hará que la experiencia del software sea peor. Lo mismo aplica para una pantalla que es útil para un usuario pero muestra opciones inútiles.
De acuerdo con Joel, ninguno :-)
Depende Pero una GUI clara y compacta es algo agradable de tener. ¿Por qué molestarse con 10 campos / controles que no puede cambiar o usar en absoluto? Por ejemplo, en tiene una IU reducida si solo tiene una baja reputación, porque no le importa para nada al usuario, que algún día podría usarla. Otra cosa es que los controles (con bordes) usualmente toman más espacio que solo el texto. Si tiene información, que actualmente no se puede cambiar, las presentaría en un campo / etiqueta de texto muy compacto. Dependiendo de la información, incluso podría colocarse fuera o lejos del formulario.
En mi opinión, una GUI estática con controles desactivados es preferible.
Cuando algunas opciones no son visibles, el usuario no sabrá que existen.
Haga que la acción no esté disponible (ocultando, deshabilitando o usando un mensaje de error) solo si la acción es lógicamente imposible para el estado actual de la tarea, o codifique las reglas de la organización sobre las acciones que ciertos usuarios pueden hacer (por ejemplo, privilegios / permisos). Siempre que sea posible, siempre las acciones del usuario estarán disponibles:
Use indicadores de estado para desalentar acciones innecesarias, pero permitalas de todos modos.
Use verificación y deshacer para evitar daños permanentes provocados por acciones desaconsejables, en lugar de rechazar las acciones. Los usuarios pueden necesitar hacer algo algún día que, por lo general, es "desaconsejable".
Modifique el diseño de la aplicación para hacer que las acciones siempre sean posibles de alguna manera. Por ejemplo, si un campo necesita completarse antes de que se pueda realizar una acción, solicite al usuario el campo, en lugar de rechazar la acción.
Controle el comportamiento del usuario a través de la política de la organización, no del software. Las políticas son más fáciles de cambiar cuando las reglas comerciales cambian o cuando hay una excepción o emergencia.
Use la desactivación cuando:
El usuario puede hacer algo en la aplicación para que la acción esté disponible.
La disponibilidad se logra mediante controles en la misma ventana o su principal.
El usuario puede descubrir fácilmente qué control hace esto.
Utilice los controles de alternancia en lugar de deshabilitar para encender y apagar procesos.
Utilice cuadros de texto de solo lectura en lugar de cuadros de texto deshabilitados para los datos que son aplicables para el estado actual incambiable por el usuario.
Usar ocultación ("IU dinámica"):
Para acciones que nunca están disponibles para el usuario en su trabajo actual.
Para indicar diferentes lugares virtuales o cosas (por ejemplo, páginas en un control de pestaña, donde cada "pestaña" es un lugar o cosa diferente). Asegúrate de que el diseño visual sea compatible con esto: si representas diferentes lugares, haz que parezcan diferentes lugares (por ejemplo, la forma en que lo hacen las pestañas)
Para intercambiar una gran cantidad de controles con controles alternativos.
Utilice el diseño, los símbolos y el texto para explicar la indisponibilidad, especialmente la desactivación. Por ejemplo, marque sus campos obligatorios; usa la información sobre herramientas para decir por qué un botón está deshabilitado.
Use mensajes de error en lugar de deshabilitar u ocultar cuando no haya otro medio para indicar gráficamente o textualmente cómo hacer que una acción esté disponible.
Más detalles y justificación en http://www.zuschlogin.com/?p=40 .
He visto buenos ejemplos de ambos y malos ejemplos de ambos.
Su objetivo principal debe ser asegurarse de que el diseño de su IU (sea cual sea la ruta que elija) hace que todo el proceso sea lógicamente sensato para su público objetivo.
La consistencia es probablemente lo más importante al diseñar una UI. Si los botones aparecen y salen, se ven como un estímulo visual, y el usuario "gastará" atención mirándolos.
Un botón sutil pero claramente desactivado (que no desaparece) es mi opción preferida para diseñar UI ...
.. Así que supongo que es la opción 1 :)
La dinámica es mejor si no quieres frustrar a tus usuarios
Lo que sea que elija, use posiciones constantes de los botones. Los usuarios a menudo no son texto leído en los botones.
Los botones en gris son mejores, porque entonces el usuario sabrá que en alguna situación dicha función está disponible (y dependiendo del contexto que el usuario pueda adivinar cuando esté habilitada), y la señal visual de estar en gris señalará para el usuario que no se puede hacer clic en el botón, por lo que el usuario no intentará hacer clic en él (el problema con un mensaje después de hacer clic es que llega demasiado tarde, el usuario ya cometió un error).
No creo que haya una respuesta correcta o incorrecta a esta pregunta, creo que es solo una cuestión de opinión / preferencia.
Personalmente, expondría toda la funcionalidad al usuario y simplemente la atenuaré cuando no sea accesible. Sin embargo, hay algunas situaciones en las que consideraría quitar los botones de la vista, por ejemplo
- Opciones administrativas (probablemente no desee exponer esto a usuarios con privilegios menores)
- Funcionalidad RunOnce (activando producto / registrando)
Las razones para esto es que no tiene sentido exponer la funcionalidad cuando el usuario no tiene la intención de acceder a ellas o si la funcionalidad va a permanecer allí en grisácea para siempre ...
Espero que ayude.
Siempre recomendé una interfaz de usuario que sea lo más invariable posible:
- No sorprender a los usuarios
Solo para repetir lo que dijo Mitch Wheat realmente.
Si haces desaparecer los botones y vuelven a aparecer según las acciones del usuario, existe el peligro de que el usuario piense que ha hecho algo que no funciona.
También está ocultando acciones del usuario, por lo que será más difícil para ellos descubrir qué puede hacer.
Deshabilitar botones es un paradigma bien conocido y los usuarios podrán ver todo lo que su aplicación puede hacer y experimentar para ver cómo habilitarlos.
Sugeriría crear prototipos y preguntar a sus usuarios (o una muestra representativa) cuál prefieren y por qué.
Una combinación de los dos.
Si una función no es aplicable en el estado actual, deshabilite el botón pero también coloque un ícono al lado del botón y asocie una información sobre herramientas con el ícono. La información sobre herramientas debe explicar por qué el usuario no puede usar el botón en este momento.
Adjuntar la información sobre herramientas directamente al botón no funciona tan bien. La mayoría de los usuarios ni siquiera pasarán el cursor sobre el botón, ya que no esperan que haga nada.
Y evita los iconos de exclamación. Sugieren que el usuario ha ingresado un valor inválido (a menos que realmente lo tengan).
Me gustaría decir que siempre hago esto, pero desafortunadamente toma mucho más tiempo de codificación, y los clientes no siempre están dispuestos a pagar por eso.
Si una acción no está disponible porque el perfil del usuario prohíbe su uso, no la muestre en absoluto.
Si una acción no está disponible solo porque otra acción debe completarse primero, ya sea:
Gray it out o
Déjelo activado pero en la ejecución muestre un mensaje con una explicación clara de por qué no se puede ejecutar
Me gusta mantener todas las opciones avanzadas ocultas debajo de una casilla de verificación "Más >>" / "Menos <<" o "Modo avanzado", según el contexto y la aplicación.
Una vez que hace clic / verifica, la ventana se expande para revelar más opciones.
Sin embargo, en términos de disponibilidad de acción (como un asistente con botones Siguiente / Anterior) siempre los muestro, y los habilito / deshabilita según la funcionalidad que sea posible.
Una interfaz de usuario modal introduce errores de modo. Siempre.
Actualmente parece que quiere elegir entre dos formas diferentes de presentar una interfaz de usuario modal. De aquellos que diría que el primero es superior (a menos que realmente tenga muchos comandos posibles, consulte la IU de Office 2007 para ver un buen ejemplo de cómo manejar esto, pero no es común tener tantos).
Si tiene el espacio y no tiene demasiados controles, realmente iría con controles desactivados, ya que muestra al usuario lo que es posible. Además, es posible que desee dejar muy claro en qué modo se encuentra la UI (no solo desde los botones que están habilitados). He visto interfaces de usuario en las que había desactivado botones, pero el usuario no ha podido descifrar qué debe hacer para habilitarlas.
En cualquier caso, asegúrese de hacer pruebas de usabilidad para descubrir qué camino es menos propenso a errores en nombre de sus usuarios.
La interfaz de usuario dinámica se hace como si la IU pudiera seguir cambiando. Los campos pueden seguir cambiando. De modo que dependiendo de eso, la información del campo obtenida de Internet está diseñada. Rembr! todos los campos similares tienen el mismo diseño, por lo que puede seguir cambiando el diseño de la interfaz de usuario y, por lo tanto, la aplicación. sin cargar la versión más nueva de la aplicación a la nube o Play Store, puede cambiar el diseño de la interfaz de usuario. Como ejemplo, el patrón y los campos de la interfaz de usuario se rellenan en la hoja de Excel y se cargan en la nube y la aplicación tiene acceso para descargar la hoja de Excel.
la explicación anterior es válida para un desarrollo de aplicaciones dinámicas de Android