Diseñadores y desarrolladores trabajando juntos [cerrado]

Question

Las ricas capacidades de presentación de WPF y Silverlight significan que desarrolladores como yo trabajaremos estrechamente con diseñadores gráficos con más frecuencia en estos días, como será el caso en mi próximo proyecto.

¿Alguien tiene algún consejo y experiencia (desde ambos puntos de vista) para hacer que esto funcione mejor?

Por ejemplo, cuando recientemente mencioné el control de fuente a un diseñador, rápidamente me dijeron que no se pueden controlar gráficos, imágenes, etc., por lo que es una pérdida de tiempo.Entonces respondí:Bien, pero ¿qué pasa con los archivos XAML en WPF/Silverlight?

Scott Hanselman habló sobre este tema en un podcast, pero él se centró más en las herramientas, mientras que a mí me interesan más los temas/aspectos de comunicación.

Answer 1

Pasé 4 meses en un proyecto trabajando muy de cerca con un diseñador y él todavía no ha captado la idea básica de CVS (que no es mi elección de sistema de control de fuente).Me refiero a archivos de plantilla, JavaScript y CSS.No es estúpido, es sólo una de esas cosas que hace que su trabajo sea más difícil, por lo que se resiste a comprometerse completamente con él.

En mi caso, tuve que recalcar el hecho de que casi todo mi JavaScript dependía del marcado y cuando cambió su diseño CSS puro, basado en DIV, a uno basado en tablas sin decirme, entonces todo mi JS se fue. romper.

A menudo, durante el transcurso del proyecto, yo y el diseñador, con quien me llevo bastante bien y con quien juego al fútbol fuera del trabajo, tuvimos intercambios muy acalorados sobre nuestras respectivas responsabilidades.Si no lo conociera lo suficiente como para superar estos intercambios, creo que habría creado un ambiente de trabajo insoportable.Por eso creo que es importante establecer entre ambos y con algún tipo de gerente o supervisor del proyecto exactamente lo que se espera de ambas partes durante el proyecto.

En mi caso, últimamente ha habido muy pocos problemas, porque la situación con CVS se ha solucionado, así como la idea de que no puede simplemente ir y cambiar el margen cuando le apetezca.En lugar de intentar crear archivos de plantilla y trabajar en ellos directamente, el diseñador solo trabaja con archivos estáticos y es mi responsabilidad conectarlos a mis archivos de plantilla.

Se trata de comunicación y un poco de compromiso por ambas partes.

Answer 2

Una de las cosas que descubrí es que la forma en que usted, como desarrollador, diseña su código afecta en gran medida lo que el diseñador puede hacer con él.A menudo descargas una aplicación de muestra de Silverlight o WPF de la web y la abres en Blend, solo para que Blend se bloquee porque el código no se ejecuta bien dentro del diseñador.Si no falla, rara vez se parecerá a la aplicación en ejecución.

Recientemente di una charla en Tech Ed Australia y Nueva Zelanda sobre técnicas que se pueden aplicar al "diseño para la designabilidad".Se incluye una breve lista redondeada:

1. Escriba código que pueda aprovechar el enlace de datos.El modelo Model-View-ViewModel o el patrón de presentación es una buena opción para esto.

2. Proporcione resguardos de "tiempo de diseño" para sus dependencias de servicio.Si la clase a la que se vincula realiza llamadas a servicios web, asegúrese de reemplazar el cliente del servicio web con una clase auxiliar que devuelva "datos ficticios" que el diseñador consume dentro de la mezcla.Esto se puede hacer fácilmente mediante IoC e inyección de dependencia, inyectando una implementación si HtmlPage.IsEnabled == false.

3. Al utilizar el enlace de datos, puede limitar la cantidad de "elementos con nombre" que tiene en su archivo XAML.Si escribe una gran cantidad de código detrás, terminará acoplando su código C# con elementos con nombre como txtName o txtAddress, lo que facilitará que el diseñador "meta la pata".

4. Utilice un patrón de comando en lugar del código detrás de los controladores de eventos de clic.Al acoplar libremente el invocador de un evento del controlador, puede tener menos elementos con nombre y le da al diseñador la libertad de elegir entre un botón o un elemento de menú para invocar un comando específico.

