Publicado por Viv Dehaes on 18-10-2008

Formularios diestros y siniestros

Existen tareas rutinarias, que se hacen sin prestar demasiada atención porque, ejerciendo las acciones apropiadas, obtendrá el comportamiento buscado, eso suele pasar con los formularios, más de una vez completamos campo, tab, completamos el campo siguiente, tab y así hasta llegar al final y por último aceptar. En estas acciones recurrentes más de una vez los usuarios tienen inconvenientes ya que muchas veces se encuentran ante formularios que no respetan las convenciones.

Los formularios vienen acompañados de botones para realizar acciones en combo, por ejemplo Aceptar/Cancelar.  Si tomamos en cuenta el perfil general de nuestros usuarios: occidentales que leen de izquierda a derecha, los comportamientos más frecuentemente usados del combo deberían estar a la izquierda y los no tanto a la derecha, entonces, ustedes qué creen? en un formulario, el botón de aceptar debería estar a la derecha? o a la izquierda? y el de cancelar?

A mi entender, “Aceptar” es la opción principal, a menos que se equivoquen, se arrepientan o pase algo excepcional, los usuarios no suelen cancelar formularios luego de empezar a llenarlos, entonces la acción de Aceptar debería estar a la izquierda y la de Cancelar a la derecha, no?

Hace unos días, al tratar de suscribirme a un Journal no entendía por qué, luego de terminar de llenarlo, me mostraba de nuevo el formulario vacío en vez de una página de confirmación, luego de que me pasara 2 veces, decidí prestar atención al proceso y me di cuenta que estaba apretando el botón de cancelar en vez del de guardar porque los habían puesto al reves de mis suposiciones.

He aquí la impresión de pantalla del formulario, como se ve en el área donde están los botones con las acciones (Clear form a la izquierda y Send Form a la derecha) hay un cartel resaltado en rojo que dice: Usted debe hacer clic en el botón “Send form” para completar el registro. Esto me hace pensar en que mucha gente debe equivocarse, al llenar el formulario. Pero no nos confundamos, los usuarios no son los que están errados, los que están errados son quienes realizaron esta página y cuando vieron que el número de errores crecía en vez de solucionarlo cambiando los botones de lugar, lo parcharon con un cartel.

Sin embargo no es el único ejemplo que encontré, en la siguiente imagen, de las interfases del MT 4, podemos observar que cuando se abre la ventana para publicar el sitio la acción más a mano que ofrece el formulario (contrario al imaginario popular) es Cancelar, la diferenciación por color (Gris para cancelar y azul para publicar) no sirve en este caso porque el gris del botón cancelar no es lo suficientemente claro como para darme la idea de segunda opción.

Este año llegó a mis manos los secretos del futuro de Arthur Clarke, escrito en 1962, en el  que especula con el futuro y próximos descubrimientos para fechas tan lejanas en ese entonces como 1982, si es que la humanidad no se ha destruido para esas épocas como reza la contraportada. Al final del libro  hay una suerte de calendario de inventos y progresos en una línea de tiempo que va desde el 1800 hasta el 2100, como habrán imaginado, todo lo que esa línea de tiempo expresa a partir de 1962 es futurología casi en estado puro. Podemos encontrarnos entonces que para el año 2000 se predijo la Colonización de planetas o para el 2010 el control del clima.

¿A qué viene todo esto? no soy tan pretenciosa del futuro como Clarke, no espero viajes interplanetarios, pero plantada en el año 2000 yo hubiera firmado que a 2008 ya tendríamos una web más organizada, basada en partones, en estándares para GUI, que proporcionaran  ayuda a los usuarios a través del reconocimiento de los elementos de una interfaz y su comportamiento esperado. La consistencia siempre ha sido uno de los elementos más importnates de la usabilidad, en ese sentido esta se logra por la mayoría, el comportamiento usual, o normal parte de la norma, que no es otra cosa que la regla fijada por la mayoría, todo aquello que entra dentro de la curva normal.

