wpf - Diseñadores y desarrolladores trabajando juntos

silverlight design (12)

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 más a menudo en estos días, 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 funcione más fácilmente?

Por ejemplo, cuando mencioné el control de código fuente a un diseñador recientemente, me dijeron rápidamente que no se pueden generar gráficos de control, 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.

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 desempeñar 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 activos de diseño que están siendo creados por 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 combinar 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.

Esto puede ser un poco fuera de tema (estoy respondiendo específicamente a su pregunta sobre control de fuente y gráficos), pero puede poner datos binarios (imágenes, etc.) en control de código fuente (y en mi opinión, en muchos casos debería) - - 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.

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

Puede ser un poco no convencional y no podrás hacer una fusión ni nada de esa naturaleza, pero habrá revisiones y un historial, etc. Las imágenes también se pueden incrustar en un archivo de recursos que también entra en control de fuente .

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 los consejos de trabajar con un diseñador, el 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í.

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 recargo y cuando cambió su CSS puro, el diseño basado en DIV en uno basado en tablas sin decirme, entonces todo mi JS se va. 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 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.

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

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

Desea involucrarlos para que revelen suposiciones desalineadas y establezcan un patrón de trabajo conjunto en lugar de arrojar cosas de un lado al otro del muro.

La medida en que los diseñadores se han sentido autorizados a distanciarse de todo el trabajo relacionado con la creación de un producto de software es un problema mucho más grande que debe resolverse. 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 es cierto del 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 donde se producen transferencias entre especializaciones excesivas, se forman colas de trabajos y memorias intermedias. 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.

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.

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 de VM), a los diseñadores generalmente no les gustan las soluciones geek, como ejecutar aplicaciones raras en un sistema operativo extranjero.
Los diseñadores usan sus herramientas del oficio: Photoshop e Illustrator. Período.
La agresividad de los horarios de hoy por lo general no brinda 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 ilustrado gráficamente. 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 tomaba un elemento de diseño y lo volví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 el paisaje actual). para verse bien en SD de baja resolución y escalar 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.

Originalmente, se preveía 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 puedes asignar 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 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.

Soy Felix Corke, el diseñador del podcast de 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 escuchado hablar de Visual Studio, C # o cualquier otro tipo de control de fuente cuando comencé a trabajar en xaml hace unos años. Eran tan extraños para mí como quizás Illustrator o 3DsMax serían para ti.

Mi único punto más importante es que no se puede esperar que el diseñador conozca las prácticas de los desarrolladores; tenga la amabilidad de prepararse para hacerlo. 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 cualquier pregunta específica!

ps NO quieres archivos de 100Mb + .psd en control de fuente;)

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

Laurent Bugnion tiene una post sobre esto que describe de lo que estoy hablando. Robby Ingebretsen también es 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 del que 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.

Recientemente, Shannon Braun realizó una presentación en una conferencia de desarrolladores locales sobre la relación entre el desarrollador y el diseñador y los flujos de trabajo que la comunidad está descubriendo que funcionan para ellos. No asistí a la conferencia, pero pensé que sus slides fueron una gran discusión sobre el tema.

Una de las cosas que descubrí es que cómo 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". Se incluye una breve lista de todos los tipos:

Escriba el código que puede aprovechar el enlace de datos. El Model-View-ViewModel o el patrón de presentación es una buena opción para esto.
Suministre stubs 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.
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".
Use un patrón de comando en lugar de 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.
¡Prueba tu 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 serían comenzar en pequeño. 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 cómo crear un 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.

Voy a suponer que se refieren a proyectos de RIA desde su mención de 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 algo de experiencia en programación aunque patético en comparación con ustedes.

Acepta que no te entenderás.

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

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.

Usted, el desarrollador, DEBE 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.

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

No es que no estés 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 él mismo. ¿Qué formato, activos? Naming?

Todas las cosas que están involucradas en la entrega 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 salvar su vida, qué es una viuda, cómo colocar capas de FireWorks o crear un ícono fotorrealista, crear un buen eslogan 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 más importante. No empieces a debatir sobre Mac vs. PC :) Los proyectos han sido cancelados debido a esto.