[Ovillo] Diseño de templates de forma visual

Jue Sep 6 12:51:53 UTC 2007

>>>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