Notes | Olaf Gleba

SVG Icon Sprites, Nunjucks, Gulp

Thu, 09 Mar 2017 08:41:00 +0100

Für die Einbindung von Icons nutze ich aus vielerlei Gründen extern referenzierte SVG Sprites, deren Fragmente im HTML über das <use> Attribut des <svg> Elements inline referenziert werden. Um redundante Schreibarbeit zu vermeiden und die Pflege deutlich zu erleichtern, bietet sich der Einsatz einer Template Engine an.

Worum es geht

Im folgenden Beitrag dreht sich alles um die Einbindung von Referenzen eines SVG-Sprites und wie man sich das (Arbeits)Leben durch Einsatz einer Template Engine (Nunjucks) und einem Gulp Workflow einfacher machen kann.

Nicht explizit beschrieben wird die Erstellung von SVG-Sprites (wäre was für einen weiteren Beitrag), Sinn und Zweck von Template Engines und/oder die Arbeit mit Gulp.

Wie es ist

Referenziert man ein SVG-Sprite im HTML Markup, kann das u.a. schon mal einiges an Tipparbeit (pro Referenz) bedeuten. Zumal, wenn wir - was obligatorisch sein sollte - Wert auf größtmögliche Zugänglichkeit des SVG legen.

HTML Markup:

<svg class="icon icon--huge icon-twitter" role="img" aria-labelledby="title-1668 desc-1668">
  <title id="title-1668">Titel...</title>
  <desc id="desc-1668">Beschreibung...</desc>
  <use xlink:href="assets/img/icon-sprite.svg#icon-twitter" />
</svg>

Das ist eine ganze Menge Markup für die Darstellung eines kleinen Icons.

Ja, aber: Ob und welche Attribute des oben gezeigtes Beispiel für ein Icon sinnvoll sind, bestimmt allein der Kontext, in dem sie verwendet werden.

In meinen bisherigen Projekten gab es bislang folgende Arten von Kontext:

Icon, das inhaltliche Bedeutung hat (nicht verlinkt)
Icon, das dekorativer Natur ist + Text (nicht verlinkt)
Icon, das dekorativer Natur ist (verlinkt)
Icon, das dekorativer Natur ist + Text (verlinkt)

Das bedingt sehr unterschiedliche Arten der Referenzierung, resp. welche Attribute wie und ob überhaupt gesetzt werden sollten:

1.) HTML Markup: Icon, das inhaltliche Bedeutung hat (nicht verlinkt)

<svg class="icon icon-smartphone" role="img" aria-labelledby="title-1668 desc-1668">
  <title id="title-1668">Smartphone</title>
  <desc id="desc-1668">Optimierte Darstellung für mobile Geräte</desc>
  <use xlink:href="assets/img/icon-sprite.svg#icon-smartphone" />
</svg>

2.) HTML Markup: Icon, das dekorativer Natur ist + Text (nicht verlinkt)

<svg class="icon icon-success" role="img" aria-hidden="true">
  <use xlink:href="assets/img/icon-sprite.svg#icon-success" />
</svg> 
Ihre Eingaben wurden erfolgreich gespeichert

3.) HTML Markup: Icon, das dekorativer Natur ist (verlinkt)

<a href="#0" title="Titel..." aria-label="Labeltext...">
  <svg class="icon icon-twitter" role="img">
    <use xlink:href="assets/img/icon-sprite.svg#icon-twitter" />
  </svg>
</a>

4.) HTML Markup: Icon, das dekorativer Natur ist + Text (verlinkt)

<a href="#0" aria-label="Labeltext...">
  <svg class="icon icon-twitter" role="img">
    <use xlink:href="assets/img/icon-sprite.svg#icon-twitter" />
  </svg>
  Twitter
</a>

Was wir wollen

Wie die vorigen Beispiele zeigen, müssen wir ggf. sehr unterschiedliches Markup schreiben. Je nach Kontext des Icons. Das bedeutet viel Tipparbeit, Anfälligkeit für Fehler und es wird mit zunehmenden Anzahl der Referenzen schwierig den Überblick zu behalten. Das muss anders gehen...

Eine Möglichkeit ist der Einsatz einer Template Engine*. Alle mir bekannten Engines beinhalten - teilweise unterschiedlich benannt - ähnliche Funktionalitäten: Partials, Includes und Macros.

