user interface - angular2 - Información sobre herramientas en la era del tacto

tooltip material 2 (12)

¿Qué hay de tocar y mantener? Creo que sería una regla de interfaz bastante simple en términos de usabilidad e implementación. Como muchas cosas que ver con la usabilidad, aunque será difícil decirlo hasta que una idea haya existido por un tiempo para verla utilizada en un montón de contextos diferentes ...

La información sobre herramientas es un paradigma de interfaz increíblemente útil para conocer una aplicación. Son el mapeo entre el control visual y la acción específica de la aplicación asociada a ese control. El usuario puede explorar la acción sin invocarla simplemente colocando el puntero del mouse.

Los dispositivos táctiles hacen que este paradigma sea básicamente imposible. Esto limita la usabilidad de la aplicación, que en algunos casos se vuelve bastante misteriosa.

¿Sabes si existe un sustituto para el concepto de información sobre herramientas para dispositivos táctiles? De hecho, carecen de un grado de libertad en la interacción de la ui: la posición del puntero. ¿Cómo recuperar este canal de comunicación de manera efectiva?

Bueno, el beneficio de la información sobre herramientas es que agrega una etapa suprayacente de información (muy pequeña) antes de que ocurra una acción. Por lo tanto, me parece que volver a agregar esa capa mediante un " doble clic " para realizar la acción con un "solo clic" para mostrar la información sería una idea equivalente.

Creo que todos hemos visto las películas con las futuras interfaces de pantalla donde alguien toca la pantalla y muestra una forma geométrica de información alrededor de ese toque. ¿Por qué no utilizar ese concepto, tener el primer toque ampliar la información sobre la acción como una información sobre herramientas útil en la página, y luego el segundo clic en el mismo lugar confirmaría / realizaría la acción.

Si no, "click-on-item-shows-tooltip-second-click-performs-action", ¿qué hay de la proximidad ? Si desea información sobre un widget UI, con suficiente espacio, puede tocar al lado del widget y recibir información sobre él, toque -on- el widget y realice la acción.

La información sobre herramientas proporciona tan poca información, en general (puntero contra mano, sugerencia de herramienta de texto, negrita) que creo que también podría duplicar la información de información prestando mucha atención al historial de acciones del usuario. Si han estado haciendo clic en dos cosas con más frecuencia que otra cosa recientemente, haga que la información sobre herramientas predeterminada y el valor agregado y el énfasis aparezcan para las pocas cosas que se hacen clic con más frecuencia en lugar de otras.

Editar: Además, al pensarlo más, arrástrelo en un espacio que no necesita desplazamiento o similar parece ser un desencadenante adecuado para la información de información sobre herramientas. Tome el teclado del iphone, por ejemplo. Cada letra tiene una información sobre herramientas mientras la arrastra, mientras que la carta en sí misma se activa cuando la suelta. Ayuda a la precisión de reposicionamiento.

Más allá de eso, creo que los detalles entran en juego. ¿Estás hablando de una tableta portátil? interfaz táctil del teléfono con espacio muy limitado? Creo que el espacio disponible juega un papel importante en cómo hacer las cosas con una interfaz táctil.

Dependiendo de a quién le preguntes, incluso podrían decirte que una interfaz que necesita consejos de herramientas para ser comprensible debe ser rediseñada, mal (ver Jef Raskin: The Humane Interface ).

De hecho, las sugerencias de herramientas son la solución a un problema muy específico: botones icónicos sin etiquetas, como los que se ven en las barras de herramientas. Siempre que tenga etiquetas, úselos. No es necesario proporcionar una información sobre herramientas porque ya tiene texto para decir qué control particular va a hacer.

Además, las interfaces táctiles no se corresponden con el modelo de interfaz WIMP actual. Muchos controles son buenos de manejar con punteros de mouse pero son frustrantes de usar con un dedo. Menus, checkboxes, botones de radio vienen a la mente. Por lo tanto, el paradigma de la interfaz para las interfaces táctiles tiene que ser bastante diferente de las interfaces actuales impulsadas por el mouse y el teclado.

Así que creo que el problema no es tanto la falta de herramientas, sino que no exploramos muchas formas nuevas de interactuar con una computadora en los últimos 30 años (básicamente, no desde la investigación realizada por Doug Engelbart y Xerox PARC). en los años 60 y 70).

