YellowLeds Weblog v2

Web ≠ Print – So geht es auch

nospam@example.com (Matthias Mees) — Wed, 16 May 2012 15:50:00 +0200

Es ist nichts Neues, dass die Zusammenarbeit zwischen Webdesignern und Print-Grafikern mitunter etwas schwierig ist. Da treffen zwei Welten aufeinander, die zusammenarbeiten sollen, aber andere Werkzeuge benutzen und unterschiedliche Sprachen sprechen. Der Kollege Marc Hinse hat dazu mal den schönen Artikel Web ≠ Print verfasst.

Ich hatte neulich™ das Vergnügen, einem vorbildlichen Gegenbeispiel zu begegnen.

Ich bat im Gespräch mit dem Kunden um die Kontaktdaten der Grafikerin, die das Logo entworfen hatte, um ggf. Rückfragen zur verwendeten Schriftart und Farbcodes klären zu können. Antwort: „Aber das haben wir doch alles da.“ Man versprach, mir eine PDF-Datei zukommen zu lassen.

Was ich bekam, war – vorbildlich.

Neben dem Logo wies die PDF-Datei die darin verwendete Schriftart inklusive aller verwendeten Schriftschnitte (nebst Schriftprobe) aus und listete sämtliche verwendete Farben auf, und zwar jeweils als:

(Und jetzt merke mir bitte niemand in den Kommentaren an, dass da noch Hex- und HSL-Farbcodes fehlen. Ja, websichere Farben sind heutzutage bedeutungslos.)

Das ist alles, was man als Webdesigner an Informationen zu einem Logo braucht. Ein solches Infoblatt spart dem Webdesigner eine Menge Zeit, vor allem dann, wenn Printler auf die Frage nach den verwendeten Farben nur die (für sie wichtigen, für uns aber völlig irrelevanten) Pantone-Farben benennen können oder offenbar wahllos Schriften einsetzen, ohne sich um Aspekte wie Webfonts und Schrift-Lizenzen auch nur Gedanken zu machen. (Ja, das sind leider echte Praxisbeispiele aus anderen Projekten.)

Ein solches PDF sagt: „Ich weiß, dass Andere meine Arbeit weiterverarbeiten. Deshalb dokumentiere ich sie sorgfältig.“ Ich habe der Kollegin dafür ausdrücklich gedankt. Und ich möchte so etwas jetzt in jedem Projekt haben.

7 Books Apart

nospam@example.com (Matthias Mees) — Sun, 13 May 2012 17:12:00 +0200

Ich habe schon sehr lange vor, Rezensionen der Bücher aus der Reihe A Book Apart zu schreiben – mittlerweile umfasst die liebevoll gestaltete Reihe „Kurze Bücher für Leute, die Webseiten machen“ sieben Bände, ein achter (auf den ich für meinen Teil wahnsinnig gespannt bin, dazu später mehr) ist für 2012 bereits angekündigt.

Alle sieben Exemplare widmen sich in überschaubarer Länge (83 bis 150 Seiten) einem Thema aus dem Bereich Webdesign. Zielgruppe sind also ausdrücklich nicht Einsteiger, sondern Webworker, die bereits „im Thema“ sind und es auffrischen bzw. auf den aktuellen Stand bringen möchten.

Die Aktualität ist – wie immer bei Printerzeugnissen in unserem Bereich – natürlich so eine Sache, zumal die wirklich ansprechende, sorgfältig Gestaltung der Bücher eine zeitnahe Veröffentlichung schwierig macht.

Disclaimer: Ich besitze und kenne nur die Print-Versionen der Bücher, höre aber wundervolle Dinge über die E-Book-Ausgaben (PDF, ePub, mobi). Über ergänzende Kommentare zu diesen würde ich mich sehr freuen.

Zu den Büchern im Einzelnen:

Jeremy Keith: HTML5 For Web Designers

leistet genau das, was der Titel aussagt. Es geht hier um den Teil von HTML5, den Designer benutzen: Medien-Elemente wie natives Audio und Video (aber auch canvas), neue semantische und Formularelemente. Mittlerweile stellenweise natürlich nicht mehr auf dem aktuellsten Stand, aber nach wie vor ein guter Schnelleinstieg in HTML5.
Dan Cederholm: CSS3 For Web Designers

