ubicación de los labels en un formulario

[Juan Lanus]

Gente,

Los labels de los campos se ubican de dos maneras: al lado de los campos de input (formato horizontal) como en una terminal o sobre ellos (formato vertical) con letra chica como en un papel. 

Cuáles on las ventajas y desventajas de cada layout? 

Estoy decidiendo para una aplicación que tiene formularios con muchos campos, de 100 a 300. 

La audiencia contiene un porcentaje significativo de gente con nivel educacional bajo, y también seniors. 

--

Juan Lanus

[Paulo Arancibia]

Te dejo el link de un post que escribí hace un tiempo sobre este tema

http://weblogs.asp.net/pauloarancibia/archive/2008/07/07/buenas-pr-225-cticas-y-recursos-para-la-creaci-243-n-de-formularios.aspx

Y un algunos links con mas recursos

http://www.lukew.com/resources/articles/web_forms.html

http://www.lukew.com/resources/articles/WebForms_LukeW.pdf

http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php


paulo arancibia | developer | realnorth
mobile +54 911 3 291 8188
http://realnorth.net

2009/5/8 Juan Lanus <juan....@gmail.com>

[Dunga Din]

En esa cantidad(!!!!!!!!!!!) sin dudas a izquierda, dado que respeta el orden de lectura.
De colocarse arriba luego de la cuarta ya no se sabe si la pregunta corresponede contestarla arriba o abajo.

Saludos

--
D()

[Tomas Roggero]

Opino que a la izquierda, pero sin respetar el orden de lectura, esto es, a la izquierda del input pero alineado a la derecha (bien al lado) porque mas alla que se pierda la velocidad de lectura, se gana en comprension del usuario para saber que campo le corresponde.
O bien, a la izquierda alineado a la izquierda, pero bien espaciados un input del otro (2em o mas de line-height) lo cual pierde en ganas de llenar al ser un form tan alto... (aunque se podria paginar)

2009/5/8 Dunga Din <dun...@gmail.com>

--
Tomás Roggero
Online Developer // Desarrollador Online

[Michael Kay]

para tantos, elegiria el formato vertical. La forma con los dos mas
justos. Para la otra formate el ojo tiene que trabajar mucho mas. No
habrá mucha diferencia para menos de 10 campos, pero para tantos, si.

No podés bajar el numero de campos? Son muchisimos, mas para los
usuarios que corresponden.

Saludos,
Mike

[Juan Lanus]

Hi Mike,

Aparentemente para muchos campos es mejor el formato a dos columnas.

Sí, estoy bajando el número de campos paginando el formulario. Tienen secciones de tamaño razonable y cada seccción va en una página con controls tipo

(prev) 2 de 7 (next)

para que el U vea unidades que caben en una sola pantalla, approx. 

--

JL

2009/5/9 Michael Kay <mik...@peep.org>

[Juan Lanus]

Gente, les cuento que crosspostié al IxDA de USA y recibí algunas buenas respuestas allá también. El subject es "Label location". 

Estoy planeando hacer un documentito con los lineamientos resultantes, para publicar en nuestro site (?).

--

JL

2009/5/10 Juan Lanus <juan....@gmail.com>

[Euge Ortiz]

Personalmente me gusta una manera más interesante de colocar los
labels.
Les paso directamente un ejemplo:

http://www.webdesignerdepot.com/wp-content/uploads/2009/01/mobileme_login.jpg

* Pros: Se ahorra espacio, hace la interfaz minimalista y simple.

* Contras: Generalmente en estos tipos de formularios, el usuario al
hacer click (con o sin intención) en el textbox el "label" se borra, y
quizás si lo hizo sin intención, olvidará lo que había que ingresar
alli.

-- Posible solución? Que al hacer click (como en el gráfico)
sigan los labels en el textbox (quizás con alguna atenuación de color)
y cuando el usuario comience a tipear (que denota que sabe lo que está
ingresando) desaparezca el label.


