Das dunkle Erscheinungsbild von macOS im Webdesign nutzen

Seit macOS 10.14 ist es möglich statt des klassisch hellen ein dunkles Erscheinungsbild zu wählen. Die Auswahl des Erscheinungsbilds hat systemweite Auswirkung, und verwandelt die Benutzeroberfläche des Mac in ein angenehm dunkles Farbspektrum. Nach einer kurzen Testphase gefiel mir die dunkle Ästhetik wesentlich besser und ich wechselte auch im Editor zu einem dunklen Theme.

macOS Systemeinstellungen, Allgemein

Während viele Programme die dunkle Ästhetik sehr gut umgesetzt haben, wirkten helle Webseiten, wie diese hier, sehr schnell wie ein Störkörper in der sonst dunkel gehaltenen Ästhetik. Aus diesem Grund nahm ich mir eben einen Moment Zeit um den kommenden Ausdruck für eine Media Query zu testen, um auch eine Webseite auf die Auswahl der Nutzerin reagieren zu lassen. Die Media Query, die dafür verantwortlich ist, liest sich folgendermaßen:

@media (prefers-color-scheme: dark) {
  /* dark mode styles */ 
}

Wird diese verwendet, lässt sich eine Webseite so designen, dass sie sowohl das helle wie das dunkle Erscheinungsbild unterstützt.

In diesem Codepen habe die Anwendung des dunklen Erscheinungsbildes auf eine Webseite schnell getestet. Bisher unterstützt nur Safari Technology Preview (ab Version 68) den Ausdruck prefers-color-scheme, der für ein solches Webdesign benötigt wird. Falls Du diesen Browser nicht installiert hast, siehst Du unter obigem Link die helle Version der Webseite, die dunkle sieht folgendermaßen aus:

Webdesign: Dunkles Erscheinungsbild (Dark Mode)

Zum direkten Vergleich, hier noch ein Bildschirmfoto der hellen Version:

Webdesign: Helles Erscheinungsbild (Light Mode)

Bis der Ausdruck in allen gängigen Browsern unterstützt wird, kommen nur weniger Nutzerinnen in den Genuss des dunklen Webdesigns. Im Sinne von Progressive Enhancement kann diese Technologie schon jetzt eingesetzt werden, so dass das Erlebnis einiger weniger Nutzerinnen schon jetzt verbessert wird, und andere zu einem späteren Zeitpunkt in den Genuss kommen werden.

Vor einigen Wochen las ich den Artikel Redesigning your product and website for dark mode von Andy Clarke, der noch auf einige weitere wichtige Aspekte eingeht. Die Entwickler-Dokumentation von Apple gibt ebenfalls nützliche Hinweise zum Design für das dunkle Erscheinungsbild.

Bürogemeinschaft in Karlsruhe

Bist Du auf der Suche nach einem Büroplatz in Karlsruhe? Ab Dezember ist bei uns im Büro 5&30 wieder ein Platz frei.

Büro 5&30

Das Büro 5&30 liegt in der Karlsruher Oststadt zwischen KIT und Altem Schlachthof. In den hellen Räumen im Erdgeschoss arbeiten Illustrator_innen, Grafiker_innen, Konzepter_innen und ein Webdesigner.

Seit 2011 ist das Büro 5&30 ein Ort an dem Selbstständige gut arbeiten können. Neben Phasen von Konzentration, lebt das Büro vom Austausch über und Anregung für die Arbeit und das Leben. Gerne auch bei einer Tasse Kaffee auf unserem Vorplatz.

Vorplatz des Büro 5&30

Wenn sich das für Dich interessant anhört, freue ich mich von Dir zu lesen.

Am Besten schreibst Du eine kurze Mail an mich über buero@5und30.de oder die Kontaktseite hier. Nachdem Du ein bisschen davon erzählt hast wer Du bist und was Du machst, erzähle ich Dir ein paar wissenswerte Dinge, und wir sehen ob Du und das Büro zusammenpassen.

Platz im Büro 5&30

Bist Du auf der Suche nach einem Büroplatz in Karlsruhe? Ab Juli ist bei uns im Büro 5&30 ein Platz frei.

Büro 5&30

