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" ;-) -- Juan Ignacio Sánchez Lara Ingeniero Informático + Técnico de Sistemas http://juanignaciosl.blogspot.com - Hoy: La Catedral de Justo http://www.flickr.com/photos/juanignaciosl _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
