Share
Nelle ultime settimane, il nostro team ha avuto il compito piuttosto impegnativo di progettare dieci modelli di email in tempo per il lancio di Canvas, un nuovo e facile generatore di newsletter in Campaign Monitor.
Oltre ai normali requisiti forniti con i modelli di costruzione per un servizio di email marketing che i designer usano (ad esempio, le campagne sembrano buone, anche sui dispositivi mobili!) C'erano un paio di cose extra che dovevamo affrontare. Innanzitutto, collaborando con il design, i test e, naturalmente, tra i codificatori di e-mail per realizzare questo progetto. A quanto pare, lo sviluppo di un processo attorno a questo è stato davvero un progetto a sé stante.
Lavorare in e attraverso i team è a) difficile, e b) richiede davvero sia strumenti che processi da mettere in atto in anticipo. Se hai difficoltà a ottenere i risultati desiderati dai tuoi progetti di design - anche se non sono correlati all'email - allora probabilmente ti troverai in relazione con questi punti. Con un po 'di fortuna, troverai le nostre esperienze utili per superare le tue stesse sfide con la collaborazione di squadra.
Come programmatore di e-mail che, per molti anni, ha adottato un breve approccio di> code> delivery alle attività, l'utilizzo di un approccio simile a cascata sembrava naturale durante lo sviluppo di ciascuno dei modelli di Canvas. Per darti un'idea della complessità del compito, ognuno dei dieci modelli è costituito da più layout e una selezione di elementi (campi di testo, pulsanti, ecc.), Con ogni pezzo che richiede una stretta collaborazione tra il nostro codice email e i team di progettazione. Come è stato il caso quando ho iniziato anni fa, la collaborazione può essere irta di pericoli, anche tra i più ben educati.
Quindi, ecco uno sguardo ai sette passaggi, dal kickoff al testing e al passaggio di consegne, che il nostro team ha elaborato per creare i modelli. Ancora una volta, mentre queste riflessioni sono su un progetto di posta elettronica, probabilmente troverai questi suggerimenti per il flusso di lavoro proprio come applicabili al web.
Era davvero importante trovare un mezzo per collaborare e condividere tra design, codifica e-mail e chiunque volesse entrare nel progetto.
Abbiamo provato un certo numero di approcci per discutere e chiarire i problemi, tra cui l'uso di Spedizione (per revisioni di progetti), LayerVault (per il controllo della versione) e una sala HipChat (per la chat di gruppo). Alla fine della giornata, abbiamo selezionato Basecamp, una famosa app per la collaborazione in team. Non solo era già in uso e familiare a molti in Campaign Monitor, ma è piuttosto buono per organizzare attività di codifica e facilitare discussioni più approfondite nei team.
Usiamo Basecamp per collaborare internamente e tra teamPer i problemi relativi ai modelli (ad esempio, il rendering di glitch), è stato selezionato JIRA, un'app di rilevamento del problema e del progetto, ancora una volta uno strumento molto familiare per il team. L'utilizzo di JIRA ci ha permesso di collegarci anche alle nostre coorti nel team di test, senza costringerli a utilizzare strumenti al di fuori del loro flusso di lavoro esistente.
Una volta stabiliti tutti gli strumenti di collaborazione, è arrivato il momento di ricevere i mock di Photoshop in formato PSD dal team di progettazione. Questa è stata una fase un po 'scoperta (e forse non è poi così cascata) che ha richiesto agli sviluppatori di email come me di dare una buona occhiata ai PSD delle versioni sia desktop che mobile di un template.
Un modello di desktop per il modello MasonLe cose su cui ci siamo concentrati includono l'identificazione di layout standard in cui i codificatori di e-mail sono generalmente familiari (per esempio 1-3 colonne statiche), rispetto a quelli non standard e più avventurosi. Vedere come lo stesso layout o elemento appare tradotto tra desktop e mobile è sempre molto interessante; per fortuna i nostri progettisti sono abituati a lavorare con e-mail reattive (e le loro stranezze), quindi non sono inclini a fare richieste oltraggiose per quanto riguarda i layout!
Chiunque abbia codificato un progetto web o email da zero sa che spesso, scoprire cosa funziona e cosa no attraverso più piattaforme può essere un processo abbastanza esplorativo. Con i nostri modelli, alcuni elementi dovevano essere codificati e testati a parte il modello in corso, per garantire che potessero essere incorporati nel design. Come sempre, alcune cose potrebbero non apparire esattamente uguali su tutti i client di posta elettronica (o browser, come nel caso del web), ma dovrebbero almeno degradarsi con garbo - e avere un bell'aspetto.
Inoltre, se una cosa in una simulazione si rivelava effettivamente impossibile da ottenere, era opportuno dare quel feedback in anticipo, poiché i cambiamenti di progettazione possono spesso avere effetti a catena.
Una volta abbastanza fiduciosi che i template mock forniti dai nostri designer potevano essere trasformati in un solido modello di email, era il momento di mettere da parte e creare risorse. Ciò include sia gli elementi grafici nel modello stesso, sia le foto segnaposto del modello.
Per garantire che le immagini siano ottimizzate per i display Retina, le abbiamo esportate dai PSD forniti con dimensioni 2x, e quindi ridimensionate fino a 1x utilizzando gli attributi di larghezza e altezza dell'immagine. Sì, questo è qualcosa che fanno anche i designer di email!
Una delle icone, ingrandita per lavori dettagliatiL'eccezione a questo erano le immagini di sfondo (ad esempio quelle utilizzate nei pulsanti a prova di proiettile), che venivano solitamente esportate in entrambe le dimensioni 1x e 2x.
Sebbene ciascun modello di canvas sia progettato per essere abbastanza dinamico per quanto riguarda la combinazione di layout ed elementi, abbiamo scoperto che la codifica di un lungo file HTML statico con contenuto segnaposto ci ha aiutato a immaginare il prodotto finale. Abbiamo sviluppato un framework da zero basato su LESS, con il file styles.less di ogni modello contenente un numero di variabili per stili e calcoli di base, seguiti da stili specifici per il modello. CodeKit è stato utilizzato per elaborare i file LESS e velocizzare i test del browser.
Per inciso, il sempre utile Stig del nostro team ha creato un'estensione di Chrome per la sovrapposizione dei progetti PSD su pagine HTML. Chiamato Blueprint, questa estensione ha permesso al team di raggiungere un livello senza precedenti di perfezione dei pixel.
Mentre un sacco di persone potrebbero scagliarsi per far sembrare le cose "uguali" su tutti i client di posta elettronica - o browser per questo - c'è sicuramente virtù nell'aspirare questo obiettivo, raggiungere un livello di qualità e magari persino placare un cliente esigente qualche grado!
Per quanto riguarda il test delle versioni "desktop" e "mobile" di un progetto di email, il nostro processo non era poi così diverso da ciò che accade sul web. Purtroppo ma veramente, faremmo un sacco di schiacciamenti e allungheremo il browser.
Tuttavia, almeno per quanto riguarda i test, la semplice visualizzazione del modello in Chrome (o il browser scelto) non è mai abbastanza. In questa fase, di solito importiamo la campagna in Campaign Monitor per eseguire un rapido test di progettazione e spam (essendo un progetto di posta elettronica) e / o testato in Litmus (che fornisce anche schermate automatiche del browser). Se il progetto fosse stato superato nei test virtuali, avremmo progredito per testare i dispositivi.
Oltre a utilizzare alcune macchine virtuali in VMware, ci siamo rivolti anche al nostro "laboratorio di dispositivi", in gran parte costituito da telefoni mobili, per testare il più accuratamente possibile. Se non hai il vantaggio di un laboratorio di dispositivi sul posto di lavoro, consulta OpenDeviceLab per verificare se esiste una raccolta di dispositivi accessibile al pubblico nella tua zona.
Una volta soddisfatti del nostro lavoro, la codifica di questi modelli non è stata diversa da qualsiasi altro progetto. In Campaign Monitor, utilizziamo GitHub per impegnare il nostro lavoro e collaborare a qualsiasi problema di rendering in sospeso, oltre a eseguire cicli di test e progettazione laddove richiesto. Se non hai già usato GitHub, readwrite ha un'eccellente guida per principianti per iniziare.
Evidentemente, molto spesso questi passaggi si confondevano l'un l'altro, o si ripetevano; la codifica e il collaudo di web ed e-mail sono raramente rapidi, puliti o senza incidenti. Tuttavia, i risultati finali parlano da soli: un primo gruppo di dieci modelli robusti, consegnati in tempo e ora pronti per essere utilizzati da chiunque. Dai un'occhiata a Canvas quando hai bisogno di inviare una newsletter via email che abbia un bell'aspetto sui dispositivi mobili, oltre a Gmail, Apple Mail e tutti i soliti client.
Sia i processi che gli strumenti utilizzati per creare e collaborare con gli altri non ci sono venuti in un attimo - ma vista la tempistica di più settimane del progetto e che abbiamo dovuto lavorare ripetutamente su compiti simili, abbiamo avuto il vantaggio di essere in grado di migliorare il nostro flusso di lavoro mentre procedevamo. Seguendo questo progetto, i nostri consigli agli altri sono:
I passaggi precedenti sono stati delineati nella nostra wiki interna prima dell'inizio del lavoro; avere questa guida / specifica accessibile a tutti permetteva al personale nuovo e remoto di accelerare molto rapidamente, dando agli altri team visibilità su come funzionano i programmatori. Questo documento è stato perfezionato mentre procedevamo, fornendo così a tutti le informazioni più recenti.
Mentre c'è sempre la tentazione di "guardarsi attorno" per le ultime e le più grandi quando si inizia un nuovo progetto, costringere tutti ad adottare app non familiari può creare sfide inutili. Parla con gli altri team di ciò che usano per collaborare e vedi come possono essere adattati alle tue attività.
Sia nella posta elettronica che nei progetti web, ci possono essere disconnessioni in ciò che i progettisti, i team di marketing, le vendite e altri pensano sia possibile e cosa può essere fatto come programmatore ... Soprattutto quando ci sono scadenze da rispettare. Prenditi il tempo per condurre la tua scoperta e stabilire delle aspettative: passare qualche giorno in più a sperimentare e discutere le attività è sempre meglio che mancare una pietra miliare importante o una mancata consegna!
Come appare il tuo design sui dispositivi Android? Anche se non lo usi personalmente per navigare, il 33% degli Stati Uniti lo fa - e questa percentuale è molto più alta altrove. Più piattaforme puoi testare, meglio è.
Quindi, mentre possono esserci grandi differenze tra il modo in cui la posta elettronica e il lavoro sul Web sono codificati e prodotti, i passaggi necessari per dare vita alla visione di un designer sono altrettanto rilevanti. Speriamo che le nostre esperienze ti aiutino a formulare un piano per il tuo prossimo progetto di codice, nonché a garantire che il tuo team rimanga felice e produttivo quando collabora insieme.
Accentsconagua