sebadog

Juan Paulo me invitó a participar del primer podcast de su excelente blog Digilicious.

Estuvimos hablando un rato de usabilidad, experiencia del usuario, interacción y de todas las cosas que los que me conocen ya las escucharon 10 mil veces, así que si me conoces ni te gastes, jeje.

Gracias MAD!

Si, del humano que puso el botón donde no debía.

“Mi dedo resbaló de forma accidental y presioné el botón que se utiliza para reiniciar el coche”, declaró el piloto inglés al periódico La Presse.

El error le costó al de McLaren que le adelantaran 17 coches en las primeras vueltas del Gran Premio de Brasil, en el circuito de Interlagos.

“El coche quedó en punto muerto y tuve que reiniciar el sistema, el cual contiene el programa que controla la caja de cambios”, concluyó el piloto de McLaren.

¿Reiniciar el sistema?¿Es algo que debería hacer un piloto que maneja un motor con ruedas a 300 kilómetros por hora?

Dan Saffer

Un pequeño ejemplo de lo que paso en Santa Cruz con motivo del retiro de arquitectura de información.

No se a ustedes pero a mi cuando camino hacia algún lugar me gusta tener mi objetivo a la vista y si no lo tengo me creo objetivos más cercanos y de ahí busco otro hasta llegar al bar, mi objetivo final. Creo que hago esto porque me permite limitar mi tarea a un tamaño manejable para poder explorar y comprender todo lo que pasa en ese tramo entre mi objetivo y yo, así puedo analizar donde tengo que esquivar algo, cuanta gente hay, en fin puedo planificar ese pedacito de trayecto.

Generalmente este tramo hasta mi objetivo parcial esta delimitado por mi vista, por ejemplo si tengo que doblar en la esquina no puedo planificar más allá de esta porque no puedo ver que hay (a no ser que sea el recorrido al bar que me lo conozco de memoria). Muchas veces cuando no conozco donde estoy, cosa que me pasa seguido, me estreso un poco ya que el no conocer que hay del otro lado me provoca dudas de donde estoy y si voy bien encaminado, claro que esto me pasa cuando tengo que llegar a algún lugar en específico y no cuando estoy paseando sin mayores preocupaciones.

En el diseño de paginas web ocurre algo similar, cuando estamos navegando en una página nuestra visión esta limitada a esta página y podemos movernos en ella pero no podemos ver que hay en la próxima página, peor aun cuando estamos realizado alguna tarea de varios pasos y no podemos ver lo que viene, no nos podemos responder preguntas básicas como ¿A dónde voy? ¿Falta mucho para llegar? ¿Qué habrá en la próxima esquina? ¿Un ladrón? ¿Un bar? etc.

Este tipo de preguntas sin respuesta son lo que hacen que un usuario se sienta incómodo a la hora de navegar por un sitio web, es por eso que siempre hay que recordar que el usuario esta navegando prácticamente a ciegas y depende de lo que nosotros le digamos por lo que tenemos que comprender que tal vez para nosotros es obvio por donde hay que ir pero que al usuario hay que explicarle todo para que su nivel de ansiedad sea el mínimo posible.

Para esto hay un par de tips que paso a enumerar:

1) Cuidar que el texto de los links sean explicativos de hacia donde se dirigen o que acción realizan.

3) Avisar con anticipación si el usuario va a necesitar algo extra para realizar la tarea, por ejemplo si se necesita el numero de la factura, avisar al principio no al final porque el usuario puede que no lo traiga consigo.

Todo esto para cualquiera que haya leído algo de usabilidad no es ningún misterio y ya se han escrito miles de artículos al respecto, yo solamente lo escribo porque se me ocurrió mientras caminaba.

De ahora en más intentare escribir un TIP semanal de usabilidad, estos tips no pretenden ser un tutorial solamente son detalles a tener en cuenta.

