Share
In den letzten Wochen hatte unser Team die recht anspruchsvolle Aufgabe, zehn E-Mail-Vorlagen rechtzeitig vor dem Start von Canvas zu erstellen, einem neuen und benutzerfreundlichen E-Mail-Newsletter-Builder in Campaign Monitor.
Zusätzlich zu den regulären Anforderungen, die mit dem Erstellen von Vorlagen für einen E-Mail-Marketing-Service verbunden sind, den Designer verwenden (zum Beispiel, dass Kampagnen auch auf mobilen Geräten gut aussehen!), Gab es ein paar zusätzliche Dinge, die wir berücksichtigen mussten. In erster Linie arbeitete man mit Design, Test und natürlich mit E-Mail-Programmierern zusammen, um dieses Projekt umzusetzen. Wie sich herausstellte, war die Entwicklung eines Prozesses in der Tat ein eigenständiges Projekt.
Die Arbeit in und über Teams hinweg ist a) schwer und b) erfordert von Anfang an, dass sowohl Werkzeuge als auch Prozesse vorhanden sind. Wenn Sie Schwierigkeiten haben, die gewünschten Ergebnisse aus Ihren Entwurfsprojekten zu erzielen - selbst wenn diese nicht mit E-Mails in Verbindung stehen -, beziehen Sie sich wahrscheinlich auf diese Punkte. Mit etwas Glück finden Sie unsere Erfahrungen nützlich, wenn Sie Ihre eigenen Herausforderungen durch Teamzusammenarbeit meistern.
Als E-Mail-Coder, der seit vielen Jahren einen kurzen Code-Zustellungsansatz für Aufgaben verwendet, erschien die Verwendung eines ähnlichen Wasserfallansatzes bei der Entwicklung der Canvas-Vorlagen als selbstverständlich. Um Ihnen einen Eindruck von der Komplexität der Aufgabe zu vermitteln, besteht jede der zehn Vorlagen aus mehreren Layouts und einer Auswahl von Elementen (Textfelder, Schaltflächen usw.), wobei für jedes Teil eine enge Zusammenarbeit zwischen unserem E-Mail-Code und unseren Designteams erforderlich ist. Wie schon vor Jahren, war Kollaboration mit Gefahren verbunden, selbst unter den am besten verhaltenen von uns.
Hier ein Blick auf die sieben Schritte, vom Start bis zum Testen und zur Übergabe, die unser Team für die Erstellung der Vorlagen erarbeitet hat. Auch wenn diese Überlegungen sich auf ein E-Mail-Projekt beziehen, werden Sie diese Workflow-Tipps wahrscheinlich ebenso für das Web finden.
Es war wirklich wichtig, dass wir ein Mittel gefunden haben, um zwischen Design, E-Mail-Codierung und demjenigen, der in das Projekt einsteigen wollte, zusammenzuarbeiten und zu teilen.
Wir haben eine Reihe von Ansätzen zur Erörterung und Klärung von Problemen ausprobiert, einschließlich der Verwendung von Versand (für Konstruktionsprüfungen), LayerVault (für Versionskontrolle) und eines HipChat-Raums (für Teamchat). Am Ende des Tages wählten wir Basecamp, eine beliebte Team-Collaboration-App. Es wurde nicht nur in Campaign Monitor bereits verwendet und ist vielen vertraut, es ist aber auch gut für die Organisation von Codieraufgaben und für tiefere Diskussionen in Teams geeignet.
Wir verwenden Basecamp, um intern und zwischen Teams zusammenzuarbeitenBei Vorlagenproblemen (z. B. beim Rendern von Fehlern) wurde JIRA, eine App für das Issue- und Projekt-Tracking, ausgewählt - ein Tool, das dem Team sehr vertraut ist. Die Verwendung von JIRA ermöglichte es uns, auch unsere Kohorten im Testteam einzubinden, ohne dass sie dazu gezwungen wurden, Tools außerhalb ihres vorhandenen Workflows zu verwenden.
Nachdem sich alle mit Tools für die Zusammenarbeit befasst hatten, war es an der Zeit, die Photoshop-Mocks im PSD-Format vom Designteam zu erhalten. Dies war ein bisschen eine Entdeckungsphase (und vielleicht auch nicht so ein Wasserfall), dass E-Mail-Entwickler wie ich die PSDs sowohl der Desktop- als auch der Mobile-Version einer Vorlage genau unter die Lupe nehmen müssen.
Ein Desktop-Mock für die Mason-VorlageZu den Schwerpunkten gehörten das Erkennen von Standardlayouts, mit denen E-Mail-Codierer im Allgemeinen vertraut sind (z. B. 1-3 statische Spalten), im Gegensatz zu nicht standardmäßigen, abenteuerlicheren. Es ist immer sehr interessant zu sehen, wie das gleiche Layout oder Element zwischen Desktop und Mobile übersetzt wird. Gott sei Dank sind unsere Designer daran gewöhnt, mit responsiven E-Mails (und ihren Macken) zu arbeiten. Daher sind sie nicht anfällig, wenn es um Layouts geht!
Jeder, der ein Web- oder E-Mail-Design von Grund auf neu programmiert hat, weiß, dass es oft ein Erkundungsprozess sein kann, herauszufinden, was auf verschiedenen Plattformen funktioniert und was nicht. Bei unseren Vorlagen mussten einige Elemente neben der laufenden Vorlage codiert und getestet werden, um sicherzustellen, dass sie in das Design integriert werden können. Wie üblich sehen manche Dinge nicht für alle E-Mail-Clients (oder Browser, wie im Web) gleich aus, aber sie sollten sich zumindest leicht abbauen - und gut aussehen.
Wenn sich herausstellte, dass etwas in einem Schein tatsächlich unmöglich zu erreichen war, war es gut, dieses Feedback frühzeitig zu geben, da Designänderungen oft Welleneffekte haben können.
Nachdem wir uns ziemlich sicher waren, dass die von unseren Designern bereitgestellten Schablonenmodelle in eine solide E-Mail-Vorlage umgewandelt werden konnten, war es an der Zeit, sich zu trennen und Assets zu erstellen. Dies umfasst sowohl grafische Elemente in der Vorlage selbst als auch Platzhalterfotos aus dem Modell.
Um sicherzustellen, dass Bilder für Retina-Displays optimiert sind, haben wir sie aus den bereitgestellten PSDs mit der doppelten Größe exportiert und dann mithilfe der Breiten- und Höhenattribute des Bildes auf 1x verkleinert. Ja, das tun auch E-Mail-Designer!
Eines der Symbole wurde für Detailarbeiten vergrößertEine Ausnahme bildeten Hintergrundbilder (z. B. solche, die in kugelsicheren Knöpfen verwendet werden), die normalerweise in den Größen 1 und 2 exportiert wurden.
Obwohl jede Canvas-Vorlage hinsichtlich der Kombination von Layouts und Elementen relativ dynamisch gestaltet ist, haben wir festgestellt, dass das Codieren einer langen, statischen HTML-Datei mit Platzhalterinhalt uns das Endprodukt vor Augen geführt hat. Wir haben von Grund auf ein neues Framework entwickelt, das auf LESS basiert, wobei die styles.less -Datei jeder Vorlage eine Reihe von Variablen für grundlegende Stile und Berechnungen enthält, gefolgt von Stilen, die für die Vorlage spezifisch sind. CodeKit wurde verwendet, um die LESS-Dateien zu verarbeiten und den Browsertest zu beschleunigen.
Nebenbei hat der stets hilfreiche Stig aus unserem Team eine Chrome-Erweiterung erstellt, um die PSD-Designs über HTML-Seiten zu legen. Die so genannte Blueprint-Erweiterung ermöglichte es dem Team, eine beispiellose Pixel-Perfektion zu erreichen.
Während viele Leute davon absehen, dass die Dinge in allen E-Mail-Clients - oder auch in Browsern - "gleich" aussehen, ist es sicherlich eine Tugend, wenn man dieses Ziel anstrebt, um ein Qualitätsniveau zu erreichen und vielleicht sogar einen heiklen Client dazu zu bringen einem gewissen Grad!
Was das Testen der "Desktop" - und der "Mobile" -Version eines E-Mail-Designs betrifft, war unser Prozess nicht ganz anders als im Web. Leider, aber wirklich, würden wir den Browser stark quetschen und dehnen.
Zumindest beim Testen reicht es jedoch nicht aus, die Vorlage in Chrome (oder dem von Ihnen gewählten Browser) anzuzeigen. Zu diesem Zeitpunkt würden wir normalerweise die Kampagne in Campaign Monitor importieren, um einen schnellen Design- und Spam-Test (ein E-Mail-Projekt) durchzuführen und / oder in Litmus getestet zu werden (der auch automatisierte Browser-Screenshots bereitstellt). Wenn das Design in virtuellen Tests fehlgeschlagen wäre, würden wir zu Gerätetests weitergehen.
Neben dem Einsatz einiger virtueller Maschinen in VMware haben wir uns auch an unser "Device Lab", das größtenteils aus mobilen Endgeräten besteht, gewandt, um so gründlich wie möglich zu testen. Wenn Sie an Ihrem Arbeitsplatz nicht über ein Gerätelabor verfügen, überprüfen Sie OpenDeviceLab, um festzustellen, ob in Ihrer Umgebung eine öffentlich zugängliche Sammlung von Geräten vorhanden ist.
Nachdem diese Vorlagen mit unserer Arbeit zufrieden waren, unterschieden sie sich nicht von anderen Projekten. Bei Campaign Monitor verwenden wir GitHub, um unsere Arbeit zu binden und bei noch offenen Rendering-Problemen zusammenzuarbeiten sowie bei Bedarf Tests durchzuführen und zu entwerfen. Wenn Sie GitHub noch nicht verwendet haben, gibt es in readwrite einen hervorragenden Einsteiger-Leitfaden für den Einstieg.
Zugegeben, diese Schritte würden häufig ineinander bluten oder sich wiederholen; Das Codieren und Testen von Web- und E-Mails ist selten schnell, sauber oder ohne Zwischenfälle. Die Endergebnisse sprechen jedoch für sich - eine erste Charge von zehn robusten Vorlagen, die pünktlich geliefert werden und nun für jeden einsatzbereit sind. Schauen Sie sich Canvas an, wenn Sie das nächste Mal einen E-Mail-Newsletter senden möchten, der auf mobilen Geräten, Gmail, Apple Mail und allen üblichen Clients gut aussieht.
Sowohl die Prozesse als auch die Werkzeuge, mit denen andere erstellt und zusammengearbeitet wurden, kamen nicht sofort zu uns - aber angesichts der mehrwöchigen Projektlaufzeit und der wiederholten Bearbeitung ähnlicher Aufgaben hatten wir den Vorteil, dass wir dabei waren Im Laufe der Zeit konnten wir unseren Workflow verbessern. Nach diesem Projekt empfehlen wir anderen:
Die obigen Schritte wurden vor Beginn der Arbeiten in unserem internen Wiki beschrieben. Da dieser Leitfaden für alle zugänglich war, konnten neue und externe Mitarbeiter sehr schnell auf den neuesten Stand gebracht werden, während andere Teams Einblick in die Funktionsweise der Codierer erhielten. Dieses Dokument wurde im Laufe der Zeit verfeinert, um alle mit den neuesten Informationen zu versorgen.
Zwar gibt es immer die Versuchung, beim Start eines neuen Projekts nach dem neuesten und größten Angebot zu suchen, doch kann es unnötige Herausforderungen darstellen, wenn alle gezwungen werden, unbekannte Apps zu übernehmen. Sprechen Sie mit anderen Teams darüber, was sie zur Zusammenarbeit verwenden, und sehen Sie, wie sie für Ihre eigenen Aufgaben angepasst werden können.
Sowohl bei E-Mail- als auch bei Webprojekten kann es Unstimmigkeiten geben, was Designer, Marketingteams, Vertrieb und andere für möglich halten und was man als Kodierer tun kann. Besonders dann, wenn Fristen einzuhalten sind. Nehmen Sie sich die Zeit, um Ihre eigenen Entdeckungen durchzuführen und Erwartungen zu setzen. Ein paar Tage mehr zu experimentieren und Aufgaben zu besprechen, ist immer besser, als einen wichtigen Meilenstein zu verpassen oder zu wenig zu erreichen!
Wie sieht dein Design auf Android-Geräten aus? Selbst wenn Sie nicht persönlich zum Browsen verwenden, tun dies 33% der USA - und dieser Prozentsatz ist anderswo viel höher. Je mehr Plattformen Sie testen können, desto besser.
Obwohl es große Unterschiede zwischen der Art und Weise gibt, wie E-Mail und Webarbeit codiert und produziert werden, sind die Schritte, die erforderlich sind, um die Vision eines Designers zum Leben zu erwecken, ebenso relevant. Wir hoffen, dass unsere Erfahrungen Ihnen dabei helfen werden, einen Plan für Ihr nächstes Code-Projekt zu formulieren und sicherzustellen, dass Ihr Team bei der Zusammenarbeit glücklich und produktiv bleibt.
Accentsconagua