The post 10 Tipps zur HTML-Banner Erstellung mit Animate CC first appeared on Zensations.

Wie funktioniert wichteln mit Santa-Rama?

Wenn ihr der oberste Wichtelbeauftragte seid, gebührt euch die Ehre der Erstellung einer Wichtelrunde. Dafür könnt ihr einen Namen für die Wichtelrunde, einen Veranstaltungsort sowie den Zeitpunkt und einen maximaler Geldbetrag, für das Wichtelgeschenk, definieren. Im Anschluss gibt der Oberwichtel alle Teilnehmer wahlweise mittels Name und E-Mail-Adresse ein. Nach dem Speichern werden automatisiert E-Mails an die gesamte Wichtelrunde ausgeschickt. Durch einen integrierten Link gelangen die einzelnen Wichtel im Anschluss zu unserem Wichtel-Selector, bei dem man Wunschpräferenzen betreffend des eigenen Wichtelpartners auswählen kann. It’s magic! Zu guter letzt wird dann der ausgeloste Wichtelpartner angezeigt!

Die Umsetzung

Umgesetzt haben wir Santa-Rama mit dem Content Management System Drupal, natürlich responsive und mit einer Sprachumschaltung auf Deutsch und Englisch. Ein weiteres Add on ist unser Wichtel-Selector, den wir für alle Teilnehmer integriert haben, um sich den perfekten Wichtelpartner auszusuchen. Mehr wird aber nicht verraten, probiert es lieber selbst aus. Merry Christmas & spread the word!

The post Online wichteln mit Santa-Rama first appeared on Zensations.

Von Photoshop zu Sketch

Sketch ist ein sehr schlankes Programm. Dadurch ist es möglich, das gesamte Design einer Website in einer Datei zu speichern (bei Photoshop führte das ja oft zu endlosen langen Lade- und Speicherzeiten). Die App lässt sich aber auch um ein Vielfaches erweitern, da es unzählige Plugins und kompatible 3rd-Party-Programme gibt, z.B. für Prototyping. Wer versucht, Sketch mit Photoshop, Illustrator oder InDesign zu vergleichen, der kommt schnell an seine Grenzen. Es handelt sich zwar wie bei Illustrator um ein Vektor-Programm, aber es ist weniger auf Illustration, sondern wirklich auf UI- und Web-Design ausgelegt. Daher ersetzt es keines dieser Programme gänzlich. Adobe bietet als Alternative die App Adobe Experience Design. Diese ist zwar vielversprechend, hinkt aber Sketch noch hinterher.

Gliederung der Inhalte

Sketch spielt in einer ganz anderen Liga. Da die App für UI- und Web-Design optimiert ist, bietet sie ganz neue Möglichkeiten, zum Beispiel bei der Gliederung der Inhalte.

Pages

Zur Gliederung für die Unterseiten verwende ich Pages – also es gibt bei mir eine Page für die Landingpage, eine für die Newsübersicht, eine für die Artikeldetailseite usw.

Artboards

Um wiederum verschiedene Ausprägungen von den Unterseiten anzuzeigen, sind Artboards sehr praktisch. So kann ich z.B. bei der Page “Kontaktseite” jeweils ein Artboard erstellen für das Kontakt-Formular

• vor dem Ausfüllen (leeres Formular)
• während des Ausfüllens (Darstellung der Inline Errors)
• nach dem Ausfüllen (Erfolgsmessage)

Dasselbe gilt für die Darstellung verschiedener responsiver Optionen. So können z.B. Artboards für Desktop, Tablet und Mobile mit von Sketch vorgeschlagenen Maßen erstellt werden.

Symbole

Das nächste tolle built-in Feature sind die Symbole. Sie funktionieren ähnlich wie Smart-Objects in Photoshop, doch sie bieten noch ganz andere Möglichkeiten. Wenn man beispielsweise mehrere Icon-Symbole in derselben Größe erstellt, kann man sie im Design per Dropdown auswechseln. Das funktioniert sogar, wenn man Symbole verschachtelt. Sehr praktisch sind in diesem Zusammenhang auch Namenskonventionen. Wenn ein Button beispielsweise einen hover, focus und active State aufweist, so können die Symbole gruppiert werden, indem man sie “button/hover”, “button/focus” und “button/active” nennt. Das trägt sowohl zur Übersichtlichkeit als auch zur schnelleren Auffindbarkeit bei.

Textstyles

Ähnlich wie in anderen Programmen funktionieren auch die Textstyles in Sketch. Für eine übersichtliche Darstellung habe ich die einzelnen Styles durchnummeriert. Für die Trennung von Semantik und Optik kann schon in Sketch der Grundstein gelegt werden. Unsere Überschriften tragen die Namen Heading XXL bis Heading S. Nennt man sie beispielsweise Heading1, so kann das irreführend sein, weil damit das h1-Element gemeint sein könnte. Meistens stimmen die optischen und semantischen Überschriften zwar überein, aber sie müssen auch oft extra gesetzt werden, beispielsweise wenn bei einer Blogübersichtsseite nach der großen Überschrift (h1) kleinere Blogtitel folgen.

Erstellung von Layouts

Beim Webdesign ist es essentiell, dass sich der Designer an einem Grid orientiert. Für dieses Grid wird eine Gesamtbreite festgelegt und man teilt es in eine bestimmte Anzahl von Spalten (meist zwölf). Zudem wird eine Spaltenbreite definiert und daraus ergibt sich auch die Breite des Spaltenzwischenraums. Durch die Definition eines Grids wird gewährleistet, dass das Design gut umsetzbar ist. Das Erstellen eines solchen Grids ist oft mühsam, egal ob es von einem CSS-Framework wie Bootstrap oder Foundation vorgegeben wird, oder ob es in Absprache mit dem Development manuell berechnet oder mit Hilfe von Online-Kalkulatoren erstellt wird. Sketch bietet daher die Option “Layout Settings”, wo bequem die gewünschten Werte für das jeweilige Artboard eingetragen werden können und das “Grid” bzw. “Layout”, wie es in Sketch heißt, automatisch angezeigt wird.

Responsive Design mit Resizing

Egal ob man den Mobile First Ansatz verwendet, oder klassisch von Desktop auf Mobil runterbricht, Sketch bietet für beide Varianten ein tolles Tool an. Die Option “Resizing” ermöglicht es, das Verhalten von Objekten zu definieren. Der Designer kann also festlegen, an welchen Ecken ein Objekt fixiert ist und ob die Größe des Objekts beim Resizing gleich groß bleibt oder prozentuell mitwächst bzw. -schrumpft. Eine genaue Erklärung wie dieses Tool funktioniert findet ihr in Jon Moores Artikel Sketch 44 Resizing: How does it work???.