trifft eine gute, praxisorientierte Auswahl an Eigenschaften von CSS3, die zum Zeitpunkt der Erscheinens noch relativ „frisch“ waren und mittlerweile problemlos verwendbar sind. Dan zeigt anhand eines Demo-Projektes u.a. Transitions und Transforms, die Vewendung multipler Hintergrundgrafiken und Gestaltung von Formularen. In dieser Kompaktheit erstaunlich umfassend, aber natürlich ebenfalls stellenweise nicht mehr ganz up to date.
Erin Kissane: The Elements Of Content Strategy

entlockte mit ein „Content was?“. Content Strategy ist ein recht junges Thema, das schwer eindeutig einzugrenzen ist. Es ist aber gar nicht Anspruch dieses Buches, es umfassend abzudecken. Es bietet vielmehr Denkanstöße und Techniken dazu, wie man die planvolle Strukturierung und Verwaltung (großer Mengen) von Inhalten angehen kann. Mir persönlich war das Ganze beim ersten Lesen einen Hauch zu abstrakt.
Ethan Marcotte: Responsive Web Design

ist meines Wissens bis heute das einzige gedruckte Werk zu Responsive Web Design. Es erklärt nicht nur die drei Kerntechniken (flexibles Grid, flexible Grafiken, Media-Queries) anhand eines Beispielprojektes, sondern verdeutlich vor allem das für diese Technik notwendige Umdenken sehr klar. Wegweisend, auch wenn es mittlerweile Hilfstechniken gibt, die hier aufgrund des Erscheinungsdatums des Buches noch nicht angesprochen werden.
Aarron Walter: Designing For Emotion

versucht sich daran, zu erklären, wie man über das Design einer Seite „den Menschen erreicht“, somit letztlich also eine Marke prägt und über psychologische Faktoren Erfolge erzeugt. Etwa so abstrakt, wie sich das anhört, ist das ganze Thema ohne die gut gewählten Fallbeispiele des Buches zu erfassen. Leider verliert es sich aus meiner Sicht sehr in diesen Beispielen, ohne wirklich konkret zu werden.
Luke Wroblewski: Mobile First

leidet für meine Begriffe leider sehr unter der Kompaktheit des Buches. Mobile Webseiten und Apps sowie die Anforderungen der Benutzer an sie sind ein hochkomplexes Thema, zu dem man erheblich dickere Bücher schreiben könnte und sollte. Angesichts des explodierenden Markets für mobile Endgeräte ist aber auch Frage, ob man dieses Thema überhaupt in Buchform halbwegs aktuell erfassen kann – ich glaube: Nein. Als Einstieg geeignet, mehr jedoch nicht.
Mike Monteiro: Design Is A Job

erklärt die geschäftlichen Aspekte des (Web-)Designs. Interessant sind dabei weniger die konkreten Inhalte (Akquise, Finanzielles, Rechtliches), die es behandelt (zumal diese mitunter ohnehin schwierig auf Deutschland oder Europa übertragbar sind), sondern vielmehr die grundsätzliche Einstellung zum Job, die dieses Buch (in unvergleichlich direkter, sehr unterhaltsamer Weise) vermittelt, die es wirklich lesenswert machen. Und natürlich ist es ein sehr beliebtes Thema, zu dem es viel zu wenig Literatur gibt.

Dazu soll noch im Jahr 2012 Jason Santa Maria: On Web Typography kommen, auf das ich sehr gespannt bin – Jason ist der kreative Kopf (nicht nur) hinter TypeKit, hat alle bisherigen Bücher der Reihe gestaltet und ist ein ausgewiesener Experte in Sachen (Web-)Typografie. Von Band 8 dürfen wir uns Einiges erwarten.

Fazit

Alle bisher erschienen Bände der Reihe eignen sich bestens als Schnelleinstieg in das jeweilige Thema, können es aber naturgemäß nicht allumfassend und auf dem ganz aktuellen Stand der Zeit behandeln. Die üblicherweise 18 US-Dollar (plus 9 US-Dollar Versand) bzw. 9 US-Dollar für die E-Book-Pakete sind sie in jedem Fall absolut wert, zumal A Book Apart diverse Rabattmöglichkeiten anbietet.

s9y 1.6.1 oder: 2k11 wird stable

nospam@example.com (Matthias Mees) — Tue, 08 May 2012 11:09:00 +0200

