Designers e desenvolvedores trabalhando juntos [fechado]

Question

Os ricos recursos de apresentação do WPF e do Silverlight significam que desenvolvedores como eu trabalharão em estreita colaboração com designers gráficos com mais frequência atualmente, como será o caso em meu próximo projeto.

Alguém aí tem alguma dica e experiência (de ambos os pontos de vista) para tornar isso mais tranquilo?

Por exemplo, quando mencionei recentemente o controle de origem para um designer, rapidamente me disseram que você não pode controlar o código-fonte de gráficos, imagens, etc., então é uma perda de tempo.Então eu respondi:ok, mas e os arquivos XAML no WPF/Silverlight?

Scott Hanselman falou sobre este tópico em um podcast, mas ele se concentrou mais nas ferramentas, enquanto eu estou mais interessado nas questões/aspectos de comunicação.

Answer 1

Passei 4 meses em um projeto trabalhando em estreita colaboração com um designer e ele ainda não entendeu a ideia básica do CVS (que não é minha escolha de sistema de controle de origem).Estou falando de arquivos de modelo, JavaScript e CSS aqui.Ele não é estúpido, é apenas uma daquelas coisas que torna seu trabalho mais difícil, então ele resiste a se comprometer totalmente com isso.

No meu caso, eu tive que realmente enfatizar o ponto de que quase todo o meu JavaScript dependia da marcação e quando ele mudou seu CSS puro, layout baseado em DIV para um layout baseado em tabela sem me dizer que todo o meu JS estava indo quebrar.

Muitas vezes, durante o projeto, eu e o designer, com quem me dou muito bem e com quem jogo futebol fora do trabalho, tivemos discussões muito acaloradas sobre nossas respectivas responsabilidades.Se eu não o conhecesse bem o suficiente para superar essas trocas, acho que teria criado um ambiente de trabalho insuportável.Então acho importante que você estabeleça entre vocês dois e com algum tipo de gerente ou supervisor do projeto exatamente o que se espera de ambas as partes durante o projeto.

No meu caso tem havido muito poucos problemas ultimamente, porque a situação com o CVS foi resolvida, bem como a ideia de que ele não pode simplesmente mudar a margem sempre que lhe apetecer.Em vez de tentar criar arquivos de modelo e trabalhar neles diretamente, o designer só trabalha em arquivos estáticos e é minha responsabilidade conectá-los aos meus arquivos de modelo.

É tudo uma questão de comunicação e um pouco de compromisso de ambos os lados.

Answer 2

Uma das coisas que descobri é que o modo como você, como desenvolvedor, projeta seu código afeta muito o que o designer pode fazer com ele.Muitas vezes você baixa um aplicativo de amostra Silverlight ou WPF da web e o abre no Blend, apenas para que o Blend trave porque o código não funciona bem dentro do designer.Se não travar, raramente se parecerá com o aplicativo em execução.

Recentemente dei uma palestra na Tech Ed Austrália e Nova Zelândia sobre técnicas que você pode aplicar ao "design para designabilidade".Uma pequena lista com marcadores está incluída:

1. Escreva código que possa aproveitar a vinculação de dados.O Model-View-ViewModel ou o padrão de apresentação é uma boa opção para isso.

2. Forneça stubs de "tempo de design" para suas dependências de serviço.Se a classe à qual você está vinculando fizer chamadas de serviço da Web, certifique-se de substituir o cliente do serviço da Web por uma classe stub que retorne "dados fictícios" que o designer consome dentro do blend.Isso pode ser feito facilmente por meio de IoC e injeção de dependência, injetando uma implementação se HtmlPage.IsEnabled == false.

3. Ao usar a vinculação de dados, você pode limitar o número de "elementos nomeados" que possui no arquivo XAML.Se você escrever muito código atrás, acabará acoplando seu código C# a elementos nomeados, como txtName ou txtAddress, tornando mais fácil para o designer "estragar tudo".

4. Use um padrão de comando em vez de código por trás dos manipuladores de eventos de clique.Ao acoplar livremente o invocador de um evento ao manipulador, você pode ter menos elementos nomeados e dá ao designer a liberdade de escolher entre um botão ou um item de menu para invocar um comando específico.

