Julianab

Ya hace varios días salió publicada la segunda parte de los comentarios de Richard Heilman acerca de los 7 principales errores que cometen los diseñadores a la hora de diseñar un sitio web. Esta vez me voy a tomar algo más de libertad a la hora de traducir el texto de Heilman guardando, por supuesto, la esencia de sus planteamientos. Un poco largo, pero bien vale la pena recordar estas sugerencias que, como bien me comentaban, provienen de la práctica más que de lo teórico.
Error #4: Compartir problemas con el visitante
Una preocupación comprensible que podemos tener a la hora de desarrollar un sitio web es la de proteger los contenidos publicados. Esto es válido para la protección contra hackers, contra virus y contra el robo de información sin la debida protección de derechos. Para Heilman está claro que no debemos dar al usuario tareas adicionales que lo distraigan de lo que verdaderamente viene a buscar a nuestra página. Hacerle las cosas más difíciles con pasos adicionales para contactarnos, por ejemplo no hace que nuestro site sea mejor. Todo lo contrario.
Dos puntos importantes acá: 1) una de las cosas más importantes es ofrecerle al usuario una vía clara de comunicación con nosotros, ya que ello le muestra apertura por nuestra parte a escuchar sus quejas y problemas. En algunos países es una obligación legal dejar muy claro cuál es ese punto de contacto; 2) la protección del material gráfico: para Heilman la protección real de derechos de autor para documentos gráficos es en el fondo una ilusión, ya que cualquier persona con una cierta habilidad puede hacerse con ellos así que ¿por qué hacérselo más difícil a los usuarios impidiéndoles hacer clic con el botón derecho y copiarlos?
Implicaciones para el desarrollo
* No prometa ninguna protección basada en JavaScript- o CSS, ya que tal cosa no existe.
* Enseñe a los usuarios la importancia de los canales de comunicación. Una página web es, en primer lugar, un espacio para transmitir información pero también es una invitación a comunicarse. La cantidad de preguntas o dudas que se transformen en soluciones son una medida clara de nuestro éxito como aliados.
* Encuentre soluciones al tema del spam desde el inicio, en lugar de hacerle las cosas más difíciles al usuario final.
Error #5: Tratar de resolver los problemas fuera de su área de experiencia
Este punto, de alguna manera, es acerca de no perder el tiempo programando para solucionar problemas que ya han sido solucionados por otros. El ejemplo que da el autor, y que tiene que ver con el tema de la accesibilidad, es el del tamaño de la fuente. Los navegadores vienen con una herramienta para que el usuario programe el tamaño de la fuente en la cual desea ver su página. En lugar de trabajar más haciendo una herramienta interna de personalización para eso, quizás sería mejor indicarle al usuario cómo hacerlo con las que ya vienen en su navegador predilecto.
¿Qué significa todo esto para el proceso de desarrollo?
* No se emocione demasiado con el desarrollo de agentes y aplicaciones que ya hayan sido diseñados por otros. Recuerde que hay muchas aplicaciones útiles allá afuera.
* No replique. Si quiere hacer la navegación de los usuarios poco experimentados más fácil, simplemente publique pequeñas guías para ellos.
* Si usted va a agregar sus propias utilidades hágalas a prueba de todo.
* Si le va a dar a los visitantes la oportunidad de mejorar su página, hágalo adecuadamente: ofrezca vías para cambiar la visualización, agregar o eliminar secciones, ofrezca alternativas de navegación.
* Tenga en cuenta las inconsistencias que permanecen en los navegadores. Tal parece que a los desarrolladores les encanta agregar pero tienen resistencia a eliminarlas.
Error #6: Esconder o resaltar elementos de accesibilidad y de usabilidad.
No hay muchas mejoras a la accesibilidad que puedan cambiar drásticamente la salida de un sitio y muchas veces, simplemente, no son necesarias. Una que posiblemente si es necesaria y que causa mucho ruido en las listas de discusión es la que se refiere a los “links de salto” (Skip links).
Estos links ayudan a los visitantes a pasar por secciones repetitivas de la página -como aquellos 30 links antes de llegar a la primera línea de contenido. Son muy útiles para usuarios ciegos, pero también ayudan a aquellos que son dependientes del acceso a través del teclado o que navegan a través de pantallas muy pequeñas como PDA´s o teléfonos celulares.
¿Qué daño haría un link para ir directamente al contenido, en un tipo más pequeño y alineado a la derecha en lugar de escondido con CSS? Tanto como un aviso de certificación de Accesibilidad y visibilidad al pie de la página un enlace de ese tipo mostraría a sus clientes que su empresa atiende las necesidades de sus visitantes.
Los mismo aplica para todos los señalamiento contextuales (elementos resaltados, etiquetas, por ejemplo) que, puede que no se vean sexy pero que sirven a un propósito: permiten que el usuario perciba que hay una unidad lógica en todos ellos.
Los links tienen diferentes estados y tiene sentido que definamos diferentes visualizaciones para cada uno de ellos.
Implicaciones para el desarrollo:
* Asegúrese de que cualquier mejora en la accesibilidad que usted incluya pueda ser usada por aquellos que la necesitan. Los links de “salto” (Skip links) no son sólo para usuarios que leen en pantalla.
* Aunque no sea obvio de entrada, la manera en la que los buscadores organizan sus controles y links tiene un sentido. Si usted quiere obviarlos y hacer algo distinto es mejor que haga buenas pruebas de usabilidad con seres humanos para probar su eficacia. Quienes desarrollaron los buscadores más famosos lo hicieron (No en balde –y este es un agregado mío- el IE7 incorpora en esta nueva versión muchas de las facilidades que han hecho a Firefox subir en su favoritismo).
* Siempre que usted intente mejorar el aspecto de una forma usted pierde el beneficio del reconocimiento instantáneo. Debe tomar esto en cuenta a la hora de innovar la apariencia.