Das Büro 5&30 liegt in der Karlsruher Oststadt zwischen KIT und Altem Schlachthof. In den hellen Räumen im Erdgeschoss arbeiten Illustratoren, Grafiker, Konzepter, Marketingfachleute und Webdesigner.

Seit 2011 ist das Büro 5&30 ein Ort an dem Selbstständige gut arbeiten können. Neben Phasen von Konzentration, lebt das Büro vom Austausch über und Anregung für die Arbeit und das Leben. Gerne auch bei einer Tasse Kaffee auf unserem Vorplatz.

Vorplatz des Büro 5&30

Wenn sich das für Dich interessant anhört, freue ich mich von Dir zu lesen.

Der freie Platz ist mittlerweile vergeben. Falls Du denkst es wäre dennoch gut wir würden uns mal kennenlernen, schreibe mir gern über die Infos auf der Kontaktseite.

ServiceWorker von Apple unterstützt

Webseiten werden ab jetzt auch auf Apple-Geräten zwischengespeichert, und stehen dann zur Verfügung wenn keine Verbindung zum Server hergestellt werden kann. Apple unterstützt ab iOS 11.3 und macOS 10.13.4 ServiceWorker!

Ab jetzt ist es auch im Apple-Umfeld möglich Progressive Web Apps (PWA) einzusetzen. Der Einsatz von PWA wird dadurch ermöglicht, dass zusätzlich zu ServiceWorker das Web App Manifest ab dieser Version von Safari (11.1) unterstützt wird.

Als Nutzer unterschiedlicher Apple-Geräte, und Angesichts deren Verbreitung, freue ich mich sehr darüber.

Beispiel eines ServiceWorker unter iOS 11.3

Wie ich auf meiner Seite ServiceWorker einsetze, habe ich in diesem ServiceWorker-Artikel vom 5. März beschrieben. Falls Du auf Deiner Seite ebenfalls von den Vorteilen – schnelleren Ladezeiten und offline-Verfügbarkeit – eines ServiceWorker profitieren möchtest, melde Dich gerne über das Kontaktformular oder per Mail bei mir.

Wenn ich es richtig sehe, fehlt nun noch die Implementierung in Edge, dann können wir, bezogen auf aktuelle Betriebssysteme und Browser, von einer guten Abdeckung ausgehen und plattformübergreifend PWA weitaus prominenter einsetzen.

Auf der Seite Is service worker ready? von Jake Archibald findest Du eine gute Übersicht zum aktuellen Stand der Implementierung von ServiceWorker in den unterschiedlichen Browsern.

Webseiten benutzbar machen

Laura Kalbag legt mit Accessibility for Everyone ein wunderbares Buch zu Barrierefreiheit vor, in dem sie sowohl grundlegende Überlegungen ausführt als auch konkrete Beispiele zur Verbesserung von Webseiten gibt.

In den sieben Kapiteln des kurzen Buches beleuchtet sie die Frage was Barrierefreiheit bedeutet. Welche konkreten Auswirkungen einige Beeinträchtigungen auf die Nutzung von Webseiten haben. Wie sich Barrierefreiheit im gesamten Entwicklungsprozess planen lässt. Darüber hinaus thematisiert sie den Zusammenhang von Inhalt und Design und die Verbindung von Barrierefreiheit und HTML. In den letzten beiden Kapiteln spricht sie über Tests und deren Auswertung und gibt einen kurzen Einblick in Gesetze und Richtlinien zur Barrierefreiheit.

In ihrem Buch folgt sie dem Konzept des Universal Design und spricht davon wie wichtig es ist davon auszugehen, dass Menschen auf unterschiedlichste Weise im Netz unterwegs sind. Der Zweite Schwerpunkt des Buches ist die Betonung auf den Beitrag aller Beteiligten am Entstehungsprozess einer Webseite zur Barrierefreiheit derselben.

»Making our sites accessible starts with the understanding that people access the web differently, and continues with every member of the team ensuring their output is inclusive«

Universal Design

Der Wikipedia-Artikel zu Universal Design beginnt mit dem Hinweis, dass es sich bei Universal Design um ein internationales Design-Konzept handelt, nach dem »Produkte, Geräte, Umgebungen und Systeme derart gestaltet« sind, »dass sie für so viele Menschen wie möglich ohne weitere Anpassung oder Spezialisierung nutzbar sind.«

