Diseñadores y desarrolladores que trabajan juntos

Question

Las amplias capacidades de presentación de WPF y Silverlight significan que los desarrolladores como yo trabajarán en estrecha colaboración con los diseñadores gráficos con mayor frecuencia actualmente, como es el caso en mi próximo proyecto.

¿Hay alguien por ahí que tenga algún consejo y experiencia (desde ambos puntos de vista) para hacer que esto vaya más fácilmente?

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

Scott Hanselman habló sobre este tema en un podcast, pero se centró más en las herramientas, mientras que estoy más interesado en los aspectos/aspectos de comunicación.

Answer 1

He pasado 4 meses en un proyecto trabajando muy estrechamente con un diseñador y todavía no ha recogido la idea básica de CVS (que no es mi elección del sistema de control de fuente). Estoy hablando de archivos de plantilla, JavaScript y CSS aquí. Él no es estúpido, es solo una de estas cosas que hace su trabajo más difícil por lo que se resiste a comprometerse con él.

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

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

En mi caso, ha habido muy pocos problemas últimamente, debido a que la situación con CVS ha sido resuelta, así como la idea de que no puede simplemente ir y cambiar el margen cada vez que le da la gana. En lugar de intentar crear archivos de plantilla y trabajar en ellos directamente, el diseñador solo trabaja en archivos estáticos y es mi responsabilidad insertarlos en mis archivos de plantilla.

Todo se trata de comunicación y un poco de compromiso en ambos lados.

Answer 2

Esto puede ser un poco fuera de tema (estoy respondiendo específicamente a su pregunta sobre control de fuentes y gráficos), pero puedo poner los datos binarios (imágenes, etc) en control de código fuente (y en mi opinión en una muchos casos deberían): solo ocupan más espacio en disco y no puedes usar una vista de diferencias para analizar qué ha cambiado de manera significativa, pero lo que obtienes es un historial de mensajes de compromiso que documentan cada revisión, capacidad de deshacer y la capacidad de archivar fácilmente (etiquetando una revisión en términos SVN) todos los archivos (ya sean activos visuales, documentación, código fuente, lo que sea) que pertenecen a una versión/versión específica en conjunto. También es más fácil para su sistema de compilación obtener todo lo necesario para construir una versión específica de su software desde el control de origen.

Answer 3

Involucre 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 arrojar cosas de un lado a otro sobre la pared.

Answer 4

Francamente, debe decirle al diseñador que las imágenes pueden, deben y "se pondrán en el control de fuente señor!" :)

Puede ser un poco no convencional y no podrás hacer 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 entra en control de fuente también.

XAML puede (y debe) ponerse en control de fuente y, como es un archivo de marcado, se beneficiará de todas las características.

En cuanto a las sugerencias de trabajar con un diseñador, la que está trabajando me asusta con solo ese comentario, por lo que todo se reduce a la OMS con la que está trabajando. Explicaría las mejores prácticas básicas de una manera agradable y procederé desde allí.

Answer 5

Una de las cosas que he descubierto 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 Silverlight o WPF de la web y la abres en Blend, solo para que Blend se cierre porque el código no funciona bien dentro del diseñador. Si no falla, rara vez se parece a la aplicación en ejecución.

Recientemente di una charla en Tech Ed Australia y Nueva Zelanda sobre las técnicas que puede aplicar al "diseño para la designabilidad". Una lista corta bulled se incluye:

1. Escribir código que puede tomar ventaja de enlace de datos. El Model-View-ViewModel o el patrón de presentación es una buena opción para esto.

2. Suministro de "tiempo de diseño" para sus dependencias de servicio. Si la clase a la que está vinculando hace llamadas al servicio web, asegúrese de reemplazar al cliente del servicio web con una clase de código auxiliar que devuelva "datos ficticios" que el diseñador consume dentro de la combinación. Esto puede hacerse fácilmente a través de IoC y Dependency Injection, inyectando una implementación si HtmlPage.IsEnabled == false.