Diese können wir nutzen, um das Markup der SVG-Sprite Referenzen in einer eigenen Template-Datei auszulagern und dann mit unterschiedlichen Parametern in unser Haupt-Template einzubinden.

Hugo Giraudel hatte diese Idee letztes Jahr schon beschrieben. Da ich nicht mit dem von ihm genutzten Static Site Generator Jeckyll arbeite, musste ich mich nach einer Alternative umschauen. Und habe mich für Nunjucks als Template Engine entschieden.

Jeckyll erlaubt in Includes eine Parameterübergabe, Nunjucks nicht. Mit den Macros, die Nunjucks bereitstellt, erreichen wir - wenn auch auf einem leicht anderen Weg - das gleiche Ziel.

*) Alternativ sind lokale Lösungen wie Snippets für den Lieblings-Editor denkbar

Macro anlegen, importieren und anwenden

Ein macro besteht aus einer Datei, die eine oder mehrere Funktionen enthält, welche dann beliebig oft im Haupt-Template genutzt werden können.

Für unser Anliegen reichen zwei Funktionen: mean und loose. Mit den beiden können wir die o.g. Szenarien abdecken (s. auch nächster Abschnitt).

Nunjucks Template: Macro (Datei: templates/macros/icon.nunjucks)

// s. 1. Icon, das inhaltliche Bedeutung hat (nicht verlinkt)

{% macro mean(file, title, desc, size, uid = randomHash()) -%}
<svg class="icon {% if size %}icon--{{ size }} {% endif %}icon-{{ file }}" role="img" {% if title or desc %}aria-labelledby="{% if title %}title-{{ uid }}{% endif %}{% if desc %} desc-{{ uid }}{% endif %}"{% endif %}>
{%- if title -%}
<title id="title-{{ uid }}">{{ title }}</title>
{%- endif -%}
{%- if desc -%}
<desc id="desc-{{ uid }}">{{ desc }}</desc>
{%- endif -%}
<use xlink:href="assets/img/icon-sprite.svg#icon-{{ file }}" /></svg>
{%- endmacro %}


// s. 2. Icon, das dekorativer Natur ist + Text (nicht verlinkt)
// s. 3. Icon, das dekorativer Natur ist (verlinkt)
// s. 4. Icon, das dekorativer Natur ist + Text (verlinkt)

{% macro loose(file, ariaHiddenStatus, size) -%}
<svg class="icon {% if size %}icon--{{ size }} {% endif %}icon-{{ file }}" role="img"{% if ariaHiddenStatus %} aria-hidden="{{ ariaHiddenStatus }}"{% endif %}><use xlink:href="assets/img/icon-sprite.svg#icon-{{ file }}" /></svg>
{%- endmacro %}

Um die Funktionen des Macros einsetzen zu können, müssen wir die Macro-Datei zuerst in das Haupt-Template importieren (vor dem Aufruf der Funktionen):

Nunjucks Template: Macro importieren (Datei: templates/index.nunjucks)

{% import 'macros/icon.nunjucks' as icon %}

Anschließend stehen die Funktionen des Macros zur Verfügung.

Nunjucks Template: Macro Funktionen anwenden (Datei: templates/index.nunjucks)

// Beispiele...

// s. 1. Icon, das inhaltliche Bedeutung hat (nicht verlinkt)
{{ icon.mean("smartphone", "Smartphone", "Optimierte Darstellung für mobile Geräte") }}

// s. 2. Icon, das dekorativer Natur ist + Text (nicht verlinkt)
{{ icon.loose("success", "true") }} Ihre Eingaben wurden erfolgreich gespeichert

Wird das Template nun gerendert, entspricht das generierte Markup dem HTML aus den Beispielen 1(eins) und 2(zwei).

Die beiden Macro-Funktionen im Detail

Aber der Reihe nach. Wann nutze ich welche Funktion (mean(), loose()) und was für Parameter stehen zur Verfügung?

icon.mean()

Es gibt für die Funktion mean() nur einen sinnvollen Anwendungsfall: Wenn ein allein stehendes Icon eine Aussage transportieren soll und nicht nur der Dekoration dient. Hier muss sichergestellt werden, dass assistive Geräte/Anwendungen die Bedeutung auch erfassen können (durch den Einsatz von "title" und "description").

Nunjucks Template: Macro Funktion mean()

// Mögliche Parameter
{{ icon.mean("[file]", "[title]", "[description]", "[size]") }}

