Hace ya un tiempo que Astracán desde su blog propuso la lectura de un libro sobre Usabilidad, concretamente de Pensar Primero de Daniel Mordecki y yo acepté el reto. Pues ya lo leí y como mi comentario al respecto es muy grande he preferido postearlo en mi blog. Es el que sigue.

Debo reconocer que no había escuchado antes hablar sobre Usabilidad. Cuando estudié había una asignatura que era Análisis de Sistemas de Gestión, la cuál ocupaba 2 horas diarias del primer curso y en ella se enseñaba a recopilar información sobre la gestión que se iba a informatizar, a desmenuzar los procesos y a preparar la implementación en la Base de Datos, todo ello con diferentes metodologías. Esta asignatura también me enseñó que era capaz de dormir con los ojos abiertos. Y efectivamente, el análisis de sistemas no tiene en cuenta al usuario final, todos los métodos y técnicas que abarca ayudan al analista a establecer las bases internas del futuro programa, sin tener en cuenta el aspecto que debe presentar al concluir. Por tanto, me he encontrado ante un libro interesante.

Al comenzar el libro, se hace una diferenciación entre los apologistas (personas que se adaptan y disfrutan con las nuevas tecnologías) y los supervivientes (personas nada apasionadas con las nuevas tecnologías que se ven obligados a usarlas). Yo me encuentro, por supuesto, entre los apologistas.

De los siete hábitos de la gente altamente ingenierizada que se describen en el libro me encuentro muy identificado con dos de ellos: "No me equivoqué al responder: tú hiciste la pregunta equivocada", "Consideran la ausencia de crítica como un cumplido".

La verdad es que no te das cuenta que existen los supervivientes hasta que te topas con ellos. Una vez hablé por teléfono con una mujer para resolverle un problema; intenté durante una hora que entrara en el disco duro y no conseguí que pasara de Mi PC, así que se dio por vencida antes que yo y me dijo que "volvería a llamar su cuñao que entiende más de esto". Sucesos que al terminar los comentamos entre nosotros y siempre decimos "¿Por qué se comprarán un ordenador sin tener ni idea?".

Pero mucha culpa de ello tenemos los programadores, que nos olvidamos del usuario final. Rescato un párrafo del libro sobre cómo se sienten estos tipos de personas: "El software es humillante: pregunta cosas que no entiendo ni sé, mientras me oculta las que él sabe y que a mí me interesan, me interrumpe permanentemente con mensajes que no me importan y que a pesar de que dicen ser extremadamente importantes no deben serlo, porque los cierro sin leer y sigo trabajando. Me hace perder enormes cantidades de tiempo cuando se cae, se olvida permanentemente de lo que le digo, no confía en mí y me echa la culpa de sus errores".

Esto ocurre mayoritariamente en las aplicaciones para ser explotadas desde el propio equipo, así que el usuario debe o aprender o aprender. Pero con el boom de Internet son estos tipos de usuarios los que tienen el poder sobre los programadores, al menos en el entorno web.

Como cualquier trabajo que se precie, la creación de una aplicación o un sitio necesita de una planificación. El eterno enfrentamiento de la Teoría versus la Práctica; en la práctica te olvidas de la teoría, al menos en mi experiencia trabajada.

Lo que en el libro llama "lista de features" yo lo estudié como "especificación de requisitos" (ERS). Uno de los requisitos que siempre se encuentran en todas (la inmensa mayoría) las aplicaciones son los informes y listados; parte ésta que, como dice el libro, siempre se deja para el final. Y es aquí, al realizar los cálculos que debe llevar el informe, donde te das cuenta que tenías que haber planteado la Base de Datos de otra manera y haber tratado los campos para los cálculos de una forma distinta, y de eso te das cuenta cuando ya tienes la aplicación hecha. Así que no queda otra que crear un nuevo campo (redundante) para no tener que retocar todo el código y cambiarlo allí donde fuere necesario. Efectivamente: un parche.

Al final le entregas al cliente lo que pidió, y claramente no era lo que esperaba, pero insistes en que está implementado todo lo que pidió. ¡Cuánto odio las reuniones! Dice Mordecki que terminamos diciendo que "no saben lo que quieren". No puedo estar más a favor de su comentario, de acuerdo que los clientes no saben diseñar pero hay veces... Hice una aplicación para ser explotada desde la delegación centro de una empresa y el resto de delegaciones, repartidas por España, accedían a esa aplicación mediante la red (Internet). Ocurría que a veces se desconectaban de Internet y dejaban de ver la aplicación, por lo que me pidieron que los datos se guardasen conforme se iban introduciendo y no cuando pulsasen el botón de Guardar, pero a la vez querían que cuando estuvieran trabajando existiera el botón de Cancelar, para deshacer los cambios y dejarlo como estaba. ¿Cómo narices hago esas dos cosas a la vez? Pues no lo hice.