La entrada táctil es lo suficientemente similar como para que funcione para la mayoría de los propósitos. Pero no solo carece de un componente de ubicación sin contacto, sino también de precisión. Básicamente, todas las entradas táctiles son buenas para tocar algo y arrastrar algo. Incluso el doble toque es difícil, por lo que lo que realmente necesitamos es un cambio fundamental en la forma de diseñar y diseñar la IU específicamente para una interfaz táctil.

Verá algo de esto en dispositivos dedicados, como el iPhone, simplemente porque esa es una plataforma que no tiene puntero de mouse ni teclado y solo lo toca. Esto significa que no tiene que construir una interfaz de usuario que tenga que ser utilizable con todos los métodos posibles de interacción (un problema con Windows en la actualidad; tengo una computadora portátil multi-táctil pero para muchas tareas el toque simplemente no funciona) pero solo con uno. Pero una solución de uso general para el software "normal" y las computadoras está bastante lejos en este momento, creo.

Así que te aconsejo que pienses un poco diferente sobre cómo diseñar tu UI. Como se dijo anteriormente (y se puede leer en Acerca de la cara de Alan Cooper), las sugerencias de herramientas son para etiquetar los controles que no tienen etiquetas o donde el espacio no sería suficiente para colocarlos. El escenario clave de uso aquí son barras de herramientas. Pero una interfaz diseñada para touch haría todos los controles más grandes de todos modos. Muchos íconos pequeños, agrupados de cerca, son difíciles de usar con la entrada táctil, incluso si tiene sugerencias de herramientas, simplemente porque carece de precisión.

Encuentro que la información sobre herramientas es muy útil y creo que todos los que argumentan que no son necesarios para un buen diseño de la interfaz de usuario piensan que es muy limitado.

Solo para darte una idea ...

En general, un buen diseño de UI (como muchas otras cosas en la vida) es aquel que es efectivo y eficiente durante un cierto período de tiempo de uso. De manera efectiva, puede hacer lo que espera que pueda hacer (por ejemplo, hacer una llamada con un teléfono móvil ). Medios eficientes, es factible con un mínimo esfuerzo del usuario (por ejemplo, simplemente escribiendo los números y presionando un botón "marcar" , sin tener que navegar primero por algunos menús). Durante un cierto período de tiempo , significa que puede no ser óptimo en el primer uso o, al revés, después de conocerlo y todo lo demás (por ejemplo, una pantalla de terminal del aeropuerto debe estar más centrada en una sola vez) -usuarios "dummies" que un software de edición de video para profesionales como Adobe Premiere ).

Dicho esto, encuentro que los tooltips son extremadamente útiles en situaciones donde

como diseñador , no quiere / no puede explicar cada detalle sobre la funcionalidad de la GUI dentro de un área determinada de la interfaz de usuario
- debido a la usabilidad, espacio general disponible, etc.
- Por ejemplo, tomando los ejemplos anteriores puede ser útil incluso en un escenario de llamada móvil simple para personas mayores .
  - Puede que no esté familiarizado con muchas cosas que "enloquecemos" ;-) resultan triviales.
  - Y se les debería alentar a que hagan clic sin miedo a llamar por teléfono a alguna línea directa de compras y finalmente estar convencidos de que no pueden vivir sin la aspiradora de 1000 EUR.
  - entonces, en este caso, un paradigma de información sobre herramientas con un solo clic podría tener sentido
    - en general, no lo recomendaría
como usuario, no está seguro del significado de alguna acción / botón proporcionado, etc.
- siguiendo de nuevo los ejemplos anteriores, incluso un usuario experimentado de Adobe Premiere puede no recordar todos los detalles sobre un área funcional determinada de todos los módulos / complementos disponibles
  - por ejemplo, si la mayoría de las veces corta videos y rara vez ajusta la configuración de audio
  - mientras que otros pueden tener el problema al revés

Ahora volvamos a las limitaciones y posibilidades de una interfaz táctil ...

