Designer e sviluppatori lavorano insieme [chiuso]

Question

Le ricche funzionalità di presentazione di WPF e Silverlight significano che gli sviluppatori come me lavoreranno più spesso a stretto contatto con i grafici, come nel caso del mio prossimo progetto.

Qualcuno là fuori ha qualche consiglio ed esperienza (da entrambi i punti di vista) su come rendere tutto più fluido?

Ad esempio, quando di recente ho menzionato il controllo del codice sorgente a un designer, mi è stato subito detto che non è possibile controllare il codice sorgente di grafica, immagini, ecc., quindi è una perdita di tempo.Quindi ho risposto:ok ma che dire dei file XAML in WPF/Silverlight?

Scott Hanselman ha parlato di questo argomento in a podcast, ma lui si è concentrato di più sugli strumenti, mentre a me interessano di più le questioni/aspetti comunicativi.

Answer 1

Ho trascorso 4 mesi su un progetto lavorando a stretto contatto con un designer e lui non ha ancora afferrato l'idea di base di CVS (che non è la mia scelta come sistema di controllo del codice sorgente).Sto parlando di file modello, JavaScript e CSS qui.Non è stupido, è solo una di queste cose che rende il suo lavoro più difficile, quindi resiste ad impegnarsi completamente in esso.

Nel mio caso ho dovuto insistere sul fatto che quasi tutto il mio JavaScript dipendeva dal markup e quando ha cambiato il suo puro layout basato su CSS e DIV in uno basato su tabelle senza dirmelo, tutto il mio JS se ne va rompere.

Spesso nel corso del progetto io e il designer, con cui vado piuttosto d'accordo e con cui gioco a calcio anche fuori dal lavoro, abbiamo avuto scambi molto accesi sulle nostre rispettive responsabilità.Se non lo avessi conosciuto abbastanza bene da superare questi scambi, penso che si sarebbe creato un ambiente di lavoro insopportabile.Quindi penso che sia importante stabilire tra voi e con una sorta di manager o supervisore del progetto esattamente cosa ci si aspetta da entrambe le parti durante il progetto.

Nel mio caso ci sono stati pochissimi problemi ultimamente, perché la situazione con CVS è stata risolta così come l'idea che non può andare a cambiare il mark-up ogni volta che ne ha voglia.Invece di provare a creare file modello e lavorarci direttamente, il designer lavora solo su file statici ed è mia responsabilità inserirli nei miei file modello.

È tutta una questione di comunicazione e un po' di compromesso da entrambe le parti.

Answer 2

Una delle cose che ho scoperto è che il modo in cui tu come sviluppatore progetti il ​​tuo codice influisce notevolmente su ciò che il progettista può farci.Spesso scarichi un'applicazione di esempio Silverlight o WPF dal Web e la apri in Blend, solo per avere Blend che si blocca perché il codice non funziona bene all'interno del designer.Se non si blocca, raramente assomiglia all'applicazione in esecuzione.

Recentemente ho tenuto una conferenza al Tech Ed Australia e alla Nuova Zelanda sulle tecniche che è possibile applicare al "design for designability".È incluso un breve elenco puntato:

1. Scrivere codice che possa trarre vantaggio dall'associazione dati.Il Model-View-ViewModel o il modello di presentazione è adatto a questo scopo.

2. Fornire stub "in fase di progettazione" per le dipendenze del servizio.Se la classe a cui stai effettuando l'associazione effettua chiamate al servizio Web, assicurati di sostituire il client del servizio Web con una classe stub che restituisce "dati fittizi" che il progettista consuma all'interno della fusione.Questa operazione può essere eseguita facilmente tramite IoC e Dependency Injection, inserendo un'implementazione se HtmlPage.IsEnabled == false.

3. Utilizzando l'associazione dati puoi limitare il numero di "elementi denominati" presenti nel file XAML.Se scrivi molto codice dietro finisci per accoppiare il tuo codice C# con elementi denominati come txtName o txtAddress, rendendo facile per il progettista "rovinare".

4. Utilizza un modello di comando anziché il codice dietro i gestori eventi clic.Accoppiando liberamente l'invocatore di un evento dal gestore puoi avere meno elementi con nome e dai al progettista la libertà di scegliere tra un pulsante o una voce di menu per invocare un comando specifico.