Recuerda que los usuarios no leen las páginas si no que “escanean” en busca de lo que necesitan.
Además de esto los usuarios de una página web escanean de arriba hacia abajo y de izquierda a derecha, por lo tanto las cosas que estén ubicadas a la izquierda de la página serán más visibles para el usuario.
Esto es algo que también hay que tener en cuenta a la hora del “orden” en el que queremos que el usuario vea las cosas. Un ejemplo claro de esto son los asteriscos que marcan la obligatoriedad de los campos de un formulario, los asteriscos deben ubicarse ANTES de el nombre del campo, de esta manera que el usuario antes de leer el campo ya sepa si es obligatorio o no. Esto hace que, en caso de que sea obligatorio, el usuario preste más atención al nombre del campo y si el campo no es obligatorio puede saber de antemano que el campo no es obligatorio y puede eligir no leerlo, por lo que hace que se reduzca el tiempo para completar un formulario, haciendo la tarea más eficiente.

Ya hace un tiempo que he estado trabajando diseñando interfaces de sistemas Web utilizando el famoso Ajax y creo que es tiempo de compartir algunas conclusiones personales que he obtenido.

Es más difícil de diseñar
Si es así, y no es que no se pueda hacer es solo que lleva mucho más tiempo y es algo que todos los participantes del proyecto deben tener en cuenta.

Es más difícil de explicar
En el método tradicional era fácil solo había que hacer unos cuantos wireframes y diagramas de navegación con su descripción y todo el mundo entendía.

Utilizar Ajax implica que hay eventos que ocurren en la misma página y que seguramente involucren un cambio, como animaciones o cosas que aparecen y desaparecen, para estos casos además de los entregables anteriores hay que realizar Storyboards y descripciones más detalladas que expliquen como funciona la página.

Es más difícil de programar
La página ya no es solamente un elemento que “dibuja” lo que le dice el servidor, la página ahora tiene inteligencia y puede encargarse de ciertos procesos lógicos de la aplicación.

Esto obviamente hace que la página sea más difícil de programar, pero lo más complicado es definir cuales procesos se harán en la página y cuales en el servidor. Por un lado si pasamos procesos a la página el tiempo de respuesta para el usuario puede ser más rápida que si se consulta en el servidor, pero por el otro lado estaremos aumentando el peso de la página y dependiendo de la capacidad de proceso del cliente, cosa que en Internet desconocemos.

Lograr este equilibrio es unos de los mayores desafíos de desarrollar un sistema con Ajax.

Los browsers no están preparados, aún.
Los browsers fueron hechos originalmente para funcionar bajo el modelo tradicional de la Web y se les hicieron adaptaciones para funcionar en el modelo de Ajax, las herramientas que tienen para soportar lo que Ajax solicita son limitadas.

Se necesita de un Maquetador/Programador o de un Programador/Maquetador
Con esto quiero decir que para armar estas páginas se necesita de un perfil que escasea, un maquetador que sepa javascript no es suficiente, debe tener más conocimientos de programación avanzada y conseguir un programador que se “rebaje” a saber html y javascript también es complicado.

Parece, pero no es
Si, parece que se pueden hacer aplicaciones con las funcionalidades de las aplicaciones cliente-servidor, pero no.

Que se puedan hacer ventanas flotantes, live search, animaciones, etc. no significa que funcionen de la misma manera, hay ciertas cosas que no se pueden, o no son recomendables de hacer.

Javascript no es lo suficientemente potente
Para las animaciones los drag and drop y esas cosas javascript si sirve, donde se queda un poco corto es en el tema de parsear xml, cambiar formatos, etc. aunque claro esas cosas no se deberían hacer en el cliente pero hay veces que no queda otra.

Ajax es una palabra demasiado fácil
Si Jesee James Gareth le hubieran dejado el antiguo nombre XMLHttpRequest a los encargados de venta nunca les hubiera interesado y no lo estarían repitiendo como si vendieran limpiador en polvo en una feria y además XMLHttpRequest suena a complicado y le tendrían más miedo o por lo menos respeto.

Es fantástico!!!
La cantidad de cosas que se pueden hacer y lo mucho que mejora la experiencia del usuario en muchos aspectos es genial, creo que es un gran avance para los sistemas Web y que aun le queda mucho camino por recorrer.

Y como siempre
Las herramientas hay que usarlas cuando el usuario, la tarea y el contexto lo ameriten, no tenemos por que cargar con una pesada caja de herramientas si solo queremos clavar un clavo.