Exportieren von Komponenten

Für den Export bietet Sketch eine sehr innovatives System. Jedes Element kann rechts unten über die Schaltfläche “Make Exportable” zu den exportierbaren Komponenten hinzugefügt werden. Dann kann ausgewählt werden, in welcher Auflösung das Element gespeichert werden soll. Spezielle Auswahlmöglichkeiten z.B. für Retina Anzeigen, Präfix/Suffix und Dateiformate machen das Exportieren so einfach wie noch nie. Im Anschluss können alle exportierbaren Komponenten mit einem Klick in dem ausgewählten Format gespeichert werden.

Shortcuts

An dieser Stelle alle Sketch Shortcuts anzuführen ist ein Ding der Unmöglichkeit und würde den Rahmen dieses Blogartikels sprengen. So mancher Shortcut stellt eine enorme Zeitersparnis dar, wie beispielsweise die Verwendung der Alt-Taste zum Anzeigen von Abständen zwischen Elementen. Wer sich genauer über Shortcuts informieren will, dem empfehle ich folgende Lektüre von designcode.io.

Plugins

Ebenso wie bei den Shortcuts gibt es auch bei den Plugins so unendliche viele, dass ich sie hier nicht alle anführen kann. Dennoch möchte ich ein paar an dieser Stelle vorstellen, die mir gute Hilfestellungen leisten.

• Ganz oben auf der Liste steht Craft von Invision. Das Plugin hat viele Funktionen, ich nütze sie hauptsächlich für Dummy Content. Es können Bilder z.B. von Unsplash oder aus einem bestimmten Ordner zufällig eingefügt werden. Aber auch Namen, Adressen, Telefonnummern können automatisch hinzugefügt werden.
• Auch sehr praktisch ist das Plugin Clipboard Fill, das es ermöglicht, ein Bild in eine bestimmte Form einzufügen. Da Sketch dieses Feature nicht nativ anbietet, ist dieses Plugin von großem Vorteil.
• Das Plugin Magic Mirror ermöglicht perspektivische Transformationen mit einem Klick darzustellen. So können z.B. Screens schnell in Shapes (z.B. einen IPhone-Screen) eingefügt werden.

Prototyping

Da das Web nun einmal nicht statisch, sondern agil ist, sind Prototyping Tools unerlässlich im Designprozess. Sketch allein ermöglicht kein Prototyping, allerdings gibt es viele kompatible Programme:

• Zeplin: Zeigt Farben, Assets und Schriften an und es können Guidelines erstellt werden. Zudem gibt es eine Kommentarfunktion für Besprechungen mit Developern. Außerdem kann Source Code (ios/android) exportiert werden.
• Invision App: Hier handelt es sich um ein Online Prototyping Tool, das für ein Projekt kostenlos ist. Für mehrere Projekte gibt es verschiedene Pricing-Modelle. Mit der Invision App lassen sich Click-Dummies erstellen und sie hat ebenfalls eine Kommentarfunktion.
• Flinto: Ist ein Prototyping Tool, mit dem Scrolling, Transitions und Microinteractions animiert werden können.
• Principle: Ist ebenfalls für Animationen geeignet.
• Marvel: Bietet alles von Design über Prototyping bis hin zu Collaborations.

Fazit

Ich liebe Sketch! Und würde es jedem ans Herz legen, es selbst zu testen.

The post Erste Erfahrungen mit Sketch first appeared on Zensations.

Es kommt durchaus vor, dass einem die folgenden Fragen gestellt werden:

• Was kostet eine Website, so ähnlich wie diese?
• Wie hoch ist der Aufwand für eine Digital-Betreuung?
• Wie aufwendig ist ein Newsletter-Design?

Wenn es nur so einfach wäre. Als kleines Gedankenspiel stellen wir oft die Gegenfragen: “Wie lange ist eine Schnur oder wie teuer ist ein Haus?” Denn um eine seriöse und fundierte Antwort darauf zu geben, benötigt man weitaus mehr als einen Satz bzw. eine Referenz und muss sich mit dem den verfügbaren Informationen ausführlich beschäftigen.

Um ehrlich zu sein sind die Anforderungen oft auch so komplex, dass wir aus gutem Grund keinen Fixpreis bei Projekten anbieten, die über einen längeren Zeitraum gehen, wachsen oder crossmedial umgesetzt werden. Selbst wenn wir detaillierte Informationen vorliegen haben, so schätzen wir eine agile Arbeitsweise und es ist beinahe schon unseriös vorzugeben, ein Projekt im höheren fünfstelligen Bereich bis ins kleinste Detail auf Basis eines Pflichtenheftes abschätzen zu können ohne nicht dabei einen enormen Puffer einzurechnen, der dementsprechend zu Lasten des Kunden gehen würde. Anforderungen ändern sich über die Zeit. Wer schon einmal ein größeres Projekt umgesetzt hat, der weiß wovon ich spreche. Wir sehen uns die Features an, definieren die User-Stories und überlegen uns genau, welche in die erste Phase und welche in weitere Ausbauschritte gehören. Nicht jedes Feature ist business critical und wir sind absolute Befürworter erst mal mit einem Minimum Viable Product (MVP) an den Start zu gehen. Aber dieses Thema werden wir in einem anderen Blogpost nochmals ausführlich behandeln.

Also zurück zum Thema: Ordentliche Briefings sparen ganz einfach viel Geld und Ärger! Dabei sind die Punkte, die dieses enthalten sollte, stets die gleichen. Lediglich die Form sowie der Detailgrad variieren. Aus meiner Sicht sollte jedes Briefing im Großen und Ganzen folgende Punkte beinhalten.

1. Informationen zum Unternehmen bzw. der Ausgangslage

In gleicher Weise, wie sich Auftragnehmer vorstellen und ihre Expertise erklären, sollten es auch Auftraggeber tun. Eine Beschreibung des Unternehmens, der Vision, eine Marktanalyse und weiterer Faktoren wie Stärken, Schwächen oder bisher getätigten Maßnahmen zur Erreichung von Zielen sind unerlässlich, sodass Auftragnehmer die selbst recherchierten Informationen mit diesen verknüpfen und sich ein Bild des potenziellen Kunden machen können.

Ob nun bei einer Marketingkampagne, einem Online-Auftritt oder der kompletten Digitalbetreuung: je detaillierter die Informationen zum Unternehmen sind, umso genauer kann man auch auf die Kundenwünsche eingehen. Da ist kein Platz für falsche Egoschmeicheleien. Klarheit ist der Weg zum Erfolg.