3. Al utilizar el enlace de datos, puede limitar el número de "elementos con nombre" que tiene en su archivo XAML. Si escribe un código detrás, termina acoplando su código C# contra elementos con nombre como txtName o txtAddress, lo que facilita al diseñador el "error".

4. Utilice un patrón de comando en lugar del código detrás de los manejadores de eventos click. Al acoplar holgadamente el invocador de un evento desde el controlador, puede tener elementos menos nombrados 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. ¡Pruebe su código en Blend! Incluso si se considera un desarrollador puro, debe probar que su código es 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 toma decisiones de diseño de software solo para que el código sea más comprobable. Creo que es algo inteligente que hacer, y la única forma en que puede obtener un verdadero flujo de trabajo de diseñador-desarrollador.

Otros consejos podrían ser pequeños. Si su diseñador es nuevo en XAML, WPF y Silverlight, comience presentándolos al equipo del proyecto y pídales que hagan algunos diseños básicos en las herramientas que conocen. Permita que ellos hagan algunos botones e ilustraciones en Adobe Illustrator, y expórtelos a XAML, y muéstreles cómo puede aprovechar sus activos de diseño directamente. Continúa presentando más y más, y con suerte se interesarán y querrán cambiar a Blend.Es una gran curva de aprendizaje, ¡pero seguro que lo vale!

¡Buena suerte!

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

Answer 6

Originalmente, se pensó que los diseñadores profesionales trabajarían en Expression Blend, y los desarrolladores trabajarían en Visual Studio, realizando cambios en un solo conjunto compartido de archivos de origen. Si bien es posible hacerlo (siempre que tenga cuidado de comprobar regularmente que no ha roto algo esperado por el otro desarrollador o herramienta de diseño), muchos miembros de la comunidad de desarrolladores, incluidos algunos dentro de Microsoft, han descubierto beneficios para mantener la actividad del proyecto Blend y Visual Studio SEPARADO, incluso hasta el punto de cortar y pegar manualmente versiones de Xaml generadas por Blend en la fuente de proyecto "oficial" de VStudio, en lugar de permitir que los diseñadores y desarrolladores operen directamente en un único base de código compartido. El equipo de experiencia de usuario de Microsoft en el Reino Unido publicó un video que describe los problemas que encontraron al tratar de coordinar los esfuerzos de diseñadores y desarrolladores en proyectos reales.

Real_World_WPF_DesignersAndDevelopersWorkingTogether

Una de las principales lecciones aprendidas es que no se puede personal un proyecto con los diseñadores y desarrolladores que son completamente ignorantes de dominios de cada uno. Los desarrolladores deben estar lo suficientemente familiarizados con Blend para poder proporcionar a los diseñadores conchas UI útiles para que el diseñador decore, y útiles "fragmentos" de datos con los que el diseñador puede diseñar interactividad, y el diseñador debe tener suficiente comprensión de los problemas de desarrollo que No haga cosas como eliminar controles y reemplazarlos con elementos visuales personalizados, sin darse cuenta de que rompieron toda la funcionalidad vinculada al control original.

Answer 7

Soy un gran creyente en el enfoque Integrator, que es realmente el papel que he tenido que realizar para que nuestros esfuerzos de WPF tengan éxito.

Laurent Bugnion tiene un post en esto que describe de lo que estoy hablando. Robby Ingebretsen es también un gran creyente 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 generalmente sucede es que esta persona proviene del mundo de los desarrolladores o del mundo de los diseñadores. Si provienen del mundo de los desarrolladores, probablemente sean desarrolladores con tendencias de diseñador (son responsables del aspecto y la sensación, las imágenes en la aplicación, el diseño de las pantallas, etc.). Si provienen del mundo de los diseñadores, entonces no tienen miedo al código y disfrutan zambulléndose de vez en cuando para codificar y obtener esa animación o lo que sea que brille.