5. Teste seu código no Blend!Mesmo que você se considere um desenvolvedor puro, você deve testar se seu código pode ser consumido por uma ferramenta e se esforçar para obter a melhor experiência possível em tempo de design.Alguns argumentariam que uma ferramenta não deveria afetar o design do seu software, assim como alguém reclama do "design para testabilidade" e da tomada de decisões de design de software apenas para tornar o código mais testável.Acho que é uma coisa inteligente a se fazer e a única maneira de manter um fluxo de trabalho real entre designer e desenvolvedor.

Outras dicas seriam começar aos poucos.Se o seu designer for novo em XAML, WPF e Silverlight, comece apresentando-o à equipe do projeto e peça-lhes que façam alguns designs básicos nas ferramentas que conhecem.Deixe-os criar alguns botões e ilustrações no Adobe Illustrator, exportá-los para XAML e mostrar como você pode aproveitar diretamente seus ativos de design.Continue apresentando mais e mais, e esperamos que eles se interessem e queiram mudar para o Blend.É uma curva de aprendizado e tanto, mas com certeza vale a pena!

Boa sorte!

PS:Escrevi muito sobre padrões e criação de código amigável para designers em meu blog em http://jonas.follesoe.no.Você também pode encontrar links para uma gravação de vídeo da minha palestra sobre Tech Ed, bem como muitos links para leituras adicionais sobre o assunto.

Answer 3

Isso pode estar um pouco fora do assunto (estou respondendo especificamente à sua pergunta sobre controle de origem e gráficos), mas você pode colocar dados binários (imagens etc.) no controle de origem (e na minha opinião, em muitos casos, deveriam) - eles apenas ocupam mais espaço em disco e você não pode usar uma visualização diff para analisar o que mudou de forma significativa , mas o que você ganha é um histórico de mensagens de commit documentando cada revisão, capacidade de reversão e capacidade de arquivar facilmente (marcando uma revisão em termos de SVN) todos os arquivos (sejam recursos visuais, documentação, código-fonte, qualquer que seja) pertencentes a um lançamento/versão específico juntos.Também é mais fácil para o seu sistema de compilação buscar tudo o que é necessário para criar uma versão específica do seu software a partir do controle de origem.

Answer 4

Envolva o designer gráfico nas primeiras sessões de design e arquitetura.

Você deseja envolvê-los para revelar suposições desalinhadas e estabelecer um padrão de trabalho conjunto, em vez de jogar coisas para frente e para trás por cima do muro.

Answer 5

Originalmente, previa-se que os designers profissionais trabalhariam no Expression Blend e os desenvolvedores trabalhariam no Visual Studio, fazendo alterações em um único conjunto compartilhado de arquivos de origem.Embora seja certamente possível fazer isso (desde que você tenha o cuidado de verificar regularmente se não quebrou algo esperado pelo outro desenvolvedor.ou ferramenta de design), muitos membros da comunidade de desenvolvedores, incluindo alguns dentro da Microsoft, descobriram benefícios em manter a atividade do projeto do Blend e do Visual Studio SEPARADAS - até mesmo ao ponto de recortar e colar manualmente versões cuidadosamente refatoradas do Xaml gerado pelo Blend em a fonte "oficial" do projeto VStudio, em vez de permitir que designers e desenvolvedores operem diretamente em uma única base de código compartilhada.A equipe de experiência do usuário da Microsoft no Reino Unido publicou um vídeo descrevendo os problemas que encontraram ao tentar coordenar os esforços de designers e desenvolvedores em projetos reais.

Real_World_WPF_DesignersAndDevelopersWorkingTogether

Uma das principais lições aprendidas é que você não pode equipar um projeto com designers e desenvolvedores que ignoram completamente os domínios uns dos outros.Os desenvolvedores precisam estar familiarizados o suficiente com o Blend para que possam fornecer aos designers shells de UI úteis para o designer decorar, e "stubs" de dados úteis contra os quais o designer possa projetar interatividade, e o designer precisa ter compreensão suficiente dos problemas de desenvolvimento que eles não Não fazemos coisas como excluir controles e substituí-los por elementos visuais personalizados - sem perceber que eles quebraram todas as funcionalidades vinculadas ao controle original.