Und hier heißt es dann Tabula rasa: Das ist auch der Moment darüber zu sprechen, warum Aktivitäten bisher vielleicht nicht den gewünschten Output geliefert haben, die gut durchdachte Strategie in der Umsetzung auf der Strecke blieb oder die Kampagne meilenweit an der Zielgruppe vorbeiging.

2. Problemstellung / Zielsetzung

Soll die Brand-Awareness gesteigert, der Verkauf gefördert oder die Interaktion ausgebaut werden? Unterstützt der Webauftritt die Ziele des Unternehmens nicht mehr, bzw. gibt es neue Anforderungen (Responsive Design, Barrierefreiheit, Usability, diverse technologische Ansätze), die aktuell nicht erfüllt werden, so gilt es bei diesen Angaben eine ausführliche Beschreibung der IST- sowie SOLL-Situation zu formulieren. Was läuft aktuell schief und warum? Welche Anforderungen müssen erfüllt werden, um die Prozesse wieder zu unterstützen? Der Weg von der Ausgangslage zum Wunschszenario ist dabei irrelevant, denn dafür sind die Experten dann ja da.

Über die Sinnhaftigkeit und Aussagekraft von KPIs kann man diskutieren und darüber haben wir vor kurzem in unserem Beitrag “5 KPIs für den digitalen Kommunikationserfolg” schon ausführlich berichtet, aber idealerweise ermöglichen die zur Verfügung gestellte Analyse- und Performance-Informationen eine Erfolgsmessung, sodass der Projekterfolg im Anschluss auch messbar gemacht werden kann. Diese können etwa die CTR, Leads, organischer Traffic, Engagement rate, etc. sein. Sollten diese nicht zur Verfügung stehen, so ist es notwendig, im Vorfeld eine Analyse über einen aussagekräftigen Zeitraum zu erstellen.

Bei allen Projekten ist es hilfreich, auch eine Vision zu skizzieren, die über den aktuellen Umfang hinausgeht. So können Aspekte berücksichtigt werden, die anderenfalls, etwa beim Ausbau einer Website, zusätzliche Mehrkosten verursachen, da Funktionen, Templates, etc. komplett umgebaut werden müssen. Hierfür bietet sich etwa ein Kick-off-Workshop an, um die Anforderungen gemeinsam mit dem Kunden im Detail durchzugehen, auf Machbarkeit zu überprüfen und so bereits im Vorfeld etwaige Bottlenecks aufzuspüren.

3. Zielgruppen

Das Targeting ist ebenso wichtig wie das Projektziel, denn jede Zielgruppe hat ihre Präferenzen und Eigenheiten. Dementsprechend sollte eine klare Vorgabe gemacht werden, denn wer alle Kunden erreichen will, erreicht am Ende niemanden richtig. Somit müssen gegenebenfalls mehrere Sujets, differenzierter Content, Landingpages, etc. entwickelt und unterschiedliche Kanäle gewählt werden, sodass bei den definierten Zielgruppen auch der gewünschte Impact erzielt wird. Je genauer ein Segment definiert werden kann, umso besser stehen die Chancen, dass die Maßnahme auch Wirkung zeigt. So wird es vermutlich wenig zielführend sein, eine Kampagnen mit Snapchat aufzusetzen, die Senioren erreichen soll oder einen Online-Shop mit atypischer Navigation, wenn es darum geht den Verkauf zu fördern.

4. Termine

Zeitreisen sind leider noch nicht möglich, auch wenn man es sich manchmal wünschen würde. Wann soll die Website online gehen oder die Kommunikation starten? Gibt es Faktoren (saisonale Schwankungen, Events, etc.) die den Zeitplan vorgeben? Informationen, die für den Auftragnehmer essentiell sind, um dementsprechend Ressourcen und Durchlaufzeiten zu planen. Dabei gilt es jedoch realistisch zu bleiben und Puffer für die einzelnen Milestones einzuplanen, um Risiken abzufedern und die finale Deadline nicht zu gefährden. Diese Informationen sollten alle verantwortlichen Projektpartner kennen, da anderenfalls eine falsche Erwartungshaltung entsteht.

5. Budget

Gerade im Development-Bereich sind häufig die vorgegebenen Budgets von Kunden mit ihren Wünschen nicht vereinbar. Dies bedeutet aber nicht, dass es nicht möglich wäre, die Ziele mit einem reduzierten Umfang zu erreichen. Man legt dabei den Fokus auf die business critical Features und führt mit diesen einen Proof of Concept durch, Stichwort: Minimum Viable Product. Zeit ist Geld und dementsprechend sollte das Produkt schnell auf den Markt gebracht werden. So kann Feedback gesammelt werden, welches in den weiteren Ausbauschritten einfließt. Beim Budget sind natürlich nicht nur die externen Kosten zu berücksichtigen, sondern auch die internen Ressourcen.

Fazit

Wer sich Partner an Board holt, die einem den Himmel auf Erden zum Super-Schnäppchen versprechen, sollte schnell das Weite suchen. Wir machen es nicht und raten davon ab. Kreativität, Expertise und Beratung haben eben ihren Preis. “Wer billig kauft, kauft zweimal”, heißt es ja so schön. Eine Binsenweisheit, die schon auch ihre Daseinsberechtigung hat.

Natürlich könnte ich zu jedem dieser Punkte noch ausführlichere Informationen bringen, aber kurz gefasst kann man es auch so formulieren: Nur wer gut gebrieft ist, kann auch gute Arbeit liefern. Um jedoch keine Verwechslung aufkommen zu lassen. Ein gutes Briefing ersetzt noch lange kein Konzept bzw. Pflichtenheft, sondern dient als Basis für die Ausarbeitung derer. Mit Hilfe eines Konzeptes wird ein nicht bis ins Detail geplantes Modell definiert, dass im Anschluss durch das Pflichtenheft ergänzt wird. Dieses beschreibt dann detailliert, wie und womit das Projektziel erreicht wird.

Was sind eure Erfahrungen? Worauf kommt es beim Briefing aus eurer Sicht an, welche Punkte dürfen auf gar keine Fall fehlen?

The post Warum man um (ordentliche) Briefings nicht umhin kommt first appeared on Zensations.

Doch die E-Mail hat auch ihre Tücken. Aufgrund fehlender Standards hat jeder E-Mail Client seine eigenen Methoden zum Rendern von HTML und CSS. Daher müssen viele alte und neue Programme getestet und Workarounds gefunden werden, damit E-Mails auch in jedem Mail-Client und über jedes Endgerät richtig angezeigt werden.