Kalbach folgt in Ihrem Buch Ronald L. Mace, der Universal Design in der Architektur etabliert hat. Sie überträgt das Konzept auf Webseiten und formuliert es folgendermaßen:

»Web accessibility is the degree to which a website is usable by as many people as possible.«

Daraus folgt die Notwendigkeit Barrierefreiheit von Anfang zu bedenken, und nicht zu einem späteren Zeitpunkt im Entwicklungsprozess einer Webseite darauf zurück zu kommen. Wie bereits erwähnt ist es daher auch die Aufgabe von allen Beteiligten die Webseite auf eine Art zu designen, die von so vielen Menschen wie möglich ohne weitere Anpassung oder Spezialisierung nutzbar ist.

Aufmerksamkeit auf vier Aspekte helfen nach Kalbag dabei eine Webseite gemäß Universal Design zugänglich zu designen:

  • visuell: achte auf gute Sichtbarkeit.
  • auditiv: achte auf gute Hörbarkeit.
  • motorisch: achte auf die Bedienbarkeit der Interaktionen.
  • kognitiv: achte auf Verständlichkeit.

Bei der Ausführung dieser vier Aspekte wird deutlich wie eng Barrierefreiheit mit guter Bedienbarkeit zusammenhängen: »Good accessibility is good usability.« Eine Webseite, die dem Universal Design Konzept folgt, ist demnach für alle besser zu bedienen, und somit insgesamt ein besseres Produkt.

Konkrete Beispiele

Browser verwenden die vorhandene Struktur des HTML um die Inhalte entsprechend darzustellen und zugänglich zu machen. Webseiten deren HTML semantisch und gut strukturiert ist, sind demnach automatisch barrierearm und auf unterschiedliche Weise auslesbar. Kalbag empfiehlt daher die HTML-Spezifikation gut zu kennen, und die Elemente in ihrer vorgesehenen Funktion zu verwenden. Ein guter Seitenaufbau lässt sich einfach verbessern, während es beinahe unmöglich ist eine schlechte Struktur barrierefrei zu bekommen.

Im folgenden fasse ich ein paar ihrer konkreten Beispiele zusammen, die dazu beitragen im Entstehungsprozess einer Webseite darauf zu achten, dass am Ende ein barrierefreies Produkt steht.

Die Navigation bietet den User_innen Orientierung und hilft bei der Einschätzung welche Inhalte auf der Webseite angeboten werden. Daher sollte sie eine knappe Zusammenfassung der Inhalte darstellen um ihre Funktion gut zu erfüllen.

Links mit Texten wie ›weiter‹ und ›hier klicken‹ sind unbedingt zu vermeiden, da diese bei der Sprachausgabe keinen Zusammenhang zum Ziel des Links bieten. Das Ziel sind sprechende Links, die eine Verbindung zum verlinkten Inhalt herstellen, und bei der Erstellung dabei helfen den eigenen Schreibstil zu verbessern.

Alternative Attribute von Bildern, und Beschreibungen für Infografiken und Diagramme sind wichtig und sollen eine verständliche Erklärung des Dargestellten enthalten. Ihre Anregung beim Schreiben der alternativen Texte daran zu denken den Inhalt am Telefon oder in einer E-Mail zu erklären finde ich hilfreich:

»It might help to think about how you would explain the contents of the media to someone over the phone, or via email.«

Bezüglich der Strukturierung des Inhalts gab es mit dem Aufkommen von HTML5 eine Diskussion über die mehrfache Verwendung von Überschriften erster Ordnung (h1) in einem Dokument. Auch wenn das laut Spezifikation möglich ist, rät Kalbag diese nur für den Titel der Seite zu verwenden und damit die Hauptfunktion der Seite zu bezeichnen.

Für Formulare ist die Verknüpfung von label und input und erforderliche Felder mit einem entsprechenden Texthinweis im label zu versehen – und eben nicht mit dem zur Gewohnheit gewordenen Sternchen*. Dadurch bleibt die Benutzbarkeit offensichtlich und erfordert keine Vorerfahrung.

