Share
En las últimas semanas, nuestro equipo tuvo la exigente tarea de diseñar diez plantillas de correo electrónico a tiempo para el lanzamiento de Canvas, un nuevo y fácil de usar creador de boletines por correo electrónico en Campaign Monitor..
Además de los requisitos regulares que vienen con la creación de plantillas para un servicio de marketing por correo electrónico que usan los diseñadores (por ejemplo, que las campañas se ven bien, ¡incluso en dispositivos móviles!) Había un par de cosas adicionales que debíamos abordar. En primer lugar, se trabajó en colaboración con el diseño, las pruebas y, por supuesto, entre los programadores de correo electrónico para que este proyecto se realizara. Como resultado, desarrollar un proceso en torno a eso fue realmente un proyecto por derecho propio..
Trabajar en y entre equipos es a) difícil, yb) realmente exige que las herramientas y los procesos se implementen por adelantado. Si tiene dificultades para obtener los resultados que desea de sus proyectos de diseño, incluso si no están relacionados con el correo electrónico, entonces es probable que se relacione con estos puntos. Con un poco de suerte, encontrará nuestras experiencias útiles cuando supere sus propios desafíos con la colaboración en equipo..
Como un programador de correo electrónico que, durante muchos años, ha tomado un breve enfoque de entrega de código para tareas, el uso de un enfoque de cascada similar parecía natural al desarrollar cada una de las plantillas de Canvas. Para darle una idea de la complejidad de la tarea, cada una de las diez plantillas consta de varios diseños y una selección de elementos (campos de texto, botones, etc.), y cada pieza requiere una colaboración estrecha entre nuestro código de correo electrónico y los equipos de diseño. Al igual que cuando comencé hace años, la colaboración puede estar llena de peligros, incluso entre los más educados de nosotros..
Entonces, aquí hay un vistazo a los siete pasos, desde el inicio hasta las pruebas y la entrega, que nuestro equipo trabajó para crear las plantillas. Nuevamente, mientras estas reflexiones se encuentran en un proyecto de correo electrónico, es probable que encuentre estos consejos de flujo de trabajo que sean aplicables a la web..
Fue realmente importante que encontráramos un medio para colaborar y compartir entre el diseño, la codificación del correo electrónico y quien quisiera saltar al proyecto..
Probamos varios enfoques para discutir y aclarar problemas, incluido el uso de Envío (para revisiones de diseño), LayerVault (para control de versiones) y una sala de HipChat (para chat de equipo). Al final del día, seleccionamos Basecamp, una popular aplicación de colaboración en equipo. No solo estaba en uso y era familiar para muchos dentro de Campaign Monitor, sino que también es bastante bueno para organizar tareas de codificación y facilitar discusiones más profundas en equipos..
Utilizamos Basecamp para colaborar internamente y entre equipos.Para problemas de plantillas (por ejemplo, problemas de representación), se seleccionó JIRA, una aplicación de seguimiento de problemas y proyectos, nuevamente, una herramienta que es muy familiar para el equipo. El uso de JIRA nos permitió también hacer un bucle en nuestras cohortes en el equipo de pruebas, sin obligarlas a usar herramientas fuera de su flujo de trabajo existente.
Una vez que todos se decidieron por las herramientas de colaboración, llegó el momento de recibir las simulaciones de Photoshop en formato PSD del equipo de diseño. Esto fue un poco de una fase de descubrimiento (y tal vez no tan catastrófica después de todo) que requería que los desarrolladores de correo electrónico como yo veamos bien las PSD de las versiones de escritorio y móvil de una plantilla.
Un simulacro de escritorio para la plantilla de Mason.Las cosas en las que nos centramos incluyeron la identificación de diseños estándar con los que los programadores de correo electrónico están familiarizados (por ejemplo, 1-3 columnas estáticas), en comparación con los no estándar, los más aventureros. Ver cómo se ve el mismo diseño o elemento traducido entre el escritorio y el dispositivo móvil siempre es muy interesante; afortunadamente, nuestros diseñadores están bastante acostumbrados a trabajar con correos electrónicos receptivos (y sus peculiaridades), por lo que no son propensos a realizar demandas escandalosas en lo que respecta a los diseños!
Cualquiera que haya codificado desde cero un diseño web o de correo electrónico sabe que, a menudo, descubrir qué funciona y qué no en varias plataformas puede ser un proceso bastante exploratorio. Con nuestras plantillas, algunos de los elementos tuvieron que codificarse y probarse aparte de la plantilla en curso, para garantizar que pudieran incorporarse en el diseño. Como siempre, es posible que algunas cosas no sean exactamente iguales en todos los clientes de correo electrónico (o navegadores, como ocurre en la web), pero al menos deberían degradarse con gracia y lucir bien..
Además, si algo en un simulacro resultó ser realmente imposible de lograr, fue bueno dar esa retroalimentación temprano, ya que los cambios de diseño a menudo pueden tener efectos dominó.
Una vez bastante seguro de que los simulacros de plantillas proporcionados por nuestros diseñadores podían convertirse en una plantilla de correo electrónico sólida, era hora de cortar y crear activos. Esto incluye tanto elementos gráficos en la propia plantilla como fotos de marcadores de posición de la maqueta..
Para garantizar que las imágenes estén optimizadas para las pantallas Retina, las exportamos desde los PSD proporcionados a un tamaño 2x, y luego redimensionamos a 1x utilizando los atributos de ancho y alto de la imagen. Sí, esto es algo que también hacen los diseñadores de correo electrónico.!
Uno de los iconos, ampliado para un trabajo detallado.La excepción a esto fueron las imágenes de fondo (por ejemplo, aquellas utilizadas en los botones a prueba de balas), que generalmente se exportaban en tamaños de 1x y 2x.
Si bien cada plantilla de Canvas está diseñada para ser bastante dinámica en lo que respecta a la combinación de diseños y elementos, encontramos que la codificación de un archivo HTML largo y estático con contenido de marcador de posición nos ayudó a visualizar el producto final. Desarrollamos un marco desde cero basado en MENOS, con el archivo styles.less de cada plantilla que contiene una serie de variables para los estilos y cálculos básicos, seguidos de estilos que son específicos de la plantilla. CodeKit se utilizó para procesar los archivos LESS y acelerar las pruebas del navegador.
Además, el siempre útil Stig en nuestro equipo creó una extensión de Chrome para superponer los diseños de PSD sobre páginas HTML. Llamado Blueprint, esta extensión permitió al equipo lograr un grado de perfección de píxeles sin precedentes..
Si bien mucha gente puede que se oponga a hacer que las cosas se vean "iguales" en todos los clientes de correo electrónico, o en los navegadores para el caso, ciertamente existe la virtud de aspirar a ese objetivo, lograr un nivel de calidad y quizás incluso apaciguar a un cliente exigente. algun grado!
En lo que respecta a probar las versiones de "escritorio" y "móvil" de un diseño de correo electrónico, nuestro proceso no fue tan diferente de lo que sucede en la web. Tristemente pero en verdad, haríamos muchos aplastamientos y estiramientos del navegador..
Sin embargo, al menos en lo que respecta a las pruebas, nunca es suficiente con ver la plantilla en Chrome (o el navegador que elija). En esta etapa, generalmente importamos la campaña en Campaign Monitor para ejecutar una prueba rápida de Diseño y Spam (que es un proyecto de correo electrónico) y / o probamos en Litmus (que también proporciona capturas de pantalla del navegador automatizado). Si el diseño tuviera un aspecto negativo en las pruebas virtuales, pasaríamos a las pruebas en vivo del dispositivo.
Además de usar algunas máquinas virtuales en VMware, también recurrimos a nuestro "laboratorio de dispositivos", que consiste principalmente en teléfonos móviles, para realizar las pruebas lo más exhaustivamente posible. Si no tiene el beneficio de un laboratorio de dispositivos en su lugar de trabajo, visite OpenDeviceLab para ver si existe una colección de dispositivos de acceso público en su área..
Una vez satisfechos con nuestro trabajo, la codificación de estas plantillas no se diferenciaba de ningún otro proyecto. En Campaign Monitor, usamos GitHub para comprometer nuestro trabajo y colaborar en cualquier problema de renderización sobresaliente, así como para realizar un ciclo de pruebas y diseño donde sea necesario. Si no ha usado GitHub antes, readwrite tiene una excelente guía para principiantes para comenzar.
Es cierto que la mayoría de las veces estos pasos se mezclarían o se repetirían; La codificación y las pruebas web y de correo electrónico rara vez son rápidas, limpias o sin incidentes. Sin embargo, los resultados finales hablan por sí mismos: un primer lote de diez plantillas robustas, entregadas a tiempo y ahora listas para que todas las usen. Echa un vistazo a Canvas la próxima vez que necesites enviar un boletín por correo electrónico que se vea bien en dispositivos móviles, así como en Gmail, Apple Mail y todos los clientes habituales..
Tanto los procesos como las herramientas utilizadas para crear y colaborar con otros no nos llegaron en un instante, pero dado el cronograma de varias semanas del proyecto y que trabajamos en tareas similares repetidamente, tuvimos el beneficio de ser capaz de mejorar nuestro flujo de trabajo a medida que avanzábamos. Siguiendo este proyecto, nuestras recomendaciones a otros son:
Los pasos anteriores se detallaron en nuestra wiki interna antes de comenzar el trabajo; tener esta guía / especificación accesible para todos permitió que el personal nuevo y remoto se pusiera al día muy rápido, al tiempo que les da a los otros equipos visibilidad sobre cómo funcionan los codificadores. Este documento se refinó a medida que avanzábamos, proporcionando así a todos la información más reciente.
Si bien siempre existe la tentación de "comparar precios" para obtener lo último y lo mejor al comenzar un nuevo proyecto, obligar a todos a adoptar aplicaciones desconocidas puede crear desafíos innecesarios. Hable con otros equipos sobre lo que usan para colaborar y vea cómo pueden adaptarse a sus propias tareas..
Tanto en el correo electrónico como en los proyectos web, puede haber desconexiones en lo que los diseñadores, los equipos de marketing, las ventas y otros creen que es posible y lo que se puede hacer como programador ... Especialmente cuando hay plazos que cumplir. Tómese el tiempo para realizar su propio descubrimiento y establecer expectativas: pasar unos pocos días adicionales experimentando y discutiendo tareas siempre es mejor que perder un hito importante o una entrega insuficiente!
¿Cómo se ve tu diseño en los dispositivos Android? Incluso si no utiliza uno personalmente para navegar, el 33% de los EE. UU. Lo hace, y este porcentaje es mucho mayor en otros lugares. Cuantas más plataformas puedas probar, mejor.
Entonces, si bien puede haber grandes diferencias entre la forma en que se codifica y se produce el correo electrónico y la web, los pasos necesarios para dar vida a la visión de un diseñador son igualmente relevantes. Esperamos que nuestras experiencias lo ayuden a formular un plan para su próximo proyecto de código, así como a asegurar que su equipo se mantenga feliz y productivo cuando colaboren juntos.
Accentsconagua