Muchas veces todo el esfuerzo para conseguir este objetivo, se derrumba en el formulario de registro. Estos son algunos errores que he observado (incluso en páginas importantes):

1. Solicitar más datos de los necesarios.

Pide los datos estrictamente necesarios. Es muy tentador recopilar el mayor número de datos, sobre todo la gente de marketing se pirra por esto. Es uno de los factores que más influye en el índice de abandono.

Por ej., se puede eliminar el nombre de usuario (nick) si  basta con la dirección de correo. El usuario siempre puede ampliar la información de su perfil más adelante.

O por ejemplo, si solicitas el código postal, no será necesario preguntar por la ciudad.

2. Campo email no estándar

El campo email debe ser lo suficientemente largo y admitir letras y números, pero también los siguientes símbolos (según especificación RFC):

! # $ % & ‘ * + – / = ? ^ _ ` { | } ~ .

Por ej., Gmail admite como dirección alternativa [tu email]+[cualquier cosa]@gmail.com

3. Marear con las contraseñas

La seguridad es importante, pero no debe prevalecer por encima de la usabilidad. No tiene sentido que algo sea muy seguro si luego nadie lo utiliza.

1. La contraseña la debe elegir el usuario. Debe tener un mínimo de caracteres, pero no deben ser obligatorios números, símbolos o mayúsculas.
2. Otro error es no permitir incorporar en la contraseña ciertas palabras, como el propio nick.
3. Permitir contraseña largas. Si el campo es muy pequeño, es muy difícil darse cuenta si la contraseña se trunca mientras se escribe.
4. Por defecto, los navegadores ocultan la contraseña con asteriscos. Esto provoca más problemas de usabilidad que beneficios en la seguridad. Se recomienda no ocultar los caracteres de la contraseña o, en todo caso, que el usuario pueda seleccionarlo.

En definitiva, si el usuario cambia la contraseña que había elegido originalmente, hay más probabilidades que en un futuro la olvide.

Si te preocupa la seguridad, lo ideal advertir al usuario sobre el nivel de solidez de su contraseña.

4. Borrar algún campo del formulario.

Una ley no escrita de los formularios dice que: “cualquier selección o campo definido por el usuario es sagrado“. No hay nada que moleste más que rellenar varias veces un mismo formulario porque has cometido un error.

• Si el formulario devuelve un error, se deberían dejar los campos tal cual los he dejado el usuario, e indicar claramente el tipo de error (con excepción de la contraseña).
• Nunca borres un campo cuando haces clic en él (en serio, lo he visto en portales con millones de visitas… )
• Nunca pongas un botón “limpiar/borrar formulario”.

5. No seguir las convenciones

Las convenciones ayudan a la usabilidad. El usuario está habituado a un tipo de estructura en los formularios y reconoce los elementos del mismo.

Pasarse de original o alterar demasiado los competentes de un formulario puede llevar a confusión. ¡Pónselo fácil al usuario! ¡No le hagas pensar!

6. Campos demasiado restrictivos

Haz que sea sencillo introducir la información. Algunos errores comunes:

• Separar el email en 2 campos, para introducir por separado la dirección (antes de la @) y el domino. (mal)
• Obligar a poner el número de teléfono sin espacios o con espacios o… (mal)
• Obligar a poner el número de tarjeta sin espacios o con guiones o en varios campos separados o… (mal)
• etc.

Por último, algunas recomendaciones…

• Usar la etiqueta label
• Evitar poner la descripción de un input dentro del propio campo (por ej., “Escribe tu nombre de usuario”), aunque quede muy cool y ocupe poquito espacio.
• Validar los campos a medida que se rellenen (con AJAX si es preciso).
• Validar siempre en servidor todo los campos al enviar el formulario (para los programadores perezosos).
• Nunca usar Flash si el propio navegador te permite hacer lo mismo de forma nativa.
• Añadir un campo extra para confirmar el email como en la contraseña (la gente se equivoca a menudo al poner su email)

Me gustaría proponer una nueva etiqueta opcional para HTML:
IMG. Argumento necesario SRC=’URL’ [...]

1993, Marc Andreessen,
cofundador Netscape Communications Corporation

Estos puntos están basados en una encuesta realizada por Jupiter Research en EE.UU., pero desgraciadamente el artículo no enlaza la fuente.