Vor allem die Anzeige am Smartphone oder Tablet spielt eine große Rolle. Da E-Mails heute sehr oft mobil abgerufen werden, müssen auch Newsletter auf jedem Endgerät richtig angezeigt werden. Responsive Design spielt dabei also eine wichtige Rolle. Grundsätzlich gibt es viele Anbieter, die responsive Templates kostenlos oder gegen eine einmalige Zahlung zur Verfügung stellen. Wenn das Corporate Design des eigenen Unternehmens oder des Kunden aber ein Custom Template erfordern, entsteht leider oftmals das Problem, dass die Erstellung eines Custom Newsletter Templates die Budgetvorstellungen bei weitem übertreffen und in vielen Fällen auch gar nicht unbedingt notwendig sind.

Um diesem Problem entgegenzuwirken, wollen wir in dem folgenden Beitrag zeigen, welche Möglichkeiten und Tipps es gibt, um auch bei kleineren Budgets an das Corporate Design angepasste Newsletter Templates zu erstellen und den Workflow bei der Erstellung dieser zu erleichtern.

E-Mail Templates designen

SCHRITT 1 (OPTIONAL): DOWNLOAD EINES BASIC TEMPLATES

Wie bereits erwähnt, gibt es viele Anbieter, die Basic Templates oder bereits designte Templates kostenlos oder gegen eine einmalige Zahlung zur Verfügung stellen.

Wer am liebsten mit einem bestehenden Design starten möchte, dass dem Endprodukt vielleicht schon ähnlich ist oder auf das man zumindest aufbauen kann, der wird bei themeforest, pixel77 und copernica fündig.

Wenn der Aufbau allerdings komplett individuell sein soll, dann ist Campaign Monitor eine gute Wahl. Einerseits bieten sie einen Template Builder an, mit dem man online selbst Templates bauen kann, die responsive, fully tested und sogar für Outlook und Gmail geeignet sind. Andererseits stellen sie auch ein Campaign Tool zur Verfügung. Dieses ist allerdings kostenpflichtig. Der Online Builder ist einfach anzuwenden und bietet auch die Möglichkeit den HTML Code herunterzuladen, um noch custom Änderungen vorzunehmen, die mit dem vorgefertigtem Builder nicht möglich sind oder um ein anderes Campaign Tool nutzen zu können.

Mindestens so gut (oder sogar noch besser?) ist MailChimp. Es ist der Alleskönner im Mailbereich, weil er sowohl predesignte Templates zur Verfügung stellt, als auch einen Drag and Drop E-Mail Designer.

Wer sein Template selber Coden möchte, für den hält MailChimp sechs responsive E-Mail Templates bereit, die eine responsive Struktur aufweisen und deren Code zum Bearbeiten runtergeladen werden kann. Dafür kann man dann den E-Mail Template Reference Guide zu rate ziehen.

Ein weiteres Framework, das mehrere getestete Grundgerüste zur Verfügung stellt, die dann beliebig erweitert/verändert werden können bietet zum Beispiel ZURB Ink. Sie stellen fünf responsive E-Mail Templates zur Verfügung, die alle E-Mail Clients (sogar Outlook) unterstützen und mithilfe der Dokumentation individuell angepasst werden können. Dasselbe gilt für Cerberus, die zwei Templates anbieten: einmal mit und einmal ohne Media Queries.

SCHRITT 2: DER SPASS MIT DEM CODE

Soweit alles kein Problem. Doch jetzt fängt der Spaß erst an. Egal ob erfahrener Web Entwickler oder Anfänger, ab jetzt heißt es: Vergessen Sie alles, was Sie über Web Development wissen. Man kann weder divs verwenden, noch einen margin einstellen. Semantisches HTML und die neuesten CSS Features sind bei E-Mails leider nicht zu gebrauchen.

Falls kein bereits bestehendes und getestetes Template verwendet wird, muss zuerst eine Struktur gebildet werden – und zwar mithilfe von tables, die ineinander verschachtelt werden. Diese Struktur sollte dann sofort getestet werden. Dazu eignen sich am besten Litmus oder Email on Acid. Generell sollte man während dem Erstellungsprozess sehr sehr oft testen, um später nicht mit vielen Bugs, die sich gegenseitig beeinflussen, konfrontiert zu sein.

Während des Entstehungsprozesses sollte man sich die Borders anzeigen lassen, damit man über einen guten Überblick verfügt. Nicole Merlin empfiehlt im Artikel What You Should Know About HTML Email beispielsweise den folgenden Workflow: + Skeleton erstellen + Testen + Content einfügen + Testen + Farben und Fonts stylen + Testen + Borders entfernen + Testen und senden

Man darf aber auch nicht darauf vergessen, mit dem W3C Validator zu validieren.

Über diesen Part könnte man seitenweise berichten, aber das haben zum Glück schon andere getan. Auch hier findet man viele Hilfestellungen im Web, wie zum Beispiel ein Tutorial, wie man eine einfache Responsive HTML Email mit all seinen Tücken und Workarounds erstellt.

SCHRITT 3: VERSENDEN MIT EINEM E-MAIL CAMPAIGN TOOL

Beliebte Tools zum Versenden sind MailChimp und Campaign Monitor. Sie sind leicht zu bedienen und mit einem freien Account verwendbar. Bei MailChimp ist das Campaign Tool sogar bis zu 2000 Abonnenten und 12000 Mails pro Monat kostenlos. Diese Tools bringen deinen CSS Code automatisch inline, sodass er in den meisten E-Mail Clients gerendert wird.

Fazit

E-Mail Templates zu erstellen ist und bleibt kein allzu einfaches Unterfangen. Glücklicherweise gibt es einige Tools, welche das Prozedere erleichtern und mit denen man den Weg aus dem Client-Chaos findet. Dadurch finden wir immer wieder Mittel und Wege, um Newsletter so zu gestalten, dass es am Ende dem Corporate Design unser Kunden entspricht.

The post In 3 Schritten zum responsive E-Mail Template first appeared on Zensations.

Der folgende Arbeitsschritt beginnt also mit einer Identitätskrise des Frontend Developers.

An diesem Punkt stehen wir an einem Scheideweg. Nicht selten entscheidet man sich dann für den scheinbar leichteren Weg. Seite für Seite werden die unterschiedlichst gearteteten HTML-Konstrukte entsprechend des Designs platziert und angemalt. Irgendwie fühlt man sich schmutzig, aber dafür gibt es keine Diskussionen mit dem Designer und der Kunde hat ja schließlich jeden Pixel einzeln abgesegnet. Im schlimmsten Fall findet ein Hack nach dem anderen findet seinen Weg ins Theme und spätestens nach den ersten ein- oder zweitausend Zeilen CSS ist von Wartbarkeit nicht mehr zu sprechen.