:-) Hover : Hace poco vi en alguna parte, que algunos dispositivos pueden reconocer el dedo antes de que toque realmente el panel táctil o diferencia entre la intensidad táctil (por ejemplo, solo toque muy suave). Esto parece ser el colgante perfecto para la funcionalidad de información sobre herramientas establecida en las interfaces WIMP para mí
- por supuesto, dependería de las capacidades táctiles del hardware
:-) Zoom UI : en realidad me gusta el concepto de en.wikipedia.org/wiki/Zooming_user_interface mencionado por Joey también
- El concepto de usar solo dos dedos ya es bastante común para hacer zoom y la idea es bastante intuitiva, por ejemplo, muestra más detalles, como infos de información sobre herramientas típicas, al acercar o alejar un botón
- pero ciertamente introduce el problema de diferenciar entre Me gusta tener una información sobre herramientas para este botón y me gusta hacer zoom en toda el área de entrada / salida, sin tener el botón de información sobre herramientas cerca de mis dedos en mente
  - aunque creo que las áreas típicas habilitadas con herramientas son bastante diferentes de las áreas con zoom en general
    - por ejemplo, algunas áreas de contenido de lectores de PDF generalmente están bastante separadas visualmente de, por ejemplo, algunas barras de herramientas (botón)
  - información sobre herramientas para áreas sin acción, como alguna área de texto, tampoco son triviales para manejar o requerirían más "acuerdo de diferenciación de gestos"
- desde la perspectiva del desarrollo, parece también bastante robusto
:-) QM : el clic de la interrogación o la función de función arrastrar y soltar también podría ser una buena alternativa
- tener muchos de estos en todas partes en la pantalla parece estúpido, especialmente cuando tienen que adquirir un cierto espacio para poder hacer clic / arrastrarse
- tener uno para arrastrar a todas partes parece mejor, pero de nuevo requeriría espacio para ello en la pantalla
- desde una perspectiva de desarrollo, me parece al menos un poco difícil como una solución general porque el arrastrar y soltar es una característica común y diferenciar en una interfaz de usuario entre aquí viene una gota de información sobre herramientas que tengo que manejar y aquí viene una caída de archivos que tengo manejar (por ejemplo, en un área de carga de archivos ) puede no ser fácil o al menos un terreno común para los marcos existentes
: - | Hold : la idea de disparar la información sobre herramientas si el usuario no suelta el botón después de un cierto período de tiempo , por ejemplo, 1s, parece ser la segunda mejor solución para mí
- ya es una característica común en algunos escenarios, como las ventanas emergentes mencionadas del teclado en pantalla (por ejemplo, descansando en una "o" y obteniendo una lista de alternativas elegibles como oóòô )
- de nuevo, requiere cierta confianza del usuario, que no ejecutará la acción de áreas en el lanzamiento
- en algunos botones puede ser difícil diferenciar lo que el usuario quiere hacer, por ejemplo, hacer clic en un signo / botón "+" para aumentar un número y mantenerlo pulsado para aumentar más o más rápido puede contradecir esta función de información sobre herramientas
- para áreas sin acción, una acción push-hold puede no parecer intuitiva
- desde una perspectiva de desarrollo podría ser bastante fácil, aunque pueden existir algunas contradicciones de comportamiento como las mencionadas
: - | SCT / DCA : la solución de un solo clic que muestra información sobre herramientas, haga doble clic en la acción de ejecución que podría imaginarse útil en escenarios limitados
- por ejemplo, la llamada móvil para personas ancianas o ficticias mencionadas anteriormente o donde la acción debería protegerse del uso inconsciente o inseguro
- de nuevo, la perspectiva de desarrollo parece robusta de nuevo aquí
: - / SCA / DCT : la solución de un solo clic ejecuta la acción, haga doble clic en muestra información sobre herramientas parece muy extraño para mí
- Si no está seguro de alguna funcionalidad, dudaría en hacer clic en un botón, y seguramente no en dos, especialmente si no puede estar seguro si puede esperar este comportamiento.
- la perspectiva de desarrollo podría ser problemática aquí:
  - ¿Después de qué hora es un doble clic en dos simples clics?
  - ¿Qué pasa si el segundo clic no se reconoce o no se puede reconocer, por ejemplo, porque aparece otra ventana emergente, el diseño de la interfaz de usuario cambia repentinamente, el usuario no apuntó con cuidado, ...
: - / Otros gestos : usar otros gestos mencionados o en los que podría pensar, como dibujar un signo de interrogación sobre el área que se va a pinchar con la herramienta, deslizar sobre el área de alguna manera, etc.
- porque esto no parece un terreno común, no me gustaría porque también puede bloquear otras funcionalidades disponibles