Garvin hat heute Serendipity 1.6.1 veröffentlicht. Während der Release primär zwei Sicherheitslücken fixt, ist es zudem die erste s9y-Version, die 2k11, das mögliche neue Standard-Template für s9y, enthält. Das bedeutet auch, 2k11 wird in gewisser Weise „stable“.

2k11? Hä?

Sollte jemand von 2k11 noch nichts mitbekommen haben, empfehle ich die Ausgaben #9 und #13 des s9y Infocamps sowie den Artikel Fragen und Antworten hier im Blog.

Wieso „stable“?

Es ist generell in nächster Zeit mit relativ wenig Entwicklung an 2k11 zu rechnen – zum einen ist es mittlerweile relativ weit gediehen, zum anderen habe ich (beruflich wie auch innerhalb der s9y-Entwicklung) andere Brocken auf dem Teller.

Irgendwann™ soll 2k11 einen kompletten CSS-Rewrite bekommen, der dann respond.js entbehrlich machen soll, aber das ist nicht ganz trivial, zumal es eine Runderneuerung des user.css-Generators nach sich ziehen wird.

Außerdem ist nun, da 2k11 nicht mehr nur über GitHub zu haben, sondern Teil des Download-Paketes ist, mit deutlich mehr Nutzern und damit mehr Tests, Bugs und Anfragen im Allgemeinen zu rechnen. In der (Frei-)Zeit, die ich für Community-Arbeit abzwacken kann, möchte ich mich zunächst eine Weile darauf konzentrieren.

Selbst wenn das (hier Stoßgebet einfügen) glatt läuft, werde ich mich dann aber vermutlich zunächst darauf konzentrieren, 2k11 fit für den Einsatz als Standard- oder gar Default-Template zu machen.

„Ich nutze 2k11 schon. Muss ich etwas ändern?“

Es kommt (wie immer) darauf an. Wer unbedingt weiter am „bleeding edge“ bleiben möchte oder den Mechanismus, 2k11 über GitHub zu aktualisieren, einfach bequemer findet, kann das tun. (Das in s9y 1.6.1 enthaltene 2k11 entspricht der – derzeit aktuellen – GitHub-Version 1.1.7.)

Wer etwas „sicherer“ gehen möchte, ohnehin das Updaten über GitHub umständlich fand oder gar nicht auf dem letzten Stand ist, kann auf die enthaltene Version wechseln – beide Versionen sind problemlos nebeneinander installierbar, solange man das Verzeichnis der GitHub-Version (wie empfohlen) gar nicht oder in s9y-2k11 umbenannt hat. Die enthaltene Version liegt in /templates/2k11/.

Falls Ihr wechseln wollt, denkt bitte daran, eventuell vorgenommene Änderungen, zusätzliche Grafikdateien und/oder Eure user.css ins Template-Verzeichnis der „Core-Version“ zu übernehmen. Zusätzliche Dateien (die nicht in 2k11 enthalten sind) wie z.B. eine user.css sind updatesicher, d.h. sie werden im Fall eines s9y-Updates nicht überschrieben. Hacks an 2k11-Dateien müsst Ihr natürlich sichern und im Fall eines s9y-Updates rückportieren – das wäre aber in der GitHub-Version auch so.

Eure 2k11-Einstellungen in den theme options werden natürlich nicht übernommen – mit Ausnahme der Navigationslinks, da 2k11 die (noch relativ) neue Core-Navigation nutzt. Es ist empfehlenswert, bei einem Wechsel die GitHub-Version nicht direkt zu löschen, damit man zur Not zurückschalten kann, sollte wider Erwarten doch irgendwo der Fehlerteufel stecken.

Ich hoffe, ich habe nichts vergessen. Ansonsten gilt wie immer: „Bei Fragen – fragen.“

Nachtrag: Mit dem letzten commit habe ich jetzt noch schnell dafür gesorgt, dass sich die GitHub-Version in der Template-Liste künftig als 2k11-dev zeigt, damit man es klarer unterscheiden kann. (Ja, darauf hätte ich früher kommen können. Ja, ich werde vermutlich irgendwann bei einem Übertrag ins Core-Repository vergessen, das zu ändern.)

Modernizr: API

nospam@example.com (Matthias Mees) — Sat, 03 Mar 2012 09:11:00 +0100