Sin embargo, independientemente del mundo de donde provengan, generalmente tienen que desarrollar habilidades que nunca antes habían tenido. En mi caso, soy desarrollador que ama la capa de interfaz de usuario y, por lo tanto, diría que soy un desarrollador con tendencias de diseñador. Para cubrir esa brecha y mantener conversaciones productivas con nuestro diseñador gráfico, tuve que aprender un montón de habilidades de diseñador como: aprender a usar Expression Design, XAM 3D, etc.

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

Answer 8

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

• diseñadores a menudo prefieren utilizar Mac (diseñadores en mi empresa son 100% Mac - 0% de Windows)
• Blend no se ejecuta en un Mac (por lo que las soluciones de VM - diseñadores normalmente no les gusta soluciones geek como ejecutar aplicaciones raras en un SO extranjero).
• Los diseñadores usan sus herramientas del oficio: Photoshop e Illustrator. Período.
• La agresividad de los horarios actuales generalmente no proporciona suficiente tiempo para que los diseñadores aprendan un entorno de aplicación/diseño totalmente nuevo (como Blend).

Así que, dado 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 gráficamente iluminado. Básicamente, alguien que puede tomar los activos de diseño en forma cruda, generalmente formato .psd o ilustrador, y aplicarlos según sea necesario para el proceso de solicitud.

Resulté ser ese tipo (programador gráficamente iluminado). Pasé mucho tiempo exportando XAML desde archivos de Illustrator, limpiándolos a mano cuando era necesario y haciendo que estos activos se puedan utilizar fácilmente para mostrar objetos en Blend o VS. También hubo momentos en los que tomaría un elemento de diseño y lo volvería a dibujar utilizando combinación (generalmente cuando el activo original estaba basado en mapas de bits y tenía más sentido convertirlo en vector).

Mi aplicación puede no haber sido típica, ya que era extremadamente rica en gráficos y la independencia de resolución era uno de los objetivos principales, ya que necesitaba verse bien en múltiples resoluciones y relaciones de aspecto (piense en las dificultades para diseñar TV en la actualidad paisaje: las cosas tienen que verse bien tanto en SD de baja resolución como en escalas hasta HD de alta resolución).

En resumen, creo que WPF es una tecnología increíble 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 redefina el rol del diseñador.

Answer 9

En mi experiencia, el integrador o el rol "devsigner" realmente necesita involucrarse en este proceso a menos que todos en el (pequeño) equipo puedan realizar este rol. Esta es una circunstancia muy rara. Por lo general, descubrirá que los desarrolladores son muy buenos en el desarrollo, pero que no son tan buenos con el diseño/usabilidad y los diseñadores son geniales con la estética/usabilidad pero no quieren o no tienen suficiente formación para codificar. Tener a alguien que pueda cruzarse en ambos mundos y "hablar el idioma" es muy importante.

El integrador necesita coordinar los controles que se están desarrollando con los recursos 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 de mi día en Expression Blend. Los desarrolladores trabajan principalmente en VS creando controles que cumplan con nuestras especificaciones de producto y la tienda 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 fácil.

Es muy útil crear el "aspecto" para 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 el aspecto y sentirse correcto sin verse demasiado atrapado en lo que aún podrían ser controles incompletos.

Answer 10

Supongo que se refiere a proyectos de RIA desde que mencionó SL.

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

El mejor consejo que puedo darle está basado en mis 14 años de experiencia como diseñador de UX y Visual con cierta experiencia en programación aunque patético en comparación con ustedes.

Acepta que no te entenderás.

El programador piensa en lo que funcionalidad se debe hacer, el diseñador piensa en cómo la funcionalidad debe comportarse.

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

Así que aprenda a comprender que su responsabilidad es diferente.

El desarrollador TIENE que pensar qué tan genérico es su código y no puede permitirse el lujo de tratar todo como único y una composición codificada. Eso es a menos que pueda automatizar esa singularidad de alguna manera.

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

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 comprenda el suyo.

No es que no esté interesado en hacer la mejor aplicación en el mundo. Es solo que algunas de estas decisiones de diseño toman bastante tiempo.

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

