jueves, diciembre 29, 2005
De la 'radio del pueblo' al ordenador de 100 dólares
Javier Ca�ada publica un interesante artí£µlo sobre el dise�o al servicio de las personas (PDF, 86Kb).
Entre otras cosas, nos explica la diferencia de visi�n entre los dise�adores europeos, herederos de la Bauhaus, y los estadounidenses, m᳠preocupados por el mᲫeting.
�Deberí¡os hacer en Europa un "dise�o centrado en las personas" en vez de "dise�o centrado en el usuario" y recuperar el espí²©tu de la Bauhaus?
jueves, diciembre 22, 2005
Ejemplo de libro
Southwest Airlines debe ser má³ conocida por su famoso ejemplo del uso de met᦯ras en una interfaz que como lí®¥a aé²¥a.
Esta interfaz es del a�o 97 y se ha utilizado muchí³©mas veces como paradigma del mal uso de met᦯ras visuales. En el 99, por fin, desecharon la idea.
Por eso nos hace gracia encontrarnos con un ejemplo clavado má³ de 5 a�os despué³® No decimos que se haya hecho con mala intenci�n, pero sí creemos que se ha malgastado el dinero p�blico. Otro ejemplo de que en Galicia todaví¡ tenemos un camino muy largo que recorrer...
mié²£oles, diciembre 14, 2005
Experiencia de usuario potenciada con Ruby on Rails, 1ª parte
Cualquier lenguaje de programación es una interfaz y Ruby on Rails sigue uno de los principios fundamentales del diseño de interacción: ocultar en lo posible el funcionamiento interno de la máquina (alejar el modelo de diseño del modelo de implementación). Y esto es tremendamente potente.
Con Ruby on Rails las URL no tienen que estar asociadas a directorios y ficheros del servidor, sino con objetos y acciones que pueden realizar estos objetos.
Todo esto no parece muy relacionado con el diseño centrado en el usuario (y de forma directa no tiene nada que ver). Sin embargo, al romper esta relación unívoca URL-fichero nos resulta mucho más sencillo centrarnos en la información y cómo queremos que se comporte, olvidándonos de su ubicación en el sistema de directorios.
Resumiendo: podemos crear aplicaciones más complejas y de funcionamiento más "suave" con muchísimo menos esfuerzo.
martes, diciembre 06, 2005
Una alternativa a los wireframes
Nuestra experiencia utilizando wireframes para comunicarnos con clientes y diseñadores no es muy grande, pero si lo suficiente para ver algunos problemas.
Por mucho que nos empeñemos, es difícil convencer a un cliente que se olvide del diseño (y con wireframes en HTML creo que es más difícil todavía).
También podemos condicionar la creatividad de los diseñadores visuales que pueden acabar dándole una mano de pintura al wireframe, como apunta Dan Brown en Where the wireframes are. En este artículo propone una nueva herramienta: los diagramas de página.
La idea es representar la misma información, pero de tal forma que facilite olvidarse del diseño, para que clientes se centren en lo importante y que los diseñadores trabajen sin condicionantes.
Su objetivo es acabar con los problemas de comunicación.
La idea es sencilla: narrar la descripción del contenido y funciones de la página, colocando los elementos más importantes a la izquierda y a su derecha, sucesivamente, los menos importantes.
Se hacen eco de esta técnica:
Entradas relacionadas:
sᢡdo, diciembre 03, 2005
Hace un año...
Dentro de otro año volveré con la misma historia y me seguiré preguntando ¿pero cómo pude ser tan ingenuo?
viernes, diciembre 02, 2005
(muchos) recursos
En el Centro de recursos para el eGobierno del estado de Victoria (Australia), podemos encontrar muchí³©mo material relacionado con la usabilidad, arquitectura de la informaci�n y accesibilidad, entre otros.
Supongo que una administraci�n que pone a disposici�n de los ciudadados tanta informaci�n, tendrá uy claro que los servicios web que ofrezca no pueden hacerse de cualquier manera. Mientras tanto, por aquí¬ paciencia.
jueves, diciembre 01, 2005
El correo electrónico como herramienta de trabajo
Últimamente tuvimos una serie de problemas de coordinación del trabajo con unos clientes. Ellos no entendían que nos comunicásemos preferentemente por correo electrónico, ya que el teléfono les parecía una vía más rápida y efectiva de tratar los problemas.
Nosotros ya teníamos claro que para nuestra forma de trabajar es mucho mejor comunicarse de manera habitual por correo que por teléfono, pero este hecho nos ha obligado a reflexionar y concretar cuáles son las ventajas que encontramos al utilizar el correo:
- La primera y más evidente es que es un medio escrito, por lo que la precisión de la información es más fácil de conseguir. Este hecho es fundamental en el trato con el cliente para evitar posibles malentendidos.
- Otra ventaja del correo es su carácter permanente, totalmente opuesto a la inmediatez del teléfono. De este modo, tanto nosotros como los clientes sabemos lo que hemos tratado y pactado en todo momento.
- Y la más importante para nosotros, la ayuda que el correo proporciona para la organización de proyectos. Utilizando el correo de manera inteligente, con reglas de cadena que nos clasifique los mensajes según los emisores o los asuntos, podemos tener a lo largo del tiempo una historia de cada uno de los proyectos.
Todas estas ventajas hacen que nosotros creamos rentable utilizar el correo como herramienta de comunicación preferente. Evidentemente, para comunicar un mensaje es más rápido el medio oral, pero si sumamos al proceso comunicativo la tarea de almacenar correctamente la información (tanto para el emisor como para el receptor) esa ventaja desaparece completamente.
Eso sí, habrá que contentar a los clientes menos habituados a este medio y darles una llamadita de vez en cuando.
Eyetrack: dos lecturas recomendables
Como dice Juan Carlos, el estudio de eyetrack de Alt64 se está haciendo eco en la blogosfera.
Para comprender las ventajas e inconvenientes del Eyetrack están muy bien How Accurate is Eyetrack? y Eyetrack Is Not a Solution.
Nunca he trabajado con una má±µina de estas, pero nuestra experiencia en otros trabajos nos dice que en el tratamiento estadí³´ico de datos recogidos experimentalmente, la calibraci�n de las má±µinas y los errores experimentales influyen de forma determinante.