Jakob Nielsen, con la modestia que lo caracteriza, promueve la “Ley de la experiencia del usuario web de Jakob” en la cual postula que: los usuarios pasan mucho tiempo en otros sitios, entonces, cualquier cosa que sea usada por la mayoría de los otros sitios será grabada a fuego en los usuarios y si te desvías de esa senda tendrás grades problemas de usabilidad.

Si bien esto es cierto, creo que la falta una parte porque también es cierto que el usuario no adopta comportamientos, funciones o interfases que no tengan que ver con su modelo mental por más mayoría de sitios lo usen, entonces podríamos redefinir la ley de Jakob sosteniendo que lo que sea que se repita en la gran mayoría de los sitios también debe coincidir con la lógica de la mayoría de los usuarios para contar con su asimilación. En este sentido parece ser una serpiente que se muerde la cola ya que, a causa de las leyes estadísticas, los diseñadores, muchos de ellos por lo menos, arribarán a una solución coincidente también.

Volviendo a los botones, Jakob Nielsen sacó un artículo donde también plantea la posición de los botones OK/CANCEL, que retuerce una vuelta más el tema: ateniéndose a los estándares según las plataformas que usen sus usuarios, entonces, en lo que respecta a los botones:

  • Microsoft pone el Ok a la izquierda
  • Apple pone el Ok a la derecha

¿Entonces qué hacer? Nielsen propone, salomónicamente, que para aplicaciones de escritorio se utilice la convención que cada una de ellas propone, pero ¿qué pasa con aplicaciones web? que son casi independientes del sistema operativo, la propuesta es similar, propone mirar los logs y tomar parte por la plataformas que más te visita, en la mayoría de los casos: Windows. No sabría explicar por qué pero esta respuesta no termina de cerrarme.

Pasando a otra persona que sabe mucho del tema, Luke Wroblewski sostiene que, dentro de un formulario, las acciones de Guardar, Enviar, Continuar, son primarias ya que son las que habilitan la acción más importante dentro del form que es la finalización del mismo. En la misma dirección las acciones menos usadas como Cancelar, Borrar, o Ir Atras, son consideradas secundarias.

Debido a que muchas veces los usuarios utilizan las acciones secundarias por error, lo ocasiona muchas veces pérdida de datos es que muchos diseñadores están en contra de considerarlas en las interfaces, pero muchos otros creemos que es mejor que estén, para determinados casos y como salvaguarda para los usuarios. (ver post El botón reset en formularios web de octubre de 2003).

La situación que se presenta es la siguiente, necesitamos posicionar dos acciones, una primaria y una secundaria, una que nos llevará al éxito y una que podría ser letal para nuestros planes en un mismo sector, pero de manera tal que queden perfectamente diferenciadas. ¿Cómo podremos lograr esto?

Una estrategia muy usada es reducir la importancia visual de las acciones secundarias acompañadas o no, por un resaltado de las acciones primarias, esto ayudará a enfocar la atención del usuario hacia las acciones importantes pero sin dejar de ofrecerle un escape por si lo necesita.

Esta imagen es un buen ejemplo, pertenece a Feedly y muestra en la esquina derecha cómo el botón de la acción primaria “Suscribe” es visible y la acción secundaria “Cancel” ni siquiera es un botón, sino que es un link en donde además de haber perdido jerarquía de acción de formulario, el que sea un link reduce el área clicleable y de esta manera también la posiblidad de accionarlo por error.

Mientras que los estándares en la web siguen rondando en torno a código palpable (CSS, HTML, XML, incluso accesibilidad) cuesta mucho ponerse de acuerdo en cuanto  a los mecanismos que proporcionan la experiencia del usuario en la web, cuestiones como navegación, interacción, y acciones complejas son quizás demasiado subjetivas para un único criterio, para el “diseño centrado en el usuario” porque lo primero que hay que preguntarse es ¿quien es mi usuario?

Hasta la próxima!