Zum Abschluss der kleinen Reihe über Modernizr noch ein paar Dinge, die vielleicht über den alltäglichen Einsatz hinausgehen oder nicht für jeden Webentwickler interessant sind – API-Methoden und Möglichkeiten, Modernizr zu erweitern.

Prefixed

Hersteller-Präfixe in CSS sind ein (derzeit) viel diskutiertes Thema. Wie alle anderen CSS-Eigenschaften gibt es auch für diese ein Äquivalent in Javascript, allerdings etwas anders implementiert: Ohne Bindestrich und case-sensitiv. In Javascript wird also aus -moz-transform z.B. MozTransform.

Die Methode Modernizr.prefixed ermöglich es, auf das vom jeweiligen Browser benutzte Präfix zu testen und somit zur Laufzeit nur auf dieses zu reagieren – was eine Menge Code einsparen kann. Die Methode liefert die vollständige Präfixform in Javascript-Format als String zurück. Sie kann noch etwas mehr, auf das ich hier allerdings nicht weiter eingehen möchte – es gibt aber einen sehr ausführlichen ausführlichen Artikel von Andi Smith dazu.

Media Queries

Gerade in Zeiten des Responsive Web Design kann es absolut Sinn machen, Skripte in Abhängigkeit von bestimmten Dimensionen des Bildschirms auszuführen – also im Prinzip das zu tun, was Media Queries in CSS leisten. Das geht etwas primitiver bereits in nacktem Javascript, indem man screen.width abfragt, aber Modernizr.mq stellt hier als Javascript-Methode etwas mehr bereit.

Es testet ein als String übergebenes Media Query, welches einen Typ enthalten sollte und einen Wert enthalten muss, also z.B. Modernizr.mq('only screen and min-width:480px'), zur Laufzeit gegen den aktuellen Zustand des Browserfensters und liefert true/false zurück.

(Und genauso kann man natürlich auch andere Werte des Modernizr-Objektes als Testbedingungen in Javascript verwenden.)

Erweiterungen schreiben

Wer Modernizr erweitern möchte (so weit überhaupt noch nötig, siehe unten), findet auch dafür einige API-Methoden vor. Ich spare es mir, das entsprechende Beispiel aus der Modernizr-Dokumentation hier zu zitieren – angesichts der bereits zur Verfügung stehenden Community-Erweiterungen wird es vorerst kaum nötig sein, eigene zu schreiben.

Falls doch, bietet die API Methoden, um Tests anzulegen (wobei sich die API um das Anlegen der CSS-Klassen und Werte im Modernizr-Objekt kümmert), das so erzeugte Test-Element auf Styles und Events zu testen und dabei auch Browser-Präfixe zu berücksichtigen.

Unerkennbares

Es gibt Features, die Modernizr aus technischen Gründen nicht erkennen kann – die sogenannten Undetectables, die im Modernizr-Wiki in einer Liste gesammelt werden. (Dort findet man auch eine Liste der empfehlenswerten Polyfills.)

Community-Erweiterungen

Es gibt bereits eine Vielzahl von Erweiterungen für Modernizr aus der Community (Stand März 2012: 74). Diese liegen auf GitHub, lassen sich jedoch viel einfacher über den Download-Builder in Modernizr integrieren. Ebenso müssen die API-Methoden zur Nutzung von Prefixed (nicht aber für Media Queries) und zum Schreiben eigener Erweiterungen auf diese Weise ausdrücklich eingebunden werden.

Modernizr: Load

nospam@example.com (Matthias Mees) — Thu, 01 Mar 2012 09:26:00 +0100

Wie im Grundlagen-Artikel bereits angedeutet halte ich den integrierten Script-Loader mittlerweile für die wichtigere Komponente in Modernizr. Bevor wir uns den Loader genauer ansehen nochmals der Hinweis: Er wird nur in generierte Versionen eingebunden, die Entwicklerversion (die z.B. auch im HTML5 Boilerplate enthalten ist) kommt ohne Loader daher.

Warum überhaupt ein Script Loader?

Zunächst mal ist Modernizr.load eigentlich kein Script-, sondern vielmehr ein Ressource-Loader – es kann nicht nur Javascript-, sondern auch CSS-Dateien nachladen, und das asynchron und parallel, wobei sie dennoch in der beabsichtigten Reihenfolge ausgeführt werden. Auch ist Modernizr natürlich bei weitem nicht der einzige Script-Loader – sein großer Vorteil ist die Integration mit Modernizr.