5. Metti alla prova il tuo codice in Blend!Anche se ti consideri uno sviluppatore puro, dovresti verificare che il tuo codice sia utilizzabile da uno strumento e sforzarti di ottenere la migliore esperienza possibile in fase di progettazione.Alcuni sostengono che uno strumento non dovrebbe influenzare la progettazione del software, proprio come qualcuno si lamenta della "progettazione per la testabilità" e di prendere decisioni sulla progettazione del software solo per rendere il codice più testabile.Penso che sia una cosa intelligente da fare e l'unico modo per avviare un vero flusso di lavoro progettista-sviluppatore.

Altri suggerimenti potrebbero essere quello di iniziare in piccolo.Se il tuo progettista non conosce XAML, WPF e Silverlight, inizia presentandolo al team di progetto e chiedigli di eseguire alcune progettazioni di base con gli strumenti che conosce.Lascia che creino alcuni pulsanti e illustrazioni in Adobe Illustrator, li esportino in XAML e mostra loro come sfruttare direttamente le loro risorse di progettazione.Continua introducendo sempre di più e, si spera, si interessano e vogliono passare a Blend.È una bella curva di apprendimento, ma ne vale sicuramente la pena!

Buona fortuna!

PS:Ho scritto molto sui modelli e sulla creazione di codice intuitivo per i designer sul mio blog all'indirizzo http://jonas.follesoe.no.Puoi anche trovare collegamenti a una registrazione video del mio discorso Tech Ed, nonché numerosi collegamenti a ulteriori letture sull'argomento.

Answer 3

Questo potrebbe essere un po' fuori tema (sto rispondendo specificamente alla tua domanda sul controllo del codice sorgente e sulla grafica), ma tu Potere inserisci i dati binari (immagini, ecc.) nel controllo del codice sorgente (e secondo me in molti casi dovrebbero) - occupano semplicemente più spazio su disco e non puoi utilizzare una vista diff per analizzare ciò che è cambiato in modo significativo , ma ciò che ottieni è una cronologia dei messaggi di commit che documentano ogni revisione, capacità di rollback e capacità di archiviare facilmente (contrassegnare una revisione in termini SVN) tutti i file (siano essi risorse visive, documentazione, codice sorgente, qualunque cosa) appartenenti insieme a una specifica versione/versione.È anche più semplice per il tuo sistema di compilazione recuperare tutto il necessario per creare una versione specifica del tuo software dal controllo del codice sorgente.

Answer 4

Coinvolgere il grafico nelle prime sessioni di progettazione e architettura.

Vuoi coinvolgerli per rivelare presupposti disallineati e stabilire un modello di lavoro insieme piuttosto che gettare le cose avanti e indietro oltre il muro.

Answer 5