Esto puede ser útil:

Google Material Tooltips

Dicen que los tooltips son

Convocado por:
Al pasar el cursor sobre un elemento con un cursor
Enfocarse en un elemento con un teclado (generalmente la tecla de tabulación)
Al tacto

No tiene mucha información solo sobre dispositivos móviles. El único toque que puedes encontrar es el del tacto, que es frustrante si tu botón hace algo, no quieres tocarlo antes de saber qué hace. La presión prolongada puede funcionar, pero algunas aplicaciones requieren una pulsación prolongada para otras funciones, es una ruta UX utilizada y un usuario no esperaría consejos largos sobre herramientas de prensa a menos que se lo indique.

Estoy pensando que la información sobre herramientas puede no funcionar las maravillas en el móvil que lo hacen en el escritorio. Sin desplazamiento, necesita otra forma reservada para recordar rápidamente o mostrarle a un usuario qué icono o botón tiene.

Lo mejor que puedo pensar es en el modo de ayuda. Presionando la configuración, luego ''ayuda'', mostrando una tarjeta corta en la parte inferior que dice algo así como ''haga clic en un elemento para obtener ayuda'' y un botón ''cerrar''. Luego, al golpear los elementos con punta de herramienta, se mostrará la información adicional para ellos.

Veo arriba este mencionado, pero otro caso de uso moderno para esto son los juegos. A menudo se diseñan con un joystick en mente, lo que significa que tienen aproximadamente 14 botones para trabajar, pero la mayoría están ocupados por las funciones del juego.

En los juegos de roles suelen tener pantallas estadísticas complejas que el jugador desconoce (a menudo inventan sistemas nuevos para cada juego) llenas de números que son importantes, pero los jugadores no saben. Muchos de ellos le permiten presionar el botón de selección para acceder al modo de información sobre herramientas / explicación.

Esto bien puede funcionar en una aplicación que es lo suficientemente compleja como para requerir información sobre herramientas en dispositivos móviles y es el único patrón que puedo ver en este momento que no está muy lejos de los diseños comunes de ux.

La información sobre herramientas en los teclados en pantalla - repita la letra que se está tocando - es evidencia suficiente para mí de que la información sobre herramientas es muy útil en una interfaz táctil. Llegué a este artículo para ver cómo podría implementarlo en una página web móvil.

Leer aquí me hizo pensar. La información sobre herramientas se usa generalmente para dar una etiqueta a botones sin texto, pero también es una gran manera de dar más información en el espacio reducido disponible en una interfaz. A veces, se utiliza para proporcionar ayuda contextual, o una explicación detallada de un único widget.

La idea de Tchalvak de dar a todos los elementos GUI un solo clic de comportamiento común, y proporcionar una información sobre herramientas con doble clic tiene sus ventajas, e incluso puede ser detectable, ya que muchas personas utilizan doble clic en todo lo que ven, independientemente del elemento .

Pero recordé el viejo ? botón que fue tan popular años atrás, que una vez hecho clic en él transformaría el cursor en un signo de interrogación. Una vez que haya hecho clic en un widget, verá una pequeña información sobre herramientas o globo de información. Creo que algo así podría ser utilizado fácilmente en una interfaz táctil. Debido a la falta de un cursor, se debe dar otra señal visual al usuario diciéndole que está en modo de ayuda . Puede cambiar el tono de la pantalla y dar un pequeño texto. También se puede hacer a través de multitouch al requerir el ? para presionar mientras presiona otro widget para obtener la información sobre herramientas (que debe mostrarse en un lugar ligeramente separado para no quedar demasiado oculto por el dedo).

Pero incluso si es posible mantener la misma funcionalidad técnica para que los programadores usen tooltips, deberíamos pensar en la intención , para qué la utilizaremos.

Lo usaría solo para brindar ayuda adicional cuando te enfrentas a una pantalla pequeña, de lo contrario, haz visible un área de ayuda en todo momento en la parte inferior de la "ventana" (refiriéndome a cualquier tipo de interfaz con forma cuadrada) , que cambia su contenido para proporcionar una explicación detallada y / o ayuda para el widget seleccionado, como se hace en algunas ventanas de preferencias en vuelo estacionario.

