Bases para el desarrollo web

2 de diciembre, 2008 - por

Cualquier persona que ha participado de alguna forma en un proyecto web, conoce la enorme incertidumbre con la que se trabaja, a causa de las numerosas opciones que se barajan. Tomar una decisión sobre cualquier aspecto conlleva la necesidad -o la sensación de tenerla- de informarse y evaluar las distintas alternativas, a menudo sólo apoyándose en una metodología cualitativa difícil de formular conscientemente.

En todo ésto hay una parte, para mí, asumible de forma natural, que tiene que ver básicamente con el esfuerzo constante por innovar. Las tecnologías nacen para tener versiones, mejoras e incluso ser sustituidas por otras, con lo que los cambios -estructurales o por meras modas- son algo inevitable. Algunas personas piensan, además, que es positivo; y, por supuesto, hay otras que opinan justo lo contrario. La incertidumbre a la que me refería se mueve básicamente en esta parte.

Ahora bien, hay todo otro conjunto de cosas que, en mi opinión, son de naturaleza arquitectónica, y que por eso mismo no deberían verse comprometidas por las otras. Desgraciadamente, muchas veces son las partes más descuidadas de los proyectos, y los problemas que traen consigo suelen convertirse en críticos.

La primera cosa que suele descuidarse es el marcado HTML. Este descuido tiene consecuencias a todos los niveles, puesto que la web se apoya, intrínsecamente, en las estructuras de los documentos. Existe todavía una actitud bastante generalizada que concede poca importancia a este aspecto, produciendo una base de conocimiento muy pobre y poco rigurosa. Recientemente, Opera hacía públicos algunos datos recogidos a través de su herramienta MAMA, que cifraban en tan sólo un 4,13% los documentos existentes en la red validados correctamente. En este tipo de datos lo interesante no está tanto en las cifras, cuanto en la actitud que éstas reflejan.

El descuido en el marcado produce una reacción en cadena de descuidos que, en conjunto, afectan sustancialmente al documento.

Por un lado, existe un riesgo mayor de que estructura y presentación no se comporten como partes estancas, con lo que se incrementa la probabilidad de restringir y/o dificultar el acceso al documento (documentos más pesados, documentos no válidos para algunos dispositivos, etc.), así como de ofrecer un contenido menos significativo.

Por otro lado, aumenta la dificultad de incorporar comportamientos relacionados con el navegador, puesto que éstos se benefician de una estructura bien organizada y limpia de estilos. Ésto, a su vez, incrementa la posibilidad de restringir el acceso a causa de problemas con los dispositivos.

Asimismo, al disponer de un contenido menos significativo, disminuirá la capacidad de acceder a éste mediante búsquedas de patrones y/o semánticas. Lo que repercutirá, nuevamente, en restricción de acceso.

Más importante aún que todo ésto es que este tipo de actitud va en aumento según se desarrolla un proyecto, de forma que las pocas consideraciones que se tenían en el momento 0, han disminuido en el momento 5, y empiezan a considerarse como un problema en el momento 10. A partir de ahí se habrá invertido lo que debería ser el orden natural del proyecto, de forma que la web habrá pasado a considerarse un corsé demasiado pobre que necesariamente hay que forzar.

En ese punto penetrarán todos esos aspectos de la primera parte (tecnologías cambiantes, modas, etc.) desbordando sus límites naturales. En la historia de la web -que escribimos cada día- hay ejemplos de todo ésto -que todos vivimos diariamente- y se puede decir que prácticamente nadie está a salvo, y que es un ejercicio diario hacer el esfuerzo por mantener cada cosa en su sitio.

Merece la pena, puesto que ayuda a gestionar la incertidumbre que se mencionaba al principio, poniéndole límites, y evita la generación gratuita y progresiva de problemas y restricciones a todos los niveles.

Tema: Análisis

Etiquetas: , , , , .


Otras entradas que pueden interesarte