Todo lo que está involucrado en la entrega de un paradigma a otro.

Y lo más importante 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 salvar su vida, qué es una viuda, cómo crear capas de FireWorks o crear un icono fotorrealista, crear un buen lema o hacer algo comprensible para el promedio de Joe en 4 palabras No sabe qué es una grilla o una alineación y tiende a hacer que las cosas sean de color verde y morado sobre negro.

Y el diseñador debe entender que el hecho de que se ocupe de la programación no significa que usted sea un robot, no puede tener ideas y soluciones creativas. También debería tratar de aprender cómo programar al menos un pseudo programa para que comprenda lo que implica hacer su proyecto.

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

Answer 11

Soy Felix Corke, el diseñador del podcast hanselman que mencionaste, así que aquí hay un par de puntos de una creatividad genuina en lugar de un desarrollador.

Me llevó mucho tiempo acostumbrarme a las herramientas de desarrollo. Nunca había oído hablar de Visual Studio, C# o cualquier tipo de control de fuente cuando comencé a hacer el trabajo xaml hace unos años. Eran tan extraños para mí como quizás Illustrator o 3DsMax serían para ti.

Mi punto más importante es que no se puede esperar que el diseñador conozca las prácticas de desarrollo. Esté preparado para hacer muchas cosas. No tendrá que aprender nada nuevo, mientras que el diseñador se lanzará a un lado completamente nuevo y aterrador del desarrollo de aplicaciones. Hice un lío correcto de algunas soluciones y controles (y todavía lo hago).

Afortunadamente, aprendí a ser más un integrador enfocado en el diseño que una creatividad directa, y tal vez este es un rol que necesita incluir en su proyecto. Esta es la ilustración que hice para nuestra belleza y la sesión geek - diseñador/desarrollador en Mix - si alguno de ustedes está demasiado lejos en cualquier extremo del espectro, puede ser difícil entender cómo funciona el otro y cuál debería ser su función.

feliz de responder a cualquier pregunta específica!

ps NO desea 100Mb + Psd archivos de control de código fuente;)

Answer 12

La medida en que los diseñadores han llegado a sentirse con derecho a estar lejos de todo el trabajo que supone la construcción de un producto de software es una gran problema más grande que necesita ser resuelto. No se complazca con el derecho expresado de ningún diseñador a no tener que saber cómo su trabajo se integra en el todo.

El tipo de especialización rígida 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 de forma predecible crea más retrabajo y tiempos de ciclo más largos.

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

La especialización extrema es siempre un multiplicador exponencial en problemas de productividad. Solucionarlo de manera organizacional mediante la adopción de procesos que promuevan culturas de aprendizaje. Este es el nivel de madurez que la mayoría de las otras industrias de producción ya se han dado cuenta y que el software arrastra tristemente detrás.

En cada lugar de un flujo de trabajo de desarrollo en el que se producen transferencias entre especializaciones excesivas, se forman colas de trabajos y búferes. El software sigue siendo una de las pocas industrias que no reconoce este como uno de los mayores problemas que enfrentamos. Esto se agrava aún más en la comunidad de Microsoft ya que la especialización excesiva parece cada vez más normal debido a la perpetuación de la especialización excesiva de Microsoft a través de sus herramientas y orientación. A menos que pueda permitirse el lujo de gastar tanto dinero como Microsoft en los 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 probar y el que no puede programar es un síntoma de la misma inmadurez industrial.

No aprenderá nada de esto de la plantilla de Scrum para TFS.Microsoft estaba a años luz de la agilidad de pensar en el juego incluso en sus formas más rudimentarias, y ahora que estamos progresando en el pensamiento Lean, Microsoft estará a tres o cinco años de intentar incorporar el pensamiento Lean en sus líneas de productos. . No espere que Microsoft le indique cómo configurar un equipo y un flujo de trabajo. Puede aprender ahora de las personas a las que Microsoft finalmente prestará atención en unos pocos años.