Answer 6

A visão da Microsoft sobre o casamento do fluxo de trabalho designer/desenvolvedor definitivamente parece fracassar na vida real.Tenho experiência trabalhando em um projeto WPF de grande escala que envolveu 2 recursos de design dedicados por cerca de 4 meses.Aqui estão alguns fatos que a Microsoft parece esquecer com frequência.

• Os designers geralmente preferem usar Macs (os designers da minha empresa são 100% Mac - 0% Windows)
• O Blend não funciona em um Mac (no que diz respeito a soluções VM - os designers normalmente não gostam de soluções geeks, como executar aplicativos estranhos em um sistema operacional estrangeiro).
• Os designers usam suas ferramentas profissionais - Photoshop e Illustrator.Período.
• A agressividade das programações atuais geralmente não dá tempo suficiente para os designers aprenderem um ambiente de aplicação/design totalmente novo (como o Blend).

Considerando o que foi dito acima, o que percebi foi que isso cria um novo tipo de trabalho - ou um designer muito técnico ou um programador com conhecimento gráfico.Basicamente, alguém que pode pegar os ativos de design em formato bruto - geralmente em formato .psd ou ilustrador e aplicá-los conforme necessário ao processo de inscrição.

Acabei por ser aquele cara (programador graficamente esclarecido).Passei muito tempo exportando XAML de arquivos do Illustrator, limpando-os manualmente quando necessário e tornando esses ativos objetos de exibição facilmente utilizáveis ​​no Blend ou VS.Houve também momentos em que eu pegava um elemento de design e o redesenhava usando blend (geralmente quando o ativo original era baseado em bitmap e fazia mais sentido convertê-lo em vetor).

Meu aplicativo pode não ter sido típico - pois era extremamente rico graficamente e a independência de resolução era um dos objetivos principais, pois precisava ter uma boa aparência em múltiplas resoluções e proporções (pense nas dificuldades em projetar para TV no cenário atual - as coisas mudaram para ter uma boa aparência em SD de baixa resolução e escalar bem para HD de alta resolução).

Em resumo, acho que o WPF é uma tecnologia incrível e absolutamente um passo na direção certa para a Microsoft.No entanto, não é a solução definitiva para integrar o designer no processo de desenvolvimento - a menos que você redefina o papel do designer.

Answer 7

Sou Felix Corke, o designer do podcast hanselman que você mencionou, então aqui estão alguns pontos de um criativo genuíno em vez de um desenvolvedor.

Demorou muito para me acostumar com as ferramentas de desenvolvedor - eu nunca tinha ouvido falar de Visual Studio, C# ou qualquer tipo de controle de origem quando comecei a trabalhar com xaml há alguns anos.Eles eram tão estranhos para mim quanto talvez o Illustrator ou o 3DsMax seriam para você.

Meu maior ponto é que não se pode esperar que o designer conheça as práticas do desenvolvedor - por favor, esteja preparado para dar muita ajuda.Você não terá que aprender nada novo, enquanto o designer será lançado em um novo lado assustador do desenvolvimento de aplicativos.Eu baguncei algumas soluções e checkins (e ainda faço).

Felizmente, aprendi a me tornar mais um integrador focado em design do que um criativo direto, e talvez essa seja uma função que você precisa incluir em seu projeto.Esta é a ilustração que fiz para nossa beleza e geek - sessão de designer/desenvolvedor no Mix - se algum de vocês estiver muito longe em qualquer extremidade do espectro, pode ser difícil entender como o outro funciona e qual deveria ser seu papel.

Será um prazer responder a quaisquer perguntas específicas!

ps você NÃO deseja arquivos .psd de 100 MB + no controle de origem;)

Answer 8

Acredito muito na abordagem do Integrador, que é realmente o papel que tive que desempenhar para tornar nossos esforços no WPF bem-sucedidos.

Laurent Bugnion tem um publicar sobre isso que descreve o que estou falando. Robby Ingebretsen também acredita muito nesta abordagem.