Error#7: Atender a su cliente y no a los clientes de su cliente.

Los tiempos en los cuales nuestros clientes no sabían nada acerca de la Web y en los cuales se creían cualquier cosa que les dijéramos lamentablemente han pasado. Años de vendedores de software, revistas, desarrolladores web o familiares diciéndole a nuestros clientes que diseñar para la web es tan fácil como apretar un botón han hecho que nuestro trabajo sea mucho más difícil de llevar de lo que debería.
Los clientes aman la visuales y se dejan llevar más fácilmente por un menú trancisional que por un mapa bien organizado con ejemplos que lo ayuden, sucintamente, a conseguir lo que está buscando en el menor tiempo posible.
Los clientes tampoco están muy dispuestos hoy en día a gastar mucho dinero y quieren resultados tangibles muy rápidamente. Talleres, entrenamientos, ejercicios de card-sorting, sesiones de arquitectura de la información, ejercicios y análisis competitivos permiten ahorra tiempo de desarrollo ya que usted no codificará nada que no haya sido pensado y probado de antemano. Estas actividades, sin embargo, no producen “algo” en sí mismas y son difíciles de vender para el muy corto tiempo con el que contamos. La rapidez con la que se mueve la web da la impresión de que el desarrollo debe ser tan rápido como el uso que se le da a la aplicación. Algunos clientes creen que al darnos una presentación con los contenidos tal como deberían estar en la web, han hecho la mitad del trabajo.
Es tentador recortar por todos lados para mantener contentos a nuestros clientes. Si ellos usan nada más que Internet Explorer, ¿por qué enredarse con pruebas para otros navegadores? Si estamos presionados por el tiempo y el dinero por qué no enfocarse en el soporte para no usuarios de JavaScript en la aplicación Web? ¡Al fin y al cabo eso hacen muchas otras páginas!
La parte triste del asunto es que eso a veces funciona: nuestro cliente está contento, no hay casi feedbacks negativos de los visitantes y usted estará bien de tiempo y de dinero. Todo un éxito financiero. Pero los usuarios del producto merecen más. Y parece que nos olvidamos de ellos.
Este es el error más engañoso que hay que evitar y no puedo darle una solución para él. Nuestro cliente está más cerca de nosotros de lo que lo están sus usuarios. Lo que necesitamos es ejemplos en los cuales los desarrollos centrados en el usuario han traído mayor rentabilidad a las empresas permitiéndoles mantenerse más allá del período de crecimiento. Si usted tiene historias de ese tipo, compártalas por todos los medios.
Implicaciones para el desarrollo:

* No asienta a cualquier idea que le plantee su cliente. Usted no es un mayordomo sino un experto que debe hacer su trabajo apropiadamente.
* Asegúrese de conocer los ejemplos que obnubilan a su cliente y tener a la mano material explicativo de por qué no es buena idea implementarlos en su producto.
* No actúe impulsivamente. Explique que cada cambio necesita probarse así como el involucramiento de otras personas de la compañía como analistas de negocio, arquitectos técnicos, diseñadores, desarrolladores web, etc. Provea recursos y esquemas temporales. Adelante trabajo.
* Mantenga el número de personas contacto con el cliente en el mínimo posible. Idealmente debería ser una sola persona contacto cara a cara, delegando el resto de las tareas al equipo de trabajo. Con muchos puntos de contacto alguien puede prometer la implementación de un cambio sin consultar al grupo o subestimar el costo que este cambio de trabajo va a implicar. Los niños lo saben bien: “Si papá dice que no ¡prueba con mamá
* Comienza un catálogo de historias exitosas de diseños centrados en el cliente para todos tus proyectos. Debes ser capaz de implementar algo adicional en cada uno de ellos para ensamblar una buena carpeta para tus futuros prospectos.

El link para esta segunda parte lo pueden encontrar aquí: http://digital-web.com/articles/seven_accessibility_mistakes_part_2. Por alguna extraña razón me ha sido imposible colocar enlaces en mis post hoy.