El quinto Beatle de la usabilidad

Debo confesar que el t�tulo es una "licencia" para atraer su atenci�n, una peque�a mentira. Perdone el atrevimiento, prometo que es este primer p�rrafo centrar� el tema sin adornos. Los Beatles (como casi todo el mundo sabe) eran cuatro, pero exist�a tras el escenario un quinto personaje al que se le atribuye buena parte del �xito del grupo: su manager. Pues bien, en usabilidad son cinco los principios que se suelen citar: navegaci�n, tiempo de respuesta, contenido, interactividad y facilidad de comprensi�n. Estos cinco t�rminos son nuestros "beatles", pero, al igual que en el famoso grupo musical, existe otro elemento entre bastidores: la documentaci�n. As� pues, no es el "quinto" elemento, sino el sexto... Total, que el art�culo no va de m�sica ni de un quinto elemento, sino de usabilidad y de un sexto pilar. La �nica conexi�n es que este principio fundamental (la documentaci�n) act�a desde la "trastienda" al igual que el manager.

La web est� viva, el papel, muerto

La importancia de la documentaci�n que debe acompa�ar a un documento web se puede argumentar desde infinidad de puntos de vista, pero este art�culo pretende hacerlo tan s�lo desde uno de ellos: la necesidad de mantenimiento posterior al dise�o de casi cualquier documento web. Cuando se dise�a un documento para si difusi�n en papel, se pone especial cuidado en la composici�n de las p�ginas porque, una vez impreso, ese documento ser� definitivo y no cambiar� con el paso del tiempo. Pero, al dise�ar un documento web, debemos pensar en que seguramente haya que modificarlo en breve. Esta sensibilidad de los documentos web a los cambios externos son una de las razones, junto con la universalidad del acceso y la facilidad de difusi�n, del �xito de la Web como medio de comunicaci�n. Pero, si en la fase de dise�o e implementaci�n, no hemos tenido cuidado en documentar el sitio web, las modificaciones futuras puedan degradar la calidad del mismo de manera alarmante, llegando incluso a violar los principios de dise�o que con mucho esfuerzo se hayan consensuado entre los miembros del equipo desarrollador.

Recuerdo el caso de una empresa que se dedica a la educaci�n (el nombre lo omito por razones obvias) que hace dos a�os me pidi� consejo para modificar la web que ten�an en ese momento. Fue desolador. El documento se hab�a dise�ado por una empresa externa hac�a dos a�os, el dise�o hab�a sido aprobado por la direcci�n y por varios grupos de testeadores. Era bastante buena ... pero en los dos a�os transcurridos se hab�an hecho modificaciones, ampliaciones de secciones enteras, de servicios ... sin centralizar ni por supuesto documentar dichos cambios. La empresa que originalmente dise�� el documento hab�a perdido en esos dos a�os al dise�ador que trabaj� en el proyecto y no guardaban ning�n tipo de documentaci�n sobre el particular, salvo una imagen del documento web en un CD-ROM. Cuando ped� un mapa de navegaci�n para poder comprender ( y por lo tanto, "usar" el documento) provoqu� no pocas peleas entre la empresa y la agencia que construy� el documento web.

Fue una experiencia dolorosa. En la copia del CD-ROM que me dieron llegu� a contar doce archivos llamados escudo.gif en diversos directorios. De ellos, nueve ten�an una copia exacta del escudo, mientras que los otros tres eran variaciones sobre el original. Adem�s, hab�a un n�mero a�n mayor de archivos llamados escudo1.gif, escudoa.gif, escud.jpg ... No aburrir� al lector con detalles sobre los nombres de los archivos, los directorios y dem�s elementos del CD-ROM, pero creo que es posible con el ejemplo explicado, hacerse una idea de lo dif�cil que resultaba utilizar dicho documento web como punto de partida para la nueva versi�n. Afortunadamente, yo no ten�a que realizar dicha actualizaci�n, s�lo emitir un informe sobre el documento actual. La cara y el estado de �nimo de la persona que deb�a realizar el mantenimiento de la nueva versi�n era un poema. No me extra�� que, al mes siguiente a la evaluaci�n de la web, dicha persona anunciara que se iba de la empresa... y tampoco extra�� a nadie que mi informe concluyera con dos recomendaciones: empezar desde cero la nueva versi�n con otra empresa distinta y pedir a dicha empresa una serie de documentos como primera entrega del proyecto.

La documentaci�n del documento web

�Es el caso comentado una excepci�n? Me temo que no. Muy a menudo en el futuro me he encontrado con documentos web mal documentados que hacen dif�cil o imposible asegurar su calidad despu�s de algunos meses. Porque las labores de mantenimiento pueden desbaratar un buen dise�o en un tiempo record.

�Qu� se puede hacer para evitar esa degradaci�n? Pues b�sicamente, tratar al desarrollo de documentos web con el rasero propio de los desarrollos software que es, en definitiva, lo que son. Y como cualquier proyecto de ingenier�a, adem�s del producto final, se deben exigir una serie de documentos t�cnicos. Nadie debiera comprar una casa sin el plano de un arquitecto, y por la misma raz�n, nadie debiera comprar una web sin documentar.

En la revista Econom�a Industrial, n� 326 (1.999) publiqu� un art�culo llamado "Los controles de calidad en la Web" donde propuse lo que a mi entender debe ser la documentaci�n de un sitio web: documento final, mapa completo de nodos y enlaces (mapa de navegaci�n), Relaci�n estructurada de todos los ficheros utilizados, hoja(s) de estilo, galer�a de elementos gr�ficos, c�digo fuente de todos los programas incluidos en el proyecto, explicaci�n de la estructura de cada nodo, contrato de mantenimiento y periodo de garant�a y presupuesto econ�mico (p�g. 132 de la citada revista).

Todos esos documentos son imprescindibles para evaluar un documento web. Pero no es suficiente con que est�n. Adem�s, hay que asegurar su uso y actualizaci�n en futuras modificaciones del documento web. Reducir el desarrollo web a un simple ejercicio de "estilismo" es en la pr�ctica asegurar la caducidad de dicho dise�o.

Valoraci�n

Comentarios

A�adir un comentario

Si no est� de acuerdo con algo o quiere a�adir m�s informaci�n al respecto puede incluirla a�adiendo un comentario.

Colabora

�Te sientes capacitado para escribir un art�culo como este? �Te gustar�a colaborar escribiendo art�culos en WebEstilo? H�znoslo saber !!