// Es muss mindestens der Fragment ID (Parameter 'file') definiert sein (SVG-Sprite: <symbol id="[x]">)
{{ icon.mean("smartphone") }}

// Beispiele

// Parameter: file, title, description
{{ icon.mean("smartphone", "Smartphone", "Optimierte Darstellung für mobile Geräte") }}

// Parameter: file, title, description, size (Icon size modifier class (.`icon--huge`))
{{ icon.mean("smartphone", "Smartphone", "Optimierte Darstellung für mobile Geräte", "huge") }}

// Parameter: file, title, keine(!) description, size (Icon size modifier class (.`icon--large`))
{{ icon.mean("smartphone", "Smartphone", "", "large") }}

// Parameter: file, title
{{ icon.mean("smartphone", "Smartphone") }}

icon.loose()

Die Funktion loose() hingegen setzen wir in allen anderen Szenarien ein. In diesen (s. Beispiele) kann auf Titel und Beschreibung verzichtet werden, ohne das die Zugänglichkeit leidet.

Nunjucks Template: Macro Funktion loose()

// Mögliche Parameter
{{ icon.loose("[file]", "[ariaHiddenStatus]", "[size]") }}

// Es muss mindestens der Fragment ID (Parameter 'file') definiert sein (SVG-Sprite: <symbol id="[x]">)
{{ icon.loose("smartphone") }}

// Beispiele

// Parameter: file, ariaHiddenStatus
{{ icon.loose("success", "true") }}

// Parameter: file, ariaHiddenStatus, size (Icon size modifier class (.`icon--huge`))
{{ icon.loose("success", "true", "huge") }}

// Parameter: file, size (Icon size modifier class (.`icon--huge`))
{{ icon.loose("smartphone", "", "huge") }}

// Parameter: file
<a href="#0" title="Gehe zur Twitter Seite" aria-label="Gehe zur Twitter Seite">
  {{ icon.loose("twitter") }}
</a>

// Parameter: file
<a href="#0" aria-label="Gehe zur Twitter Seite">
  {{ icon.loose("twitter") }}
  Twitter
</a>

Nunjucks installieren und in Gulp integrieren

Das Module wird über über den Node.js Package Manager installiert,

Bash: Plugin installieren

$ npm install gulp-nunjucks-render --save-dev

dann im Gulpfile.js in einer Variable gespeichert,

Gulpfile: Plugin einbinden

var nunjucksRender = require('gulp-nunjucks-render');

die dann im neu anzulegenden Gulp Task genutzt wird.

Gulpfile: Der (vereinfachte) Gulp Task für das Templates Rendering

gulp.task('process:templates', function() {
  return gulp.src('templates/*.nunjucks')
    ...   
    .pipe(nunjucksRender({
      path: 'templates/',
      manageEnv: expandEnv
    }))
    .pipe(gulp.dest('app/'));
});

Wenn wir den Task jetzt allerdings über die Bash aufrufen würden ($ gulp process:templates), würde es eine Fehlermeldung hageln - schauen wir uns die Pipe Aufruf für nunjucksRender an, sehen wir, dass es einen Parameter mit Namen manageEnv gibt, dem eine Variable (expandEnv) zugewiesen ist. Eine Variable, die zum jetzigen Zeitpunkt weder initialisiert noch gefüllt ist.

Das holen wir jetzt in zwei Schritten nach: Zuerst fügen wir dem Gulpfile (vor dem Aufruf des Tasks) die folgende Funktion hinzu:

Gulpfile: Funktion erstellen/einfügen

/**
 * Generates random number
 * @return {string} random number
 */
function randomHash() {
    return Math.random()*0xfff|0;
}

Anschließend erweitern wir in einem zweiten Schritt die Laufzeitumgebung von Nunjucks mit der eben eingefügten Funktion:

Gulpfile: Die Laufzeitumgebung von Nunjucks mit der zuvor erstellten Funktion (`randomHash`) erweitern 

/**
 * Enhance nunjucks environment
 * @param {object} environment
 */
var expandEnv = function(environment) {
  environment.addGlobal('randomHash', randomHash);
}

Wozu brauchen wir das? Diese - jetzt global für Nunjucks verfügbare - Funktion erlaubt es eindeutige Element-IDs (uid) für jede Funktionsinstanz des Macros zu generieren (s. Quelltext des Macros, Markup-Ausgabe). Was zwingend erforderlich ist, um die Zugänglichkeit für assistive Geräte/Anwendungen zu gewährleisten.

