>>>Tengo que construir una página web dinámica basada en BD. >>>La cuestión es que las personas dedicadas a la lógica de la >>>aplicación no se encargarán de la presentación (del diseño de la >>>web).
>>Si no he entendido mal, tú eres quien se va a encargar de montar las >>páginas con css y programarlas de manera dinámica, ¿no? > No, yo quiero encargarme de la lógica de la aplicación y ofrecer la > información necesaria para renderizar la aplicación a otro sistema, que se > encarge de generar el html. > De manera que los diseñadores sólo tengan que saber qué información tienen > disponible y pintarla como quieran. Hasta aquí no debería haber problema, si te encargas de la lógica de la aplicación, tendrás claros cuales son los procesos a seguir y, para cada uno de ellos la información que la aplicación suministra y la que necesita. Arma un buen briefing con eso y los diseñadores no tienen más que tocar las CSS al uso en cada caso. >Es más las personas dedicadas al diseño no tienen idea de lenguajes de >programación. Tampoco debería ser un problema. Si realmente son diseñadores al menos saben trabajar con conceptos "abstractos" como *menú*, *titular*, *cuerpo de texto*, ... e incluso determinar algunas propiedades de éstos como por ejemplo "elemento de texto de 200 a 1000 caracteres". >Mi pregunta es cómo puedo afrontar eso y si existen aplicaciones para >que el trabajo de los diseñadores sea algo muy visual, tipo shopify >( http://www.shopify.com/ ), es decir, que puedan mover marcos o >quitarlos para rediseñar un página entera (manteniendo la lógica >intacta). A ver, ¿no decíamos que eran diseñadores? Deberían ser capaces de poder tomar un código HTML marcado con una serie de clases determinadas por la lógica de la aplicación y la imagen corporativa del cliente y a partir de ahí construir las hojas de estilo y elementos gráficos necesarios para llevar el proyecto a buen puerto. > Así, si un cliente en particular de mi aplicación, quiere hacer algunos > cambios en la web, yo no me tengo que preocupar de nada, es sólo tarea de > los diseñadores cambiar las cosas de sistio y colores. Sigue siendo así si los diseñadores realmente son profesionales web. Sólo deberían cambiar la hoja de estilos y, eventualmente, algún elemento gráfico. > Lo genial sería que los diseñadores puedieran diseñar con una aplicación > tipo Glade, donde el deseño se hace muy WYSIWYG, haciendo clicks y > situando las secciones con contenido. Yo soy poco partidaria de las aplicaciones para el diseño. Siempre he creído que si realmente sabes diseñar para la web debes ser capaz de entender, interpretar y respetar las normas CSS y ajustarte a las dificultades de los diferentes navegadores, diferentes resoluciones, etc... > > Pues es fácil: que los diseñadores te "dibujen" los documentos (en > > CorelDraw, FreeHand... el software que sea), y a partir de ahí tú les > > pides: "necesito esta imagen, necesito el valor rgb de este color, > > necesito esta esquinita...) > Ya, esto es lo típico. El diseñador te pasa una maqueta y el programador > debe reproducirla, haciéndola realmente dinámica. > > Precisamente esto es lo que quiero evitar. Yo se programar, no diseñar. Mi > idea es que no tenga que encargarme de nada de visualización. No deberías encargarte de la visualización si hacéis unos esquemas iniciales donde indiques a los diseñadores cuáles son las pantallas que va a tener el usuario en cada etapa de la aplicación. Por ejemplo: Página inicial del sitio: Además de los elementos comunes a todas las páginas descritos (menú de navegación, buscador, información de contacto, ...), en la pantalla aparecerán exactamente 6 cajas con información de productos donde se indica: - nombre del producto (de 10 a 100 caracteres) - descripción (de 200 a 1000 caracteres) - imagen del producto - precio del producto - enlace a comprar el producto Casuística: De los 6 productos mostrados en la portada: - al menos 1 será el artículo en oferta en ese momento. Puede haber de 1 a 3 artículos en oferta. - el resto serán artículos comunes que la aplicación seleccionará en base a una serie de criterios marcados desde el departamento de ventas Se deja a criterio del diseñador si debe diferenciarse visualmente los productos según la categoría a que pertenecen. Acciones de usuario: - Hacer click sobre cualquier producto de los mostrados lleva al usuario a la página propia del producto(PR1) - Hacer click sobre el enlace de compra de alguno de los productos mostrados, añade este producto al carrito de la compra del usuario (CC1) - Navegar por el catálogo de categorías de productos lo que lleva al usuario a una página índice de la categoría seleccionada (PR2) - ... - Las acciones ya descritas en los *elementos comunes* No es la aproximación que buscabas, pero desde un punto de vista práctico te diré que es una de las mejores maneras de acotar las demandas del cliente (que puede confundir información y diseño pidiendo por tanto una modificación "menor" como por ejemplo diferenciar los productos por la categoría a que pertenecen mediante un código de colores... vaya, necesitamos un dato más para el producto, tendremos que tocar la aplicación!), y para dejar sentadas las bases de un trabajo en respeto mútuo con los diseñadores. Cuando yo empecé a utilizar ese sistema de trabajo (presentar HTML carente de estilo pero con toda la funcionalidad para luego aplicar el diseño gráfico) fue cuando empezamos a tener una buena comunicación diseñadores-desarrolladores-cliente. Desde el principio había que definir la aplicación, su alcance y sus límites, y el cliente debía dar conformidad a el funcional de la aplicación. En este punto quedaba claro que cualquier modificación de código iba a representar un trabajo extra de programación y, por tanto, era facturable. Una vez la aplicación estaba definida, los diseñadores podían trabajar con textos e imágenes simulados en sus diseños mientras nosotros desarrollábamos la aplicación. Una estructura por capas (<div>) coherente para el HTML resultante de la aplicación (p.e. separando elementos comunes de contenido específico para cada página) debería ser suficiente para garantizar que las modificaciones de diseño no van a alterar la lógica de la aplicación. > He leído que una posible solución es que mi aplicación genere xml y que > los diseñadores creen xslt para crear el html. > Eso tiene dos pegas para mí: > > - no lo he montado nunca. Además parece un sistema bastante complejo. > > - no he visto aplicaciones con las que se pueda crear los xslt > gráficamente (a base de clicks tipo dreamweaver). Conocéis vosotros? Yo trabajé en un proyecto de ese modo y el resultado era buenísimo, pero los diseñadores no fueron quienes crearon los xslt sino que tuvimos que ser los programadores en función a las páginas que ellos diseñaron. Me parece que eso es, precisamente, lo que quieres evitar. Espero que toda esta disertación te ayude a encontrar un buen camino para afrontar el proyecto. Suerte _______________________________________________ Lista de distribución Ovillo Para escribir a la lista, envia un correo a [email protected] Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://lists.ovillo.org/mailman/listinfo/ovillo