Um eine Webseite auch gut mit der Tastatur bedienen zu können helfen die tabindex Attribute. tabindex="0" weist die Tastatur-Navigation darauf hin das Element in der standardisierten Reihenfolge zu beachten. tabindex="-1" entfernt das Element aus der standardiesierten Reihenfolge. Daher ist die Verwendung von tabindex="-1" in Elementen die per Sprungmarken angesteuert werden hilfreich. Springt ein_e User_in zu einem Bereich mit tabindex="-1" wird diesem Bereich der programmatische Fokus zugewiesen, ein weiterer Tab findet dann zum entsprechend nächsten Element statt. Der Fokus bleibt nicht – wie ohne tabindex – an der ursprünglichen Stelle.

Im weiteren Verlauf des fünften Kapitels bespricht sie WAI-ARIA, was Web Accessibility Initiative—Accessible Rich Internet Applications bedeutet und als zusätzliche Ebene auf dem gut strukturierten HTML die Sprachausgabe der Inhalte unterstützt. Damit lassen sich Rollen, Bereiche, Status, Attribute und Live Regions definieren, die dann jeweils entsprechend besser zugänglich sind. Es bietet sich meiner Ansicht nach an über WAI-ARIA zu einem späteren Zeitpunkt nochmals zu schreiben.

Testen

Die aufmerksame Integration des Universal Design Konzepts in die Entwicklung einer Webseite sollte von regelmäßigen Tests begleitet werden.

»Regular testing will reassure you that you’re heading in the right direction, or give you new targets if the accessibility falls short.«

Neben den Tests durch eine breite Gruppe von User_innen empfiehlt sie das WebAIM’s WAVE web accessibility evaluation tool. Dabei handelt es sich um ein Webtool, mit dem die Barrierefreiheit einer Webseite überprüft werden kann. WAVE stellt die Webseite im Browser dar, und versieht sie an den entsprechenden Stellen mit Hinweisen auf Aspekte der Barrierefreiheit. Features, Warnungen und Fehler werden hervorgehoben, wodurch der testenden Person direkt weitere Einsichten bezüglich der Barrierefreiheit vermittelt werden.

Richtlinien

Im siebten Kapitel schriebt Kalbag über Gesetze und Richtlinien. Dabei erwähnt sie den Europäischer Rechtsakt zur Barrierefreiheit und die Web Content Accessibility Guidelines (WCAG) 2.0.

Die Web Content Accessibility Guidelines (WCAG) 2.0 enthalten drei Konformitätsstufen (A, AA und AAA), die darüber Aufschluss geben wie gründlich die Richtlinien umgesetzt werden. Die Richtlinien selbst sind durch vier Prinzipien strukturiert, welche mit den oben erwähnten Aspekten von Kalbag verwandt sind:

  • Prinzip 1: Wahrnehmbar – Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzern so präsentiert werden, dass diese sie wahrnehmen können.
  • Prinzip 2: Bedienbar – Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.
  • Prinzip 3: Verständlich – Informationen und Bedienung der Benutzerschnittstelle müssen verständlich sein.
  • Prinzip 4: Robust – Inhalte müssen robust genug sein, damit sie zuverlässig von einer großen Auswahl an Benutzeragenten einschließlich assistierender Techniken interpretiert werden können.

Zusammenfassung

Am Ende des siebten Kapitels fasst sie ihr Anliegen der Integration von Barrierefreiheit in den gesamten Entstehungsprozess einer Website in drei Haltungen zusammen:

  • Aufmerksam sein.
  • Flexibel bleiben.
  • Auf die Bedürfnisse der User_innen achten.

Wenn alle Beteiligten auf Barrierefreiheit achten und ihre Aufgaben aufmerksam erledigen, sind wir auf einem guten Weg. In Anbetracht der stetigen Veränderung und der jeweiligen Anforderungen ist es wichtig flexibel zu bleiben und unterschiedliche Schwerpunkte zu setzten und schließlich empfiehlt sie Richtlinien als solche zu verstehen, und die Bedürfnisse der User_innen zu beachten.

Bevor sie eine Fülle von Ressourcen und weiterführende Links anführt, schließt sie ihre Ausführungen mit dieser ansteckenden Vision:

»We need to work together to make and keep the web open, affordable, and available to all. Accessibility is our way to ensure that nobody gets shut out.«