Alternativ lässt sich das Design mühsam Reverse Engineeren. Dabei wird die Vorlage zunächst interpretiert und dann in einzelne logische Komponenten aufgeteilt. Die daraus resultierenden Bausteine werden dann Stück für Stück in CSS umgesetzt und so gut wie möglich auf das Theme angewendet. Weniger schmutzig, aber auch nicht ideal.

Beide Szenarien sind aus ganz unterschiedlichen Gründen absolut suboptimal. Das Model “Adobe2Theme” ist aus Gründen der Menschenwürde weder dem Designer noch dem Entwickler zumutbar.

Eine Alternative im Frontend-Development

Unserer Meinung nach ist die Entwicklung von Frontend-Lösungen ein integrativer und fließender Prozess, der entgegen der obigen Darstellung nicht beim Wireframing beginnt und beim Theming aufhört. Um dem gerecht zu werden setzen wir seit einiger Zeit Living Styleguides ein.

Ein Living Styleguide (oftmals auch “Pattern Library”) ist eine auf HTML, CSS und JS basierende, grafische Repräsentation der User Interface-Bestandteile einer Applikation. Entgegen einer einfachen Photoshop-Datei bzw. eines Static Styleguides, z.B. in Form eines starren Textdokuments, werden beim Living Styleguide also vollwertigen Prototypen der einzelnen zu erwartenden Bestandteile der entstehenden Applikation als unabhängige Komponenten unter realistischen Bedingungen im Browser dargestellt. Im Gegensatz zu einem statischen Dokument lassen sich die einzelnen Komponenten einfach erweitern und Derivate ableiten. Durch die unabhängige Aufbereitung jeder Komponente entsteht ein besonderer Fokus auf Semantik und optimaler Umsetzung und Strukturierung von HTML und CSS. Das ursprüngliche Konzept wir dabei laufend validiert. Ein besonderer Vorteil dieser Herangehensweise ist die fast zwingende, vollständige Aufarbeitung der Typographie als sog. Basis Komponente.

Der Einsatz eines Living Styleguides ist also nicht ausschließlich Dokumentation und Bauanleitung, sondern essentieller Bestandteil von Konzeption, Design und Umsetzung. Denn: Die Effektivität eines Living Styleguides liegt im besonderen Maß auch an der Ideologie und der Workflows, die er bedingt und vermittelt.

Mit anderen Worten: ! Wenn die von uns entwickelten Themes leckere Törtchen wären, dann wäre der Styleguide der Tortenboden und nicht das Sahnehäubchen.

Durch die Verwendung eines Living Styleguides sind alle Parteien bereits von Beginn an involviert. Missverständnissen zwischen Designer und Entwickler werden so vorgebeugt und gegenseitiges Verständnis aufgebaut, während bei allen Beteiligten ein Lerneffekt des gegenüberstehenden Arbeitsfeldes einsetzt. Konkret bedeutet das, dass unsere Designer inzwischen einen Großteil ihrer Arbeit selber in Sass bzw. CSS und HTML abbilden können. Der Styleguide wird also mehr und mehr zu einem Resultat der interdisziplinäre Teamarbeit und nicht nur abschließende Dokumentation bzw. Aufarbeitung des übergebenen Designs.

Ein weiterer Vorteil liegt in der ständigen Erweiterbarkeit des Styleguides und dessen Flexibilität in Bezug auf Änderungen (Maintainability). Darüber hinaus wird auf diesem Weg eine projektübergreifende Wiederverwendung sämtlicher Komponenten sowie eine parallele Erweiterung durch mehrere Entwicklerteams ermöglicht. Anstatt für verschiedene Projekte mit dem gleichen Corporate Design die jeweilig verwendeten Komponenten neu zu erfinden, können diese aus dem Styleguide entnommen und ggf. erweitert werden. Der Styleguide kann somit auch für den Kunden als durchaus nützliches, eigenständiges Produkt anerkannt werden.

Ein Ausblick

Dies ist der erste Blogpost einer Serie rund um das Thema Living Styleguide. Nachdem ich nun unsere Philosophie in Bezug auf Frontend Entwicklung und Styleguides erläutert habe werden wir demnächst auf die von uns verwendeten Tools und Practices eingehen.

The post Living Styleguide: Die Vorteile first appeared on Zensations.

Für die Erstellung eines Angebots gibt es verschiedene Ansätze: Von überschlagsmäßigen “Daumen-Mal-Pi-wird-sich-schon-irgendwie-ausgehen”-Lösungen über exakte Aufschlüsselungen sämtlicher Funktionen bis hin zu der Erstellung von User Stories.

Letztere sehen wir als probate Lösung und deshalb setzen wir nicht nur während der Designphase und im Development, sonden auch bei der Angebotserstellung auf User Stories. Diese helfen Designern, Entwicklern und Projektmanagern ihre Arbeit effizienter zu erledigen. Denn sämtliche Tasks zur Umsetzung der User stories werden vorab definiert und können nach Beauftragung vom Team ahand von Sprints konsequent abgearbeitet werden. Aber wie läuft nun eine Angebotserstellung mit Hilfe von User Stories ab, bzw. welche Vor- und Nachteile hat diese, aus Scrum bekannte, Methode?

Wir denken nicht in Features

Um den prinzipiellen Unterschied zwischen Features und User Stories zu erklären, hier ein kurzes Beispiel zur Veranschaulichung anhand eines Kontaktformulars.

Das Formular ist ein Feature, die User Story dazu lautet: Der Website-Besucher tritt mit dem Unternehmen über ein Formular (durch Eingabe des Namens, der E-Mail Adresse, einer Nachricht) in Verbindung.

Der Unterschied ist also folgender: Ein Feature beschreibt die Funktionalität, eine User Story, welche Aktion ein Benutzer auf der Website ausführt. Es ist also wesentlich einfacher sich vorzustellen, welche Handlungen durchgeführt werden müssen, um die Anforderung an einen Webservice zu erfüllen, als welche Features eine Website enthält. Unserer Erfahrung nach lässt die Auflistung von Features zu viel Spielraum und oftmals gehen die Vorstellungen in der Umsetzung dann einfach zu weit auseinander. Das kann schlussendlich zu – für beide Seiten – ungewollten Mehraufwänden führen. Aber welche Vor- und Nachteile hat aber nun diese Methode?

Die Vor- und Nachteile von User Stories

Wer bereits mit Scrum gearbeitet hat, wird nun bestimmt den zeitlichen Aufwand als Nachteil nennen. Dadurch, dass die Abschätzung wesentlich detaillierter erfolgt, ist natürlich auch bereits die Angebotslegung mit Mehraufwand verbunden.

Die Vorteile überwiegen jedoch. Durch die Aufsplittung in User Stories werden Aufwände kalkulierbar und sind selbsterklärend. Aber nicht nur der Kunde, sondern auch das Projekt-Team profitiert von dieser Vorgangsweise. Da das Projekt von allen zuständigen Team-Mitgliedern geplant wird, findet natürlich auch ein Wissenstransfer statt.

