A pesar de no poder ver el mensaje completo, me entero de lo que me quieren decir. Ahora sólo tengo que pulsar “Continuar” para que me realice la búsqueda. Pero resulta que sólo soy capaz de ver el botón “Volver” y no veo ningún botón de “Aceptar” o “Continuar”. Este botón queda también oculto detrás del banner, por lo que no puedo pulsarlo. Lo primero que me viene a la cabeza es que la página web de Iberia no me permite realizar búsquedas para poder comprar sus servicios, ya que me encuentro con un muro insalvable.

Así que redimensiono la ventana del navegador (uso una resolución de 1680×1050) para hacerla más pequeña y el mensaje se desplaza hacia la izquierda, de forma que ya puedo acceder al botón de “Continuar”. Esta acción, aunque nos parezca trivial a los desarrolladores, seguro que no se le ocure a todos los usuarios que se encuentren con este problema.

El problema está en que en las CSS usan float:left y left:50%. Esto hace que el contenedor del mensaje se posicione en el centro de la ventana del navegador. Luego lo centran aplicando un margin-left:-28.4em, que es la mitad de la anchura del mensaje. Por esos valores seguro que la resolución que usa el equipo de desarrollo es de 1280×1024 Ahora un consejo: las pruebas de tu aplicación no hay que hacerlas con tu equipo, sino con los que puedan tener tus clientes.

Al usar left:50% hacen que la posición del contenedor dependa de la anchura que tenga el navegador desde el que estás visualizando la web. La solución es sencilla: poned un left:200px y eliminad el margin-left.

Una de las primeras premisas de los programadores y diseñadores de sitios de ecommerce es “No pongas trabas al cliente en su proceso de compra. Evita que encuentre obstáculos y déjale el camino limpio hasta el botón Comprar“. En el momento de que algún usuario que acceda a tu web y por cualquier motivo no pueda finalizar una compra, estás perdiendo dinero.

Y ya que nos ponemos…

Una vez superado el tema de no poder hacer la búsqueda, llego a la pantalla en que me dicen los precios del billete que me interesa. Como bien me habían avisado, la reserva se ha calculado en la moneda del país de salida del vuelo. En este caso, coronas danesas. Pero… ¿dónde está el conversor a euros o la cotización aproximada de la corona danesa?

No me puedo creer que ahora tenga que ir a buscar un conversor online y tener que calcularme yo mi propia factura. Me parece bien que me avisen de que me calcularán y cobrarán la factura en coronas, a pesar de que sean una compañía española y yo un cliente comprando desde España. ¿Pero ni siquiera me dicen el precio aproximado en euros? Es en este momento donde decidí dejar la web de Iberia y probar en buscadores generalistas de vuelos.

Cuando decidí volver a entrar en la web para hacer pruebas con otros navegadores y para escribir esta entrada, intenté llegar al final del proceso de compra sólo para ver si encontraba algún otro problema. Justo después de la pantalla en que decidí no comprar su billete, aparece otra prácticamente igual y con un práctico conversor de divisas.

Si ese conversor hubiese estado en la pantalla anterior, podría llegar a haberles comprado el billete a ellos (aunque me hubiese salido bastante más caro que con quien realmente compré el billete). Este es un claro ejemplo de por qué hay que cuidar la usabilidad de tus aplicaciones. Puedes tener una aplicación web que no presente dificultades técnicas a tus clientes para realizar su compra. Pero si no tienes en cuenta también la usabilidad del sitio, puedes seguir perdiendo ventas.

Las conclusiones que sacaron fueron que el factor más importante para ambos géneros es la facilidad de uso, y que tras éste, los hombre prefieren una buena velocidad de descarga mientras que las mujeres les preocupa más una navegación intuitiva. De los factores analizados en el estudio, al que menos importancia le dan tanto hombres como mujeres es la posibilidad de personalización que tiene el sitio web.