Wie bereits deutlich wurde halte ich Accessibility for Everyone von Laura Kalbag für ein sehr gelungenes Buch und empfehle es gerne weiter. Kalbag gelingt es sehr gut die Auswirkungen von Universal Design deutlich zu machen, darüber hinaus kombiniert sie gekonnt grundsätzliche Überlegungen mit konkreten Beispielen.

Optimieren der Webfonts

Webfonts sind, wie alle anderen Schriften auch, für den Einsatz in unterschiedlichen Sprachen ausgelegt. Daher enthalten sie eine Fülle von Schriftzeichen. Wird ein Font in einer Webseite verwendet, die vor Allem einen Sprachraum bedient, werden viele dieser Schriftzeichen nie aufgerufen. Mit der Fülle der Schriftzeichen wächst die Dateigröße der Schrift, weshalb es sich lohnt zu überprüfen welche Schriftzeichen tatsächlich verwendet werden, und dementsprechend den Webfont anzupassen.

Dienste wie Typekit oder Google-Fonts bieten die Möglichkeit eine Teilmenge von verwendeten Schriftzeichen festzulegen, und auf diese Weise die Dateigröße des ausgelieferten Webfonts anzupassen. Sollen die Webfonts selbst gehostet werden, ist dies zwar über Font Squirrel möglich, allerdings muss dazu der Webfont hochgeladen werden.

Für mich erschien das bisher als eine nicht zufriedenstellende Lösung, weshalb ich in der letzten Woche die Artikel Three Techniques for Performant Custom Font Usage von Ollie Williams und It’s Dangerous to Go Stallone. Take Glyphhanger von Zach Leatherman mit großem Interesse gelesen habe. Am Wochenende installierte ich dann fonttools und glyphhanger um Webfonts gut über das Terminal optimieren zu können.

Das Tool glyphhanger der Filament Group verwendet die fonttools und bietet darüber hinaus noch die Möglichkeit Dateien oder URLs zu Parsen um dadurch herauszufinden welche Teilmenge an Schriftzeichen darin verwendet werden. Entsprechend dessen kann schließlich ein Webfont optimiert werden, und in unterschiedlichen Formaten abgespeichert werden.

glyphhanger https://depone.net/ --formats=woff2,woff --subset=SourceSansPro-Regular.ttf --css

Wird eben erwähnter Befehl ausgeführt wird der Webfont entsprechend der verwendeten Schriftzeichen in meiner Webseite optimiert. Die Dateigröße minimiert sich dadurch signifikant:

Subsetting SourceSansPro-Regular.ttf to SourceSansPro-Regular-subset.woff (was 287.07 KB, now 27.27 KB)
Subsetting SourceSansPro-Regular.ttf to SourceSansPro-Regular-subset.woff2 (was 287.07 KB, now 21.04 KB)

Mit Hilfe der Option --css gibt glyphhanger die Anweisung aus mit deren Hilfe der Webfont im Stylesheet verwendet werden kann. Um TOFU – hässlichen Kästchen die das fehlende Schriftzeichen ersetzen – in der Typographie zu verhindern wird die unterstützte unicode-range direkt mit angegebenen. Befinden sich im Text nicht unterstützte Schriftzeichen, greifen die Browser auf Systemschriften zurück.

@font-face {
 src: url(SourceSansPro-Regular-subset.woff2) format("woff2"), url(SourceSansPro-Regular-subset.woff) format("woff");
 unicode-range: U+A,U+20-5B,U+5D,U+5F,U+61-7E,U+A0,U+A9,U+AB,U+AD,U+B7,U+BB,U+C4,U+C7,U+D6,U+D7,U+DC,U+DF,U+E4,U+E9,U+F6,U+FC,U+2013,U+2014,U+2019,U+201C-201E,U+2026,U+2033,U+2039,U+203A,U+2192,U+21E7,U+2318,U+F8FF;
}

Der eben erwähnte Rückgriff auf Systemschriften verhindert zwar TOFU und stellt die Lesbarkeit des Textes sicher, die Typographie wird jedoch empfindlich gestört. Daher muss die Optimierung der Webfonts mit Bedacht vorgenommen werden. Die Übersicht der Unicode-Schriftzeichen in der Wikipedia hilft bei der Einschätzung der notwendigen Teilmenge.

