Share
De afgelopen weken had ons team de nogal veeleisende taak om tijdig tien e-mailsjablonen te ontwerpen voor de lancering van Canvas, een nieuwe en eenvoudig te gebruiken e-mailnieuwsbriefbouwer in Campagnemonitor.
Naast de standaardvereisten die horen bij het bouwen van sjablonen voor een e-mailmarketingservice die ontwerpers gebruiken (bijvoorbeeld dat campagnes er goed uitzien, zelfs op mobiele apparaten!), Moesten we een aantal extra dingen aanpakken. Eerst en vooral werkte er samen met design, testen en natuurlijk tussen e-mailcodeerders om dit project tot stand te brengen. Het blijkt dat het ontwikkelen van een proces daaromheen inderdaad een project op zich was.
Werken in en tussen teams is a) moeilijk, en b) vereist echt dat zowel tools als processen op voorhand aanwezig zijn. Als je moeite hebt om de resultaten te krijgen die je wilt van je ontwerpprojecten - zelfs als ze geen e-mailgerelateerd zijn - dan heb je waarschijnlijk een relatie met deze punten. Met een beetje geluk vind je onze ervaringen nuttig bij het overwinnen van je eigen uitdagingen met teamsamenwerking.
Als e-mailcodeerder die jarenlang een korte> code> delivery-benadering van taken heeft gevolgd, leek het bij het ontwikkelen van elk van de canvas-sjablonen logisch om een waterval-benadering te gebruiken. Om u een idee te geven van de complexiteit van de taak, bestaat elk van de tien sjablonen uit meerdere lay-outs en een selectie van elementen (tekstvelden, knoppen, enz.), Waarbij elk stuk een nauwe samenwerking vereist tussen onze e-mailcode en ontwerpteams. Zoals het geval was toen ik jaren geleden begon, kan samenwerking gevaarlijk zijn, zelfs bij de meest brave mensen van ons.
Dus, hier is een blik op de zeven stappen, van aftrap tot testen en overdracht, die ons team heeft doorlopen om de sjablonen te maken. Nogmaals, hoewel deze overwegingen betrekking hebben op een e-mailproject, vindt u deze werkstroomtips waarschijnlijk net zo geschikt voor internet.
Het was erg belangrijk dat we een manier vonden om samen te werken en te delen tussen ontwerp, e-mailcodering en iedereen die in het project wilde springen.
We hebben een aantal benaderingen geprobeerd voor het bespreken en verhelderen van problemen, waaronder het gebruik van verzending (voor ontwerprecensies), LayerVault (voor versiebeheer) en een HipChat-kamer (voor teamchat). Aan het eind van de dag kozen we voor Basecamp, een populaire app voor teamsamenwerking. Niet alleen was het al in gebruik en bekend bij velen binnen Campaign Monitor, maar het is best goed voor het organiseren van coderingstaken en het faciliteren van diepere discussies in teams.
We gebruiken Basecamp om intern en tussen teams samen te werkenVoor sjabloonproblemen (bijvoorbeeld rendering glitches), JIRA, een probleem- en project tracking-app, werd geselecteerd - opnieuw een tool die heel vertrouwd is voor het team. Met behulp van JIRA konden we ook onze cohorten in het testteam lussen, zonder hen te dwingen hulpmiddelen te gebruiken buiten hun bestaande workflow.
Toen iedereen eenmaal klaar was met samenwerkingshulpmiddelen, was het tijd om de Photoshop-spotjes in PSD-formaat van het ontwerpteam te ontvangen. Dit was een beetje een ontdekkingsfase (en misschien niet zo waterval-y per slot van rekening) die e-mailontwikkelaars zoals ik nodig had om goed te kunnen kijken door PSD's van zowel de desktopversie als de mobiele versie van een sjabloon.
Een desktop-mock voor de Mason-sjabloonDingen waar we ons op richtten, waren onder meer het identificeren van standaardlay-outs waarvan e-mailcodeerders algemeen bekend zijn (bijvoorbeeld 1-3 statische kolommen), versus niet-standaard, meer avontuurlijke. Zien hoe dezelfde layout of hetzelfde element er vertaald uitziet tussen desktop en mobiel is altijd heel interessant; Gelukkig zijn onze ontwerpers vrij gewend om te werken met responsieve e-mails (en hun eigenaardigheden), dus zijn ze niet geneigd buitensporige eisen te stellen voor wat betreft lay-outs!
Iedereen die een web- of e-mailontwerp vanaf nul heeft gecodeerd, weet dat vaak, en ontdekken wat werkt en wat niet op meerdere platforms mogelijk is, kan een behoorlijk verkennend proces zijn. Met onze sjablonen moesten sommige elementen gecodeerd en getest worden, afgezien van het sjabloon dat nog in ontwikkeling was, om ervoor te zorgen dat ze in het ontwerp konden worden opgenomen. Zoals altijd, zien sommige dingen er misschien niet precies hetzelfde uit voor alle e-mailclients (of browsers, net als voor internet), maar ze moeten op z'n minst degelijk verslechteren - en er goed uitzien.
Ook als iets in een mock echt onmogelijk bleek te zijn, was het goed om die feedback vroeg te geven, omdat ontwerpwijzigingen vaak rimpeleffecten kunnen hebben.
Toen we er redelijk zeker van waren dat de template-moppen van onze ontwerpers konden worden omgezet in een solide e-mailsjabloon, was het tijd om dingen weg te halen en activa te creëren. Dit omvat zowel grafische elementen in de sjabloon zelf, als plaatshouderfoto's uit de mockup.
Om er zeker van te zijn dat de afbeeldingen zijn geoptimaliseerd voor Retina-displays, hebben we ze geëxporteerd uit de PSD's die in 2x-formaat zijn geleverd, en vervolgens verkleind naar 1 x met behulp van de kenmerken width en height van de afbeelding. Ja, dit doen ontwerpers van e-mail ook!
Een van de pictogrammen, ingezoomd voor gedetailleerd werkDe uitzondering hierop waren achtergrondafbeeldingen (bijvoorbeeld die gebruikt in kogelvrije knoppen), die meestal werden geëxporteerd op zowel 1x- als 2x-formaat.
Hoewel elke canvas-sjabloon is ontworpen om redelijk dynamisch te zijn wat betreft het combineren van lay-outs en elementen, ontdekten we dat het coderen van een lang, statisch HTML-bestand met plaatsaanduiding ons hielp het uiteindelijke product te visualiseren. We hebben een raamwerk ontwikkeld op basis van MINDER, met het styles.less-bestand van elke sjabloon met een aantal variabelen voor basisstijlen en berekeningen, gevolgd door stijlen die specifiek zijn voor de sjabloon. CodeKit werd gebruikt om de MINDER-bestanden te verwerken en het testen van browsers te versnellen.
Terzijde: de altijd behulpzame Stig van ons team heeft een Chrome-extensie gemaakt om de PSD-ontwerpen over HTML-pagina's te leggen. Blueprint, deze extensie liet het team toe om een ongekende mate van pixel-perfectie te bereiken.
Hoewel veel mensen misschien belemmeren om dingen er "hetzelfde" uit te laten zien in alle e-mailclients - of browsers wat dat betreft - is er zeker deugd om naar dat doel te streven, om een kwaliteitsniveau te bereiken en misschien zelfs een kieskeurige klant tevreden te stellen. een diploma!
Wat het testen van zowel de "desktop" als de "mobiele" versies van een e-mailontwerp betreft, was ons proces niet zo verschillend van wat er op het web gebeurt. Jammer genoeg, maar echt, zouden we heel veel squishing en strekken van de browser.
Tenminste voor zover testen gaat, is het gewoon nooit genoeg om de sjabloon in Chrome (of de browser naar keuze) te bekijken. In deze fase importeren we de campagne meestal in Campaign Monitor om een snelle Design and Spam-test uit te voeren (zijnde een e-mailproject) en / of getest in Litmus (die ook geautomatiseerde screenshots van de browser biedt). Als het ontwerp er virtueel uit zou zien, zouden we doorgaan met het testen van apparaten.
Naast het gebruik van een paar virtuele machines in VMware, hebben we ook ons 'apparaatlab' - grotendeels bestaande uit mobiele handsets - ingeschakeld om het zo grondig mogelijk te testen. Als u niet het voordeel hebt van een apparaatlab op uw werkplek, kijk dan in OpenDeviceLab om te zien of er een openbaar toegankelijke verzameling apparaten bij u in de buurt is.
Eenmaal tevreden met ons werk, was het coderen van deze sjablonen niet anders dan bij elk ander project. Bij Campaign Monitor gebruiken we GitHub om ons werk te committeren en samen te werken aan uitstekende renderingproblemen, evenals lus in testen en ontwerpen waar nodig. Als je GitHub nog niet eerder hebt gebruikt, heeft readwrite een uitstekende beginnershandleiding om je op weg te helpen.
Toegegeven, vaker wel dan niet zouden deze stappen in elkaar overlopen, of worden herhaald; Web- en e-mailcodering en -testen zijn zelden snel, schoon of zonder incidenten. Eindresultaten spreken echter voor zich: een eerste batch van tien robuuste sjablonen, op tijd geleverd en nu klaar voor gebruik door iedereen. Bekijk Canvas wanneer u de volgende keer een e-mailnieuwsbrief moet sturen die er geweldig uitziet op mobiele apparaten, evenals Gmail, Apple Mail en alle gebruikelijke klanten.
Zowel de processen en tools die werden gebruikt om met anderen samen te werken en samen te werken, kwamen niet meteen naar ons toe - maar gezien de meerwekelijkse tijdlijn van het project en dat we herhaaldelijk aan soortgelijke taken werkten, hadden we het voordeel dat we in staat om onze workflow te verbeteren terwijl we verder gingen. Volgend op dit project, zijn onze aanbevelingen aan anderen om:
De bovenstaande stappen werden beschreven in onze interne wiki voordat het werk begon; als deze gids / specificatie voor iedereen toegankelijk was, konden nieuwe en externe medewerkers snel aan de slag, terwijl andere teams inzicht gaven in hoe de coders werken. Dit document is verfijnd terwijl we verder gingen en iedereen zo de meest recente informatie te bieden.
Hoewel er altijd de verleiding is om 'rond te shoppen' voor het nieuwste en beste bij het starten van een nieuw project, kan het dwingen tot het adopteren van onbekende apps onnodige uitdagingen veroorzaken. Praat met andere teams over wat ze gebruiken om samen te werken en zie hoe ze kunnen worden aangepast voor je eigen taken.
Zowel in e-mail- als webprojecten kunnen er verbroken verbindingen zijn in wat ontwerpers, marketingteams, verkoop en anderen denken dat mogelijk is en wat als codeerder kan worden gedaan ... Vooral wanneer er deadlines zijn om te voldoen. Neem de tijd om je eigen ontdekking uit te voeren en verwachtingen in te stellen - een paar extra dagen experimenteren en taken bespreken is altijd beter dan een belangrijke mijlpaal missen, of onderleveren!
Hoe ziet uw ontwerp eruit op Android-apparaten? Zelfs als je niet persoonlijk iemand gebruikt om te browsen, doet 33% van de VS dat wel, en dit percentage ligt elders veel hoger. Hoe meer platforms u kunt testen, hoe beter.
Dus hoewel er grote verschillen kunnen zijn tussen hoe e-mail en webwerk worden gecodeerd en geproduceerd, zijn de stappen die nodig zijn om de visie van een ontwerper tot leven te brengen even relevant. Hopelijk helpen onze ervaringen je bij het formuleren van een plan voor je volgende codeproject, en zorg je ervoor dat je team blij en productief blijft als je samenwerkt.
Accentsconagua