Enlaces recomendados:


    6 Comentarios

  1. Es muy cierto lo que dices, hasta me he encontrado con formularios que tienen 3 botones (¿cerrar?, limpiar, enviar)… no me preguntes porqué ese 3° botón (quizás, propio de alguien que desarrolla para escritorio).

    Por otro lado, también hay que tener en cuenta que si se deja en primer lugar el botón de enviar, existe mayor probabilidad de que alguien envíe los datos sin terminar por error.

    En todo caso, creo que como se haya implementado, si está a la izquierda el botón de limpiar, este debería preguntar al usuario para confirmar la acción; y si está a la izquierda el botón de enviar, debería haber una pantalla en la cual pueda confirmar ‘visualmente’ los datos que ingresó.

    Ya se que en este caso quizás nos alejamos un poco del aspecto de usabilidad (mucha ventanita emergente, o ventanas intermedias), pero al menos solucionamos el problema de pérdida de datos, o recepción de datos incompletos.

    Saludos!

    p.d: por cierto, apretando TAB desde este último campo, me patea hacia arriba de la página y no al botón de enviar, jeje ¿existe alguna forma de solucionar eso? a mi también me pasa con un diseño que uso…

  2. Viv Dehaes dice:

    Hola Federico!

    Gracias por tus comentarios! Un tema que no se trató en este artículo es la recomendación de evitar que los botones con acciones de los formularios se accionen antes de tiempo, es decir antes de que los campos estén completos, para ello hay diferentes variantes que cubren ajax, javascript, etc,

    Con repecto a la página de confirmación hay casos en que es necesaria, spbre todo cuando los datos son sensibles y se necesita minimizar el error al máximo pero no recomiendo pop-up en estos casos sino que toda la interacción se desarrolle dentro de la misma pantalla.

    Con respecto a tu observación del TAB, te agradezco el comentario ya que no sabía que no estaba funcionando, en mi caso era un error en el tabindex.

    El tabindex es un atributo que se utiliza en los formularios para indicar el orden de tabulación, puedes encontrar más información sobre su implementación en el siguiente enlace:

    http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex

    Nuevamente gracias por tus comentarios!

  3. Gracias por las observaciones (siempre es bueno tener una opinión de gente que sabe más de uno en estos temas jeje).

    En cuanto al TabIndex, siempre pensé que solo estaba implementado para aplicaciones de escritorio :-O

    Todos los días se aprende algo nuevo! gracias!!!

    Saludos

  4. Pablo dice:

    En las aplicaciones web yo trato de minimizar las botones en los formularios, más aún los que están en la parte pública (cometarios, contacto, etc.).

    El botón que envía el formulario siempre lo coloco a la derecha porque para mí es mucho más intuitivo. A la derecha me dá la sensación de “avanzar” “>” ir hacia adelante, enviar.

    En el caso de ser necesario utilizar otro botón para acciones secundarias trato de usar enlaces o botones más chicos o menos “visibles”, o destacar el botón que invita a la acción.

    Saludos, muy buen artículo.

  5. Luis Parker dice:

    Hola,

    La alternativa de poner “Cancelar” como link en lugar de botón no es solo para reducir su área clickeable (un beneficio colateral), sino porque en términos generales los botones implican una acción y los links un acceso a otra página. Al cancelar uno realmente no ejecuta nada, sino que vuelve a la página anterior o accede a otra, y por eso el link es más consistente.

    @Pablo: Ojo con el “para mí es mucho más intuitivo”. Sin querer hacemos todo el tiempo asunciones que después no se corresponden con el comportamiento real de los usuarios.

    Saludos!

  6. Adrián Ramiro dice:

    Excelente análisis. Particularmente le tengo un poco de repulsión al boton “Reset Form”, y más de una vez caí en la trampa de que la primera opción sea borrar el formulario, con la consiguiente furia que causa! También cuando el TabIndex está organizado por algun malévolo editor WYSIWYG.

    Sinceramente no entiendo del todo la funcionalidad del “Reset Form”, porque si lo que queremos es que el usuario no ingrese nada, un link “Volver Atrás” me suena más correcto, y que se haya equivocado en todos los campos lo veo dificil.

    Para salvar el ingreso incompleto de datos se necesita exactamente el mismo código en el boton “Submit” que para frenar al usuario de que borre todo con el “Reset Form”.

    Hasta la función predeterminada del “Enter”, de ser “Submit” puede ser arma de doble filo.

    Nota al margen, en Mac, “Aceptar” normalmente es la única opción, asi que no importa donde este :P