> De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de Julio Imazio > > Me esta gustando mucho este hilo. > Creo que es uno de los problemas mas comunes dentro de > equipos de desarrollo, si estamos hablando de equipos que > pretenden incorporar unos determinados objetivos de > usabilidad (condicionando consecuentemente el ciclo de > trabajo), todavía mas. Sinceramente no me molesta si la > persona que diseña es la que maqueta, no creo que sea > condición necesaria para transmitir correctamente el trabajo > al programador. Lo que si me parece indudable, coincidiendo > con respuestas anteriores, es que la persona que diseña > conozca el medio en el que se esta moviendo. Hasta ahora la > mejor forma que he encontrado para que una persona que nunca > ha diseñado para web sea consciente de que puede y que no > puede hacer es tenerlo un tiempo maquetando, a ser posible su > propio trabajo.
Coincido contigo Julio: un tema de lo más interesante. El origen de los conflictos suele estar en que los equipos que intervienen en un desarrollo son limitados, e inevitablemente, la mayoría de las veces los integrantes del equipo deben adoptar responsabilidades que afectan a diferentes campos, mezclando diseño gráfico y maquetación, maquetación y programación, análisis y programación, prototipado y diseño gráfico... Se ha hablado sobre qué perfil era más lógico que se encargara de la maquetación en HTML + CSS, teniendo en cuenta el uso de código semántico y accesible: un diseñador o un programador. Mi opinión es que, aunque tradicionalmente haya sido el programador quien se encargue de maquetar y añadir la programación a los bocetos en photoshop proporcionados por un diseñador ( digo tradicionalmente porque, al menos desde mi experiencia, es lo que he solido encontrarme ), puede dar mucho mejores resultados que sea el propio diseñador quien se encargue de ello. Básicamente porque posiblemente el resultado final sea mucho más fiel a la idea original. En primer lugar, el diseñador que conoce el medio en el que trabaja, la web, ya parte de la premisa de las cosas posibles, las imposibles, las factibles, las desaconsejables... Mientras prepara los bocetos ya puede ir previendo los posibles problemas que va a encontrarse durante el traspaso a HTML, e ir haciéndose un "esquema mental" de la estructura semántica que tendrá el documento final, lo que le permitirá "optimizar" los recursos gráficos a utilizar. En realidad me sorprendería que un diseñador orientado a web, sin tener conocimientos en estas áreas, consiguiera un diseño realmente efectivo. El entorno web no tiene NADA que ver con el medio impreso e inevitablemente, requiere un aprendizaje adicional. Pero ojo, no estoy diciendo que sea siempre un diseñador quien deba encargarse de esa tarea. En realidad, conseguir un buen documento HTML que, además de reproducir la apariencia visual de un diseño previo, 1. esté desarrollado en base a código válido, 2. esté estructurado semánticamente y 3. respete las normas de accesibilidad WAI, tiene suficiente entidad como para que exista una figura única, un técnico experto en HTML, hojas de estilo, usabilidad, accesibilidad, técnicas SEO... Que sea el paso intermedio entre el diseñador y el programador, y por el que deba volver a pasar el trabajo una vez el programador haya terminado de implementar la lógica. Sólo que... Todos sabemos que la realidad en la mayoría de los casos es que no hay recursos suficientes para incorporar a esta figura. :P Un saludo, Albert Garcia OboLog » Tus pensamientos en red www.obolog.com ______________________________________________ Mi blog personal en http://obokaman.obolog.com _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