Abschließend ist es auch noch wichtig zu erwähnen, dass die Ersparnis in der Dateigröße nicht 90%, wie oben zitierter Ausschnitt andeutet, da es sich beim Ausgangsfont um ein TrueType Format handelt, der entsprechende Webfont (woff) war dennoch dreimal so groß wie die optimierte Teilmenge.

Der Vollständigkeit halber ist noch zu erwähnen, dass für die Komprimierung der Webfonts als woff und woff2 die Installation von Brotli und Zopfli notwendig ist.

ServiceWorker

Eine verlässliche Internetverbindung, und damit den ständigen Zugriff auf Webseiten oder Server, gibt es zwar theoretisch, der Alltag sieht jedoch anders aus. An manchen Orten ist nur eine Verbindung in Edge-Geschwindigkeit möglich, an anderen Tagen scheint LTE in vollem Umfang verfügbar, die Verbindung klappt trotzdem nicht. In anderen Situationen hat eine scheinbar schnelle DSL-Anbindung Schluckauf was eine verlässliche Datenübertragung unmöglich macht.

Um Webseiten auch in den eben beschriebenen Szenarien benutzbar zu machen, steht in einigen aktuellen Browsern ServiceWorker zur Verfügung. Chrome und Firefox unterstützen die Technologie bereits, in den kommenden Versionen von Edge und Safari wird sie erwartet.

Artikel, Vorträge und Tweets zu ServiceWorker verfolge ich seit einiger Zeit interessiert. Am vergangenen Wochenende führte dieses Interesse zur Implementierung eines ServiceWorker für diese Webseite. Der Artikel Progressing the web von Jeremy Keith gab mir den entscheidenden Schubs mich tatsächlich dran zu wagen.

Um meinen eigenen ServiceWorker zu erstellen orientierte ich mich an dem von Jeremy Keith und kombinierte diesen mit den Hinweisen von Michael Scharnagl, der in seinem Blog darüber schreibt wie er für seine WordPress-Seite einen eingerichtet hat. Das daraus resultierende ServiceWorker-Skript für diese Webseite findest Du hier.

Auf welche Punkte lohnt es sich zu achten

Der ServiceWorker muss im Root Verzeichnis liegen. Um ihn dennoch über das Theme verwalten zu können, folge ich dem Beispiel von Michael Scharnagl und erstelle einen Symbolic Link im Root Verzeichnis, der auf das Skript im Assets-Verzeichnis des Themes verweist.

$ ln -s /var/www/virtual/user/wp-content/themes/netz/assets/js/serviceworker.min.js /var/www/virtual/user/serviceworker.min.js

Den ServiceWorker registriere ich in der footer.php durch folgenden Aufruf:

if (navigator.serviceWorker) {
    navigator.serviceWorker.register('/serviceworker.min.js', {
        scope: './'
    });
    window.addEventListener('load', function() {
        if (navigator.serviceWorker.controller) {
            navigator.serviceWorker.controller.postMessage({'command': 'trimCaches'});
        }
    });
}

Der zweite Teil dieses Skripts ruft die trimCaches-Funktion auf, die dafür sorgt, dass der Speicherhunger des ServiceWorkers nicht unersättlich ist, und ab einer gewissen Anzahl von gespeicherten Inhalten, die ältesten Einträge löscht.

Den ServiceWorker habe ich so geschrieben, dass er Stylesheet, Javascript, die Hauptseiten und besuchte Seiten speichert. Diese stehen fortan sowohl dann zur Verfügung wenn die Besucherin offline ist als auch dann wenn der Server nicht erreichbar ist. Für den Fall, dass die angeforderten Inhalte nicht im Zwischenspeicher sind, habe ich eine Seite mit meinen Kontaktdaten und einer kurzen Info erstellt. Die Besucherinnen dieser Webseite bekommen also entweder die gewünschten Inhalte oder eine kurze Info und Kontaktdaten angezeigt, und nicht wie bisher die Offline-Meldung des Browsers.

Bis zur Implementierung des ServiceWorkers gab ich meinem Stylesheet und dem Javascript eine Versionsnummer mit, dieses führte jedoch zu Fehlern beim Aufruf der Webseite aus dem Speicher. Daher hänge ich momentan keine Versionsnummer an meine eigenen Dateien an. Dies möchte ich demnächst aber wieder ändern, wollte es hier jedoch nicht unerwähnt lassen, da ich einen Moment gebraucht habe, um die Quelle der Fehler zu finden.