Saludos!

PD: Postié ayer una invitación al Mozilla Design Challenge Summer
2009, agradecería algún comentario :-)

On 10 mayo, 20:49, Juan Lanus <juan.la...@gmail.com> wrote:
> Gente, les cuento que crosspostié al IxDA de USA y recibí algunas buenas
> respuestas allá también. El subject es "Label location". Estoy planeando
> hacer un documentito con los lineamientos resultantes, para publicar en
> nuestro site (?).
> --
> JL
>

> 2009/5/10 Juan Lanus <juan.la...@gmail.com>
>
> > Hi Mike,Aparentemente para muchos campos es mejor el formato a dos

> > columnas.
> > Sí, estoy bajando el número de campos paginando el formulario. Tienen
> > secciones de tamaño razonable y cada seccción va en una página con controls
> > tipo
> > (prev) 2 de 7 (next)
> > para que el U vea unidades que caben en una sola pantalla, approx.
> > --
> > JL
>

> > 2009/5/9 Michael Kay <mike...@peep.org>

[Tomas Roggero]

Mi Posible solucion es:
En "onfocus" desaparece el label (que por cierto, como en el ejemplo debe estar en menor opacidad que el texto que tipea el user).
En "onblur" aparece el label nuevamente si el texto escrito es nulo, vacio o 1 solo caracter.

2009/5/22 Euge Ortiz <m.eugen...@gmail.com>

[Santiago Bustelo]

Hola Eugenia!

Es un caso comparable a usar la primer opción de un menu drop-down
para poner el título (ej, "Seleccione localidad...").

La principal contra de mostrar el título/descripción dentro del campo,
es que ese texto desaparece no sólo al hacer click, sino también
después de haber ingresado texto (o hecho una selección en el menú).
Se hace entonces muy difícil identificar nuevamente el campo
posteriormente.

Por esas razones, encuentro que usar texto en el campo (o menú) como
descripcion o ayuda puede aplicarse sólo cuando:
- hay pocos campos,
- esos campos ya son conocidos previamente (ej: búsqueda o login),
- los campos piden datos de distinta naturaleza (si se piden varias
direcciones de email como "remitente", "destinatario", "CC" y "BCC",
resultará imposible saber cuál es cuál después de haberlos
completado), y
- existen elementos adicionales para comunicar la función del
formulario (ej: botón "buscar", "login", o icono de lupa de búsqueda)
en caso de que se presenten valores ingresados previamente y no se
muestren los títulos.


En cuanto a la implementación (cuándo mostrar o ocultar el campo,
etc):
- Si el label permanece cuando el usuario hace click, hasta que
empiece a tipear, parece un valor por default más que un tip. El
usuario tenderá a tratar de editarlo (ej, borrar el texto), agregando
al menos un keystroke y cierta confusión al proceso.
- Es necesario considerar el funcionamiento sin javascript por razones
de accesibilidad, y casos de usuarios en entornos restringidos (ej,
bancos). - Es necesario evitar que el texto de descripción/ayuda sea
enviado.


Para el buscador de bumeran.com hicimos una implementación no
intrusiva, con un modelo parecido al que plantea Tomás. Por
diferencias en la implementación de eventos en los navegadores,
encontramos que además del caso de onlbur, era necesario ocultar el
label también para los eventos onchange y onclick.

El script en cuestión toma el TITLE del propio INPUT como texto a
mostrar en el campo, cuando ese TITLE empieza por "*" (asterisco). El
formulario carga con values por default o vacíos, y se agregan los
textos de descripción/ayuda sólo si se dispone de javascript (en cuyo
caso también se eliminarán sin necesidad de esfuerzo adicional del
usuario).

Definir el texto a mostrar como atributo del INPUT, permite:
- separar funcionalidad (javascript y backend) de contenido (HTML),
simplificando mantenimiento y localización.
- que el script de prevalidación, que está separado de los scripts que
muestren/ocultan el texto de descripción, pueda reconocer al mismo y
evitar que se realicen búsquedas con ese texto como argumento.

