8 Punkte von GN⁺ 2024-07-20 | 1 Kommentare | Auf WhatsApp teilen
  • HTML-E-Mail-Editor per Drag & Drop
  • Erzeugt HTML direkt, ohne Zwischencode wie MJML
  • Unterstützt drei grundlegende Vorlagentypen: Drag-and-Drop-Design, Bearbeitung von HTML-Code, Plain Text
    • Eigene Vorlagen können erstellt und gespeichert werden
  • Motivation für die Entwicklung
    • HTML für E-Mails zu schreiben, ist eine sehr schwierige Aufgabe
    • Schon kleine Abweichungen von den Regeln führen dazu, dass E-Mails in verschiedenen OS-, Desktop- und mobilen Clients kaputt dargestellt werden
    • Obwohl die E-Mail vor fast 50 Jahren erfunden wurde und HTML seit 35 Jahren existiert, ist E-Mail-Design noch immer kein gelöstes Problem
    • Es gibt einige brauchbare Open-Source-E-Mail-Designer, aber wegen ihrer Abhängigkeiten ist es umständlich, sie in Apps einzubinden
    • Aus diesen Gründen wurde entschieden, den HTML-E-Mail-Designer als Open Source zu veröffentlichen

1 Kommentare

 
GN⁺ 2024-07-20
Hacker-News-Kommentare
  • Die Meinung, dass es ein Fehler sei, dass MJML fehlt. Das sei die wichtigste Funktion im E-Mail-Design
  • Das Design sieht großartig aus. Werde es ausprobieren
  • Wirklich großartig. Frage mich, ob man responsive Styles hinzufügen kann. Zum Beispiel Spalten auf kleinen Bildschirmen in Zeilen umwandeln
  • Die Drag-and-Drop-Funktion funktioniert nicht. Unter Firefox auf macOS erscheinen Elemente beim Anklicken, lassen sich aber nicht in die E-Mail ziehen
  • Diese Arbeit wirkt sehr vielversprechend. „HTML für E-Mails“ ist schwer zu designen und umzusetzen, besonders auf Mobilgeräten, Tablets oder bei asiatischer Spracheingabe
    • Ich arbeite für B2B-CRM-Zwecke an vielen E-Mail-Templates und habe mich für einen anderen Ansatz auf Basis des slatejs/platejs-Editors entschieden
    • Die interne Darstellung von E-Mail-Templates in slatejs/platejs ist ein JSON-Format, das sich leicht in Postgres jsonb speichern lässt
    • Reactjs-basierte Widgets lassen sich leicht hinzufügen. Z. B. Erwähnungen, Medien, Diagramme usw.
    • Der Nachteil ist, dass sich keine pixelgenauen Templates entwerfen lassen
    • Eine bessere Abstraktion wäre wahrscheinlich MJML. Allerdings kann man im JSON-Format von slatejs/platejs Bearbeitungsinhalte per Copy-and-Paste in verschiedene Assets wie CRM, Wissensdatenbank usw. übernehmen
    • Daten in MJML zu speichern, ist keine gute Wahl
    • Ich wollte im letzten Schritt etwas Ähnliches wie SendWithSES/Drag-and-Drop-Email-Designer verwenden, aber den meisten Endnutzern ist das egal
    • Meinungen zur Datenrepräsentation und zum Datenfluss „Postgres <> Editor > Email HTML > Send button“ sind willkommen. Kaum jemand denkt ernsthaft über dieses Thema nach
  • Die Meinung, dass die ganze Prämisse absurd sei
    • Ich erkenne an, dass viele Menschen formatierte E-Mails mit Bildern und Logos wollen. Ich selbst will das nicht, aber ich verstehe die Bedürfnisse und Wünsche anderer
    • Warum HTML? Eine einfache Markup-Sprache (Markdown, orgmode usw.) hätte gereicht, und man hätte keine getrennten Plain-Text- und HTML-Versionen gebraucht. Es wäre zugänglicher für Screenreader und andere Hilfsgeräte, würde die Privatsphäre weniger verletzen und wäre weniger anfällig für Sicherheitsprobleme
    • Die Antwort war jedoch: „Lasst uns in jeden E-Mail-Client einen vollständigen Webbrowser einbauen“
    • Ich weiß, dass der Zug schon abgefahren ist
  • View -> Message Body As -> Plain Text
    • Nicht meine Schuld, aber man sollte immer Alternativtext bereitstellen
  • Wer schon einmal mit HTML-E-Mails gearbeitet hat, kennt die Schwierigkeit. Lob dafür, dass dies entwickelt und als Open Source veröffentlicht wurde. Ich werde es für Newsletter ausprobieren
  • Ich hatte vor ein paar Tagen kurz nach so etwas gesucht. Werde es mir ansehen. Danke
  • Unerwartet. Ich werde jetzt einige Stunden lang Fragen beantworten