Um die Implementierung des ServiceWorkers abzurunden, fügte ich dieser Webseite noch ein manifest.json hinzu, so dass Chrome sie zukünftig als Webapp erkennt. Auf diese Weise lässt sie sich als Progressive Web App installieren, und dadurch ganz einfach starten.

Ausblick

Für die neuen Versionen von Safari und Edge ist die volle Unterstützung von ServiceWorker angekündigt. Und die kommende iOS-Version soll Progressive Web Apps unterstützen, wodurch schließlich eine Installation einer Webapp auf den Homescreen von iPhone und iPad nichts mehr im Wege steht.

Um Service Worker besser zu verstehen habe ich mir vorgenommen den Vortrag The Pragmatist’s Guide to Service Workers, den Lyza D Gardner auf der SmashingConf Freiburg 2016 gehalten hat, nochmals anzusehen.

Gelingende Teamarbeit

Auf Zeit Online las ich gestern ein Interview mit Ingrid Gerstbach, Expertin für Design Thinking und Innovationsmanagement, über introvertierte Menschen und deren Chancen im Job. In einer von Extrovertierten dominierten Arbeitswelt wirken introvertierte Menschen oft schwach und es scheint als hätten oder wollten sie nichts beitragen.

Gerstbach plädiert in dem Interview dafür, nicht die Introvertierten ändern zu wollen, sondern an der (Meeting-)Kultur zu arbeiten.

»Introvertierte Menschen beobachten viel und nehmen neben dem, was gesagt wird, auch noch die Stimmung in einem Raum wahr. Das überfordert und kann dazu führen, dass sie sich nicht mehr auf ihre eigenen Ideen fokussieren können und verstummen.«

Es kann als Schwäche ausgelegt werden, wenn eine Person sich nur unter großer Kraftanstrengung zu Wort melden kann, gleichzeitig sollte jedoch die Reflektiertheit und Achtsamkeit – auch auf Stimmungen – als Stärke betrachtet werden.

Gerstbach spricht auch davon, dass es eher kontraproduktiv ist eine stillere Person direkt in der Situation zu Wort zu bitten, sondern regt dazu an über alternative Zugänge nachzudenken. Zweiergespräche bieten sich eher zu konkreter Nachfrage an, als die Gruppensituation, und auch für diese schlägt sie eine gute Methode vor:

»Gerade in Gruppensituationen sollen Ideen entstehen und die Kreativität fließen. Das ist natürlich schwierig, wenn die einen die anderen dominieren. Um das Ungleichgewicht rauszunehmen, lasse ich viel schreiben. Eine Methode ist das Brainwriting, eine Form des Brainstorming: Jeder schreibt seine Ideen zu einem Thema für sich auf und gibt sie dann an den Nachbarn weiter. Der Nachbar ergänzt die Karte des anderen, fügt seine Gedanken hinzu. Das führt dazu, dass sich jeder mit einer Idee intensiver auseinandersetzt und nicht eine laute Person von Anfang an das Brainstorming an sich reißt. Die Methode zwingt alle ein bisschen zur Stille. Gerade den Introvertierten fällt es leichter, zu schreiben. Aber es hilft allen, denn wenn der Kopf erst mal leer ist, kann man besser zuhören. So werden alle Ideen gleichwertig behandelt und es gewinnt nicht der, der seine Idee als Erstes oder am lautesten vorträgt.«

Methodische Reflexion im Kontext von Besprechungen scheint mir nach wie vor als wichtigen Schritt hin zu einem gleichwertigen Austausch aller Beteiligten.

An dem Interview gefällt mir, dass sowohl die Kultur angesprochen wird, die in vielen Zusammenhängen gelebt wird, als auch konkrete Anregungen gegeben werden, wie erfolgreiche Teamarbeit aussehen kann.

Quelle: ZEIT ONLINE: Introvertierte, Bloß nicht anpassen.

Blockchain als Perspektive

Steven B. Johnson stellt in seinem aktuellen Artikel Beyond the Bitcoin Bubble im Magazin der New York Times Blockchain als Zukunftshoffnung für offene Protokolle dar.