Was es bringt

Deutlich weniger Aufwand in der Deklaration von SVG-Sprite Referenzen im Markup. Ein Blick auf die Quellcode-Beispiele sagt mehr als tausend Worte...

Vorher:

...
<svg class="icon icon-smartphone" role="img" aria-labelledby="title-1668 desc-1668">
  <title id="title-1668">Smartphone</title>
  <desc id="desc-1668">Optimierte Darstellung für mobile Geräte</desc>
  <use xlink:href="assets/img/icon-sprite.svg#icon-smartphone" />
</svg>

...

<a href="#0" aria-label="Gehe zur Twitter Seite">
  <svg class="icon icon-twitter" role="img">
    <use xlink:href="assets/img/icon-sprite.svg#icon-twitter" />
  </svg>
  Twitter
</a>

Nachher:

...
{{ icon.mean("smartphone", "Smartphone", "Optimierte Darstellung für mobile Geräte") }}

...

<a href="#0" aria-label="Gehe zur Twitter Seite">
  {{ icon.loose("twitter") }}
  Twitter
</a>

Workflow beschleunigen mit Browsersync

Wed, 16 Dec 2015 22:29:00 +0100

Für den Adventskalender der webkrauts habe ich einen zweiteiligen Artikel beigesteuert, der das Tool Browsersync vorstellt und dessen Einsatz in der Webentwicklung beschreibt.

Hier geht es zu Teil 1, hier zu Teil 2 des Artikels.

Das Ruby Begriffsuniversum kurz erklärt

Tue, 24 Nov 2015 12:19:00 +0100

RVM, gem, RubyGems, rbenv, Bundler etc.: Es gibt viele Begrifflichkeiten, die beim Kennenlernen von Ruby den Weg kreuzen. Ein kurzer Überblick über die wichtigsten Begriffe.

Ein Gem ist eine einzelne Ruby Bibliothek, die eine bestimmte Funktionalität bereitstellt und aus mehreren Dateien besteht. Weshalb im Zusammenhang mit gems oftmals auch von sog. Paketen die Rede ist. Ein Gem entspricht in etwa dem, was ein Modul für Node.js ist. In einem gem findet sich der Programmcode (.rb) sowie ggf. Testdateien. In einer gemspec-Datei werden allgemeine Informationen wie Name, Version, Lizenz etc. des gems definiert und der Inhalt der Bibliothek beschrieben. Im Gemfile wiederum werden die Bibliotheken gelistet, die ggf. für ein bestimmtes Projekt oder eine dezidierte Ruby Bibliothek zwingend erforderlich sind. Zusammen genommen sind die beiden Dateien (gemspec, Gemfile) mit einer package.json Datei im Node.js Kosmos vergleichbar.

RubyGems ist der Name des Package Managers für Ruby Bibliotheken. Mit ihm können gems installiert/entfernt werden ($ gem install <gem name>). RubyGems ist Teil von Ruby. Die unter RubyGems verlinkte Seite ist zugleich auch die erste Anlaufstelle, um installierbare Bibliotheken zu finden.

Bundler erleichtert die Installation und Verwaltung von gems und deren Abhängigkeiten. Basierend auf einem vorhandenen Gemfile lädt und installiert Bundler mit $ bundle install alle in dem Gemfile aufgelisteten gems. Bundler ist kein Teil von Ruby, sondern wird als gem installiert ($ gem install bundler).

RVM und rbenv sind beides Tools, um unterschiedliche Versionen von Ruby auf einem Rechner zu installieren und zu verwalten. Sie haben nichts mit der Installation und Aktualisierung von gems zu tun.

Man sollte Anfangs nicht zuviel wollen. Um erste Schritte zu machen, reicht dass Verständnis für gems und RubyGems vollkommen aus. Alles weitere kommt sowieso mit der Zeit.

Augenfreundliche NPM Informationen

Mon, 23 Nov 2015 12:44:00 +0100

Jeder, der sich einen Überblick über bspw. installierte Node-Module verschaffen will und dies mit $ npm ls versucht, wird erschlagen von Informationen, da ls ohne Parameter sämtliche abhängig installierten Module ebenfalls anzeigt. Das lässt sich leicht eingrenzen.