El programador no debe diseñar, sin embargo siempre diseña y hay que ver la gran cantidad de tiempo que se pierde en ello. "Si muevo el botón para acá, me caben aquí la rejilla y las cajas de texto. Pero si quiero poner la nueva opción tendré que descolocarlo otra vez...", pues te puedes tirar media hora colocando quince elementos de un formulario y no llegas a verlo bien de ninguna manera.

Dos de los puntos que considero fundamentales para el buen diseño de una aplicación, después de leer el libro, son definir primero el producto final y no quitar el foco del usuario. Pero, como bien argumenta Mordecki, siempre que te reúnes con el resto de compañeros cada uno ve un usuario distinto, así que propone acabar con el Usuario, pero sólo metafóricamente (vaya, algunos sí me hubiese gustado acabar con ellos con mis propias manos...). Aún así considero que no funcionaría del todo, vuelvo a rescatar ejemplos: en una parte de una aplicación, el cliente me dijo expresamente cómo debía modificarla, después de haberla hecho en un principio pensando en su comodidad; a la semana me llama y me dice que lo vuelva a poner como estaba antes porque la aplicación la usan varias personas más y les era más cómodo como estaba antes; cuelgo el teléfono dándome cuenta que no le había dado recuerdos para su madre...

El libro continúa creando personajes y escenarios para cumplir los objetivos de la aplicación. Esta parte no la he puesto en práctica pero resultaría interesante intentarlo alguna vez, por su originalidad y forma de análisis.

Ya al final, habla de la usabilidad: "el desafío de la Usabilidad es entender cómo ven el software quienes lo utilizan, qué piensan cuando lo usan, qué pistas le otorgan a los usuarios las respuestas que el software les da, entender por qué toman sus decisiones cuando se deciden por una u otra opción. [...] La Usabilidad tiene como objetivo analizar el nivel de coincidencia que el modelo de representación de una aplicación o sitio Web expresa a través de su Interface, con el modelo mental del usuario que está sentado frente a ella".

Mientras leía el libro, que por cierto es el primero que he leído íntegramente desde el ordenador, me iban viniendo a la memoria webs, que por ser un buen o mal ejemplo, se iban describiendo en el texto.

Como ejemplo de una página bien diseñada se me vino a la cabeza www.casadellibro.com, web de una librería. Cuando te das de alta escribes tus datos y listo, como el resto de los sitios. Cuando haces un pedido, en la página de datos de envío, cogen los datos de tu cuenta y los ponen en cajas de texto para que modifiques los que quieras; además existe un cuadro de selección (checkbox) que puedes picar si quieres guardar los cambios de forma permanente, o no marcar si el cambio es únicamente para ese pedido. Una manera realmente cómoda.

Como ejemplo de una página malísimamente diseñada se me vino a la cabeza www.ikerjimenez.com, web oficial de los programas "Milenio 3" (Cadena Ser) y Cuarto Milenio (Cuatro). Esta página entra dentro de lo que yo llamo Páginas Barrocas, por estar desmesuradamente recargada. Hacía tiempo que no la visitaba, pero después de leer el libro decidí volver a entrar a ver si la habían cambiado; pero lejos de eso, no sólo no la han cambiado sino que han aumentado sus contenidos por lo que la página tarda varios minutos más en cargarse completamente; tiene página de bienvenida, hay muchos elementos moviéndose a la vez, es inmensamente grande e imposible encontrar nada si no te das varias vueltas antes: un auténtico horror, pero de eso va la página ¿no? Está claro que el webmaster no tiene ni idea de diseño, por mucha fotografía que conozca (es la misma persona que analiza las fotografías que envía la gente para comprobar si hay aparaciones o sólo son reflejos).

Mordecki escribe el libro de forma muy amena y lo explica con ejemplos fáciles de entender. Por desgracia, en el mundo real, no hay tiempo para ello, bueno, en realidad sí lo hay, pero lo dedicas a parchear el código. Es necesario un cambio de mentalidad y analizar previamente todas las cosas, pero siempre se dejan para el "ya lo veremos cuando lleguemos", y como se suele decir "vale, yo soy un mandao".

Un buen libro de análisis del que he aprendido cosas nuevas y muy recomendable.