probablemente, indefinido

Copio y pego un buen artículo del cual comparto muchas cosas. Hace poco, en una charla con colegas, había expuesto que no había persona en el mercado que pudiera abarcar todo lo que solicita el mismo, y los primeros que deben entenderlo son los diseñadores web (una profesión aún mucho más nueva que se del diseño gráfico) y los programadores, que deben hacer valer su trabajo, y luego los empleadores que solicitan personal altamente capacitado de una rama demasiado nueva; y por último, los clientes, que siempre andan volando por las nubes, y que siguen sin entender qué hacemos.
La multimedia se trabaja en equipo, no hay otra. Se requiere de diseñadores, comunicadores, programadores y líderes de proyectos; a lo sumo, alguno puede ocupar más de un rol, pero no todos a la vez, es imposble hacer todo, y todo bien.
Como diseñador, gráfico y de multimedios, y básico programador, entiendo muy bien lo que se explica en el artículo, hay que abrir el juego, tener mucha paciencia, no se puede correr todo el día atrás de la tecnología, menos si es especializada y con estándares no del todo claros (que se modifican muy a menudo)...El desarrollo de un sitio web es una actividad muy nueva, que tiene todavía mucho espacio para madurar. Hasta que todos los roles y procesos se acomoden van a pasar largos años, especialmente mientras la tecnología y los estándares estén tan verdes.
Para los que tocan de oído en este tema, déjenme contarles que la producción de un sitio web comprende varias etapas, desde la concepción hasta la implementación. Parte (y sólo parte) del proceso es la creación de las páginas en sí, la parte visible del sitio, la parte que “sucede” entre el servidor y el navegador, y en el navegador mismo. Específicamente en la creación de las páginas, hay dos etapas muy claras: el diseño visual, realizado por un diseñador gráfico, y la incorporación de los datos dinámicos, por parte de uno o más programadores.

¿Y cuál es el problema?
Simplificar trae sus problemas, así que cuando miramos el proceso un poco más de cerca, descubrimos un paso intermedio, casi una formalidad, que muchos consideran una zona gris entre el diseño y la programación: el maquetado. El maquetado consiste en crear un esqueleto estático de la página en formato HTML+CSS según lo determinado por el diseñador. Esta maqueta sirve al programador de plantilla, quien le agrega luego la parte dinámica provista por el programa.

La pregunta es: ¿quién debe hacer el maquetado? Hay varios argumentos a considerar:

El diseñador no debe hacerlo porque:
* Los diseñadores encuentran difícil entender todas las sutilezas y variaciones de los lenguajes de marcado. Se trata de una organización altamente estructurada y técnica, que se pelea fuertemente con la “soltura” creativa en la que deben sumergirse para realizar el diseño apropiadamente.
* Los diseñadores consideran que la tarea está muy alejada de su profesión: ellos estudiaron morfología, semiología, comunicación, órdenes epistemológicos, etc., y su formación es -hasta cierto punto- independiente del medio en el que se expresen (web, revistas, libros, packaging, etc.).