Hierzu nutzt man die Konfigurationsoption depth, mit dem die maximale Anzahl an Ebenen der abhängig installierten Libraries bestimmt wird Mit der Angabe 0 werden keine Abhängigkeiten angezeigt:

$ npm ls --depth=0

Die Begrenzung der Anzeigetiefe ist ebenfalls interessant um sich übersichtlich anzeigen zu lassen, für welche Module neuere Versionen im NPM-Repository existieren:

$ npm outdated --depth=0

Will man die Anzeige auf veraltete Module beschränken, die im globalen Scope installiert sind, setzt man den entsprechenden Flag:

$ npm outdated --global --depth=0

Ref: NPM-Dokumentation (ls), NPM-Dokumentation (outdated).

Disabled ist nicht gleich Readonly

Wed, 11 Nov 2015 11:30:00 +0100

Möchte man in einem Processwire-API-Formular den Wert einen Feldes dynamisch vorbelegen, der zudem nicht vom Benutzer änderbar sein darf, sollte man auf ein kleines Detail acht geben.

Folgendes Szenario:

Ich hole mir einige Information aus der Datenbank, die ich anschließend im Formular nutzen möchte.

$meetings = $pages->get("parent=/tools/meetings/);

Ein Wert im Array $meetings ist ein einfacher Datums-String ($meeting_date). Ein bestimmtes Feld des Formulars soll nun mit diesem Wert vorbelegt werden.

$field = $modules->get("InputfieldText");
$field->label = "Datum";
$field->attr('value', $meetings->meeting_date);
$field->attr('id+name','meeting_date');
$form->append($field);

Damit der Benutzer den Wert des Feldes nicht anpassen kann, ergänze ich es durch ein entsprechende HTML5 Attribut, dass mir spontan sinnvoll erscheint:

$field->attr('disabled', 'disabled');

Das Attribut disabled wird von Processwire sehr wörtlich genommen, bzw. korrekt angewendet. Was dann dazu führt, dass das Formularfeld beim ersten Rendern mit den dynamischen Variablenwert befüllt wird, nach Verarbeiten des Formulars (nach einem Submit) allerdings leer ist.

Was Sinn macht, habe ich das Feld ja auch mit dem Attribut disabled versehen und das Formular somit angewiesen, dieses Feld in der Verarbeitung zu ignorieren. Hm...

HTML5 bietet für nicht bearbeitbare Formularfelder zwei Attribute: disabled und readonly...

... genau, readonly repräsentiert exakt das, was ich erreichen will. So funktioniert es:

$field = $modules->get("InputfieldText");
$field->label = "Datum";
$field->attr('value', $meetings->meeting_date);
$field->attr('id+name','meeting_date');
$field->attr('readonly', 'readonly');
$form->append($field);

Damit das Feld nach Verarbeitung des Formulars (sei es durch einen erfolgreichen Submit oder das erneute Rendern im Falle eines aufgetretenen Fehlers) weiterhin dynamisch befüllt wird und trotzdem vom Benutzer nicht änderbar ist, ist das Attribut readonly die richtige (und einzige) Wahl.

Große Logs zeilenbasiert per $ tail einlesen

Thu, 01 Oct 2015 17:57:00 +0200

Es gibt ja lustige Provider, die die Logs (error oder/und access) nicht wenigstens monatlich aufräumen, zippen und als Archiv irgendwo hinschieben. So muss man gelegentlich mit Log-Dateien arbeiten, die mehrere Gigabyte groß sind. Um den Lieblings-Texteditor nicht zu verärgern, hilft hier ein Wechsel in die Bash und - für einfache Szenarien - der Textfilter tail.

Zumindest wenn es um Brot-und-Butter Probleme geht, wie eine Webseite die plötzlich nur noch als weiße Leinwand daher kommt, ist ein schneller Blick ins error.log des Servers von Nöten.

Logs im Giga-Bereich in einem Texteditor zu öffnen ist zumeist eher ein holpriges Vergnügen (wenn es überhaupt geht). Der Umweg über die Bash bietet sich an. Mit Hilfe des Textfilter tail, der auf allen unixbasierten Betriebssystemen zur Verfügung steht, ist dies eine Sache einer Zeile:

$ tail -n [X] /pfad/zur/Datei

Das [X] steht hier für die Anzahl der Zeilen, die man anzeigen lassen möchte. Wobei der Zeiger vom Ende Richtung Anfang der Datei zählt. Folgendes Beispiel also liest die letzten 100 Zeilen der Datei aus:

$ tail -n 100 /pfad/zur/Datei

Die Beispiele eigenen sich natürlich nicht für ein gezieltes Durchsuchen der Logs. Bei aktuellen Problemen, für die zumeist nur die letzten Einträge relevant sind, kann die Methode aber durchaus hilfreich, bzw. ausreichend sein.

Let it flow, mate

Fri, 31 May 2013 01:21:00 +0200

Im Zuge einer als Hilfestellung gedachten E-Mail, die ich nach Ablauf meiner Mitarbeit an einem sog. Responsive Projekt an den verantwortlichen Mitarbeiter der Agentur schrieb, wurde mir wiederholt deutlich, wie grundlegend sich der Workflow in derartigen Projekten von dem – immer noch sehr verbreiteten – Wasserfallprinzip unterscheidet. Und zwingend muss.

Responsive Web/Design im Abriss

Das Web an sich ist responsive. Eine ursprüngliche Intension der Hypertext Markup Language war/ist die Anzeige von Inhalten unabhängig von bestimmten Viewports/Geräten.

Die Einführung von fixen Layouts hat genau das pervertiert. Just war Web == Computer-Desktop, bzw. Computer-Monitor mit dezidierten Viewports. Und lange Zeit deckte sich die Annahme auch mit der Realität, respektive den technischen Möglichkeiten. Diese Realität haben Entwickler sowie Kunden über all die Jahre erlernt und vollständig verinnerlicht.

Im Grunde geht es beim Responsive Design um nichts anderes, als genau diese Denkweise zu durchbrechen und der ursprünglichen Intension von HTML wieder mehr Raum zu geben: Der Viewport- und geräteunabhängige Darstellung von Inhalten.

Denkweisen (Device-Driven, Content-Driven)

Erstaunlicherweise scheint es, dass auch in progressiven Entwicklerhirnen das Denken in fixen Viewports noch nicht ganz ausgestorben ist. Responsive Design wird oft verstanden als die Optimierung einer Webseite auf bestimmte Viewports von Geräten, die gerade aktuell sind. So findet man überall die üblichen Verdächtigen an media queries (320px, 768px, 1024px etc.pp), die sich an den aktuellen Platzhirschen auf dem Gerätemarkt orientieren. Der Fokus liegt in erster Linie auf einen bestimmten Zustand der Darstellung (Viewport) eines jeweiligen Gerätes.

Wodurch wir uns dann im Grunde mit den gleichen Problemen rumschlagen müssen wie zuvor bei den fixen Pixel-Layouts…

Nicht nur, das die unter dieser Prämisse erstellten Seiten heutzutage schneller veralten, als die Agentur/der Kunde “iphone/Galaxy” sagen kann (Stichwort: Marktzyklen),- wir erheben es faktisch zum Prinzip, den Großteil der Besucher/Geräte da draußen mit einem Achselzucken einfach als “unbekannt/nicht verifizierbar” sich selbst und ihren Möglichkeiten der Darstellung zu überlassen.

Im Web geht es um eine adäquate Darstellung von Inhalten. Unabhängig vom Ausgabegerät. Salopp gesagt: Wir sollten die Viewports dezidierter, bekannter Geräte vergessen, an Design vorerst gar nicht auch nur denken, die Inhalte/Komponenten der geplanten Seite genau studieren, inhaltliche HTML-Protoypen bauen, uns anschauen, wie sich die Inhalte in verschiedenen Viewports verhalten und auf dieser Grundlage konzeptionelle Entscheidungen treffen, welche Breakpoints an welcher Stelle sinnvoll sind.

Soweit das Ideal. All das oben gesagte wirft natürlich – gerade im Agenturalltag – viele Fragen auf: In welcher Form ist das mit den derzeitigen Projekt- und Entwicklungsabläufen umsetzbar? Muss der Designer jetzt HTML/CSS können? Wie erkläre ich dem Kunden, warum er nicht eine gemalte, grafisch bis ins Detail ausformulierte Ansicht seiner fertigen Webseite vor Begin der Produktion bekommt? Wie binde ich ihn ein in den Entwicklungsprozess?

Responsive Web ist nicht einfach. Im Gegenteil,- es ist komplex und kann zu Anfang ziemlich anstrengend sein. Man muss neue Wege gehen und immer wieder Entscheidungen in der laufenden Entwicklung treffen. Und – das muss man klar so sehen – es ist zumindest so lange zeit- und budgetaufwändiger, bis sich die veränderten Arbeitsweisen im Team etabliert haben. Zudem ist es schwer mit den gewohnten Konventionen zu brechen, die sich in der Vergangenheit vermeintlich bewährt haben (das gilt für Kunden ebenso).

Aufgabenverteilung im Team

Ein großer Unterschied zu konventionellen Projekten ist die Notwendigkeit die Rollen/Aufgabenteilung im Team neu zu definieren. Diese sind bislang in der Regel klar verteilt sind: Man hat einen Designer, der sich ausschließlich auf die Erstellung grafischer Mockups/Assets konzentriert und im Detail wenig/nichts über technische Beschränkungen oder Bedingungen der (responsive) HTML-Welt weiß. Und den Webentwickler, der die Designs in valides, voll zugängliches und effizientes HTML/CSS Markup verwandeln soll. Beide arbeiten im Kern mehr oder weniger unabhängig von einander (und i.d.R. auch nacheinander).

Dieses Wasserfallprinzip (Konzept -> Design -> Frontend -> Backend -> Release), funktioniert bei Responsive Projekten nicht, bzw. führt fast zwangsläufig in für alle schmerzhafte Sackgassen. In solchen Projekten ist es schon in der Konzeptionsphase zwingend erforderlich, technische Details zu berücksichtigen und inhaltliche Entscheidungen zu treffen. Mit einer konventionellen Arbeitsteilung, die einzelne Aufgaben der Reihe nach abarbeitet, ist dies nicht erreichbar.

Zugespitzt gesagt: der Designer in einem solchen Projekt muss technische Kenntnisse haben, wie sich Markup im HTML-Flow verhält und wo es technische Fallstricke gibt etc.pp. Aber er kann nicht Experte für alles mögliche gleichzeitig sein: Typografie, UX – und Interfacedesign, HTML, CSS etc.pp.

Der Workflow in Responsive Projekten ist dem Prinzip der agilen Webentwicklung sehr ähnlich. In beiden ist das interdiziplinäre Teamwork von größter Bedeutung. Projektleitung, Kunde, Texter, Designer und Entwickler müssen eng zusammenarbeiten. Die Arbeitsabläufe laufen nicht linear nacheinander ab, sondern bewegen sich in kurzen Zyklen, an deren Ende immer wieder getestet, Lösungen evaluiert und eruiert und gemeinsam Entscheidungen getroffen werden.

Grafische oder HTML Mockups?

Das führt unweigerlich zur Frage: Wie soll ein Designer einen technisch umsetzbaren Layoutentwurf erstellen, der alle Eventualitäten und Besonderheiten von Responsive Design Techniken vorausschauend berücksichtigt? Die Antwort ist so schlicht wie wichtig: Gar nicht!

Es ist unmöglich am Anfang eines Projektes (das ist i.d.R. ja der Zeitpunkt, an dem der Designer sein Grafikprogramm startet) die technischen sowie inhaltlichen Anforderungen zu berücksichtigen,- sie sind zu dem Zeitpunkt noch gar nicht bekannt. Auch macht es keinen Sinn, Stunden, Tage an Arbeitszeit damit zu verschwenden, um etwas zu erstellen, dass trotz größter Sorgfalt und fantastischen Einfällen trotzdem immer nur eines bleibt: ein Bild. Etwas, das nichts mit dem Medium zu tun hat, in dem das Ergebnis unserer Arbeit stattfinden wird.

Das ist auch des Pudel’s Kern: Wir entwickeln Webseiten/Webanwendungen. Demzufolge ist es naheliegend und sinnvoll sobald als möglich direkt in dem Medium zu arbeiten, in dem unsere Arbeit konsumiert wird/funktionieren soll. Das, was häufig als Design im Browser bezeichnet wird, bedeutet im Grunde nichts anderes, als dass wir zu dem frühstmöglichen Zeitpunkt der Entwicklung damit beginnen sollten, HTML-Prototypen zu bauen. Wir sollten keine Zeit (und somit Geld) dafür verschwenden, komplexe, statische Designs mühevoll in HTML nachzubauen. Um dann mitten in der Arbeit festzustellen, dass einzelne Designideen schlicht nicht funktionieren im HTML-Flow. Oder/und sich einfach als nicht benutzerfreundlich herstellen. Wie will man anhand einer statischen Grafik die Usability/UX einer Webseite testen, bzw. bewerten?

All das heißt übrigens nicht, dass Photoshop (oder besser: Fireworks) im Schrank und der Designer zu Hause bleiben kann ;-). Ich selber bspw. brauche grafische Scribbles um mir einen visuellen Eindruck machen zu können, ob ein Design in sich stimmig ist. Das möchte ich nicht erst im Prozess später entscheiden. Und es kann ebenfalls hilfreich sein, mit Hilfe von grafischen Wireframes an bestimmten Punkten der Entwicklung visuelle Ideen auszuprobieren. Auch initiale Sketches werden ggf. benötigt. Ob diese in einem Grafikprogramm oder mit Zettel und Stift erstellt werden, ist allein abhängig, womit man sich wohl fühlt.
Aber der Designer malt nicht mehr die Mastervorlage, an dem sich dann alle weiteren Entwicklungsschritte orientieren (müssen).