5. ¡Prueba tu código en Blend!Incluso si se considera un desarrollador puro, debe probar que su código sea consumible por una herramienta y esforzarse por obtener la mejor experiencia posible en el momento del diseño.Algunos argumentarían que una herramienta no debería afectar el diseño de su software, del mismo modo que alguien se queja del "diseño para la capacidad de prueba" y de tomar decisiones de diseño de software solo para hacer que el código sea más comprobable.Creo que es algo inteligente y la única forma de lograr un verdadero flujo de trabajo entre diseñador y desarrollador.

Otros consejos serían empezar poco a poco.Si su diseñador es nuevo en XAML, WPF y Silverlight, comience presentándolo al equipo del proyecto y pídale que haga algunos diseños básicos en las herramientas que conoce.Permítales hacer algunos botones e ilustraciones en Adobe Illustrator, exportarlos a XAML y mostrarles cómo puede aprovechar sus recursos de diseño directamente.Continúe presentando más y más y, con suerte, se interesarán y querrán cambiar a Blend.Es toda una curva de aprendizaje, ¡pero seguro que vale la pena!

¡Buena suerte!

PD:He escrito mucho sobre patrones y cómo crear código amigable para los diseñadores en mi blog en http://jonas.follesoe.no.También puede encontrar enlaces a una grabación de video de mi charla de Tech Ed, así como muchos enlaces para leer más sobre el tema.

Answer 3

Esto puede estar un poco fuera de tema (estoy respondiendo específicamente a tu pregunta sobre control de fuente y gráficos), pero poder coloque datos binarios (imágenes, etc.) en el control de fuente (y en mi opinión, en muchos casos debería hacerlo): simplemente ocupan más espacio en el disco y no se puede usar una vista de diferencias para analizar lo que ha cambiado de manera significativa , pero lo que sí obtiene es un historial de mensajes de confirmación que documentan cada revisión, la capacidad de revertir y la capacidad de archivar fácilmente (etiquetar una revisión en términos SVN) todos los archivos (ya sean recursos visuales, documentación, código fuente, lo que sea) que pertenecen a una versión/lanzamiento específico juntos.También es más fácil para su sistema de compilación obtener todo lo necesario para compilar una versión específica de su software desde el control de fuente.

Answer 4

Involucrar al diseñador gráfico en las primeras sesiones de diseño y arquitectura.

Quiere involucrarlos para revelar suposiciones desalineadas y establecer un patrón de trabajo conjunto en lugar de tirar las cosas de un lado a otro por encima de la pared.

Answer 5

Originalmente, se imaginó que los diseñadores profesionales trabajarían en Expression Blend y los desarrolladores trabajarían en Visual Studio, realizando cambios en un único conjunto compartido de archivos fuente.Si bien es posible hacerlo (siempre y cuando tengas cuidado de verificar periódicamente que no hayas roto algo que el otro desarrollador esperaba).o herramienta de diseño), muchos miembros de la comunidad de desarrolladores, incluidos algunos dentro de Microsoft, han descubierto beneficios al mantener SEPARADAS las actividades de los proyectos de Blend y Visual Studio, incluso hasta el punto de cortar y pegar manualmente versiones cuidadosamente refactorizadas de Xaml generado por Blend en la fuente "oficial" del proyecto VStudio, en lugar de permitir que los diseñadores y desarrolladores operen directamente en una única base de código compartido.El equipo de experiencia de usuario de Microsoft en el Reino Unido publicó un vídeo que describe los problemas que encontraron al intentar coordinar los esfuerzos de diseñadores y desarrolladores en proyectos reales.

Real_World_WPF_DesignersAndDevelopersTrabajando juntos

Una de las principales lecciones aprendidas es que no se puede dotar de personal a un proyecto con diseñadores y desarrolladores que ignoran por completo los dominios de los demás.Los desarrolladores deben estar lo suficientemente familiarizados con Blend para poder proporcionarles a los diseñadores shells de UI útiles para que los decoren, y "stubs" de datos útiles con los que el diseñador pueda diseñar interactividad, y el diseñador debe tener suficiente comprensión de los problemas de desarrollo que no No haga cosas como eliminar controles y reemplazarlos con elementos visuales personalizados, sin darse cuenta de que rompieron todas las funciones vinculadas al control original.

Answer 6