Saludos!

--

Santiago Bustelo // icograma

[Manuel Razzari]

Hola todos,

Santiago, me parece muy acertada tu lista de casos en los que
conviene, o no, usar el texto dentro del campo.

Me gustaría hacer una salvedad respecto a la implementación con el
atributo title: hace unos cuantos años un tal Aaron Boodman, hoy
responsable de Google Gears, prácticamente inventó el javascript "no
intrusivo", cuando propuso en su "labels.js" [1] que el textito de
adentro de los campos fuera tomado del correspondiente <label> del
mismo, en vez de algún atributo (estándar o no). Simon Willison
explica muy claramente [2] cuales son las ventajas de esta
aproximación al problema.

Por otro lado, está bueno destacar que en el link que mandó Euge [3]
podemos ver una sutil pero interesante mejora: cuando hago foco en el
input, el texto no desaparece, sino que se atenúa. Me suena que a la
implementación inicial de esto la hizo Apple en el iPhone. Una
implementación en JavaScript podía verse hasta hace poco [4] en los
formularios que hizo Aen Tan para The Miele Guide. Pero si vamos al
sitio mencionado [5], vemos que ahora lo cambiaron a campos estándar
con labels a la izquierda... Esto refuerza lo que dice Santiago de que
sólo en casos muy puntuales este tipo de campos van a andar bien.

Al margen de todo esto, recordemos que Luke Wroblewski tiene un libro
entero dedicado al diseño de formularios, así que podemos seguir un
buen rato que seguirá habiendo tela para cortar.

Saludos y buen fin de semana para todos!
- Manuel

[1] Labels.js http://kusor.net/traducciones/youngpup.es/label/labels_js.html
[2] S. Willison y labels.js http://simonwillison.net/2002/Sep/10/labels/
[3] Link Euge http://www.webdesignerdepot.com/wp-content/uploads/2009/01/mobileme_login.jpg
[4] Caso de estudio
http://aenui.com/works/website-design/designing-the-miele-guide-website/
[5] Implementación real http://mieleguide.com/register
[6] Web Form Design http://www.rosenfeldmedia.com/books/webforms/

[Euge Ortiz]

Interesantísimos aportes! :-)
Creo que como bien dicen, existen casos para los cuales diferentes
enfoques son apropiados y otros no.

Saludos a todos!

> [1] Labels.jshttp://kusor.net/traducciones/youngpup.es/label/labels_js.html

> [2] S. Willison y labels.jshttp://simonwillison.net/2002/Sep/10/labels/

> [3] Link Eugehttp://www.webdesignerdepot.com/wp-content/uploads/2009/01/mobileme_l...
> [4] Caso de estudiohttp://aenui.com/works/website-design/designing-the-miele-guide-website/
> [5] Implementación realhttp://mieleguide.com/register
> [6] Web Form Designhttp://www.rosenfeldmedia.com/books/webforms/

[Juan Lanus]

Muy agredecido por las respuestas, comienzo a responder.

Gracias Euge. No consideraba este formato, para el caso que tengo entre manos no para otros.
En este caso no puedo aplicarlo, por la demografìa de la audiencia: una mezcla normal de iletrados de todas las edades, incluyendo la proporciòn normal de gente grande de una ciudad.
Y es incompatible con un lineamiento similar que sí puse, que es usar ese recurso para "máscaras" como por ejemplo el formato de la fecha dd/mm/aaaa adentro del campo que desaparece al escribir.

La tuya es una, como expresàs, una preferencia personal. Lo que uno haría en el propio blog.
Luego voy a subir los lineamientos que finalmente no apliqué del todo, mi versión, para más debate.

Gracias!
--
Juan Lanus

PD: leí el desafìo Mozilla y estoy tratando de pensar algo ... es interesante!