Alles schön und gut, aber der Kunde will sehen, wie seine Seite aussehen wird

Ein Knackpunkt, dem man bei richtiger Kommunikation (gerade bei größeren Auftraggebern) und Techniken oft beikommen kann.

Anstatt dem Kunden am Beginn des Projektes grafisch vollständig ausformulierte Layouts zu präsentieren, ist es sinnvoller mit sog. Style tiles zu arbeiten. Style tiles konzentrieren sich auf die grundsätzliche visuelle Sprache, die im Gespräch mit dem Kunden in einem ersten Schritt entwickelt wird. Abgebildet werden bspw. Farben, Schriften, einzelne Interface-Elemente die Relevanz für die CI haben, Link-Auszeichnung etc.pp. Diese Datei bildet die gestalterische Blaupause im späteren Designprozess.

Das wichtigste hieran: Das Design wird von der Entwicklung entkoppelt. Der Kunde erwartet in diesem Ansatz nicht eine 1:1 Umsetzung eines ausformulierten, grafischen Designs, wenn er einen HTML Entwicklungsstand gezeigt bekommt. Präsentiere ich dem Kunden zu Anfangs ein detailiertes, gemaltes Design, wird der Kunde immer enttäuscht sein bei Ansicht eines beliebigen Entwicklungsstandes. Einfach aus dem Grund, dass er – bewusst oder unbewusst – kontinuierlich vergleicht zwischen dem Bild, das ihm vorliegt und der aktuellen Ansicht des Prototypen. Er wird immer die Defizite sehen…