Mas basicamente, alguém tem que cobrir a “lacuna” que existe entre o mundo dos desenvolvedores e o mundo dos designers.O que geralmente acontece é que essa pessoa vem do mundo dos desenvolvedores ou do mundo dos designers.Se ele vem do mundo dos desenvolvedores, então provavelmente é um desenvolvedor com tendências de designer (ele é responsável pela aparência, pelo visual do aplicativo, pelo layout das telas, etc.).Se eles vêm do mundo do designer, então não têm medo do código e gostam de mergulhar de vez em quando no código para obter aquela animação ou qualquer coisa brilhante.

No entanto, independentemente do mundo de onde vêm, geralmente precisam desenvolver habilidades que nunca tiveram antes.No meu caso, sou um desenvolvedor que adora a camada de interface do usuário e por isso diria que sou um desenvolvedor com tendências de designer.Para cobrir essa lacuna e ter conversas produtivas com nosso designer gráfico, tive que adquirir um monte de habilidades de designer, como:aprendendo a usar Expression Design, XAM 3D, etc.

Shannon Braun recentemente fez uma apresentação em uma conferência local de desenvolvedores sobre o relacionamento desenvolvedor/designer e os fluxos de trabalho que a comunidade está descobrindo que funcionam para eles.Não participei da conferência, mas pensei que ele diapositivos houve uma grande discussão sobre o assunto.

Answer 9

Até que ponto os designers se sentem no direito de se distanciarem de todo o trabalho envolvido na construção de um produto de software é um problema muito maior que precisa ser resolvido.Não ceda ao direito expresso de nenhum designer de não precisar saber como seu trabalho se integra ao todo.

O tipo de especialização que cresceu na comunidade de designers é um dos maiores problemas de maturidade industrial que a indústria de desenvolvimento de software enfrenta.É uma extensão de especialização que previsivelmente cria mais retrabalho e tempos de ciclo mais longos.

Isso também se aplica ao senso de direito dos desenvolvedores de ignorarem o design e a implementação da interação.

A especialização extrema é sempre um multiplicador exponencial nos problemas de produtividade.Resolva-o organizacionalmente, adotando processos que promovam culturas de aprendizagem.Este é o nível de maturidade que a maioria das outras indústrias de produção já alcançou, e que o software fica lamentavelmente para trás.

Em todos os lugares de um fluxo de trabalho de desenvolvimento onde ocorrem transferências entre superespecialização, filas de trabalho e buffers se formam.O software continua a ser uma das poucas indústrias que não reconhece este como um dos maiores problemas que enfrentamos.Isto é ainda mais exacerbado na comunidade Microsoft, uma vez que a especialização excessiva parece cada vez mais normal devido à perpetuação da especialização excessiva da Microsoft através das suas ferramentas e orientações.A menos que você possa desperdiçar tanto dinheiro quanto a Microsoft em esforços de desenvolvimento, você deve procurar metodologias que sejam muito mais bem informadas sobre questões de fluxo e produtividade.

Conseqüentemente, o desenvolvedor que não consegue testar e o testador que não consegue codificar são sintomas da mesma imaturidade industrial.

Você não aprenderá nada disso com o modelo Scrum para TFS.A Microsoft estava anos atrasada na implementação do pensamento ágil, mesmo em suas formas mais rudimentares, e agora que estamos progredindo para o pensamento Lean, a Microsoft levará mais três a cinco anos para tentar incorporar o pensamento Lean em suas linhas de produtos. .Não espere que a Microsoft lhe diga como moldar uma equipe e um fluxo de trabalho.Você pode aprender agora mesmo com as pessoas às quais a Microsoft prestará atenção em alguns anos.

Answer 10

Na minha experiência, a função de integrador ou "desenvolvedor" realmente precisa estar envolvida nesse processo, a menos que todos na (pequena) equipe sejam capazes de desempenhar essa função.Esta é uma circunstância muito rara.Normalmente você descobrirá que os desenvolvedores são muito bons em desenvolvimento, mas não são tão bons em design/usabilidade, e os designers são ótimos em estética/usabilidade, mas não querem ou não têm formação suficiente para codificar.Ter alguém que possa cruzar os dois mundos e “falar a língua” é muito importante.