1. Poner siempre un título descriptivo al formulario.
2. Pedir información estrictamente necesaria.
3. Diferenciar los campos obligatorios, y si es posible, agrúpalos al principio del formulario.
4. Si el formulario dispone de varios pasos o páginas, indicar al usuario tanto el paso en que se encuentra como los que le quedan para finalizar (Paso 2 de 4).
5. En formularios de varios pasos, permitir que el usuario navegue al paso anterior o siguiente sin que pierda los datos ya introducidos.
6. No pedir los mismos datos varias veces. Por ejemplo, para los campos de una sección “Dirección de entrega” habilitar un checkbox “Usar los mismos datos del comprador”.
7. Agrupar los campos de forma lógica.
8. Usar una única columna de datos.
9. La anchura de los campos debe ser suficiente para que entre el texto estandar de ese campo, y campos contiguos deberían tener la misma anchura.
10. Si hay campos que sólo se deben completar dependiendo de un campo anterior, mantenerlos ocultos y mostrarlos sólo cuando el usuario tenga que completarlos.
11. No solicitar datos mediante popups o ventanas externas.
12. Realizar la validación de campos en el navegador, y preferiblemente mientras el usuario lo completa.
13. Si la validación la hacemos en el servidor, informar al usuario detalladamente de los campos incorrectos, y nunca borrar la información que ya ha completado.
14. Para campos que deben validarse en el servidor, usar AJAX. Por ejemplo, para que el usuario sepa de antemano que el nombre de usuario que quiere escoger ya está en uso.
15. Si se usa javascript, debes asegurarte de que el formulario se envía correctamente si se tiene desactivado.
16. Mostrar un texto de ayuda exclusivamente en campos que puedan ofrecer dudas de qué información se está solicitando.
17. Evitar elementos visuales que puedan molestar al completar el formulario.
18. Si no permitimos el uso de contraseñas débiles, tener un contol que informe de la fortaleza de la contraseña.
19. Para las fechas, si usamos controles de calendario nos evitamos problemas por los diferentes formatos internacionales .
20. En campos con “fecha desde” y “fecha hasta”, dar preseleccionado el campo “fecha hasta” con un valor posterior a “fecha desde”, y evitar que pueda seleccionar un valor anterior.
21. Evita los combos si no son estrictamente necesarios.
22. En los combos, los valores tienen que tener un orden lógico (orden alfabético, por ejemplo).
23. Como excepción al punto anterior, podemos poner como primera opción de la lista desplegable en valor que sabemos que hay más probabilidad que seleccione el usuario. Por ejemplo, si mostramos la versión francesa del formulario, colocar “Francia” en primer lugar del combo “País”.
24. En combos anidados (país, comunidad, provincia), no recargar la página para cargar la lista de los siguientes combos. Usar javascript o AJAX. Si recargas la página, asegurate de mantener los campos ya completos con el valor que tenían.
25. Incluir un valor “Otros” en los combos si no cubrimos todas las posibles opciones a completar.
26. Marcar siempre un valor por defecto en los combos o radiobuttons, aunque sea “Ninguno”.
27. Usar radiobuttons cuando ofrecemos como máximo tres respuestas. Si ofrecemos dos posibilidades y el texto es corto, podemos ponerlos en horizontal en vez de en vertical.
28. No marcar los checkbox que no sean obligatorios.
29. No pedir información que podemos obtener nosotros a partir de otros campos. Por ejemplo, podemos obtener la provincia a partir del código postal o la letra del DNI a partir del número de documento.
30. No incluir un botón “Limpiar formulario”.
31. Usar etiquetas (labels) descriptivas asociadas a cada campo.
32. Permitir la navegación entre campos mediante tabulación, siempre desde el campo superior al inferior.
33. No incluir las etiquetas en la navegación mediante tabulación.
34. Finalizar la navegación por tabulación en el botón “Enviar”.
35. Asignar la tecla “Intro” para que realice la acción principal.
36. Evitar que el usuario pueda enviar el mismo formulario más de una vez.
37. No fijar un timeout demasiado corto para completar el formulario.
38. Si el proceso de envío del formulario es lento, mostrar un mensaje “Enviando formulario”.
39. Una vez recibido el formulario, informar al usuario de que el proceso ha finalizado correctamente.
40. En caso de errores, mostrar información detallada, evitando el típico mensaje de “No se ha podido enviar el formulario”.

Artículos relacionados:

• Making the Web Easy to Use for Users With Disabilities
• Formularios largos: ¿una pantalla con scroll o varias páginas?
• Best practices for form design
• Directrices de usabilidad para el diseño de formularios
• Usabilidad al diseñar formularios de contacto

Una vez dentro de la sección cliente, accedo a los datos de mi última factura. Me deja descargarla en formato excel. Ahora intento acceder al histórico de facturas para descargar las de meses anteriores. Después de seleccionar la única opción que aparece en un pequeño formulario y presionar “Aceptar”, a página se recarga y no muestra nada.

Pruebo entonces desde la opción “e-factura”, donde me muestra la última, y pulso un enlace de “Si quieres ver más facturas pincha aquí”. Veo la últimas seis facturas con opciones de Visualizar, Descargar y Detalles. Ninguna de las tres opciones me permite ver mi factura detallada.

Lo único que me aparece es un popup con el siguiente texto.

Te recordamos que las descargas o visualizaciones que realices posteriormente serán notas informativas

Y de ahí no consigo pasar. He probado con Internet Explorer 6.0, IE7 y Firefox 3.0.6. Con Firefox, no cargan algunos menús, ni las CSS, y se ve todo descuadrado. Con IE se ve bien, pero no funcionan las opciones. No me atrevo ni aprobar a acceder con Opera o Safari.

Lo curioso, es que en el footer (pie de página) hay un enlace “Optimizado para…” que te da la siguiente información:

• optimizado para configuración de pantalla 800×600
• versiones de IE 5.5 y superiores

Y a continuación te explica todo el proceso que debe hacer un usuario de Windows para combiar la configuración de pantalla a 800×600. Viendo un poco por encima el código fuente, vemos que tiene hojas de estilo para CWEB_maciex5x.css, CWEB_mac.css, CWEB_explorer4x.css, CWEB_netscape4x.css, CWEB_pcns6x.css. Aquí teneis unas capturas de las diferencias de visualización entre IE y Firefox. En Firefox hay por ahí en medio un “< %@ page import=…”.

Mi primera impresión ha sido que la web está desfasada, hay opciones que no funcionan, suspende en accesibilidad y parece que la empresa no se preocupa por remediarlo. Pero hay funciones javascript con comentarios de modificación bastante recientes(diciembre de 2008). Aunque también siguen anuncios de promociones de octubre de 2008…

A veces es mejor sacar un mensaje advirtiendo que una aplicación web no es compatible con el navegador del usuario y recomendarle que use otro, que no decir nada y dejar que éste se vuelva loco intentando acceder a servicios que no funcionan.