Sind erst einmal alle Stories notiert, kristallisiert sich schon ein weiterer Vorteil heraus. Denn in diesem Prozess können fehlende Spezifikationen oder Planungsfehler sehr leicht identifiziert und so bereits vor Angebotslegung geklärt werden. Durch diese Herangehensweise haben sich die Anzahl an Fragen zum Angebot, die Probleme während der Umsetzung sowie Change Requests und damit einhergehende Mehrkosten für beide Seiten deutlich reduziert.

The post Angebotslegung mit User Stories oder Features? first appeared on Zensations.

Wer noch nie ein barrierefreies Design erstellt hat ist vielleicht zunächst ratlos und wirft Google an. Dort erfährt man schnell, dass verschiedenste Standards und Guidelines (W3C, WACG, HTML5) einzuhalten sind und das “betrifft in erster Linie die technische Umsetzung”. Wichtig ist auch, dass vor allem die Erstellung semantisch korrekter Inhalte entscheidend ist.

3 einfache inhaltliche Richtlinien:

1. BESCHREIBENDE LINKS VERWENDEN

schlecht: hier klicken gut: mehr Informationen zum Thema XY

2. KEINE TABELLEN

Wenn es doch Tabellen sein müssen, verwenden wir Zeilen- und Spaltenüberschriften, sowie im Idealfall eine Kurzzusammenfassung des Tabelleninhalts.

3. ALTERNATIVE BILDBESCHREIBUNG

Last but not least: Jedes Bild benötigt einen „alt“-Tag, der den Bildinhalt ausführlich und sinnvoll beschreibt.

Design: Jetzt gehts ans Eingemachte

1. KEIN PIPIFAX

Es geht um die Inhalte. Das Design soll natürlich ansprechend wirken, aber übertriebene CSS-Animationen, Parallax Scrolling oder ähnliches erschweren den Zugriff.

2. RESPONSIVE DESIGN

Ja bitte und eigentlich sowieso immer! Das Interaktionsdesign sollte so angedacht sein, dass es auf jedem Endgerät perfekt aussieht. Auch sehbehinderte Menschen haben coole iPad Minis.

3. KLARE STRUKTUR

Wir gestalten klar und übersichtlich. Ein klares und leicht verständliches Layout ist ein Must! Weißraum ist unser Freund. Das Menü sollte möglichst wenige Ebenen (maximal 3) und eine klare Navigation aufweisen. Auf keinen Fall sollte es ein ausfahrendes Mouseover Menü sein! Die Seite sollte zusätzlich auch Breadcrumbs verwenden.

4. SCHRIFTEN

Mein Lieblingsthema. Ich gehöre zu den Designerinnen, die davon überzeugt sind, dass Serifen der besseren Erkennbarkeit des Schriftbilds dienen und vor allem Kinderbücher in Serifenschriften gesetzt werden sollten. Die sehbehinderten Kollegen, die uns bei der Umsetzung mehrerer Projekte unterstützt haben sehen das allerdings anders. Unbedingt serifenlos muss es sein! Denn oft wird mühsam jeder einzelne Buchstabe für sich identifiziert. Im Idealfall sind Arial oder Verdana zu wählen, da vor allem letztere sich durch große Punzengrößen und eine große x-Höhe auszeichnet, was vor allem auf Bildschirmen sehr gut lesbar ist.

Links dürfen nicht nur allein durch eine andere Farbe ausgezeichnet werden. Das heißt wir können zusätzlich: unterstreichen, den Schriftschnitt ändern (Bold, Kursiv), oder ein Element davorsetzen wie zum Beispiel einen Pfeil. Ach ja: Und natürlich ist die Schriftart nicht zu klein zu wählen, mindestens 14px groß.

Es gilt wie überall im Webdesign: Kein Blocksatz. Lasst mich das wiederholen: KEIN BLOCKSATZ. Im Idealfall ist das Design durch die Bank linksbündig. Auch zentrierter Text ist problematisch, da der Beginn der nächsten Zeile aufgestöbert werden muss. Dieser befindet sich ja nicht immer an der selben Stelle.

5. HILFESTELLUNGEN

Beim Gestalten dürfen die Hilfestellungen nicht vergessen werden. Zentrale Fragestellungen dabei: Wo platzieren wir diese und wie sollen sie aussehen? Welche Hilfestellungen gibt es überhaupt?

• Die Schriftgrößeneinstellungen dürften den meisten bekannt sein.
• Farbkontrasteinstellungen (davon gibt es standardmäßig 6)
• Bedienungsanleitung der Website mit Tastatur

 Wie das aussehen kann und funktioniert, könnt ihr euch auf www.augengesundheit.at und www.hilfsgemeinschaft.at ansehen.

6. FARBEN

Ein schwieriges Thema! Rot und Grün sollten nicht zusammen vorkommen und es muß immer an ausreichend Kontrast gedacht werden. Um bei diesem heiklen Punkt nicht ins Fettnäpfchen zu treten, gibt es ein wunderbar einfaches Tool, das uns dabei hilft unsere Farbwahl auf Herz und Nieren zu überprüfen WebAim Hier könnt ihr konkret sehen ob die Schriftfarbe auf der Hintergrundfarbe funktioniert und wie groß der Text sein muß, damit es doch klappt.

Noch ein Hinweis: Programmierer können die fertige Seite mit WAVE auf Fehler überprüfen.

Wenn ihr selbst noch weitere Tipps und Erfahrungen zum barrierefreien Webdesign habt, lasst es mich bitte in den Kommentaren wissen. Man lernt nie aus

The post Barrierefreies Webdesign aus der Design-Perspektive first appeared on Zensations.

Ein Rückblick

Wer kennt es nicht, Änderungswünsche von Kunden kommen idR. per Mail oder in ganz dringenden Fällen per Telefon. Empfänger sind meist die Projektmanager oder Entwickler aber auch gerne mal die Chefin. Jetzt kommt der Knackpunkt: Diese Änderungswunsche wurden dann agenturintern gleich per Mail an die zuständigen Designer, Entwickler oder Projektmanager weitergeleitet – was bei mehreren gleichzeitigen Projekten in der Pipeline unweigerlich im Chaos endete. In scheinbar ganz dringenden oder ganz einfachen Fällen geht aber auch noch direkter – nach dem Prinzip der kürzesten Wege gleich per Zuruf: „Kannst du bitte mal schnell… .“