En conclusión, incluso si somos capaces de proporcionar información sobre herramientas fáciles de usar, deberíamos pensar en lo que pondría en él. En una interfaz táctil, no pondría un botón inequívoco y ambiguo que requiera una información sobre herramientas para ser entendido, sino que lo usaría para proporcionar ayuda avanzada y solución de problemas contextuales.

Mi respuesta no es tan práctica, pero ...

El problema se resolvería si todas las aplicaciones admitieran la funcionalidad de deshacer, y la gente se acostumbró a saber que SIEMPRE podría revertir cualquier acción.

Como dice Andreas, "si no está seguro de alguna funcionalidad, dudaría en hacer clic en un botón".

Pero con deshacer como red de seguridad, puede haber más "hacer" y menos "vacilar, preocuparse, descubrir qué sucederá antes de tocar ... tocar".

Esta es una de las razones por las que el botón Atrás es tan popular, y Android incluso lo hizo funcionar en todo el sistema.

Desafortunadamente (aquí están las impracticabilidades ...)

La construcción confiable de deshacer permanente es mucho más difícil que la información sobre herramientas
suficientes aplicaciones necesitan ser compatibles para cambiar la mentalidad de todos los usuarios (¡ja!)

Parafraseando a Einstein, un toque debería ser tan simple como debe ser, pero no más simple.

El problema subyacente aquí no es el tacto, sino el estado. ¿En qué estado se encuentra el objeto cuando lo tocas? ¿Toca cambiar su estado? ¿Cómo se refleja el cambio de estado al usuario?

Desde la perspectiva del diseño, tratar de abarcar todas las acciones con un solo toque funcionará solo en los casos más simples. Para cualquier aplicación más útil, un primer toque puede cambiar de estado, y ese estado puede reflejarse por cambios en la imagen de un objeto, por herramientas (incluso información sobre herramientas transitorias que desaparecen después de un tiempo establecido) o por otros medios. Tocar un objeto seleccionado debe tener un significado diferente a tocar un objeto no seleccionado. Esto debe ser un aspecto detectable de la interfaz.

Puedo pensar en un par de soluciones para este problema

1) Diseña tu aplicación para que no necesite información sobre herramientas. Ponga texto en los botones (aunque sean pequeños), use íconos sencillos o muestre una "burbuja de ayuda" sobre "primer uso de un botón" (con la opción de "no mostrar esto nuevamente" una vez que el usuario haya aprendido para qué sirve el botón)

2) Responda a los eventos en el retoque , no en el aterrizaje. Responda a los toques que se han mantenido durante 0.5-1 segundos mostrando una burbuja de "ayuda". Si se muestra la burbuja de ayuda, el evento normal del botón no se activará durante el retoque (por lo que los usuarios que buscan ayuda no terminan desencadenando acciones).

3) Utilice el paradigma de arrastrar y soltar "signo de interrogación" que @voyager sugirió. O haga que el usuario "toque" primero el signo de interrogación y luego toque el elemento con el que necesita ayuda.

Tal vez etiquetas persistentes que den descripciones cortas de cada funcionalidad más o menos "oscura" disponible en la interfaz, combinadas con mensajes de notificación contextual cuando se realizan acciones -p. Ej .: el usuario modifica los datos => la notificación aparece recordándole que no se olvide de guardar usando un botón que resaltaría brevemente durante esta notificación.

Ten en cuenta que los consejos emergentes son una gran ayuda para los principiantes y no necesitan ninguna acción para aprender de ellos, porque los principiantes siempre son lentos y aparecen de forma insegura moviendo el cursor. Por otro lado, son excelentes porque no disminuyen la velocidad de los usuarios avanzados.

Para las tabletas, tomaría la idea del signo de interrogación pero agregaría algo más de complejidad:

1) Cuando toca el signo de interrogación, enciende el modo "Ayuda". 2) puede tocar el control en cuestión y muestra la información sobre herramientas. 3) si luego toca nuevamente el mismo control, termina el modo de ayuda y ejecuta lo que el control debería hacer. 4) si tocas cualquier otro control, muestra su información sobre herramientas y el modo de ayuda permanece activado. 5) uno puede finalizar el modo de ayuda tocando nuevamente el signo de interrogación.