Ein beispielhafter Workflow und die daraus entstehenden Vorteile für das Team und den Kunden folgt in einem folgenden Beitrag.

Terminal, Zeilenumbruch und $ git diff

Tue, 02 Apr 2013 19:23:00 +0200

Arbeitet man unter OS X im Terminal mit Git, fällt auf, dass bei einem $ git diff kein Zeilenumbruch entlang der Fenstergröße erfolgt. Eine Möglichkeit, dies zu erreichen, ist die Anwendung des Kommandozeilen-Programm's less als Pager.

In der Standardinstallation von OS X ist das Kommandozeilen-Programm less bereits enthalten. Um die Nutzung des less Pager permanent zu machen, erweitert man die Globalen Optionen von Git um einen weiteren Eintrag.

Dieses kann man im Terminal mit der folgenden Zeile erreichen:

$ git config --global core.pager 'less -+S'

Oder man trägt ihn händisch in der Git config Datei ein:

[core]
  core.pager = less -+S
  ...

Die Option -+S des less Programm's macht in dem Fall nicht anderes als die Zeilen der $ git diff Ausgabe auf die jeweilige Fensterbreite des Terminals zurecht zu stutzen.

"It’s like in sex"

Mon, 01 Apr 2013 19:07:00 +0200

Ab und zu hat man das Glück, den richtigen Spruch zur richtigen Zeit zu lesen,- und das Lächeln vom Morgen wieder ins Gesicht zu bekommen.

Diesmal bin ich Johann Brook zu Dank verpflichtet.

Classes in your markup is fine. Just don’t abuse it, keep a sane balance. It’s like in sex: if it feels good, it’s probably totally okay to do.