A su vez, el programador no debe hacerlo porque:
* Los programadores, por su parte, están generalmente especializados en un lenguaje imperativo (Java, PHP, Python, C#, Ruby, etc.), y -cuando no lo conocen en profundidad- encuentran el HTML “soso” o incluso “simplón”.
* Además, “volcar” el diseño a HTML+CSS implica entender el diseño propuesto hasta cierto punto, y los programadores encuentran difícil (y aburrido) interpretar las -a veces inexistentes- indicaciones del diseñador respecto de la relación y jerarquía entre los distintos componentes visuales.
* Por último, el armado conlleva la utilización de programas como Photoshop para crear las imágenes necesarias, programas con los que suelen estar más familiarizados los diseñadores que los programadores.
Se da entonces una discusión bastante graciosa a mi entender, en la que programador y diseñador se miran con recelo y se señalan mutuamente diciendo “el maquetado lo tenés que hacer vos”. Por alguna razón que no entiendo, ambos esperan que sea el otro quien realice la tarea. Voy ahora a explicar por qué pienso que ninguna de las dos posiciones es correcta; que se trata de una falsa dicotomía y que en realidad existe una tercera posición: el maquetador es otra persona.

El proceso de creación de la página es más complejo
Para mí, el staff ideal para desarrollar una página web requiere de cuatro personas o roles: un líder o responsable de proyecto, un diseñador gráfico, un maquetador y un programador. Y las etapas no son dos, ni tres; hay cuatro etapas en la producción de la página, a saber:
1. Diseño de interfaz - Realizado hasta cierto punto por todos en conjunto.
2. Diseño gráfico - Realizado por el diseñador gráfico.
3. Maquetado web - Realizado por el maquetador web.
4. Programación - Realizada por el programador.

El diseño de interfaz
El diseño de interfaz es la parte donde se decide qué elementos habrá en la página y cómo se comportarán. Es un momento muy importante de la producción, ya que en él se plantea cómo va a realizar el usuario las distintas acciones, con qué herramientas contará, qué funcionalidades específicas de web se le adicionarán a la aplicación, etc. Bien hecho, es un trabajo conjunto entre el líder de proyecto, el programador, el maquetador y el diseñador. Se decide si se van a utilizar botones, input boxes, radio buttons, AJAX, RSS, pingbacks, trackbacks, preferencias en cookies, etc., y cómo se van a utilizar. Se discutirán conceptos de usabilidad y accesibilidad.
Aunque el diseño de interfaz es un trabajo de los cuatro, algunos tendrán más responsabilidad que otros, siendo el diseñador el responsable final de esta etapa. Éste debe tener alguna especialización en el área de diseño de interfaces de web, ya que debe conocer no sólo lo que es posible, sino también cómo aprovechar los elementos para producir la comunicación que se desea obtener. El líder de proyecto tendrá en claro los objetivos aplicativos a cumplir. El programador y el maquetador darán sus visiones sobre la factibilidad técnica, incluyendo por ejemplo sus análisis del impacto sobre la performance. Finalmente, el maquetador aportará su conocimiento sobre el lenguaje Web.
Aclaro que cuando digo lenguaje Web no estoy hablando de los lenguajes descriptivos de la página (HTML+CSS), sino que hablo de las características funcionales que tienen las páginas para insertarse en el mundo Web moderno (2.0, por el momento): interoperabilidad (RSS, pingbacks, microformatos), accesibilidad, etc.

El diseño gráfico
Luego de aprobarse el diseño de interfaz, se procede al diseño gráfico. Éste es realizado exclusivamente por el diseñador, quien lo realiza generalmente en una herramienta que ofrezca la máxima flexibilidad gráfica; es decir, el diseñador debe poder mover, alterar y acomodar los elementos sin limitaciones hasta quedar conforme. Eso implica que no se puede utilizar una herramienta que obligue a pensar en HTML (ej: Dreamweaver), sino que se utilizará una herramienta de estilo libre, como Photoshop o mejor aún Fireworks. Una vez obtenido y preaprobado el diseño preliminar, el diseñador deberá reunirse con el maquetador para ponerse de acuerdo sobre lo siguiente:
* Conveniencia técnica y relevancia de cada elemento gráfico: aquí se sopesan la dificultad técnica y recarga de performance (peso y capacidad de procesamiento) asociada a cada rasgo del diseño, y se evalúa si es necesario mantenerlo o replantear su utilización.
* Comportamiento de los elementos en diferentes situaciones: se plantean diferentes escenarios, evaluando qué debe pasar si una palabra o frase queda demasiado larga, cómo deben interactuar los márgenes cuando los elementos cambian de orden, cómo deben modificarse los elementos ante diferentes tamaños de pantalla, etc.

El maquetado
Cuando ya hay consenso sobre el diseño, debe producirse el maquetado. Ésta es una etapa increíblemente subestimada y a la vez muy importante. En ella se vuelcan los elementos gráficos a un formato compatible con Web, teniendo en cuenta el lenguaje Web. Esto es, no sólo el maquetado debe producir código HTML y CSS válidos (utilizando también JavaScript cuando sea necesario), sino que además debe elaborar un producto que contenga todos los elementos necesarios para que sea una página web profesional:
* Accesibilidad: uso de ALT, TITLE, accesos directos, marcado específico.
* Interoperabilidad: microformatos, RDF, marcación en header.
* Escalabilidad: estructura adecuada, estrategias de organización de clases.
* Compatibilidad: soporte de navegadores.
* Semántica: utilización apropiada de tags.
* Performance: minimización de código y cantidad de requerimientos al servidor (round trips).
* Otros: hoja de estilos para impresora, SEO.

La programación
Finalmente, el programador realiza la parte más fácilmente comprendida del proceso, aunque por supuesto no por eso la más sencilla, que consiste en utilizar la maqueta HTML como plantilla para los programas que generan el contenido dinámico.

Conclusión
Lo que acabo de exponer es una enorme simplificación del proceso, aunque creo que da una idea más clara de cuál es el rol que veo en el maquetador. Su trabajo es muy complejo, muy técnico y requiere una alta especialización, estar al día con los cambios y tendencias (nuevamente menciono los microformatos, nuevos navegadores, nuevos estándares), conocer deficiencias de los navegadores actuales y cómo subsanarlas o cómo éstas afectarán a la aplicación, tendencias en el tamaño de la pantalla, SEO, en fin… miles de pequeños detalles que hacen del maquetador un profesional por propio derecho, sin el cual los resultados obtenidos serán sin duda pobres o incompletos.

El no tener un maquetador profesional en el equipo de desarrollo suele traer uno o varios de los siguientes problemas con la página a desarrollar:
* No valida correctamente, por lo que se ve en menos navegadores, tiene menos Page Rank en Google, etc.
* Es pesada, ya sea en tamaño, round trips al servidor o simplemente en uso de CPU al ser desplegada en el navegador. Todo esto empobrece la experiencia del usuario.
* No es accesible, y como mínimo es incómoda en algún aspecto.
* Hace mal uso o desaprovecha el marcado en el header, por lo que obtiene menos Page Rank en Google del esperado.
* No respeta estándares y rompe la semántica: una vez más, tiene menos Page Rank en Google, pero ése es sólo el principio de los problemas que esto trae.
* Se ve o se siente como un “bicho raro” en la web, porque no respeta códigos a los que el usuario está acostumbrado. El usuario no se encuentra cómodo y no puede utilizar herramientas que considera útiles (autocompletadores, ruedita de scroll del mouse, modos de visualización de su navegador, accesos directos de teclado, gestures, etc.).
* Es difícil de mantener, aún siendo dinámica. Por ejemplo, el archivo CSS es incomprensible; cualquier pequeña modificación o agregado conlleva mucho más esfuerzo del necesario.
* La compatibilidad en navegadores es pobre, dejando a muchos usuarios afuera (siempre más de los necesarios).
* Carga en un orden inapropiado. Por ejemplo, el usuario puede ver las barras y menús utilitarios mucho antes que el contenido principal de la página.
* No se ve bien al imprimirla, o imprime información innecesaria, dejando afuera información que sería realmente útil en la versión impresa.
* No aprovecha todas las posibilidades de interoperabilidad que ofrece la web.

Va a costar mucho poder hacer todo eso y bien... mientras, hay que seguir haciendo.