Aquí tenéis el contenido de la presentación y el artículo (escrito junto a dos profesoras de la UdL) sobre una herramienta para Diseño Centrado en el Usuario (DCU) con que participé en el pasado congreso Interacción 2010 en Valencia.

"Más allá del cuchillo de palo: hacia una herramienta integrada para un verdadero diseño centrado en el usuario"

artículo (PDF, 525 KB)

presentación (PDF, 845 KB)

… sigue / more +++

English version of this post

Jakob Nielsen acuño el término usabilidad (o interacción persona-ordenador) de "guerrilla" para referirse a las técnicas de usabilidad que pueden aplicarse en proyectos de desarrollo de una manera informal, rápida y con pocos recursos consiguiendo resultados aceptables y evitando la barrera que supone introducir ese tipo de técnicas.

Esa usabilidad de guerrilla tiene como ventaja que puede realizarse con (relativamente) poca implicación del equipo de desarrollo, y es por tanto aplicable en el caso de desarrollos de sitios web tradicionales. Por su naturaleza, los sitios web tienen que ser autoexplicativos y tener un funcionamiento que siga los estándares existentes, ya que su público potencial es habitualmente muy variado y no puede confiarse en conocimientos avanzados o una formación previa.

Por ejemplo, puede aplicarse perfectamente la usabilidad de guerrilla en la evaluación de un sitio web de comercio electrónico, o en el de una universidad, ya que (en principio) no necesitan mayores conocimientos previos.

Sin embargo, existen situaciones en las que no es tan sencillo… … sigue / more +++

^{This post is also available in English.} 

La expresión "Diseño Centrado en el Usuario" (DCU, o UCD en inglés de User Centered Design) parece estar adquiriendo cada vez más popularidad, y no es de extrañar. ¿Quién va a oponerse a que el usuario, destinatario último del software, sea precisamente el centro del proceso de diseño? Pero rascando un poco bajo la superficie encontramos que no existe un consenso general sobre lo que entendemos precisamente como DCU.

Las definiciones más o menos formales como la de la Wikipedia o la de ISO 13407:1999 (no os voy a aburrir aquí con ellas) se refieren en términos muy generales a "filosofías de diseño", "modelos", "elementos que lo forman",  "principios generales", "recomendaciones", … Todo eso está muy bien, pero no sirven en el momento de la verdad: cuando uno se enfrenta al desarrollo de una interfaz de usuario.

El proceso de Diseño Centrado en el Usuario es, según la ISO 13407, algo tan genérico como esta figura.

¿Qué tenemos en la práctica?

En la práctica, la expresión DCU se refiere casi siempre a un conjunto de técnicas que se pueden aplicar a lo largo del ciclo de vida de una aplicación software, y que lo único que tienen en común es que, al menos en teoría, incluyen al usuario como principal protagonista. El número de esas técnicas puede ir desde seis (como en este artículo de Webcredible) a varias decenas (como en esta tabla interactiva de UsabilityNet). Entre esas técnicas suelen estar algunas tan dispares como los focus group, los tests con usuarios o el prototipado de interfaces.

Curiosamente, también se suelen incluir como técnicas de DCU algunas en las que no participan usuarios reales; por ejemplo, las evaluaciones heurísticas de usabilidad.

… sigue / more +++

En el blog de SQUaC hemos publicado una reseña de "Haz fácil lo imposible", la discutible traducción (casi de manual de autoayuda) del título del libro "Rocket Surgery Made Easy", la última obra de Steve Krug, autor también del popular libro de introducción a la usabilidad "No me hagas pensar" ("Don't Make Me Think ").

A pesar de que el libro está en principio dirigido a personas no expertas en usabilidad que quieran incorporar técnicas de testeo con usuarios en sus desarrollos, la obra es muy recomendable también para cualquier profesional de la usabilidad; en mi opinión, su propuesta de dedicar periódicamente mañana al mes a las pruebas e involucrar a todo el equipo de desarrollo en ellas resulta más que interesante como un primer paso para integrar desarrollo de software y usabilidad, algo en lo que todavía hay mucho por hacer.