Er beschreibt das Internet in zwei Phasen, die erste ist geprägt von offenen Protokollen und Peer-to-Peer-Verbindungen, die zweite charakterisiert er als Phase von Monopolisten, die alle Daten in ihre eigene Plattform einschließen und sie als Waren verstehen.

Blockchain bietet laut Johnson die Möglichkeit eine neue Phase einzuläuten, in der offene Standards und die Möglichkeit direkter Vernetzung wieder die Hoffnung auf gleichwertigeren Austausch beflügeln. Er lädt dazu ein Blockchain über Bitcoin hinaus zu beachten, und somit das inhärente Potential wahrzunehmen und zu nutzen:

Like the original internet itself, the blockchain is an idea with radical — almost communitarian — possibilities that at the same time has attracted some of the most frivolous and regressive appetites of capitalism. We spent our first years online in a world defined by open protocols and intellectual commons; we spent the second phase in a world increasingly dominated by closed architectures and proprietary databases. We have learned enough from this history to support the hypothesis that open works better than closed, at least where base-layer issues are concerned. But we don’t have an easy route back to the open-protocol era. Some messianic next-generation internet protocol is not likely to emerge out of Department of Defense research, the way the first-generation internet did nearly 50 years ago.

Yes, the blockchain may seem like the very worst of speculative capitalism right now, and yes, it is demonically challenging to understand. But the beautiful thing about open protocols is that they can be steered in surprising new directions by the people who discover and champion them in their infancy. Right now, the only real hope for a revival of the open-protocol ethos lies in the blockchain. Whether it eventually lives up to its egalitarian promise will in large part depend on the people who embrace the platform, who take up the baton, as Juan Benet puts it, from those early online pioneers. If you think the internet is not working in its current incarnation, you can’t change the system through think-pieces and F.C.C. regulations alone. You need new code.

Steven B. Johnson, Beyond the Bitcoin Bubble. New York Times, 16.01.2018.

WordPress Toolbar und vollflächiger Hintergrund

Die WordPress Toolbar ist Segen und Fluch zugleich. Einerseits stellt sie wichtige Funktionen im Frontend zur Verfügung, andererseits bringt sie einigen Ballast mit sich. Zu eben erwähntem Ballast zähle ich die Inline-Styles über die sie sich ihren Raum auf der Seite freihält. Dieser Raum wird über einen margin-top freigehalten, der mir jedoch dann in die Quere kommt, wenn ich einen vollflächigen Hintergrund einsetzen möchte.

Um sowohl die WordPress Toolbar nutzen zu können und mein Layout konsistent zu halten, gehe ich folgendermaßen vor:

Zunächst füge ich in der header.php meines Themes eine ifelse-Kontrollstruktur hinzu. Dafür setze ich zuerst eine Variable mit der ich später dem html-Element eine entsprechende Klasse zuweise. Daraufhin kontrolliere ich ob die WordPress Toolbar angezeigt wird, und weise der Variable einen entsprechenden Wert zu.

<?php
  $wpadminbarClass = '';

  if ( is_admin_bar_showing() ) {
    $wpadminbarClass .= 'wpadminbar';
  } else {
    $wpadminbarClass .= '';
  }
?>

<html dir="ltr" <?php language_attributes(); ?> class="no-js <?php echo $wpadminbarClass; ?>">

Mit dieser Klasse am html-Element habe ich ein Hilfsmittel zur Hand, um die Inline-Styles zu überschreiben. Dazu füge ich dem Stylesheet meines Themes die entsprechenden Zeilen der Inline-Styles hinzu und ersetze die vorgesehenen margin-top durch padding-top.

html.wpadminbar {
  margin-top: 0 !important;
  padding-top: 32px !important;
}

* html.wpadminbar body {
  margin-top: 32px !important;
  padding-top: 0 !important;
}

@media screen and ( max-width: 782px ) {
	html.wpadminbar {
    margin-top: 0 !important;
    padding-top: 46px !important;
  }

	* html.wpadminbar body {
    margin-top: 0 !important;
    padding-top: 46px !important;
  }
}

Welche Möglichkeiten nutzt ihr um sowohl die WordPress Toolbar zu nutzen und Eure Layouts konsistent zu halten?

Spricht Eurer Meinung nach etwas dagegen in den Inline-Styles direkt padding-top statt margin-top zu verwenden?