2009/5/22 Euge Ortiz <m.eugen...@gmail.com>

[Santiago Bustelo]

Hola Juan,

Las máscaras pueden implementarse de manera tal que sirvan no sólo
como referencia al usuario, sino además para restringir el input:

http://digitalbush.com/projects/masked-input-plugin/

[Juan Lanus]

Gracias a todos,

Inicié este thread a partir de una discusiòn con el cliente donde estoy trabajando, sobre la ubicaciòn de los labels el relación con los intputs correspondientes.
El cliente sostiene que es mejor poner los labels arriba de los campos, el letra chica, y a mí me parece más conveniente para los usuarios el label a la izquierda, left-aligned.

La evidencia cientìfica a favor de los labels arriba es que en estudios de eye-tracking este layout resulta más rápido, elgo así como 300ms por campo. En 100 campos serían 30000ms o 30 segundos.

Pero los estudios están hechos con sujetos de 20~30 años de edad y la audiencia target tiene todas las edades de la gente que trabaja, distribuidas como se distribuyen las edades de la gente que trabaja.
Y posiblemente los sujetos de los estudios con eye-tracking sean más computer-literate que la audiencia promedio de nuestro cliente.
Y si no tienen una visión 20-20 la lectura de los labels con font reducido puede castigar duramente los tiempos.

Aunque no fuera así, o los tests arrojaran el mismo resultado si fueran realizados con "mi" audiencia, hay mucho más en un formulario que la velocidad de localizaciòn de los campos. Estimo que llenar uno de estos formularios puede llevarle a un usuario algo entre 10 y 30 minutos, los 30 segundos no serían significativos. Y habría que descontarle el tiempo adicional para hacer el scroll extra que determina el formato vertical.

El diseño final lleva un paginado por secciones de modo que un formulario largo y árido se convierta en una sucesión de formularios menores, con artefactos para navegar entre páginas así:
         [anterior] 3 de 7 [siguiente]
con validación de los campos de cada página al avanzar a la siguiente.
Los formularios, similares a los de la AFIP de Argentina, están organizados por secciones y esas secciones se usaron para fraccionar.
Con los labels sobre los campos es más probable la necesidad del scroll vertical. Si ocurre en páginas que no sean la primera implican tiempo adicional, pero no tanto peligro de que el usuario no se de cuenta, por la esperiencia de ese primer paginado.

Como medida de seguridad adicional, no achiqué mucho el tamaño del font de los labels. Si bien esto determina más scrolling, se compensa con la mayor velocidad y precisiòn de lectura de los mayores de 50 años, que no vemos tan bien como los de 30.

Las formas "interesantes" de tratar los labels están totalmente fuera de cuestión, por el tipo de audiencia que está brevemente descripto en el post original.
Y por el tamaño de los formularios: los labels que desaparecen con OK para forms de "search" o "login". Pero no para un form de 100 ó 200 campos: còmo haría el usuario para revisarlo si los labels desaparecieron?

Hay una cantidad de conclusiones adicionales. Por ejemplo los developers se mueren por poner la validación en el evento lostFocus por que la herramienta lo soporta, pero los tests, y mi percepción, me dicen que es demasiado disruptivo para un usuario inseguro.
Estamos respetando un ciclo de tres tareas 1: cargar datos, 2: submitir, y 3: ver posibles errores, por página. No a los cambios rápidos e inesperados de tarea.

Tampoco varios campos en una misma línea: hay posibilidades de que queden sin llenar.
Pero sí cuando son campos como tipo y número de documento, que se pueden considerar una unidad y se agrega ruido si se se los presenta como campos independientes. Se identificaron varios campos con estas características y los developers tienen instrucciones de ponerlos uno al lado de otro.

Bueno basta (nadie va a leer tanto)!
En algún momento relativamente próximo voy a publicar un set de guidelines para forms en estas condiciones, basado en mi experiencia de años.

Gracias a todos!
--
Juan Lanus