Las propuestas de Krug son muy pragmáticas; aboga, por ejemplo, por poner en común y centrarse únicamente en los problemas de usabilidad más graves detectados, y realizar las correcciones mínimas para corregirlos antes de la próxima ronda de pruebas.

Más sobre el libro "Haz fácil lo imposible" en el blog de SQUaC.

Seguro que recuerdas Supernanny, ese programa de TV en el que una psicóloga aconsejaba a diferentes padres (habitualmente al borde de la desesperación) en cuanto a la educación de sus hijos.

Quizás te sorprenda, pero podemos extraer algunas lecciones de su modo de actuar aplicables al desarrollo de software. Y si no, veamos cuál es la estrategia de Supernanny:

• Observar el funcionamiento actual, sin intervenir en él.
• Anotar los problemas detectados y su posible solución.
• Exponer y aplicar esas soluciones al caso real.
• Comprobar la efectividad de las soluciones.

¿Creéis que Supernanny sería tan efectiva si, en vez de proceder así, esperara a que los padres acudieran a su despacho, le expusieran el problema, y ella les diera una solución sin ni siquiera conocer a sus hijos? Parece obvio que no.

Entonces ¿por qué no seguimos el mismo esquema en el desarrollo de software? Habitualmente esperamos que el cliente nos cuente sus problemas, y nosotros desarrollamos la solución, muchas veces sin conocer en entorno de trabajo ni a los usuarios.

La técnica equivalente a lo que hace Supernanny en el ámbito del Diseño Centrado en el Usuario (y en otras muchas disciplinas) suele ser conocida como "estudio de campo".

Y es que, si bien es cierto que no hay dos niños iguales, lo mismo ocurre con los usuarios y sus situaciones. Y sí, seguro que Supernanny nos ayudaría con muchos clientes.

Hace bastante tiempo que tengo en mente una idea para desarrollar una aplicación web y, cuando me decidí por fin a implementarla, elegí Google App Engine, a pesar de que no conocía Python, el único lenguaje que soporta ahora mismo (aunque ha sido una buena excusa para aprender) y a pesar de algunas limitaciones propias de un servicio gratuito y en pruebas.

Al fin y al cabo, esos inconvenientes parecían quedar ampliamente superados por las ventajas de usar la misma infraestructura que usa Google para sus propias aplicaciones: robustez, existencia de un entorno de desarrollo, APIs de gestión de usuarios, de almacenamiento de datos, etc.

… sigue / more +++

Tal como se explica en algunos artículos disponibles en la red (como este, este, o este) existen diversas similitudes entre los procesos de desarrollar un determinado software, y la realización de una película desde su concepción inicial. En esta entrada vamos a reunir esas analogías, así como descubrir algunas nuevas.

[…] seguir leyendo en METAeuFORiAS (1421 palabras)

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede extraer alguna enseñanza común; en este caso, la programación y la redacción de textos para la web.

Ricardo habla de un libro (Beautiful Code) y, más concretamente, de un capítulo titulado como su artículo: Treating Code As an Essay. En él se señala la similitud entre el código fuente de un programa y un ensayo, en el sentido de que, si bien en ambos casos su propósito es lo fundamental ("¿de qué se trata?"; "¿qué hace?"), no debe descuidarse el estilo en que están escritos, ya que no sirven de nada si no pueden ser interpretados por seres humanos.

A continuación rescata algunas reglas generales para escribir código de calidad:

• Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante
• Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas creean estrés y reducen productividad. Un lenguaje no debe obligar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el “código bello”.
• Simplicidad: Si un programa es complicado de entender no puede tener belleza.
• Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en “diagonal”.
• etc.

Inmediatamente me han venido a la memoria las reglas que da Jakob Nielsen para escribir para la web; de hecho, algunos de los puntos son prácticamente idénticos: simplicidad, brevedad, lenguaje familiar, etc. Y es que, pensándolo un poco, las situaciones no son tan diferentes:

… sigue / more +++

Después de desarrollar varias aplicaciones utilizando Microsoft Access, uno descubre que existen algunas prácticas y formas de trabajo que simplifican su desarrollo y el mantenimiento, sobre todo cuando la aplicación empieza a crecer más de lo que tenías previsto (cosa que suele pasar casi siempre).

