En el pasado, muchas empresas y diseñadores web tenían un flujo de trabajo de dos o tres partes como mínimo: diseño, marcado, backend. Estos están generalizando y las líneas pueden desdibujarse un poco... pero estoy seguro de que entiendes mi esencia.
A menudo, el diseñador web era "solo visual" y solo sería responsable de construir una maqueta muy detallada en un software de edición de imágenes, como Photoshop o Fireworks. Las maquetas mostrarían todos los aspectos posibles de una página web, desde opciones de colores y tipos, hasta fondos, íconos, fotos y otras imágenes que se utilizarán. Pero el "diseñador" nunca se preocupó por la construcción e implementación real en vivo. Se centraron únicamente en la apariencia.
Una vez que se aprobó el diseño (mediante la revisión de estos archivos de imagen), se llevó a cabo la etapa dos: la transición de los archivos de imagen a HTML/CSS en vivo.
En un entorno de un solo puesto o independiente, el diseñador web puede haber usado segmentos y exportarlos a HTML a través de algunas opciones de aplicaciones internas. En raras ocasiones, el diseñador puede construir marcos de página HTML/CSS básicos.
En algunos entornos corporativos, estas maquetas permanecerían en forma de un archivo de imagen en capas (.psd, .png [para Fireworks]) para el diseñador web y el diseñador nunca se preocuparía por implementar ningún marcado o código. El "diseñador" nunca tuvo que preocuparse por cómo construir HTML o CSS para implementar esta maqueta de imagen que crearon. Los archivos de imagen fueron/son entregados a un "desarrollador" que luego es responsable de construir HTML/CSS que coincida con el archivo de imagen.
Me imagino que algunos todavía trabajarán mucho de esta manera. Sin embargo, con los avances en los lenguajes de marcado, a saber, CSS3, y las mejoras en la compatibilidad con los navegadores, en muchos casos, el tiempo dedicado a construir cuidadosamente una representación de trama de una página web completa puede ser en gran medida inútil en muchos casos.
Con el marcado actual, es muy fácil implementar muchas necesidades de diseño web directamente a través de HTML/CSS y el uso de la aplicación de imágenes se limita a generar pequeñas imágenes o fotografías que pueden ser necesarias. (Las bibliotecas y/o plantillas como Bootstrap han impulsado aún más esta noción).
En mi propio flujo de trabajo, me he alejado notablemente de las maquetas de página completa a menos que se soliciten específicamente . Hago esto para mejorar la velocidad de diseño y asegurar que lo que se aprueba esté cerca de lo que finalmente se representará en los navegadores. De hecho, no he creado una maqueta de página completa en varios años. Pero soy consciente de que todavía hay flujos de trabajo que utilizan este método.
¿Hay algún beneficio real en la construcción de maquetas de página completa en la aplicación de edición de imágenes antes de sumergirse directamente en HTML/CSS para la construcción del diseño?
El beneficio de construir maquetas de página completa es la división del trabajo.
En las empresas más grandes que tienen tanto un diseñador como un desarrollador (front-end), el trabajo del diseñador es diseñar y el trabajo del desarrollador es escribir código .
Tener esta división le permite al diseñador dedicar todo su tiempo a trabajar en la apariencia y la interfaz del sitio web y no tener que saber nada sobre cómo se creó. Pueden crear un diseño de mayor calidad y pensar en las decisiones durante más tiempo precisamente porque no están trabajando para que el código haga lo que quieren al mismo tiempo.
También le permite al desarrollador escribir más código al no tener que pensar en cómo se verá, incluidos los pequeños detalles y los estados variables. Implementan el diseño lo mejor que pueden en el tiempo dado y pueden pasar a otro proyecto.
Si el diseñador también es el desarrollador, creo que la mayoría de las personas más o menos están comenzando a ponerse del lado de usted en el sentido de que crean un producto más tosco e iteran rápidamente para probar las cosas. Esto permite que las ideas se prueben rápidamente en lugar de crear un documento de Photoshop con píxeles perfectos.
Sin embargo, el diseño aproximado e iterativo sin código también es un enfoque válido e increíblemente útil, especialmente para los diseños y el flujo de trabajo. Los lenguajes de marcado y las nuevas tecnologías no se inventaron trabajando rápidamente con ideas aproximadas :)
Voy a molestar a Guffa con esta respuesta. Para ser claros, no estoy tratando de destacar a Guffa, sino que los puntos con viñetas son muy comunes que escucho. Me gustaría ofrecer algunos contrapuntos también. No digo que Guffa esté mal y yo tengo razón. Simplemente estoy ofreciendo un contrapunto.
- La parte creativa del proceso de diseño sufre si se dedica tiempo a tratar de descubrir cómo hacer cosas diferentes en HTML y CSS.
Esto es cierto si uno no considera el código igualmente creativo. Photoshop y HTML/CSS/JS son medios en los que puede trabajar un artista. Así como una pintura es tan creativa como el carboncillo, Photoshop puede ser un medio tan creativo como HTML/CSS/JS.
Y el gran beneficio de trabajar directamente en HTML/CSS/JS es su multidimensionalidad. Photoshop, al final del día, es un lienzo plano. HTML/CSS/JS es un lienzo dinámico con fluidez, interacción, animación, etc.
En pocas palabras, diría que el código es el medio más creativo en este caso.
- Cuando los diseñadores y los codificadores son personas diferentes, incluso si los diseñadores son bastante buenos en HTML y CSS, rara vez son realmente buenos en la codificación. El resultado sería (en diversos grados) un código ineficiente que está inflado y difícil de mantener.
Lamentablemente, el contrapunto a esto es algo con lo que me encuentro con frecuencia: la mayoría de los desarrolladores que trabajan en roles dedicados trabajan en organizaciones más grandes (donde los roles dedicados son más la norma) y, debido a la falta de conocimiento interdisciplinario ( y, a menudo, una falta total de código de capa de presentación) hacen que algunos de los códigos front-end más inflados y difíciles de mantener que he visto.
El punto es que no consideraría las habilidades de diseño visual de uno como una indicación de sus habilidades de codificación. Iría un paso más allá y argumentaría que un generalista talentoso que conoce el diseño y la codificación, incluso si no es el mejor diseñador o el mejor codificador, a menudo puede crear un mejor producto general que el equipo altamente segregado simplemente por el hecho que pueden ver el panorama general a medida que crean. Se pierde mucho menos en la traducción.
- Si comienza a escribir el código antes de tener una visión clara de cómo debería verse el diseño, toma decisiones desinformadas sobre cómo construir el código. El riesgo es que empeore el código y limite las posibilidades del diseño.
Pero diseñar en código no significa que ese sea su código de producción. He trabajado en proyectos en los que la mayor parte del código que creamos era puramente para el diseño completo y luego para hacer algunos prototipos. Una vez terminado, haríamos una reescritura limpia. Esto tuvo el beneficio adicional de que pudimos encontrar muchos "errores" en la primera ronda de codificación.
- El código HTML y CSS puede cambiar bastante con pequeños cambios en el diseño, lo que haría que el proceso de diseño fuera más estático. Corre el riesgo de limitarse solo a los cambios que son fáciles de realizar en el código.
El contraargumento es que el diseñador se limita solo a los cambios que son fáciles de realizar en Photoshop. No es un muy buen argumento de cualquier manera.
La única razón para no hacer una maqueta de Photoshop primero es si el diseñador no comprende las limitaciones del código. Nunca querrás darle al cliente un obsequio de algo que no puede tener en la final.
Siempre que el PSD represente algo que se pueda replicar bastante de cerca en CSS/HTML (dadas las limitaciones entre navegadores y medios cruzados), lo haría en Photoshop (o InDesign; conozco algunos diseñadores que lo hacen). Es más rápido y mucho más fácil manipular imágenes. Simular en CSS para mí sería codificar antes de codificar, si eso tiene sentido.
Hay varias razones para mantener el elemento de diseño separado del elemento de generación de código, por ejemplo:
La parte creativa del proceso de diseño sufre si se dedica tiempo a tratar de descubrir cómo hacer cosas diferentes en HTML y CSS.
Cuando los diseñadores y los codificadores son personas diferentes, incluso si los diseñadores son bastante buenos en HTML y CSS, rara vez son realmente buenos en la codificación. El resultado sería (en diversos grados) un código ineficiente que está inflado y difícil de mantener.
Si comienza a escribir el código antes de tener una visión clara de cómo debería verse el diseño, toma decisiones desinformadas sobre cómo construir el código. El riesgo es que empeore el código y limite las posibilidades del diseño.
El código HTML y CSS puede cambiar bastante con pequeños cambios en el diseño, lo que haría que el proceso de diseño fuera más estático. Corre el riesgo de limitarse solo a los cambios que son fáciles de realizar en el código.
scott
andy holmes