Gerade Entwicklern kosten solche kleinen Unterbrechungen Studienergebnissen zufolge 15 oder gar 30 Minuten Zeit, um wieder ganz in die ursprüngliche Problemstellung hinein zu finden. Abgesehen davon ist die gesamte Kommunkation zu Änderungswünschen in E-Mails, auf Notizblöcken und vor allem in den Köpfen des Teams gespeichert. Das führt dazu, dass es für alle Beteiligten schwer wird den Überblick zu behalten und konzentriert zu arbeiten. Eine Lösung musste also her, aber klassische Bugtracker sind zu sehr an Entwicklern ausgerichtet und für Projektmanager, Designer und Kunden eher ungeeignet. Nach langem Suchen sind wir aber seit letztem Jahr fündig geworden und möchten euch einen Einblick in unsere Erfahrungen geben.

Die Qual der Wahl

Nach gründlicher Recherche und Tests von vielen Bug-, Issue-Tracking und Projektmanagement-Systemen wie Jira, Redmine, Trac, Erpal, etc. haben wir uns unter anderem aus folgenden Gründen für Youtrack entschieden:

• Individuell an unseren Workflow anpassbar
• Zusammenfassung von Projektmanagement, Bug-Tracking und Zeiterfassung
• Zentrale Dokumentation aller Änderungen und Kommunikation
• Integration mit unserem Continuous Integration System (wird in einem späteren Beitrag erörtert)
• Möglichkeit zu schnelleren Strukturierung von Kundenanfragen (Erstellung von Angeboten, wird ebenfalls später gebloggt)
• Ausgefeiltes Rollensystem, um Kunden Zugriff auf Projektbereiche zu geben

Effizienter und agiler Workflow

Da wir bereits bei der Angebotserstellung die Projekte strukturieren, beschreiben und in kleinere Tasks bzw. Tickets aufteilen, können wir bei Projektstart schneller in die Umsetzung gehen. Es sind bereits alle Features und User stories definiert und werden gegebenenfalls in kleinere Subtickets aufgeteilt.

Kommunikation und Dokumentation von Änderungen Alle Änderungen, zusätzliche Informationen oder Fragen werden zu den jeweiligen Tickets gespeichert. Etwaige Rückfragen an den Kunden werden sofern möglich auch über das System abgewickelt. Kunden können aber auch via E-Mail neue Tickets eröffnen. So ist sichergestellt, dass alle Beteiligten, jederzeit, auf dem gleichen Wissenstand sind.

Priorisierung der Tickets Um abschätzen zu können, wie wichtig die Bearbeitung der Tickets ist werden folgende Prioritäten vergeben:

• Minor
• Normal
• Major
• Critical
• Show-Stopper

Als „Critical“ und „Show-Stopper“ markierte Tickets sind meist Grundbausteine und für den Projekterfolg äußerst wichtig. Diese werden dementsprechend prioritär behandelt und zuerst umgesetzt. Auch Bugs fallen in diese Kategorie.

Wöchentliche Sprints Meist 2-4 Wochen im Voraus wird durch die Projektmanager aus den laufenden Projekten und etlichen Tickets ein wöchentlicher Sprint zusammengestellt und gleich einzelnen Personen zugeordnet. Im so genannten Agile Board haben nun alle Projektbeteiligten einen Überblick über die anstehenden Aufgaben, kategorisiert nach Priorität. Die Tickets sind entweder wie erwähnt bereits zugeordnet oder aber „Unassigned“. So können am Projekt beteiligte Teammitglieder die Tickets selbst untereinander aufteilen.

Tägliche Bearbeitung der Tickets Auf Basis der für die Woche definierten Sprints wird je nach Priorität mit den wichtigsten Tickets begonnen. Der Status des Tickets wird dabei auf „In Progress“ gesetzt und auch im oben genannten Agile Board abgebildet. So bekommt jeder einen Überblick, woran gearbeitet wird. Dadurch entfallen täglich mehrmalige Nachfragen, woran gerade gearbeitet wird und was bereits gefixt wurde.

Gibt es Rückfragen oder Unklarheiten wird direkt das entsprechende Ticket kommentiert und einfach dem gewünschten Teammitglied zugeordnet. Dieses erhält eine Benachrichtigung und kann darauf direkt per Mail (wird im Ticket gespeichert) oder über die UI reagieren. So bleibt die gesamte Kommunikation an zentraler Stelle und ist nicht in Mails, auf Zetteln oder in den Köpfen verstreut.

Nach Umsetzung des Tickets wird der Status auf „Fixed“ gesetzt um zu signalisieren, dass vorerst alles fertig ist. Youtrack informiert automatisch die Projektverantwortlichen bzw. den/die ErstellerIn des Tickets und weist es zu. Ist die Umsetzung überprüft und vollständig wird das Ticket endgültig geschlossen. Sollte es noch etwas zu tun geben kann demenstprechend der Status wieder auf „Open“ gesetzt werden.

Durch die Integration von Youtrack mit unserem Continuous Integration System können Tickets auch mit einer entsprechenden Commit-Message geschlossen und auf „Fixed“ gesetzt werden. Dazu wird mein Kollege Sebastian in Kürze einen Beitrag schreiben.

Stolpersteine und Verbesserungspotenzial

Nur ein „bisschen“ Issue-Tracking, Projektmanagement und Continuous Integration funktioniert nicht wirklich. Wir haben festgestellt, dass es äußerst wichtig ist wirklich alles im System abzubilden und einzutragen – nur so ist sichergestellt dass die Flut von Informationen und Änderungswünschen im Zaum gehalten wird und der Überblick nicht verloren geht. Kundenanfragen via Mail oder Telefon sollten direkt eingetragen und damit dokumentiert werden.

Bei „nur kurz“ oder „geht das“ Nachfragen tendieren wir im Team teilweise noch dazu das System zu umgehen. Ist eine Frage oder Änderungswunsch trivial erscheint es uns manchmal keinen Sinn zu machen diese als Ticket einzutragen. Dass man mit einer scheinbar kurzen Nachfrage die Kollegen unter Umständen unterbricht und aus der Konzentration bringt (kostet wie oben bereits beschrieben bis zu 30 Minuten Arbeitszeit) ist einem in der Situation nicht klar. Da müssen wir uns noch strikter an den Workflow halten.

Für Tätigkeiten, die nicht direkt einem Ticket zuordenbar sind oder mehrere Tickets umfassen, fällt es oft schwer den tatsächlichen Aufwand zu erfassen bzw. ist einem nicht sofort klar, dass ein eigenes Ticket erstellt werden sollte. Zum Beispiel beim Testen des gesamten Projekts vor Live-Schaltung.

Fazit

