Te cuento un poco mi experiencia. Curre en una empresa donde solian maquetar con tablas y todo el cacao. El departamento de diseño grafico entregaba al depto de programacion plantillas o maquetas HTMLs generadas en Dreamweaver, y estos se dedicaban a limpiar y adecuar el codigo (por encimita, quitando redundancias y tal), y luego ya se ponian a generar los HTMLs por servidor, etc... En un proyecto que me toco participar, se decidio (por primera vez) hacer la web accesible y con codigo valido. Estabamos sin mucha carga laboral, por lo que la empresa se podia dar el tiempo para probar con otra metodologia. El primer problema que surgio fue que los diseñadores graficos no sabian ni siquiera lo que era un CSS. Ellos usaban DW para diagramar, y nunca vieron un pedazo de codigo (que por su profesion tampoco les correspondia tanto). Se decidio que los diseñadores entregarian las maquetas en PSDs, y luego los programadores (que sí sabian un poco mas de XHTML+CSS) se dedicarian a maquetar la interfaz. El problema aqui fue que los diseñadores, teniendo todas las herramientas de Photoshop al alcance, diseñaron una maqueta bastante compleja, con sombras por aqui, brillos por alla, tipografias suavizadas, etc... ademas, no se definian eventos (hovers, etc)... Luego de varias reuniones conjuntas con los programadores (que tampoco estaban 100% enterados sobre maquetacion con XHTML+CSS, ya que se dedicaban principalmente al lado servidor) se logró una maqueta suficientemente realista, que dejo a ambos "bandos" relativamente satisfechos. La empresa actualmente sigue con tablas (pq el proceso ya lo tienen automatizado, por tanto demoran menos en desarrollar), pero estan haciendo cada vez mas cositas con CSS, para aspirar en algun momento cambiar la metodologia definitivamente al XHTML.
¿Cual es realmente el problema?, pues que estamos hablando de diseñadores graficos (no web) y programadores del lado del servidor... no hay nadie que especificamente se dedique a la interfaz del lado cliente. En el pasado, con que un diseñador grafico se apañara con DW bastaba... él diagramaba graficamente, generaba codigo automaticamente, y todos felices. Lamentablemente ahora no hay ningun programa que genere codigo suficientemente limpio automaticamente, ademas que las prioridades han cambiado bastante en la web. Es necesario entonces que el depto de diseño grafico se especialice en web, que conozca bien el soporte, y que diseñe acorde...o bien, que exista un depto mediador entre ambos "bandos" que se dedique al diseño web, es decir que definan interfaces, semantica, accesibilidad y usabilidad, que son temas que considero mas cercanos al diseño que a la programacion. Esto ultimo permite ademas ampliar un poco la oferta de la empresa, ya que un depto de diseño web debiera ser capaz de abarcar temas como Flash, AJAX, y otras tecnologias web actuales. Sobre los programadores no hay problema, por que en cuanto entienden bien lo que es XHTML+CSS y como funciona, lo adoran, y aceleran sus desarrollos muchisimo. Saludos... Juan Ignacio Sánchez Lara escribió: > Gracias a todos por las detalladas respuestas, que paso a comentar > > > 1. La primera es la que aparece en "no me hagas pensar", el famoso libro > >> de Steve Krug [1], donde, en uno de sus últimos capítulos, plantéa una >> serie de viñetas muy didácticas sobre este mismo problema. Su propuesta >> de forma resumidita es centrar la atención del "equipo" en intentar >> cubrir "las necesidades del usuario" y no las necesidades personales de >> cada uno, por lo tanto adoptar el enfoque y las metodologías de la >> usabilidad. [No explica como implantar este modelo en la empresa..lo >> cual sería otro buen capítulo] >> > > > He leído el libro pero no recordaba que hubiese algo aplicable. Me haré con > un ejemplar de nuevo para repasarlo. > > 2. El segundo libro que toca este tema de los que yo he podido consultar > >> es "CSS, hojas de estilo en cascada para el diseño web", un libro >> relativamente reciente escrito por varios "gurús" de la programación web >> y dirigido por Jeffrey Zeldman[2]. El primer capítulo es tremendamente >> didáctico, y plantéa entre otras cosas, guias sobre coordinación y >> distribución de responsabilidades en un grupo de trabajo para la web. >> También ilustra un modelo del proceso que debería seguir cualquier >> proyecto web, lo cual, incluye de algún modo, la visión y postualdos de >> Krug. >> > > Voy a conseguirlo sin falta, porque tiene muy buena pinta. Por un lado, como > indicas, parece que tiene una respuesta directa a mi cuestión, lo cual no > siempre se encuentra. Por otro, parece un libro "profesional" de CSS, que va > al fondo en vez de quedarse en la programación, y no sabía que hubiese algo > así publicado. Me encanta esta frase en la referencia que indicas: "*aborda > problemas conceptuales y logísticos en relación al diseño web* " ¿Cuántas > veces un fallo de concepto hace que nuestros planteamientos sean > incorrectos? > > Ya como reflexión particular, tengo la sensación de que el problema que > >> planteas, tiene much [... recortado ...] ador, no parece tener en cuenta >> tus opiniones hasta >> llegado un punto en la producción, y esto es una cuestión que actúa >> negativamente respecto al resultado final alcanzado por la empresa a la >> que perteneces. Futuro incierto.... >> > > > Comentarios sobre tu reflexión personal: no puedo quejarme de que no se > tenga en cuenta mi opinión. De hecho, todo lo contrario. Pese a mi puesto > actual y a llevar relativamente poco tiempo en la empresa, me siento > plenamente respaldado por el equipo que me rodea, tanto "por arriba" como > por "los lados", si me permitís la expresión (no me siento respaldado "por > debajo" porque no hay mucha gente por debajo mío :D). El problema ha sido un > encontronazo ahora precisamente por intentar aplicar mis opiniones en un > punto inicial del proyecto, lo cual afecta de forma troncal a la > organización de la empresa, en lugar de resolverlas a modo individual > (proyecto) en las últimas etapas. > No he tenido tiempo para leer todas las referencias que indicas (muchas > gracias, por cierto), tan sólo he podido echar un vistazo a la del bazar y > la de los modelos de organización, y el creo que el planteamiento de > descentralizar que comentas es correcto, pero no sé hasta qué punto es > aplicable a mi problema. Se da la situación de que precisamente el diseño de > interfaces está descentralizado hasta el punto de sacarse, al menos en > parte, del resto del equipo de trabajo del proyecto. Es una situación muy > concreta, creo, como para intentar analizarla desde las perspectivas > genéricas de las últimas referencias, pero sin duda las dos primeras me > serán de gran ayuda. Muchísimas gracias, Carlos. Espero poder invertir el > tiempo que me gustaría en leerlas, e incluso redactar algún breve artículo > al respecto... > > (...) el diseñador algo tiene que ver (bastante y mucho a mi entender) con > >> lo >> accesible y lo usable. (...) cuidar los colores, sus contrastes, que el >> diseño sea >> visualizado igualmente legible en escalas de grices o color, tener en >> cuenta >> todo, inclusive a usuarios con daltonismo por ejemplo o la dispocisión de >> ls >> elementos en el plano, etc etc.. >> > > Sin duda el diseño gráfico debe tener en cuenta accesibilidad y usabilidad > en el diseño, el ejemplo que comentas de los colores es claro. Sin embargo, > no sé si otros aspectos más técnicos, internos, son "exigibles" a un > diseñador. Por ejemplo, una maquetación con tablas o no, desde el punto de > vista del diseño gráfico externo puede ser irrelevante (en la mayoría de los > casos se puede hacer con ellas y sin ellas), así que no sé si eso es > "responsabilidad" suya. Por supuesto que por mí encantado que lo que me > pasase el departamento de diseño gráfico fuese un código de enmarcar, que > pasase validadores W3 y TAW... > > En cuanto a los prototipos en mi caso particular son reutilizables > >> dependiendo de la naturaleza del trabajo. Si es un prototipo que esta bajo >> procedimientos de imágen corporativa, (...) involucrar a todas las capas >> de la empresa en >> el tema accesibilidad y usabilidad. No creo por tanto que deba existir un >> departamento controlador de la accesibilidad y la usabilidad, sino, que >> cada >> uno de los implicados en el proceso de desarrollo trabajen bajo estas >> normas >> desde la primer curva y hasta el último pedacito de código. >> > > > El problema de la reutilización de los estilos es que, como sabeis, no > basta con enlazar con la hoja de estilo para que éste se aplicase. A mi modo > de ver reutilizar el estilo exige hilar muy fino a la hora de componerlo y > además después ser todos algo disciplinados a la hora de componer las > páginas. No tengo claro que estos requisitos se puedan verificar desde la > etapa de prototipado. En ella comprendo que la prioridad sea hacerlo > gráficamente vistoso, preocuparse de cómo se ve y punto. Creo que diseñar > una apariencia mediante html y css a pelo es muy difícil. Lo habitual es > componerlo en Photoshop o Dreamweaver... > Hay actividades que como dices deberían implicar a todos. Una es usabilidad > y accesibilidad. Otra sin duda es seguridad. Y habrá más. En un mundo ideal, > todos sabríamos (¡y aplicaríamos!) todo lo necesario, pero eso es > complicado... > Anoto las referencias, que sin duda serán muy útiles. Y me alegra saber que > conseguís reutilizar los prototipos (al menos alguno), porque eso significa > que no es imposible ;-). Gracias, Alejandro. > > > A mí entender un diseñador gráfico que trabaje en el mundo de las interfaces > >> web ha de saber tanto diseñar un entorno amigable, desde la prespectiva >> visual y usable, como generar un código límpio, y si es posible anotado, >> muy >> útil con las css. >> > > > A mi entender también, pero a menudo pienso que pido demasiado (no sólo en > esto), porque siento que me miran con caras raras cuando saco ciertos temas > ;-) > > No soy amiga del Dreamweaver, genera mucho código basura. Soy más partidaria > >> de picar código directamente, mediante un buen editor, como Ultra Edit o >> Home Site, sabiendo siempre lo que se hace y los resultados que se >> producen. >> > > > Ole :-). Tras probar varios editores acabé haciendo el código de una > intranet con vi, no te digo más :D. > > Esto facilita el paso a jsp y a la manipulación de los desarrolladores, en > >> la futura evolución de la aplicación. Marcando tanto como sea posible la >> diferencia entre lo que es la parte del interfaz, con la parte de >> contenidos >> y la de la aplicación. Y ahorrándonos el poder "tocar" algo de un ámbito >> que >> no nos pertence y crear incidencias. >> >> De esta manera, te aseguras de pasar los test WAI, TAW etc, de la >> compatibilidad con navegadores y pantallas, y de que unos no os piseis los >> unos a los otros el trabajo. También facilitará que el proyecto pase por >> diferentes manos sin un gran esfuerzo. >> > > > Creo que este es el planteamiento ideal. > > Mi opinión sobre cómo repartir el tema del trabajo. > >> Informar tanto a desarrolladores como a diseñadores de lo que debe hacer >> la >> aplicación y de los requisitos de usuario que ha de tener. >> >> Que ambas partes lleguen a un acuerdo de cuales son los límites técnicos >> de >> esta, tanto a nivel de interfaz como a los problemas que esta puede >> generar >> a lo que corre por detrás. >> >> Los diseñadores se han de comprometer en lo posible, a separar mediante >> código, toda la parte gràfica de la parte del código HTML. Es decir, >> utilizar css. Será bueno para posibles modificaciones futuras y para el >> reaprovechamiento del código, en maquetas o en diferentes secciones de la >> aplicación. >> >> Los desarrolladores se han de comprometer con los diseñadores de >> preocuparse >> sólo de que funcione la aplicación y de no introducir cambios que afecten >> a >> la interfaz pq les es más cómodo en cierto momento del desarrollo, >> respetando lo más posible el código de la misma. >> > > > Rosalía, lo expones tan sencillo que parece fácil :-). Creo que esto sería > lo que habría que hacer, pero exige mucho... Aunque bueno, está bien saber > que alguien comparte mi opinión. Sólo una pregunta más: ¿conseguís esos > criterios de calidad desde el prototipado? Hay algo que no creo que sea > discutible, y es que para un diseñador es muy complicado componer un nuevo > diseño generando a la vez código "de calidad" que separe estructura de > presentación... > > > > > Muchas gracias a todos por los comentarios. A ver si puedo recopilar lo que > haya en las referencias y hacer un artículo que se titule algo así como > "Proceso para el diseño de interfaces web usables, accesibles y > reutilizables" ;-) > > _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