Seguramente Access no es una base de datos que pueda soportar una gran aplicación con multitud de usuarios accediendo al mismo tiempo, que maneje una gran cantidad de datos, o con requisitos complejos de rendimiento o seguridad. Pero como herramienta que permite implementar una aplicación completa (desde las tablas de datos hasta interfaces de pantalla o informes impresos) para unos pocos usuarios de manera rápida, hay que reconocer que tiene pocos rivales. Los desarrollos con Access son tan rápidos que puede utilizarse como una herramienta de prototipado que ayude a definir claramente los requisitos de usuario antes de pasar a un sistema más potente.

1. Define bien las tablas y sus relaciones

Los desarrolladores conocen lo importante que es tener un buen modelo de datos en su aplicación. Y en Access, eso se convierte en la pantalla de Relaciones (dentro del menú Herramientas):

Es decir, define globalmente los campos de cada tabla y las relaciones entre tablas, para toda la aplicación, tal como son en la realidad (no como deberían ser). No definas tablas, campos y relaciones para necesidades puntuales que puedas tener en un formulario o informe concreto.

En concreto, evita las listas de valores y conviértelas en tablas. Si vas a guardar todos tus CD y libros en la base de datos, no introduzcas el "tipo de objeto" como una lista de valores en un campo de la tabla "Objetos" o de un formulario; mejor crea una tabla "Tipos de objeto" y guarda los valores "libro" y "CD" como registros. Si más adelante quieres añadir un nuevo tipo de objeto (como "DVD"), bastará añadirlo a la tabla y te evitarás tener que buscar todos los puntos donde está especificada la lista de valores.

[Actualización 03-mar-2008]

Tal como indica javieran en un comentario, es conveniente crear las relaciones desde el diseño de tablas. Para eso, basta con seleccionar la pestaña "Búsqueda" y la opción "Mostrar control" > "Cuadro combinado", seleccionando una tabla como "Origen de la fila"; todo esto cuando se defina un campo que obtiene los valores de otra tabla previamente creada (lo que se conoce como "clave externa").

Siguiendo con el ejemplo anterior, se trataría de utilizar esa opción cuando se defina, dentro de la tabla "Objetos", el campo "Tipo de objeto" para que indique si cada registro es un libro, un CD o un DVD.

Esta acción tiene dos efectos:

• En vez de un cuadro de texto, la interfaz de Access mostrará automáticamente un cuadro combinado para seleccionar uno de los valores existentes.
• Se crea una relación entre ambas tablas (por defecto, sin integridad referencial)

… sigue / more +++

Me escribe Jesús Hurtado, CEO de Kroonos, solicitándome que le ayude en la promoción de su web ya que pronto (el 31 de octubre) dejará de estar abierto el registro de usuarios; a partir de entonces, será necesaria una invitación. Una mención en este blog no le va a causar ninguna avalancha de visitas, pero aquí queda esto.

El sitio web se autodefine así:

Kroonos es una web 2.0 que te permitirá sacarle partido a tu tiempo libre. Un banco del tiempo global donde podrás dar y recibir ayuda de forma gratuita de otros miembros de la comunidad.

Por el momento no se puede acceder directamente a ninguna funcionalidad específica del sitio; ésta se puede intuir buceando en el foro, en el blog, etc.; pero la falta de algo más tangible posiblemente le resta cierto atractivo a la hora de registrarse. Eso sí; el concepto de una comunidad en la que los usuarios intercambian tiempo para obtener otras cosas a cambio suena lo suficientemente interesante como para tomar nota y seguir su evolución. Yo ya me he registrado.

En lo que respecta al diseño, sin hacer un análisis profundo (es decir, echando un vistazo), el aspecto de la página es bastante claro y agradable. En el caso de una web con un propósito tan original es de agradecer el texto que lleva por título "¿Qué es Kroonos?", en el que se describe su objetivo, aunque como comenté anteriormente se echa de menos una visión más concreta de la funcionalidad que ofrecerá el sitio.

Por último, no puedo evitar que me venga a la memoria Momo, la novela de Michael Ende en la que unos misteriosos hombres grises se fumaban el tiempo de la gente. Seguiremos el desarrollo de Kroonos, aunque sea sólo para comprobar de qué otros extraños modos consume la gente su tiempo.