Keine Frage, das System ist bereits jetzt eine enorme Effizienzsteigerung für unseren internen Workflow. Wir wollen es alle nicht mehr missen. Aufgrund der Flexibilität von Youtrack ist sichergestellt, dass wir nach und nach mit den richtigen Stellschrauben unseren Workflow weiter ausbauen und optimieren.

The post Agiler Workflow statt Kommunikationschaos first appeared on Zensations.

Von Print zu Web

An dieser Stelle werde ich nicht auf die Geschichte von WYSIWYG eingehen, dazu gibt es auf Wikipedia genug nachzulesen. Eines gehört allerdings erwähnt: WYSIWYG-Editoren entspringen dem Printbereich und wurden nur aus einem Grund erfunden: Die mit Markup versehenen Texte waren unleserlich und nur wenige Menschen konnten sich das Layout des zu druckenden Dokuments auf den damaligen Mini-Bildschirmen vorstellen.

Darum entwickelte sich der erste nicht kommerzielle WYSIWYG-Editor von XEROX Parc zum heutigen MS Word und anderen Text-Editoren. Aufgrund der Tatsache, dass sich die Umsetzung interaktiver und responsiver Websysteme erst vor vergleichsweise wenigen Jahren etabliert hat und HTML einem durchschnittlichen Content-Redakteuer nicht zuzumuten war, hat sich die Benutzung von WYSIWYG-Editoren in der Content-Erstellung etabliert. Und wir auch heute noch gelebt. Weil bekanntes auch irgendwie bequem ist.

Eine falsche Editor-Anwendung ist kein Bug

Versteht mich nicht falsch, der WYSIWYG-Editor hat seine Daseinsberechtigung, allerdings nur, wenn der Redakteur einwandfrei mit Word einwandfrei umgehen kann (übrigens ein guter Test vorab). Leider ist das nicht immer der Fall und somit fängt man nur allzu leicht an auf der eigenen Website ein wenig Gott zu spielen und im Worst Case den gestalterischen “bad habbits” dabei freien Lauf zu lassen.

Gerade wenn mehrere Redakteure in einem System arbeiten, muss beim Einsatz von WYSIWYG-Editoren garantiert werden können, dass alle Benutzer die semantische Erstellung der Inhalte garantieren. Das bedeutet, Überschriften werden als H1, H2, H3 etc. ausgewiesen und nicht einfach bold markiert oder es wird der Schriftgrad erhöht. Abstände und Leerzeilen werden nicht eigenständig und nach Geschmack definiert und nicht benötigter Text wird gelöscht anstatt ihn weiß einzufärben (nur damit der Absatz nicht mehr „sichtbar“ist).

Ansonsten sind vermeintliche “Fehler im Design” vorprogrammiert. Nicht selten handelt es sich bei falscher Darstellung nicht um einen Bug, sondern um unsachgemäße Handhabung der zur Verfügung stehenden Funktionen. Durch das Zusammenspiel aus nicht validem HTML und der falscher Benutzung erhielt der Editor auch die Bezeichnung WYSIMOLWYG (What you see is more or less what you get).

Markdown als Alternative

John Gruber und Aaron Swartz haben vor zehn Jahren Markdown, einen Text-to-HTML Converter, der strukturell valides HTML erzeugt, entwickelt. Mit Hilfe eines simplen Syntax erstellen Redakteure ihren Content, der im Anschluss anhand des im CSS definierten Designs ausgegeben wird. Es stört weder den Schreib- noch den Lesefluss und ermöglicht im Vergleich zu reinen HTML- oder WYSIWYG-Editoren ein viel effizienteres Arbeiten, da man beinahe doppelt bis dreifach so schnell ist.

Durch Markdown Extensions, wie etwa Markdown Extra ist es zudem möglich Fußnoten, Tabellen, Kürzel und id/class Elemente anzulegen. Mehr benötigt man wirklich nicht mehr um einen Text zu formatieren. Durch die schnell zu lernenden Auszeichnungen wird zusätzlich eine semantische Denkweise gefördert. Und wer weiß schon, wann ein Relaunch geplant ist und eine Content-Migration bevorsteht. Mit hochwertigen HTML benötigt der Transfer kein mühsames Nachbearbeiten der Inhalte mehr.

Andere Editoren, wie der CKEditor rühmen sich damit, dass die grafische Benutzeroberfläche den kommenden WAI ARIA Guidelines der W3C entspricht. Schön und gut, aber Markdown benötigt nicht einmal das GUI zur Eingabe.

Wir verwenden standardmäßig Markdown als Content-Editor und zwar immer. In ganz wenigen Ausnahmen verlangen unsere Kunden vorab auch die Integration des WYSIWYG-Editors. Zum Einsatz kam dieser aber bisher noch nie. Natürlich klingt es am Bersprechungstisch nach einer großen Umstellung, dass das Layout und der Content getrennt werden und man als Redakteur nicht sieht, wie der finale Text auf der Website aussieht, während man ihn erstellt.

Aber es bietet eben auch jede Menge Vorteile. So zum Beispiel auch die Einbindung von Bildern in den Text. Einfach [Bild-Titel](Link zum Bild “Alt Text”) eingeben und fertig. Keine Beschäftigung mit dem Layout, garantiert makelloses responsive Design, effizienteres Arbeiten und weniger Verzweiflung in der Content-Wartung. Und wer weiß schon, wann ein Relaunch geplant ist und eine Content-Migration bevorsteht. Mit hochwertigen HTML benötigt der Transfer kein mühsames Nachbearbeiten der Inhalte mehr.

Auch die neue Blog Plattform Ghost setzt aus Gründen der Semantik und des validen HTML auf Markdown, wobei sich über den Splitscreen des Editors zur Eingabe in puncto mobile Tauglichkeit streiten lässt.

Falls ihr neugiergig geworden seid, dann testet Markdown doch einfach einmal anhand unseres Tools auf www.semantik.zensations.at. Nachstehend findet ihr Links zu Markdown Plugins und Modulen für die gängigsten CMS sowie die Slides zu meiner Präsentation. Welchen Editor nutzt ihr eigentlich und warum? Teilt mir einfach eure Erfahrungen mit, ich freue mich darauf!

Markdown Plugins & Module:

• Drupal: Markdown filter
• WordPress: WP-Markdown & Jetpack Markdown
• Joomla: ACE X Markdown Editor
• Typo3: Markdown für TYPO3

Welchen Editor nutzt ihr eigentlich und warum? Teilt mir einfach eure Erfahrungen mit, ich freue mich darauf!

Wolfgang Leitner ist Projektmanager bei Zensations und übt fleißig für das nächste Wuzzelturnier.

Und hier nun auch der #zentalk in der Kurzfassung mit den wichtigsten Punkten zu Markdown:

The post Markdown vs. WYSIWYG-Editor first appeared on Zensations.