O integrador precisa coordenar os controles que estão sendo desenvolvidos com os ativos de design que estão sendo criados pelos projetistas.Em nosso projeto atual, temos 6 desenvolvedores ativos e 2 designers de uma loja externa.Sou o integrador deste projeto e passo a maior parte do dia no Expression Blend.Os desenvolvedores trabalham principalmente no VS criando controles que atendam às especificações do nosso produto e a oficina de design está projetando a aparência do produto final.Os designers estão trabalhando no Illustrator.Meu trabalho é pegar os arquivos do Illustrator e criar estilos de controle a partir deles e depois aplicá-los aos controles desenvolvidos pela nossa equipe de desenvolvimento.À medida que avançamos para o Blend 3 com suporte nativo para arquivos PSD e AI, esta tarefa se torna muito mais fácil.

É muito útil criar a "aparência" do seu aplicativo em uma solução separada do tronco principal do aplicativo e, posteriormente, mesclar seus ResourceDictionaries no aplicativo principal.Você pode obter a aparência correta sem ficar muito preso ao que ainda podem ser controles incompletos.

Answer 11

Presumo que você se refere a projetos RIA desde a menção ao SL.

Trabalhei em vários projetos RIA com a Adobe projetando e desenvolvendo aplicativos e serviços.

O melhor conselho que posso dar é baseado em meus 14 anos de experiência como UX e designer visual com alguma experiência em programação, embora patético em comparação com vocês.

Aceite que vocês não vão se entender.

O programador pensa em o que funcionalidade deve ser feita, o designer pensa em como a funcionalidade deve se comportar.

Para o desenvolvedor, um botão é geralmente genérico, para o designer não é o caso.Os designers pensam em composição, os desenvolvedores pensam em frameworks.

Então aprenda a entender que sua responsabilidade é diferente.

Você, o desenvolvedor, PRECISA pensar em quão genérico é seu código e não pode se dar ao luxo de tratar tudo como sendo único e uma composição codificada.Isto é, a menos que você possa automatizar essa singularidade de alguma forma.

O designer PRECISA pensar no aplicativo ou serviço como único.Pode significar que um botão não é um botão.Pode haver diferentes tamanhos ou cores ou outros incômodos.

Portanto, certifique-se de desenvolver um bom relacionamento com o designer, reconhecendo que você entende a responsabilidade do designer e certifique-se de que ele entende a sua.

Não é que você não esteja interessado em fazer o melhor aplicativo do mundo.Acontece que algumas dessas decisões de design levam muito tempo.

Certifique-se de deixar bem claro como o designer deve entregar a você, para que você não perca o tempo dele.Qual formato, ativos?Nomeação?

Todas as coisas que estão envolvidas na entrega de um paradigma para outro.

E o mais importante, comunique e respeite que eles não sabem fazer JavaScript ou entender as ideias básicas do CVS.

Para a maioria dos desenvolvedores, você não saberia como fazer kern para salvar suas vidas, o que é uma viúva, como colocar melhor camadas no FireWorks ou criar um ícone fotorrealista, criar um bom slogan ou tornar algo compreensível para o Joe médio em 4 palavras.Você não sabe o que é uma grade ou alinhamento e tende a deixar as coisas verdes e roxas no preto.

E o designer deve entender que só porque você lida com programação não significa que você é um robô, que não pode ter ideias e soluções criativas.Ele também deve tentar aprender a programar pelo menos um pseudoprograma para entender o que está envolvido na realização do seu projeto.

E o mais importante.Não comece a debater Mac vs.PC :) Projetos foram cancelados por causa disso.

Answer 12

Francamente, você deve dizer ao designer que as imagens podem, deve e "serão colocadas no controle de fonte, senhor!" :)

Pode ser um pouco não convencional e você não conseguirá fazer uma fusão ou algo dessa natureza, mas haverá revisões e um histórico, etc.As imagens também podem ser incorporadas em um arquivo de recursos que também entra no controle de origem.

O XAML pode (e deve) ser colocado no controle de origem e, como é um arquivo de marcação, se beneficiará de todos os recursos.

No que diz respeito a dicas para trabalhar com um designer, aquele com quem você está trabalhando me assusta muito só com esse comentário, então tudo pode se resumir a QUEM você está trabalhando.Eu explicaria as melhores práticas básicas de uma maneira agradável e prosseguiria a partir daí.