La visión de Microsoft sobre el matrimonio del flujo de trabajo entre diseñador y desarrollador definitivamente parece romperse en la vida real.Tengo experiencia trabajando en un proyecto WPF a escala bastante grande que involucró 2 recursos de diseño dedicados durante aproximadamente 4 meses.Aquí hay algunos datos que Microsoft parece olvidar a menudo.

• Los diseñadores a menudo prefieren usar Mac (los diseñadores de mi empresa son 100% Mac - 0% Windows)
• Blend no se ejecuta en una Mac (en lo que respecta a las soluciones VM; a los diseñadores normalmente no les gustan las soluciones geek como ejecutar aplicaciones extrañas en un sistema operativo extranjero).
• Los diseñadores utilizan sus herramientas del oficio: Photoshop e Illustrator.Período.
• La agresividad de los cronogramas actuales generalmente no brinda suficiente tiempo para que los diseñadores aprendan una aplicación/entorno de diseño totalmente nuevo (como Blend).

Teniendo en cuenta lo anterior, lo que noté fue que esto crea un nuevo tipo de trabajo: ya sea un diseñador muy técnico o un programador con conocimientos gráficos.Básicamente, alguien que pueda tomar los recursos de diseño en formato bruto (generalmente .psd o formato Illustrator) y aplicarlos según sea necesario en el proceso de solicitud.

Resulté ser ese tipo (programador ilustrado gráficamente).Pasé mucho tiempo exportando XAML desde archivos de Illustrator, limpiándolos a mano cuando era necesario y haciendo que estos recursos fueran objetos de visualización fácilmente utilizables en Blend o VS.También hubo momentos en los que tomaba un elemento de diseño y lo volvía a dibujar usando blend (generalmente cuando el recurso original estaba basado en un mapa de bits y tenía más sentido convertirlo a vector).

Es posible que mi aplicación no haya sido la típica, ya que era extremadamente rica gráficamente y la independencia de la resolución era uno de los principales objetivos, ya que necesitaba verse bien en múltiples resoluciones y relaciones de aspecto (pensemos en las dificultades de diseñar para TV en el panorama actual; las cosas han cambiado). para verse bien tanto en SD de baja resolución como en HD de alta resolución).

En resumen, creo que WPF es una tecnología asombrosa y absolutamente un paso en la dirección correcta para Microsoft.Sin embargo, no es la solución definitiva para integrar al diseñador en el proceso de desarrollo, a menos que se redefina el papel del diseñador.

Answer 7

Soy Felix Corke, el diseñador del podcast de Hanselman que mencionaste, así que aquí hay un par de puntos de un creativo genuino en lugar de un desarrollador.

Me tomó mucho tiempo acostumbrarme a las herramientas de desarrollo; nunca había oído hablar de Visual Studio, C# ni de ningún tipo de control de fuente cuando comencé a trabajar con xaml hace unos años.Eran tan extraños para mí como lo serían Illustrator o 3DsMax para ti.

Mi punto más importante es que no se puede esperar que el diseñador conozca las prácticas de los desarrolladores; esté preparado para tomarse de la mano mucho.No tendrás que aprender nada nuevo, mientras que el diseñador se adentrará en un lado completamente nuevo y aterrador del desarrollo de aplicaciones.Hice un buen desastre con algunas soluciones y comprobaciones (y todavía lo hago).

Afortunadamente, he aprendido a convertirme más en un integrador centrado en el diseño que en un simple creativo, y tal vez este sea un rol que debas incluir en tu proyecto.Esta es la ilustración que hice para nuestra sesión de belleza y geek - diseñador/desarrollador en Mix - si alguno de ustedes está demasiado lejos en cualquiera de los extremos del espectro, puede ser difícil entender cómo funciona el otro y cuál debería ser su papel.

¡Feliz de responder cualquier pregunta específica!

PD: NO desea archivos .psd de más de 100 Mb en el control de fuente;)

Answer 8

Creo firmemente en el enfoque de Integrador, que es realmente el papel que he tenido que desempeñar para que nuestros esfuerzos en WPF sean exitosos.

Laurent Bugnion tiene un correo en esto que describe de lo que estoy hablando. Robby Ingebretsen también cree firmemente en este enfoque.

