Share
Under de senaste veckorna hade vårt team den ganska krävande uppgiften att designa tio e-postmallar i tid för lanseringen av Canvas, en ny och lättanvänd e-postbrevbyggare i kampanjmonitorn.
Utöver de vanliga kraven som följer med byggmallar för en e-postmarknadsföringstjänst som designers använder (till exempel, kampanjerna ser bra ut, även på mobila enheter!) Var det några extra saker vi behövde ta itu med. Först och främst var det samarbetande med design, testning och naturligtvis bland e-postkodare för att göra detta projekt hända. Som det visar sig, utvecklade en process runt det faktiskt ett projekt i sig själv.
Arbeta i och över lag är a) svårt, och b) kräver verkligen att både verktyg och processer ska vara på plats redan tidigare. Om du kämpar med att få de resultat du vill ha från dina designprojekt - även om de inte är e-postrelaterade - så kommer du troligen att relatera till dessa punkter. Med lycka till hittar du våra erfarenheter användbara när du övervinnar dina egna utmaningar med teamsamarbete.
Som e-postkodare som i många år har tagit en kort> kod> leveransmetod till uppgifter, var det naturligt att använda ett liknande vattenfall när man utvecklade var och en av Canvas mallarna. För att ge dig en uppfattning om uppgifternas komplexitet består varje av de tio mallarna av flera layouter och ett urval av element (textfält, knappar etc), med varje del som kräver nära samarbete mellan både vår e-postkod och designteam. Som det var när jag började år sedan, kan samarbetet vara farligt, även bland de mest välbetalda av oss.
Så, här är en titt på de sju stegen, från kickoff till testning och överlåtelse, som vårt team arbetade igenom för att skapa mallarna. Återigen, medan dessa reflektioner finns på ett e-postprojekt, hittar du troligtvis dessa arbetsflödestips som är tillämpliga på webben.
Det var verkligen viktigt att vi hittade ett sätt att samarbeta och dela mellan design, e-postkodning och den som ville hoppa in i projektet.
Vi har försökt ett antal tillvägagångssätt för att diskutera och klargöra problem, inklusive användningen av leverans (för designrecensioner), LayerVault (för versionskontroll) och ett HipChat-rum (för gruppchatt). I slutet av dagen valde vi Basecamp, en populär teamsamarbetsapp. Det var inte bara redan i bruk och bekant för många inom Campaign Monitor, men det är ganska bra för att organisera kodningsuppgifter och underlätta djupare diskussioner i team.
Vi använder Basecamp för att samarbeta internt och mellan lagFör mallproblem (till exempel återgivning av glitches), JIRA, en problem- och projektspårningsapp, valdes - igen ett verktyg som är mycket känt för laget. Med hjälp av JIRA får vi också slinga i våra kohorter i testteamet, utan att tvinga dem att använda verktyg utanför deras befintliga arbetsflöde.
När alla hade bestämt sig för samarbetsverktyg var det dags att ta emot Photoshop-mockarna i PSD-format från designteamet. Det här var lite av en upptäcktsfas (och kanske inte så vattenfall-y trots allt), vilket kräver att e-postutvecklare som jag själv ska ha en bra titt på PSD-skivor av både skrivbord och mobilversioner av en mall.
En skrivbordsmock för Mason-mallenSaker som vi fokuserade på inkluderade att identifiera standardlayouter som e-postkodare är vanliga med (t.ex. 1-3 statiska kolumner), jämfört med icke-standardiserade, mer äventyrliga. Att se hur samma layout eller element ser ut översatt mellan skrivbord och mobil är alltid mycket intressant; tack och lov är våra designers ganska vana vid att arbeta med lyhörda e-postmeddelanden (och deras quirks), så är de inte benägna att göra oroväckande krav vad gäller layouter!
Vem som helst som har kodat en webb- eller e-postdesign från början, vet att det ofta är en utforskande process att ofta ta reda på vad som fungerar och vad som inte går över flera plattformar. Med våra mallar måste vissa element kodas och testas bortsett från mall-in-progress, för att säkerställa att de kan införlivas i designen. Som alltid kan vissa saker inte se exakt ut över alla e-postklienter (eller webbläsare, som på webben), men de borde åtminstone försämras graciöst - och se bra ut.
Om något i en mock visade sig vara faktiskt omöjligt att uppnå, var det bra att ge den feedbacken tidigt, eftersom designändringar ofta kan få rippeleffekter.
När du är ganska säker på att mallmockarna från våra konstruktörer kan omvandlas till en rockfast e-postmall, var det dags att skära bort och skapa tillgångar. Detta inkluderar både grafiska element i mallen själv och platshållare bilder från mockup.
För att säkerställa att bilderna är optimerade för Retina-skärmar exporterade vi dem från PSD-erna som levereras i 2x storlek och ändras sedan till 1x med bildens bredd och höjdattribut. Ja, det här är något som e-postdesigners gör också!
En av ikonerna, inzoomade för detaljerat arbeteUndantaget till detta var bakgrundsbilder (till exempel de som användes i kollisionssäkra knappar), som vanligtvis exporterades i både 1x och 2x storlekar.
Medan varje kanftsmall är utformad för att vara ganska dynamisk när det gäller att kombinera layouter och element går, fann vi att kodning av en lång statisk HTML-fil med platshållarinnehåll hjälpte oss att föreställa slutprodukten. Vi har utvecklat ett ramverk från grunden baserat på LESS, med varje malls styles.less-fil innehållande ett antal variabler för grundläggande stilar och beräkningar, följt av stilar som är specifika för mallen. CodeKit användes för att bearbeta LESS-filer och påskynda webbläsartestning.
Som en sida skapade den alltid hjälpsamma Stig på vårt team en Chrome-förlängning för överlagring av PSD-mönster via HTML-sidor. Called Blueprint, tillät denna förlängning laget att uppnå en oöverträffad grad av pixel-perfektion.
Medan många människor kan rinna mot att saker ser ut "samma" över alla e-postklienter - eller webbläsare för den delen - finns det verkligen dygd i att sträva efter det målet, uppnå en kvalitetsnivå och kanske till och med tilltala en noga klient att viss grad!
När det gäller att testa både "desktop" och "mobile" versioner av en e-mail design går, var vår process inte så annorlunda som vad som händer på webben. Tyvärr, men verkligen, vi skulle göra mycket krossning och sträcka webbläsaren.
Men i alla fall, så långt som testningen går, är det bara att se mallen i Chrome (eller din egen webbläsare) aldrig tillräckligt. I det här skedet importerar vi vanligtvis kampanjen till Kampanjövervakning för att köra ett snabbt design- och spamprov (som ett e-postprojekt) och / eller testas i Litmus (som också ger automatiska skärmdumpar för webbläsare). Om designen såg ut i virtuella tester, skulle vi utvecklas för att leva enhetsprov.
Förutom att använda några virtuella maskiner i VMware, vände vi oss också till vårt "enhetslaboratorium" - till stor del bestående av mobila telefoner - för att testa så noggrant som möjligt. Om du inte dra nytta av ett enhetslab på din arbetsplats, kolla in OpenDeviceLab för att se om det finns en offentligt tillgänglig samling av enheter i ditt område.
När vi var nöjda med vårt arbete blev kodning av dessa mallar inte annorlunda än något annat projekt. På Campaign Monitor använder vi GitHub för att begå vårt arbete och samarbeta om eventuella utestående renderingsproblem samt loop i test och design där så krävs. Om du inte har använt GitHub tidigare har readwrite en utmärkt nybörjare guide för att komma igång.
Visserligen skulle dessa steg oftast blöda in i varandra eller upprepas; webb- och e-postkodning och testning är sällan snabb, ren eller utan incident. Slutresultatet talar dock för sig själva - en första sats med tio robusta mallar, levererade i tid och nu redo för alla att använda. Kolla in kanfas när du måste skicka ett nyhetsbrev som passar bra på mobila enheter, liksom Gmail, Apple Mail och alla vanliga kunder.
Både processerna och verktygen som används för att skapa och samarbeta med andra kom inte till oss på ett ögonblick - men med tanke på projektets flerveckors tidslinje och att vi upprepade gånger arbetade med liknande uppgifter hade vi fördelen av att vara kunna förbättra vårt arbetsflöde när vi gick vidare. Efter detta projekt är våra rekommendationer till andra att:
Ovanstående steg beskrivs i vår interna wiki innan arbetet påbörjades; Att ha denna guide / specifikation tillgänglig för alla möjliggjorde att nya och avlägsna medarbetare snabbt kan snabba upp och samtidigt ge andra lag synlighet över hur kodarna fungerar. Det här dokumentet förfinades när vi gick och gav alltså den senaste informationen till alla.
Medan det alltid finns frestelsen att "shoppa" för det senaste och bästa när man påbörjar ett nytt projekt, tvingar alla att anta att obekanta appar kan skapa onödiga utmaningar. Prata med andra lag om vad de använder för att samarbeta och se hur de kan anpassas för dina egna uppgifter.
I både e-post- och webbprojekt kan man koppla bort i vilka designers, marknadsföringsteam, försäljning och andra tycker att det är möjligt och vad som kan göras som kodare ... Särskilt när det finns tidsfrister att träffas. Ta dig tid att göra din egen upptäckt och ställa förväntningar - att spendera några extra dagar experimenterar och diskuterar uppgifter är alltid bättre än att missa en viktig milstolpe eller underleverans!
Hur ser din design ut på Android-enheter? Även om du inte använder en person för att bläddra, gör 33% av USA - och den här andelen är mycket högre någon annanstans. Ju fler plattformar du kan testa på desto bättre.
Så, även om det kan finnas stora skillnader mellan hur e-post och webbarbete kodas och produceras, är de steg som krävs för att få en designers vision till liv, lika relevanta. Förhoppningsvis hjälper våra erfarenheter dig att formulera en plan för ditt nästa kodprojekt, samt att ditt team förblir lyckligt och produktivt när du samarbetar tillsammans.
Accentsconagua