Juan Ignacio Sánchez Lara wrote: > Trabajo en una empresa haciendo aplicaciones web. Tenemos un departamento de > Diseño Gráfico que es el responsable del diseño de los interfaces. Huelga > decir que los interfaces de nuestras aplicaciones son páginas web (html + > css). > > Recientemente hemos tenido un pequeño gran problema serio sin importancia > (ya me entendeis) de competencias y responsabilidades. El diseño gráfico > (entendido como apariencia) por supuesto corre de su cuenta, pero en > desarrollo también utilizamos el código de prototipos/maquetas que ellos > hacen para el producto final. El acabado gráfico es impecable y por supuesto > no lo pongo en duda, pero hasta la fecha el código se venía haciendo "a la > vieja usanza" con Dreamweaver: maquetación con tablas, múltiples "blank.gif" > para hacer huecos en blanco, nada de pasarle validadores W3 o TAW... Todo > esto, aparte de los problemas de usabilidad y/o accesibilidad de los que en > esta lista seguro no tengo que comentar, nos traía a los desarrolladores > otros problemas (al menos desde mi punto de vista): el código de las páginas > se vuelve farragoso y con muchos elementos innecesarios, lo que lo hace > mucho más costoso de mantener; a la hora de pasar los prototipos (estáticos) > a páginas jsp (generadas con bucles, etiquetas de Struts, etc) se tarda > muchísimo... Seguiría con la lista, pero creo que comprendeis a qué me > refiero. El caso es que solicité que se considerase la posibilidad de > mejorar ese aspecto, y, como no podía ser de otra forma, han llegado los > problemas y los malentendidos. > > ¿Cuál es el reparto de tareas óptimo en un proyecto, y cuál es el que se > suele realizar en la práctica con resultados aceptables? ¿Tiene que recaer > en el mismo equipo el diseño gráfico, el prototipado de los interfaces, el > desarrollo del código? ¿Utilizais prototipos en HTML o sólo de Visio o > similar? ¿Vuestros prototipos son reutilizables, o desechables? En > definitiva... ¿cuál es la organización que debe seguir un proyecto para el > desarrollo de sus interfaces (web)? No sé hasta qué punto un diseñador > gráfico debe preocuparse de la accesibilidad de las páginas o calidad de su > código... > > Quizá son muchas preguntas en poco espacio. ¿Qué bibliografía puedo > consultar (disponible online a ser posible) para conocer cómo se debe hacer > esto? Es fácil encontrar la separación de tareas entre un analista, un > diseñador (no confundir con diseñador gráfico) y un programador, pero no > tanto que entre en detalle en el desarrollo de los interfaces. ¿Cuál es > vuestra experiencia al respecto? > > ¡Gracias por vuestra atención! > > Hola a todos!
Ante todo, felicitar a Juan Ignacio por el tema tan interesante que propone. Yo, personalmente, estoy en desacuerdo con Rafael García y muy de acuerdo con la mayoría de cosas que se comentaban con anterioridad, sobre todo R.Murciano. Creo que el principal problema es que los Diseñadores desconocen como norma general el MEDIO en el que desempeñan su trabajo. Esto y esto se hace esencialmente patente en el medio WEB. La formación de un buen diseñador gráfico, no sólo debería comprender teoría del color, las formas, manejo de diversos programas (mejor MÚLTIPLES) de diseño 2D, 3D, Vectorial, Bitmap... sino que también debe incluir una formación básica del medio impreso (modelos de color, perfiles, formatos gráficos, hardware y maquinaria empleada en la representación del color, etc.) si se dedica a la publicidad impresa y del medio web (código, estándares, CSS, HTML, XML, usabilidad, accesibilidad, ...) si su trabajo va a ser el de diseñador de páginas web. Y con esto no quiero decir que uno tenga que ser un erudito en todas las materias, pero sí al menos tener una base firme de conocimientos en esas materias y luego que, según sus preferencias y gustos, elija aquel o aquellos campos en los que desee profundizar. Yo creo que con esto se consigue una VISIÓN GLOBAL muy valiosa cuando se trabaja en proyectos que involucran a mas profesionales. El fallo está en pensar que un diseñador gráfico sólo tiene que hacer un diseño, un pantallazo. Porque entonces es cuando vienen los problemas derivados de "diseños imposibles", muy artísticos, pero poco usables. Código mal formado o farragoso que luego tiene que "limpiar" un programador y que al tocarlo puede provocar variaciones en la presentación (que logicamente ofenden al diseñador gráfico), ... y así suma y sigue. Si lo importante es el llevar cierta información al usuario, ¿por qué no conocer al usuario (accesibilidad y usabilidad)?, ¿por qué no conocer el medio que emplea el usuario (sistemas hardware/software, navegadores, ...)?, ¿por qué no conocer el vehículo en el que se transmite esa información (el código html, css, ...)?. Pienso que "aislar" a cada profesional en su tarea individual no produce buenos resultados. Es necesario un mínimo de formación básica y transversal que permita que cada uno de los profesionales que realiza una labor la realice teniendo siempre en mente cual es su papel en el resto del grupo y como entregar su trabajo para que el que tenga que hacer uso del mismo sólo tenga que enfrentarse a sus propias dificultades, sin heredar las del primero. Respecto a la separación de roles, pienso que depende del tamaño y política de la empresa. Yo me conformo con preparar mis diseños (porque mi trabajo es el de diseñador), de manera que cuando pasan al área de programación, los encargados de la misma no tengan que tocar el HTML (ni muchísimo menos generar ninguna línea de código HTML), sólo incrustar la programación y listo. Así nos aseguramos que los niveles de validación de código, usabilidad y accesibilidad, se mantienen y se minimizan los problemas derivados que puedan surgir tras la programación. Pero, como decía, eso es como yo creo que debe hacerse, y depende del número de personas que haya en cada grupo de trabajo. Salu2 de jEsuSdA 8) _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