Pero básicamente, alguien tiene que cubrir la 'brecha' que existe entre el mundo de los desarrolladores y el mundo de los diseñadores.Lo que suele pasar es que esta persona proviene del mundo desarrollador o del mundo del diseñador.Si provienen del mundo de los desarrolladores, entonces probablemente sean desarrolladores con tendencias de diseño (son responsables de la apariencia, las imágenes de la aplicación, el diseño de las pantallas, etc.).Si provienen del mundo del diseño, entonces no le temen al código y disfrutan sumergiéndose de vez en cuando en el código para hacer que esa animación o lo que sea brille.

Sin embargo, independientemente del mundo del que vengan, normalmente tienen que desarrollar habilidades que nunca antes habían tenido.En mi caso, soy un desarrollador al que le encanta la capa de interfaz de usuario y por tanto diría que soy un desarrollador con tendencias de diseñador.Para cubrir ese vacío y tener conversaciones productivas con nuestro diseñador gráfico, tuve que adquirir una gran cantidad de habilidades de diseñador como:aprender a usar Expression Design, XAM 3D, etc.

Shannon Braun hizo recientemente una presentación en una conferencia de desarrolladores local sobre la relación desarrollador/diseñador y los flujos de trabajo que la comunidad está descubriendo que funcionan para ellos.No asistí a la conferencia, pero pensé que su diapositivas Hubo una gran discusión sobre el tema.

Answer 9

Hasta qué punto los diseñadores han llegado a sentirse con derecho a distanciarse de todo el trabajo involucrado en la construcción de un producto de software es un problema mucho mayor que debe resolverse.No complazca el derecho expreso de ningún diseñador a no tener que saber cómo se integra su trabajo en el conjunto.

El tipo de marcada especialización que ha crecido en la comunidad de diseñadores es uno de los mayores problemas de madurez industrial que enfrenta la industria del desarrollo de software.Es un grado de especialización que, como era de esperar, genera más retrabajo y tiempos de ciclo más largos.

Esto también se aplica al sentido de derecho de los desarrolladores a ignorar felizmente el diseño y la implementación de la interacción.

La especialización extrema es siempre un multiplicador exponencial de los problemas de productividad.Resolverlo organizacionalmente adoptando procesos que promuevan culturas de aprendizaje.Este es el nivel de madurez que la mayoría de las otras industrias de producción ya han alcanzado, y que el software arrastra lamentablemente detrás.

En cada lugar de un flujo de trabajo de desarrollo donde se producen traspasos entre la sobreespecialización, se forman colas de trabajo y buffers.El software sigue siendo una de las pocas industrias que no reconoce que éste es uno de los mayores problemas que enfrentamos.Esto se ve aún más exacerbado en la comunidad de Microsoft, ya que la sobreespecialización parece cada vez más normal debido a la perpetuación de la sobreespecialización por parte de Microsoft a través de sus herramientas y orientación.A menos que pueda darse el lujo de desperdiciar tanto dinero como Microsoft en esfuerzos de desarrollo, debería buscar metodologías que estén mucho mejor informadas sobre cuestiones de flujo y productividad.

En consecuencia, el desarrollador que no puede realizar pruebas y el evaluador que no puede codificar son síntomas de la misma inmadurez industrial.

No aprenderá nada de esto de la plantilla Scrum para TFS.Microsoft estuvo años detrás de la curva en cuanto a implementar el pensamiento ágil incluso en sus formas más rudimentarias, y ahora que estamos avanzando hacia el pensamiento Lean, Microsoft estará a otros tres a cinco años de intentar incorporar el pensamiento Lean en sus líneas de productos. .No espere a que Microsoft le diga cómo dar forma a un equipo y un flujo de trabajo.Puede aprender ahora mismo de las personas a las que Microsoft finalmente prestará atención dentro de unos años.

Answer 10

En mi experiencia, el rol de integrador o "diseñador" realmente debe estar involucrado en este proceso, a menos que todos los miembros del (pequeño) equipo puedan desempeñar este rol.Esta es una circunstancia muy rara.Por lo general, encontrará que los desarrolladores son muy buenos desarrollando pero no tan buenos con el diseño/usabilidad y los diseñadores son excelentes con la estética/usabilidad pero no quieren o no tienen la educación suficiente para codificar.Tener a alguien que pueda cruzar ambos mundos y "hablar el idioma" es muy importante.

