Kreativt
Eit dokument, ikkje ein mal
Det du skriv er eit blokktre med eit publisert skjema. Det som går ut er det dokumentet rendra for eit mål — e-post, side, skjema, SMS, push eller print. Dei to er skilde med vilje, for redigeringsprogrammet kan bytast ut og rendringa kan ikkje, og å late som anna er korleis eit marknadsføringsverktøy endar opp med seks versjonar av same meldinga som ikkje lenger er samd.
Seks mål, éi kjelde
Kvar mål har avgrensingar som ikkje er eit smaksspørsmål, og rendraren kjenner dei så du slepp det.
E-post betyr tabellar og innebygd CSS, ingen flex og ingen grid fordi Outlook framleis bruker Word til å leggja ut e-post, eit rein tekst-alternativ generert for deg, fargar som overlever ein mørkmodus-klient som inverterer ting, og ein storleiksvakt på rundt 102 KB der Gmail byrjar å klippa.
Side betyr vanleg moderne responsiv HTML, publisert under ein slug, på ditt eige domene om du vil ha det. Skjema er ei side pluss feltbindingar, validering, ein honeypot og ein rate limit — og det er den eine vegen inn til kontaktane dine som kan produsera eit consent-grunnlag på lovleg vis.
SMS tel segment medan du skriv. Push er ein tittel, ein brødtekst, eit ikon, handlingar og ei djup lenkje. Brev er print-CSS rendra til ein PDF, adressert og postlagt.
Dokumentet sjølv er lagra som eit oppsett med eit publisert skjema, i økosystemet sin dokumentteneste i staden for gøymd i ein privat tabell. Det betyr at den dagen eit betre redigeringsprogram kjem, redigerer det same dokumenta og ingenting oppstraums endrar seg.
- 1e-postTabellar, innebygd CSS, tekstalternativ, trygg i mørk modus, ~102 KB-vakt.
- 2sideResponsiv HTML under ein slug, på ditt domene.
- 3skjemaSide pluss bindingar, validering, honeypot, rate limit.
- 4smsTekst med ein live GSM-7 / UCS-2-segmentteljar.
- 5pushTittel, brødtekst, ikon, handlingar, djuplenkje.
- 6brevSkriv ut CSS → PDF.
- iSjøenRedigeringsprogrammet kan bytast ut; måla kan ikkje. Det er derfor dokumentet har eit publisert skjema.
Rendera utdata bufra per mål
Flettevariablar
Ein ukjend variabel feilar ved publisering, ikkje stille ved sending
Standardåtferda i kvart malspråk for ein manglande nøkkel er å rendera ingenting. I ein e-post betyr det «Hei ,» sendt til førti tusen menneske, og ingen får det med seg før svara byrjar å koma inn. Derfor vert dokumentet validert mot variabelvokabularet før det i det heile kan publiserast.
Kva du kan interpolera
Kontaktens e-post, namn, telefon og språk; attrs.*, som er ope fordi attributta er dine; namnet og postadressa til organisasjonen din; lenkjene for avmelding og innstillingar; og emnet og preheaderen til meldinga sjølv.
Med vilje ei liste, ikkje «kva som helst frå posten». Ein kontaktrad inneheld også interne identifikatorar, og ingen av dei høyrer heime i ei melding.
Ein fallback er ikkje ein manglande variabel
{{first_name | default:there}} er ein kjend variabel som denne kontakten tilfeldigvis ikkje har — ei importert liste der halvparten av radene mangla namn. Då vert fallbacken rendera, og det er heilt greitt.
Det som vert avslått er {{frist_name}}: ein variabel som ikkje finst for nokon. Ved sending ser dei to identiske ut. Ved publisering kunne dei ikkje vore meir ulike, og det er derfor kontrollen skjer der.
Det same vokabularet verkar på tvers av alle mål, så ei formulering skriven for ein e-post vert rendera i SMS-en og på landingssida utan å bli skriven om. Og first_name vert utleidd ved rendring frå heile namnet i staden for å vera lagra — fordi ein lagra deling er ei feil deling som ventar på personen whose namn ikkje passar med antakinga.
Skriv det ein gong. Det kjem fram kledd for kanalen.
Før det går ut
Kontrollane som skjer medan du framleis kan retta opp ting
Gmail-klippet
Over rundt 102 KB klipper Gmail meldinga og gøyer resten bak ei lenkje dei fleste aldri trykkjer på — heilt nedst, mellom anna, avmeldinga di. Renderaren måler og varslar ved publisering.
Bilettvekt
Eit fire megabyte stort hero-foto sprekk storleiksbudsjettet og renderar dårleg på ein telefon. Bilete vert skalerta og konverterte ved opplasting, noko som er eit leveranse-spørsmål snarare enn ein finess.
Førehandsvising i innboks
Meldinga vert rendera og fotografert i skrivebords- og mobilbreidd, så listevisninga viser korleis tinga faktisk ser ut, ikkje namnet på ho. Ingen betalt førehandsvisingsteneste er involvert.
Ein ekte testutsending
Send den til deg sjølv, gjennom same renderar og same sendeidentitet som ein ekte mottakar ville fått. Ein førehandsvising som tek ein annan kodeveg beviser ingenting om meldinga som vert sendt.
Innlimt HTML vert reinsa
Innhald limt inn frå andre stader går gjennom ein reinsar før det vert lagra, for ein marknadse-post er ikkje staden å finna ut kva som låg i nokon sitt utklippstavle.
Markdown, om du føretrekk det
Skriv i Markdown og la det verta rendera. Langt meir påliteleg enn å be ein modell om e-post-HTML, og det er det som gjer at ein agent som skriv ei melding er ein arbeidbar idé, ikkje ein demo.
Med utgangspunkt i nettstaden din
Lim inn ei URL ved første køyring. ClickSomo les sida etter logoen, ikona, manifestet og dei målte fargane — ikkje fargar nokon gissa seg fram til — og byggjer ein første e-post som allereie ser ut som din. Den oppdagar også plattforma, noko som som regel er nok til å føreslå ein trakt som er verdt å ha: ein butikk får ein forlaten handlekorg, ein utgjevar får eit nyhetsbrev-velkomsten.
Kvart hent av ei URL du oppgjev går gjennom ein vakta hentar: berre HTTP og HTTPS, litterale adresser kontrollerte direkte, kvart DNS-svar krevd å vera offentleg, og kvart omdirigeringshopp revalidert. Å henta vilkårlege URL-ar på vegne av ein kunde er ein av dei enklaste måtane å laga eit hol i eige nettverk på, og det er ikkje noko ein skriv to gonger.
Det ærlege: ein første mal generert frå nettstaden din er ein god start, ikkje eit ferdig design. Den får logoen, fargane og typografien omtrent rett, slik at di første utsending ikkje ser ut som ein demo — og så redigerer du den, noko som er eit langt betre arbeid enn å stirra på eit tomt lerret.