Las principales motivaciones que impulsan a un usuario a abandonar una web son:

1. La página es lenta o el enlace no funciona. (84%)
2. No se encuentra la información que se buscaba. (68%)
3. No se encontró la información de la empresa. (31%)
4. Búsquedas limitada o nulas.  (23%)
5. Enlaces difíciles de identificar. (16%)
6. Información no actualizada. (6%)
7. Mapa del sitio demasiado general. (4%)
8. El sitio contiene publicidad que abre automáticamente otras ventanas. (4%)
9. Otras… (3%)

Ya hemos hablado en otras ocasiones sobre alguno de estos puntos en el blog. Por ejemplo sobre el punto 1, puede venir bien saber por qué diseñar con tablas es estúpido y como haciendo un buen uso de CSS se puede ahorrar mucho ancho de banda.

También hemos hablado del punto 5 y la necesidad de identificar claramente los enlaces de tu web.

Resumiendo “sencillez, claridad y acceso rápido”.

Visto en Usable y accesible

Ahora ha salido una nueva versión IEPNGFix v2.0 Alpha que admite también las propiedades CSS repeat y position.

Aunque suelo utilizar este parche para IE6, en muchas ocasiones recurro a un formato especial de PNG en 8 bits que aunque no admite valores de alfa intermedios, supone una alternativa si no queremos usar scripts.

Vía anieto2k

Lo peor es que cualquiera puede sufrir este problema. Ya no es necesario que el usuario tenga un deficiencia visual. El problema se presenta de una forma inesperada: debido a las modernas pantallas LCD.

Muchas de estás pantallas planas se venden con unos valores por defecto para el brillo o el contraste muy altos o muy bajos. Y como suele pasar, muchos usuarios noveles no suelen cambiarlos.

He podido observar este defecto en los monitores planos de familiares y amigos. Y nadie lo encuentra raro (si fuera la tele del comedor seguro que la cosa cambiaba). Debido a esto tuvimos algunos problemas en Mundijuegos al utilizar texto de color gris. Pese a ser un gris relativamente oscuro (60%), muchos usuarios no podían leerlo por este problema.

Otras veces es difícil diferenciar el negro de otros colores, como rojos o verdes oscuros, y el enlace se hace casi ilocalizable. Justamente la web de alzado.org, que trata temas de diseño, usabilidad, etc, peca de este problema. En mi modesto portátil me cuesta horrores distinguir los enlaces de color (rojo oscuro sin subrayar) del resto de texto (negro).

Haz visibles tus enlaces. Además de utilizar un color diferente al resto del texto, subráyalos. Y si no quieres subrayarlos, asegúrate que sean totalmente reconocibles de un simple vistazo. Tus lectores te lo agradecerán.

Artículo relacionado: “Guidelines for Visualizing Links” de Jakob Nielsen

En el rediseño de una web [...] es tan importante lo que permanece como lo que cambia. No puedes tirar por la borda las muchas horas que los usuarios han invertido en aprender a utilizar tu web hasta sentirse cómodos con ella. Por respeto al usuario es crítico que los cambios sean lo más sutiles e imperceptibles posible. Para nosotros el éxito de un rediseño es que los usuarios encuentren la página más fácil de usar sin darse cuenta de qué ha cambiado exactamente. En las pruebas con usuarios buscábamos que los usuarios pensasen que no ha cambiado nada. Mejorar sin molestar. Esa es la clave de un buen rediseño.

Jesus Encinar
Ceo de idealista.com
Comentando el rediseño de dicho portal.

Ya que esta nueva versión será compatible con IE6 y IE7, los desarrolladores web aún no sabíamos cómo se iba a activar este nuevo modo de representación. Hasta ahora se recurría al DOCTYPE para definir el tipo de render: el famoso “Quirks Mode” (también llamado modo chapuzas) o en “modo estándar“.

Gracias a Josep, me entero que para utilizar este modo superestándar se utilizará una etiqueta Meta adicional:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

Actualizado (4 de marzo de 2008):
Parece que al final Microsoft a echado marcha atrás y no será necesaria esta etiqueta.

El formato mágico

Pero, por casualidad encontré una alternativa para IE6 que podría ser útil en ciertos casos y con la que tendríamos transparencias reales en los navegadores modernos, y transparencia binaria en IE6 (como la del GIF).