El integrador necesita coordinar los controles que se están desarrollando con los activos de diseño que están creando los diseñadores.En nuestro proyecto actual, tenemos 6 desarrolladores activos y 2 diseñadores de una tienda externa.Soy el integrador de este proyecto y paso la mayor parte del día en Expression Blend.Los desarrolladores trabajan principalmente en VS creando controles que cumplan con las especificaciones de nuestro producto y el taller de diseño está diseñando cómo se verá el producto final.Los diseñadores están trabajando en Illustrator.Mi trabajo es tomar los archivos de Illustrator y crear estilos de control a partir de ellos y luego aplicarlos a los controles desarrollados por nuestro equipo de desarrollo.A medida que avanzamos hacia Blend 3 con soporte nativo para archivos PSD y AI, esta tarea se vuelve mucho más sencilla.

Es muy útil crear el "aspecto" de su aplicación en una solución separada del tronco principal de la aplicación y luego fusionar sus ResourceDictionaries en la aplicación principal más adelante.Puede obtener la apariencia correcta sin quedar demasiado atrapado en lo que aún podrían ser controles incompletos.

Answer 11

Voy a suponer que te refieres a proyectos RIA ya que mencionas SL.

He trabajado en bastantes proyectos RIA con Adobe diseñando y desarrollando aplicaciones y servicios.

El mejor consejo que puedo darles se basa en mis 14 años de experiencia como diseñador visual y de UX con cierta experiencia en programación, aunque patético en comparación con ustedes.

Acepten que no se entenderán.

El programador piensa en qué La funcionalidad debe hacerse, el diseñador piensa en cómo la funcionalidad debería comportarse.

Para el desarrollador, un botón es generalmente genérico, para el diseñador no es el caso.Los diseñadores piensan en composición, los desarrolladores piensan en marcos.

Así que aprende a comprender que tu responsabilidad es diferente.

Usted, el desarrollador, DEBE pensar en qué tan genérico es su código y no puede darse el lujo de tratar todo como si fuera único y una composición codificada.Eso es a menos que puedas automatizar esa singularidad de alguna manera.

El diseñador DEBE pensar en la aplicación o servicio como algo único.Podría significar que un botón no es un botón.Puede haber diferentes tamaños o colores u otras molestias.

Así que asegúrese de desarrollar una buena relación con el diseñador reconociendo que comprende la responsabilidad del diseñador y asegúrese de que él comprenda la suya.

No es que no estés interesado en hacer la mejor aplicación del mundo.Lo que pasa es que algunas de estas decisiones de diseño llevan bastante tiempo.

Asegúrese de tener muy claro cómo debe entregarle el diseñador para que no pierda su tiempo ni el suyo.¿Qué formato, activos?¿Nombrar?

Todas las cosas que están involucradas en la transición de un paradigma a otro.

Y lo más importante es comunicar y respetar que no saben cómo hacer JavaScript o cómo entender las ideas básicas de CVS.

La mayoría de los desarrolladores no sabrían cómo utilizar el kern para salvarles la vida, qué es una viuda, cómo superponer mejor FireWorks o crear un ícono fotorrealista, idear un buen eslogan o hacer algo comprensible para el ciudadano medio en 4 palabras.No sabes qué es una cuadrícula o alineación y tiendes a hacer las cosas verdes y moradas sobre negro.

Y el diseñador debe comprender que el hecho de que se ocupe de la programación no significa que sea un robot, que no pueda tener ideas y soluciones creativas.También debería intentar aprender a programar al menos un pseudoprograma para que comprenda lo que implica realizar su proyecto.

Y más importante.No empieces a debatir Mac vs.PC :) Los proyectos han sido cancelados debido a esto.

Answer 12

Francamente, debes decirle al diseñador que las imágenes pueden, deberían y "¡se pondrá en el Control de la fuente Mister!" :)

Puede que sea un poco poco convencional y no podrá realizar una fusión ni nada por el estilo, pero habrá revisiones y un historial, etc.Las imágenes también se pueden incrustar en un archivo de recursos que también pasa al control de código fuente.

XAML puede (y debe) colocarse en control de código fuente y, como es un archivo de marcado, se beneficiará de todas las funciones.

En cuanto a los consejos para trabajar con un diseñador, el que estás trabajando me asusta muchísimo solo con ese comentario, por lo que todo puede reducirse a QUIÉN estás trabajando.Explicaría las mejores prácticas básicas de una manera agradable y procedería a partir de ahí.