Performance

In Sachen Performance kann es vorteilhaft sein, mehrere kleine Skripte anstatt einer kombinierten Skript-Datei parallel zu laden, obwohl mehrere Skripte logischerweise auch mehrere HTTP-Requests bedeuten – muss es aber nicht. Der eigentliche Vorteil eines Script-Loaders in Zusammenhang mit Polyfills ist, dass man nur die Skripte (nach)lädt, die tatsächlich vom Browser benötigt werden, um Funktionalitäten nachzurüsten, die er nicht nativ beherrscht. Das spart in modernen Browsern in jedem Fall zu übertragende Daten ein. Im Übrigen ist es natürlich auch möglich, über den Loader zusammengefasste Skripte (etwa in Form einer oldie.js) nachzuladen.

Die grundsätzliche Form

Allgemein sieht die Form eines Aufrufes von Modernizr.load so aus:

Modernizr.load([
    {
        test: Modernizr.test,
        yep: Aktion_1,
        nope: [
            Aktion_2,
            Aktion_3
        ]
    }
]);

Wir testen also eine (oder mehrere über Javascript-Operatoren verknüpfte) Bedingung und führen in Abhängigkeit des Ergebnisses entweder die eine oder andere Aktion aus, wobei es nicht notwendig (und wohl auch in den wenigsten Anwendungsfällen sinnvoll) ist, beiden Testergebnissen eine Aktion, aber sehr wohl möglich, einem Ergebnis mehrere Aktionen (also etwa das Laden einer JS- und einer CSS-Datei) zuzuweisen. Wichtig ist allerdings die Reihenfolge, in der ggf. mehrere solcher Anweisungen in der Skriptdatei stehen, denn sie bestimmt auch die Reihenfolge, in der Ressourcen von Modernizr.load nachgeladen werden.

Testen kann man grundsätzlich alles, was Modernizr erkennt, nachladen kann man JS- und/oder CSS-Dateien. Ausführlichere Dokumentation zum Loader findet man auf der Webseite von yepnope, dem „Mutterprojekt“ von Modernizr.load.

Ein praktisches Beispiel

Nehmen wir an, wir wollen für ein Projekt den placeholder-Polyfill von Dirk Ginader verwenden. Nachzuladen wären in Browsern, die placeholder nicht nativ unterstützen, eine JS- und eine CSS-Datei, die Testbedingung ist auch klar:

Modernizr.load([
    {
        test: Modernizr.input.placeholder,
        nope: [
            'placeholder_polyfill.min.css',
            'placeholder_polyfill.jquery.min.combo.js'
        ]
    }
]);

Oder in Klartext formuliert: „Falls der Browser das input-Attribut placeholder nicht unterstützt, lade die CSS- und die JS-Datei nach“ (der Pfad zu den nachzuladenden Ressourcen ist hier relativ zum Dokument, das den Modernizr-Aufruf enthält). Wichtig auch hier: Die Tests basieren auf den tatsächlich vom Browser unterstützten Funktionen, nicht auf dem von ihm (eventuell fälschlich) übermittelten User Agent.

In jedem Fall lohnt sich ein Blick in die Dokumentation der Tests von Modernizr. Zum einen sind diese (zum Teil) nicht hundertprozentig verlässlich – so liefern zum Beispiel Palm Pre/WebOS-Geräte bei Modernizr.touch ein false zurück, da diese Geräte trotz Touchscreen keine Touch-Events unterstützen. Des weiteren reicht es bei einigen Tests nicht, nur auf true/false zu prüfen – dem Test auf Media-Queries etwa sollte man einen Typ und muss man einen Wert mitgeben, also z.B. Modernizr.mq('only screen and (max-width: 768px)').

Selbstverständlich gilt auch hier, dass man sich in jedem Fall einen angepassten build von Modernizr erzeugen lassen sollte, der nur die Tests enthält, die man konkret benutzt, um Performance-Einbußen durch die Einbindung von Modernizr möglichst gering zu halten.

Nachtrag: Schepp hat mich per Twitter auf einen sehr umfassenden Vergleich gängiger Script-Loader aufmerksam gemacht. Danke!