Inizialmente, si prevedeva che i designer professionisti lavorassero in Expression Blend e gli sviluppatori lavorassero in Visual Studio, apportando modifiche a un singolo set condiviso di file di origine.Anche se è certamente possibile farlo (a condizione che tu stia attento a controllare regolarmente di non aver rotto qualcosa previsto dall'altro sviluppatore.o strumento di progettazione), molti membri della comunità di sviluppatori, inclusi alcuni interni a Microsoft, hanno scoperto vantaggi nel mantenere SEPARATA l'attività dei progetti Blend e Visual Studio, fino al punto di tagliare e incollare manualmente versioni accuratamente refactorizzate di Xaml generato da Blend in la fonte "ufficiale" del progetto VStudio, invece di consentire a progettisti e sviluppatori di operare direttamente su un'unica base di codice condivisa.Lo User Experience Team di Microsoft nel Regno Unito ha pubblicato un video in cui descrive i problemi incontrati nel tentativo di coordinare gli sforzi di designer e sviluppatori su progetti reali.

Real_World_WPF_DesignersAndDevelopersWorkingTogether

Una delle principali lezioni apprese è che non è possibile affidare un progetto a designer e sviluppatori che ignorano completamente i reciproci domini.Gli sviluppatori devono avere abbastanza familiarità con Blend da poter fornire ai progettisti utili shell dell'interfaccia utente da decorare e "stub" di dati utili su cui il progettista può progettare l'interattività, e il progettista deve avere una comprensione sufficiente dei problemi di sviluppo che non affrontano. non fare cose come eliminare i controlli e sostituirli con elementi visivi personalizzati, senza rendersi conto che hanno interrotto tutte le funzionalità legate al controllo originale.

Answer 6

La visione di Microsoft del connubio del flusso di lavoro progettista/sviluppatore sembra decisamente crollare nella vita reale.Ho esperienza di lavoro su un progetto WPF su larga scala che ha coinvolto 2 risorse di progettazione dedicate per circa 4 mesi.Ecco alcuni fatti che Microsoft sembra spesso dimenticare.

• I designer spesso preferiscono utilizzare i Mac (i designer della mia azienda sono 100% Mac - 0% Windows)
• Blend non funziona su un Mac (per quanto riguarda le soluzioni VM: ai progettisti in genere non piacciono le soluzioni geniali come l'esecuzione di applicazioni strane in un sistema operativo straniero).
• I designer utilizzano i loro strumenti del mestiere: Photoshop e Illustrator.Periodo.
• L'aggressività dei programmi odierni di solito non fornisce ai progettisti il ​​tempo sufficiente per apprendere un'applicazione/ambiente di progettazione totalmente nuovo (come Blend).

Quindi, considerato quanto sopra, quello che ho notato è che questo crea un nuovo tipo di lavoro: un designer molto tecnologico o un programmatore graficamente illuminato.Fondamentalmente, qualcuno che può prendere le risorse di progettazione in forma grezza, solitamente in formato .psd o Illustrator, e applicarle secondo necessità al processo di candidatura.

Si è scoperto che ero quel ragazzo (programmatore graficamente illuminato).Ho trascorso molto tempo esportando XAML da file Illustrator, ripulendoli manualmente quando necessario e rendendo queste risorse oggetti di visualizzazione facilmente utilizzabili in Blend o VS.C'erano anche momenti in cui prendevo un elemento di progettazione e lo ridisegnavo utilizzando la fusione (di solito quando la risorsa originale era basata su bitmap e aveva più senso convertirla in vettoriale).

La mia applicazione potrebbe non essere stata tipica, poiché era estremamente ricca dal punto di vista grafico e l'indipendenza dalla risoluzione era uno degli obiettivi principali in quanto doveva avere un bell'aspetto su più risoluzioni e proporzioni (pensa alle difficoltà nella progettazione per la TV nel panorama odierno: le cose sono cambiate per avere un bell'aspetto sia in SD a bassa risoluzione che scalare bene fino all'HD ad alta risoluzione).

In sintesi, penso che WPF sia una tecnologia fantastica e assolutamente un passo nella giusta direzione per Microsoft.Tuttavia non è la soluzione definitiva per integrare il progettista nel processo di sviluppo, a meno che non si ridefinisca il ruolo del progettista.

Answer 7

Sono Felix Corke, il designer del podcast di Hanselman che hai citato, quindi ecco un paio di punti da parte di un vero creativo anziché di uno sviluppatore.

Ci è voluto molto tempo per abituarmi agli strumenti di sviluppo: non avevo mai sentito parlare di Visual Studio, C# o qualsiasi tipo di controllo del codice sorgente quando ho iniziato a lavorare su xaml qualche anno fa.Mi erano estranei come forse Illustrator o 3DsMax lo sarebbero per te.

Il mio punto più importante è che non ci si può aspettare che il progettista conosca le pratiche degli sviluppatori: sii pronto a fare una grande quantità di manodopera.Non dovrai imparare nulla di nuovo, mentre il designer verrà lanciato in un lato completamente nuovo e spaventoso dello sviluppo di app.Ho fatto un bel pasticcio con alcune soluzioni e check-in (e lo faccio ancora).

Fortunatamente, ho imparato a diventare più un integratore focalizzato sul design che un creativo puro e semplice, e forse questo è un ruolo che devi includere nel tuo progetto.Questa è l'illustrazione che ho fatto per la nostra bellezza e il geek - sessione di designer/sviluppatore al Mix - se uno di voi è troppo lontano alle due estremità dello spettro può essere difficile capire come funziona l'altro e quale dovrebbe essere il suo ruolo.

Felice di rispondere a qualsiasi domanda specifica!

ps NON vuoi più di 100 Mb di file .psd nel controllo del codice sorgente ;)

Answer 8

Sono un grande sostenitore dell'approccio Integrator che è davvero il ruolo che ho dovuto svolgere per garantire il successo dei nostri sforzi WPF.

Laurent Bugnion ha un inviare su questo che descrive ciò di cui sto parlando. Robby Ingebretsen è anche un grande sostenitore di questo approccio.

Ma fondamentalmente, qualcuno deve coprire il 'gap' che esiste tra il mondo degli sviluppatori e quello dei designer.Ciò che di solito accade è che questa persona proviene dal mondo degli sviluppatori o dal mondo dei designer.Se provengono dal mondo degli sviluppatori, probabilmente sono sviluppatori con tendenze da designer (sono responsabili dell'aspetto grafico, delle immagini nell'applicazione, del layout degli schermi, ecc.).Se provengono dal mondo dei designer, allora non hanno paura del codice e si divertono a tuffarsi di tanto in tanto nel codice per ottenere quell'animazione o qualunque cosa brillante.

Tuttavia, indipendentemente dal mondo da cui provengono, di solito devono sviluppare competenze che non hanno mai posseduto prima.Nel mio caso, sono uno sviluppatore che ama il livello dell'interfaccia utente e quindi direi che sono uno sviluppatore con tendenze da designer.Per colmare questa lacuna e avere conversazioni produttive con il nostro designer grafico, ho dovuto acquisire tutta una serie di competenze di tipo designer come:imparare a utilizzare Expression Design, XAM 3D, ecc.

Shannon Braun ha recentemente tenuto una presentazione in una conferenza locale degli sviluppatori sulla relazione sviluppatore/designer e sui flussi di lavoro che la comunità sta scoprendo adatti a loro.Non ho partecipato alla conferenza, ma ho pensato che fosse suo diapositive c'è stata una bella discussione sull'argomento.

Answer 9

La misura in cui i progettisti si sentono autorizzati a restare distanti dall’intero lavoro coinvolto nella realizzazione di un prodotto software è un problema molto più grande che deve essere risolto.Non assecondare il diritto espresso di nessun designer di non dover sapere come il suo lavoro viene integrato nel tutto.

Il tipo di forte specializzazione che si è sviluppato nella comunità dei progettisti è uno dei maggiori problemi di maturità industriale che il settore dello sviluppo software deve affrontare.È un livello di specializzazione che prevedibilmente crea più rilavorazioni e tempi di ciclo più lunghi.

Ciò vale anche per il senso di diritto degli sviluppatori a ignorare beatamente la progettazione e l'implementazione dell'interazione.

La specializzazione estrema è sempre un moltiplicatore esponenziale dei problemi di produttività.Risolverlo a livello organizzativo adottando processi che promuovono le culture dell’apprendimento.Questo è il livello di maturità che la maggior parte degli altri settori produttivi ha già raggiunto, e che il software si trascina tristemente dietro.

In ogni punto del flusso di lavoro di sviluppo in cui si verificano passaggi di mano tra specializzazione eccessiva, si formano code di lavoro e buffer.Il software rimane uno dei pochi settori a non riconoscere questo come uno dei maggiori problemi che dobbiamo affrontare.Ciò è ancora più esacerbato nella comunità Microsoft poiché l'eccessiva specializzazione sembra sempre più normale a causa della perpetuazione dell'eccessiva specializzazione da parte di Microsoft attraverso i suoi strumenti e le sue linee guida.A meno che tu non possa permetterti di sprecare tanto denaro quanto fa Microsoft negli sforzi di sviluppo, dovresti cercare metodologie che siano molto più informate su questioni di flusso e produttività.

Di conseguenza, lo sviluppatore che non sa testare e il tester che non sa programmare sono un sintomo della stessa immaturità industriale.

Non imparerai nulla di tutto ciò dal modello Scrum per TFS.Microsoft era anni indietro rispetto alla curva nel mettere in gioco il pensiero agile anche nelle sue forme più rudimentali, e ora che stiamo progredendo verso il pensiero Lean, Microsoft avrà altri tre o cinque anni di distanza dal tentativo di incorporare il pensiero Lean nelle sue linee di prodotti. .Non aspettare che Microsoft ti dica come modellare un team e un flusso di lavoro.Puoi imparare subito dalle persone a cui Microsoft presterà attenzione tra qualche anno.

Answer 10

Nella mia esperienza, il ruolo di integratore o "sviluppatore" deve davvero essere coinvolto in questo processo, a meno che tutti i membri del (piccolo) team non siano in grado di svolgere questo ruolo.Questa è una circostanza molto rara.Di solito scoprirai che gli sviluppatori sono molto bravi nello sviluppo ma non sono così bravi con il design/usabilità e i designer sono bravi con l'estetica/usabilità ma non vogliono o non sono abbastanza istruiti per programmare.Avere qualcuno che possa attraversare entrambi i mondi e "parlare la lingua" è molto importante.

L'integratore deve coordinare i controlli in fase di sviluppo con le risorse di progettazione create dai progettisti.Nel nostro progetto attuale abbiamo 6 sviluppatori attivi e 2 designer di un negozio esterno.Sono l'integratore di questo progetto e trascorro gran parte della mia giornata in Expression Blend.Gli sviluppatori lavorano principalmente nella creazione di controlli VS che soddisfino le specifiche del nostro prodotto e l'ufficio di progettazione sta progettando l'aspetto del prodotto finale.I designer stanno lavorando in Illustrator.Il mio lavoro è prendere i file di Illustrator e creare da essi stili di controllo, quindi applicarli ai controlli sviluppati dal nostro team di sviluppo.Man mano che ci muoviamo verso Blend 3 con supporto nativo per file PSD e AI, questo compito diventa molto più semplice.

È molto utile creare il "look" per la tua applicazione in una soluzione separata dal trunk principale dell'applicazione e quindi unire i tuoi ResourceDictionaries nell'app principale in un secondo momento.Puoi ottenere l'aspetto corretto senza rimanere troppo coinvolto in quelli che potrebbero essere controlli ancora incompleti.

Answer 11

Presumo che tu faccia riferimento ai progetti RIA poiché hai menzionato SL.

Ho lavorato a numerosi progetti RIA con Adobe progettando e sviluppando applicazioni e servizi.

Il miglior consiglio che posso darti si basa sui miei 14 anni di esperienza come UX e visual designer con una certa esperienza di programmazione anche se patetica rispetto a voi ragazzi.

Accettate che non vi capiterete.

Il programmatore pensa Che cosa la funzionalità dovrebbe essere realizzata, pensa il progettista Come la funzionalità dovrebbe comportarsi bene.

Per lo sviluppatore un pulsante è per lo più generico, per il designer non è così.I designer pensano in composizione, gli sviluppatori pensano in framework.

Quindi impara a capire che la tua responsabilità è diversa.

Tu, lo sviluppatore, devi pensare a quanto sia generico il tuo codice e non puoi permetterti di trattare tutto come unico e una composizione codificata.Questo a meno che tu non riesca ad automatizzare quell'unicità in qualche modo.

Il progettista DEVE pensare all'applicazione o al servizio come in qualche modo unico.Potrebbe significare che un pulsante non è un pulsante.Potrebbero esserci dimensioni o colori diversi o altri fastidi.

Quindi assicurati di sviluppare un buon rapporto con il designer riconoscendo di comprendere la responsabilità del designer e assicurandoti che lui capisca la tua.

Non è che non sei interessato a realizzare la migliore applicazione al mondo.È solo che alcune di queste decisioni progettuali richiedono molto tempo.

Assicurati di avere ben chiaro come il designer dovrebbe consegnarti in modo da non sprecare il suo tempo.Che formato, risorse?Nominare?

Tutte cose che sono coinvolte nel passaggio da un paradigma all'altro.

E, cosa più importante, comunica e rispetta il fatto che non sanno come eseguire JavaScript o come comprendere le idee di base di CVS.

La maggior parte degli sviluppatori non saprebbe come creare una crenatura per salvarsi la vita, cos'è una vedova, come sovrapporre al meglio FireWorks o creare un'icona fotorealistica, inventare un buon slogan o creare qualcosa di comprensibile per Joe medio in 4 parole.Non sai cosa sia una griglia o un allineamento e tendi a rendere le cose verdi e viola su nero.

E il designer dovrebbe capire che solo perché ti occupi di programmazione non significa che sei un robot, che non puoi avere idee e soluzioni creative.Dovrebbe anche cercare di imparare a programmare almeno uno pseudoprogramma in modo da capire cosa comporta la realizzazione del tuo progetto.

E, soprattutto.Non iniziare a discutere di Mac vs.PC :) I progetti sono stati annullati per questo motivo.

Answer 12

Francamente dovresti dire al designer che le immagini possono, dovrebbero e "saranno messe in Mister di controllo della fonte!" :)

Potrebbe essere leggermente non convenzionale e non sarai in grado di fare una fusione o qualcosa del genere, ma ci saranno revisioni e una cronologia, ecc.Le immagini possono anche essere incorporate in un file di risorse che entra anche nel controllo del codice sorgente.

XAML può (e dovrebbe) essere inserito nel controllo del codice sorgente e poiché è un file di markup trarrà vantaggio da tutte le funzionalità.

Per quanto riguarda i consigli per lavorare con un designer, quello con cui stai lavorando mi spaventa a morte solo per quel commento, quindi tutto potrebbe ridursi a CON CHI stai lavorando.Spiegherei le migliori pratiche di base in modo gradevole e procederei da lì.