Se trata de utilizar un formato especial de PNG, en el que tendríamos una imagen indexada de 8 bits con un valor alfa especifico por cada uno de los colores de la paleta (Más información en la especificación PNG).

Imagen de 32 bits optimizada con PNGOUT (3,36 KB)

Imagen de 8 bits con canal alfa optimizada con PNGOUT (2,42 KB).

Los navegadores modernos muestran correctamente este formato, pero IE6 no aplica bien el alfa y elimina todas la zonas semitransparentes, dejando sólo las zonas opacas. Esta opción puede ser válida para pequeños iconos o similares.

Ejemplo de como quedaría en IE6

Para utilizar esta triquiñuela, sólo tenemos que reducir el número de colores de la imagen y del canal alfa, y después optimizarla con PNGOUT. ¡Ojo! Photoshop no carga bien este tipo de imágenes.

También podemos utilizar Fireworks, de los pocos programas capaces de trabajar con imagenes de 8 bits con alfa.

Para utilizar un PNG de 32 bits con transparencias en Internet Explorer 6 (y 5.5) no había más solución que echar mano del poco agraciado filtro Directx AlphaImageLoader (código propietario Microsoft).

Posible solución: iepngfix.htc

Por suerte Angus Turnbul creó un atajo que nos facilita mucho la vida a los diseñadores web:

1. Descarga este fichero HTC y este GIF en tu directorio CSS
2. Añade este código en tus CSS para utilizar PNG’s con transparencia (¡ojo!, no valida)
   IMG { behavior: url(iepngfix.htc); }
3. ¡Listo!

El fichero HTC (referencia en Microsoft) es un componente HTML con un script que puede ser leído por Internet Explorer y que trata el PNG con transparencias para aplicarles el filtro. Funciona tanto para imágenes dentro de la etiqueta IMG o en los BACKGROUND de CSS

Ejemplos

Por ejemplo, si tenemos definido el siguiente fondo:

DIV#base { background: url(imagen-con-alfa.png); }

Añadiríamos la siguiente línea en nuestro CSS:

IMG, DIV#base { behavior: url(iepngfix.htc); }

Aunque aconsejo utilizarlo sólo en los fondos o imágenes que lo necesiten. Podemos utilizar, por ejemplo, la siguiente clase:

IMG.transparencia { behavior: url(iepngfix.htc); }

Las pegas

• Los fondos en PNG no se pueden repetir, es decir, no se pueden usar como tiles.
• Hay que definir los tamaños de las imagenes con width y height o crear un contenedor tipo DIV con el tamaño apropiado. También es posible editar el fichero HTC y cambiar la propiedad SCALE por CROP para evitar esto.
• No se puede utilizar padding o border
• Más detalles

Véase también

• PNG de 8 bits con canal alfa (la alternativa a IE6)
• Por qué según Yahoo no se debe usar AlphaImageLoader: Image Optimization, Part 5: AlphaImageLoader

Para probar tu página web en una Wii (sin usar una Wii, obviamente) puedes usar el navegador Opera (Opera for desktop) y cambiar el modo de renderizado a 5 en la configuración de navegador (RenderingMode=5). Para acceder a esta opción escribe en el campo de direcciones:

opera:config#UserPrefs|Renderingmode

Algunos detalles…

• Opera admite HTML, XHTML, XML, WML, RSS – Atom, CSS 3, XSLT, SVG, y JavaScript; excepto designMode, contentEditable, y audio.
• Utiliza una pantalla virtual de 800px, aunque la resolución de las televisiones suele ser bastante peor. El zoom es imprescindible en muchos casos.
• Lo ideal son los diseño elásticos (yo prefiero llamarlos flexibles). Nada de utilizar “px“. La página se adapta al dispositivo, y no al contrario.
• El único plug-in que soporta es Flash 7
• A nivel de CSS, admite media="tv" (¡woh!). Si este tipo no está presente, opta por el tipo screen, aunque, como indica la especificación, nunca los mezclará.
• También admite Web Forms 2.0. Están muy bien, aunque el soporte en otros navegadores es nulo,
• Sólo dispone de dos tipografías. Una sans-serif (Wii NTLG PGothic) y otra monoespaciada (Wii NTLG Gothic)

Más información Making Wii-friendly pages