praegnanz.de Das private Weblog von Gerrit van Aaken tag:praegnanz.de,2005:b9374958e211727ae8ae76f7b6521d30 2017-04-17T00:00:00Z Gerrit van Aaken https://praegnanz.de/ Gerrit van Aaken 2017-04-17T00:00:00Z 2017-04-17T00:00:00Z Ladesysteme im Überblick tag:praegnanz.de,2017-04-17:7b9d6dbb3b8a6614e96eb66854f82100 Ergänzend zu meinem 2016er Artikel über die Stecker- und Stromsituation bei Elektroautos habe ich nun eine kompakte Grafik gebastelt, die das ganze noch ein wenig besser verdeutlicht:

Diese Grafik darf gerne geteilt, verlinkt, verändert und kommerziell verwendet werden, sie steht unter einer entsprechenden CC-Lizenz.

Hier der etwas ältere Artikel mit Prosa

]]>
Gerrit van Aaken 2017-04-10T00:00:00Z 2017-04-10T00:00:00Z Und irgendwo er … tag:praegnanz.de,2017-04-10:166e193afda19de7f0f2a16c307b0e4f … lachend, in einem weiß getünchten Loft, die fernen Finger zärtlich auf dem Deck, das Gesicht von Tränen der Erleichterung überströmt.

]]>
Gerrit van Aaken 2017-04-03T00:00:00Z 2017-04-03T00:00:00Z Beyond 1280 tag:praegnanz.de,2017-04-03:1868ec4940c2aec1573dcd72c3ed491b Bei all dem Affentanz, der in den letzten fünf Jahren um das Mobile-First-Konzept betrieben wurde, blieb leider ein scheinbar exotisches Nutzungszenario auf der Strecke: Der gute alte große Bildschirm. Ein paar Ideen, wie man diesen sinnvoll bespielen könnte, möchte ich euch selbstverständlich nicht vorenthalten.

Wer Websites ganz oder teilweise im Browser entwirft und entwickelt, hat sich üblicherweise ein individuelles Bildschirm-Setup zurechtgelegt: Browser rechts – Texteditor links, Browser am Laptop – IDE auf dem großen stationären Monitor, oder etwas ganz anderes. Und auch außerhalb der Webdev-Szene kenne ich kaum jemanden, der seinen Browser auf eine Breite von mehr als 1440 (logischen) Pixeln zieht. Es gibt in aller Regel ja nicht viel Spannendes zu sehen an den Rändern links und rechts, wie beispielsweise Spiegel Online beweist:

Wäre es nicht sinnvoller, das Missverhältnis von Layoutbreite und Bildschirmbreite ein bisschen besser zu kaschieren, indem man zumindest erstere zentriert darstellt? Das machen die meisten anderen Kandidaten. Mal etwas lustlos, wie die BUNTE, welche zusätzlich den dunklen Headerbalken einfach über die komplette Breite zieht:

Oder etwas inspirierter, wie bei The Verge oder A List Apart, wo man mit interessanten Mustern oder typografischen Elementen versucht, den Weißraum außerhalb der Textspalte spannender zu inszenieren:

Man kann natürlich auch krass drauf sein, und das gesamte Layout mitsamt aller Schriftgrade gnadenlos proportional skalieren, bis man sich beim Augenoptiker wähnt. Aber wer macht sowas schon?

Fakt ist, dass niemand bei klarem Verstand auf die Idee kommt, die tatsächlichen Textspalten breiter als ca. 100 Anschläge zu gestalten, denn dann wäre die Lesbarkeit dahin. Insbesondere bei Publikationen, die sehr textlastig sind und bei denen Lesbarkeit an vorderster Stelle … Ach komm, wem mache ich hier was vor?

Wer hingegen ausschließlich Inhalte in Bildform zu bieten hat, kann gerne einmal mit der vollen Breite experimentieren, wie beispielsweise Fotografen:

Bei User Generated Content (ist dieses Wort arg 2004?) kommt es darauf an, ob man es den Minipublizisten selber überlassen möchte, wie Ihre Inhalte dargestellt werden sollten. Das aufgrund seiner guten Typografie weltbekannte Medium Medium macht das so. Normalerweise spielt der breite Bildschirm hier keine wichtige Rolle:

Aber gnade uns Gott, wenn ein Autor ein redaktionelles Bild im Text mit voller Breite einstellt:

Ihr seht – es gibt verschiedene Techniken, um mit dem Problem umzugehen, dass Kunden und Nutzer eben nicht nur kleinere Bildschirme einsetzen als wir bei der Entwicklung von Websites, sondern eben auch immer größere Exemplare. Letztere werden natürlich – wie alle Gadgets dieser Welt – immer billiger und immer größer, aber die unbedarften Gelegenheitsnutzer verändern ihr gelerntes Verhalten nicht analog dazu. Kaum ein Windows-Anwender nutzt die Möglichkeit, das Browserfenster auf eine vernünftige Dimension zu konfigurieren. Wie alle anderen Programme läuft der Browser selbstverständlich immer im Vollbild, weil das zu 1280px-Zeiten so üblich war und auch gerade noch knapp Sinn ergeben hat. Im Laufe der Jahrzehnte, angefangen von 640×480 über 800×600 und 1024×768 bis hin zu den 13-Zoll-Laptop-Größen wie 1280px und 1440px hat niemals jemand „Stopp“ gerufen und den irrationalen Vollbildwahn verhindert!

Da wir Webdesigner uns aber immer an der tatsächlich Realität orientieren müssen, ist es geboten, auch diese unerfahrenen Falschbenutzer (jaja, ich weiß!) mitzunehmen und ihnen ein Angebot zu machen, welches sie zumindest im Ansatz zufrieden stellt. Denkt euch etwas nettes für den Hintergrund aus, fügt noch eine Schriftgrad-Stufe mehr ein, experimentiert eventuell ein wenig mit Textspalten (Vorsicht – nicht in die diversen Scrolling-Fallen tappen!)

Habt ein Herz für unsere Breitschirmfreunde – auch wir müssten da bei dem einen oder anderen Kundenprojekt nochmal kritischer ran, das ist sicher.

]]>
Gerrit van Aaken 2017-02-20T00:00:00Z 2017-02-20T00:00:00Z praegnanz.de v7 – Kirby Edition tag:praegnanz.de,2017-02-20:b7d5eab052af3014eac435ae1844db8d Es ist eine alte Erkenntnis: Im Web und auch im Leben läuft alles in Wellen ab. Mal wird auf-, dann wieder abgerüstet, je nach Trend und persönlicher Situation. Für praegnanz.de heißt es nun gerade einmal wieder zurück zu den Wurzeln – mit einer klaren Fokussierung auf die Blogartikel und Kommentare. Hier sind einige Aspekte, die mir beim 2017er-Relauch wichtig waren.

vertraute Designelemente

Blogs brauchen keine Logos, aber ein (im weitesten Sinne) Designblog braucht zumindest eine deutliche Wiedererkennung, insbesondere wenn man da Wort Prägnanz im Namen trägt. Also führt kein Weg an der Nutzung des klassischen Grün vorbei: #009900ist mir zwar eigentlich etwas zu Dunkel und schwer geraten, aber jetzt geht’s auch nicht mehr anders.

Ebenso dabei: Der Schrägstrich, welcher Headline und Rubrik miteinander verbindet (diesmal in Form eines Non-Rectangular Headers), aber auch als Markierung von Zwischenüberschriften. Ich mag diese Anwendung des Schrägstriches. Wer mit mir bereits per Mail kommuniziert hat, kennt ihn auch von meiner Signatur:

Viele Grüße,
/Gerrit

neue Schrift

Zur hier verwendeten FF Tisa gibt’s eine kleine Geschichte zu erzählen. Als ich Ende 2012 das #webtypobuch geschrieben habe, war sie natürlich auch in der Liste der modernen Webfont-Klassiker vertreten. Aus reiner Schusseligkeit hat der Abschnitt mit dem Tisa-Miniportrait aber leider den Weg vom Manuskript in die Layout-Datei nicht mehr geschafft, und ich habe es zu spät gemerkt. Die Manuskript-Datei ist inzwischen irgendwie auch verschwunden, sonst hätte ich sie hier gerne zitiert :-(

Auf jeden Fall wollte ich schon sehr lange mit Tisa arbeiten, da sie so wahnsinnig freundlich-kraftvoll-warmherzig ist und sowohl in Headlines als auch im Fließtext fantastisch aussieht! Außerdem überträgt sie perfekt die Qualitäten der Georgia – die wahrhaft klassische praegnanz.de-Schrift – ins hochaufgelöste Webfont-Zeitalter.

Teaser auf der Übersichtsseite

Früher waren Blogs ja lediglich kurze Notizen über kleine Entdeckungen im World Wide Web, knapp kommentierte Linklisten, Web-Log-Bücher eben. Da diese Aufgabe längst von Twitter übernommen wurde, finden sich auf den meisten Blogs nurmehr längere Beiträge. Und von daher ist es selbstverständlich nicht mehr zeitgemäß, auf der Artikel-Übersichtsseite die einzelnen Artikel in voller Länge darzustellen, wie es bisher auf praegnanz.de der Fall war. Es ist 2017, und ich habe mir für ein Teasermodell entschieden! Die älteren Beiträge werden dabei automatisch gekürzt, aber bei den neuen Beträgen setze ich die Grenze selber.

neues CMS

Ja, es ist wahr: Textpattern ist nun auch an dieser Stelle offiziell Geschichte. Nach mehr als 13 Jahren der erfolgreichen und stressfreien Zusammenarbeit trennen sich unsere Wege. Das neue System musste selbstverständlich Kirby sein, auch wenn ich damit ein bisschen was riskiere. Wie viele wissen, ist Kirby ein dateibasiertes CMS ohne Datenbank, und damit relativ unorthodox; es ist daher noch nicht so richtig gut erprobt, wie sich das System mit über 2.000 Artikeln und fast 22.000 Kommentaren schlägt. Aber ich bin ja von guten Leuten umgeben: Freund des Hauses Bastian Allgeier ist Erfinder und Hauptentwickler des Systems, und das Kommentar-Plugin kommt von unserem Würzburger Mitstreiter Florian Pircher. Falls also Dinge schief gehen, weiß ich, was zu tun ist.

Pflege & Deployment

Selbstverständlich habe ich darüber nachgedacht, wie ich mit dem Erstellen von neuen Inhalten und dem Anpassen des Stylings verfahren soll. Da bei Kirby sowohl die Inhalte als auch die Templates und die Konfiguration im Filesystem enthalten sind, bietet es sich an, alles komplett über git versionszuverwalten und einen wie auch immer gearteten Workflow für das Deployment aufzusetzen. Immerhin habe selbst ich eine gewisse Nerdehre zu retten! Dabei habe ich bisher leider noch keine perfekte Lösung gefunden:

  • Unser selbstbetriebener Gitlab-Server ist schon gestresst genug und muss nicht noch mit 120 MB Binärdaten in Form von Bilddateien belastet werden.
  • Der cloudbasierte Gitlab.com-Server bietet zwar auch private Repos an, aber die dort frei verfügbaren Runner ließen sich nicht zu einem FTP-Sync auf meinem Shared Hosting bewegen.
  • Ein Dropbox-Workflow mittels Uberspace-Hosting hätte grundsätzlich funktioniert, aber leider macht der Linux-Filewatcher standardmäßig bei 10.000 Dateien Schluss, und ich habe über 50.000 Einzeldateien im Projekt.
  • Ein echter virtueller Server kommt für mich als Admin-Laien nicht in Frage.

Ich bin von daher für jegliche Vorschläge offen, wie ich meine Website cool und stressfrei pflegen, deployen und versionskontrollieren kann.

To-Do

Es fehlen noch ein paar Kleinigkeiten, insbesondere eine Volltextsuche, die ich wahrscheinlich über Google Custom Search abwickeln werde, sowie eine manuell gepflegte Liste mit Top-Artikeln, die in der linken Spalte platziert wird, auf eine Weise, die ich mir noch ausdenken muss. Und natürlich sind noch lange nicht alle Browser und Bildschirmgrößen hinreichend getestet. Hier bin ich natürlich auf eure Hilfe angewiesen mit sachdienlichen Hinweisen.

Ich hoffe, euch gefällt die Grundidee der neuen praegnanz.de-Seite! Ich für meinen Teil habe mich noch nicht satt gesehen und liebe das Schriftbild der Tisa heiß und innig. War ’ne gute Entscheidung!

]]>
Gerrit van Aaken 2017-02-16T00:00:00Z 2017-02-16T00:00:00Z Sechzehneinhalb Jahre tag:praegnanz.de,2017-02-16:f4678d7455f153dac06f63865401f7e0 Die Geschichte dieses Weblogs beginnt, irgendwie, Mitte Juni 2000, als ich das Gefühl hatte, ich könnte meinen Alltag als Designstudent und ein paar lockere Beobachtungen über aktuelles Webdesign auf einer Website festhalten – aufgeteilt in einzelne Artikel, die mit einem Datum versehen sind. Dass dieses Konzept „Weblog“ genannt wird und einige Jahre später das ganz heiße Ding wurde, ahnte natürlich niemand, ich am wenigsten.

Als Name diente der Einfachheit halber der Name meines alten Popmusik-Projektes: „Base-Box“, da hatte ich die Domain schon, und mit Dreamweaver konnte ich auch gar prächtige Designs zaubern.

Screenshot Base-Box 1.0

Von der zweiten Vorabversion dieses Weblogs ist nicht sonderlich viel an grafischem Material übrig geblieben. Es muss der 3. September 2003 gewesen sein, und als Software setzte ich von Anfang an (vielleicht aber auch erst im späteren Verlauf) Blogger.com ein. Natürlich mit selbsterstellten Vorlagen und dynamischen Template-Variablen! Hier auch bereits schön zu erkennen: mein Einheitsgrün (#090), von dem ich seither nicht mehr losgekommen bin.

Screenshot Base-Box 2.0

praegnanz.de v1

Ende April oder Anfang Mai 2004 (Die Wayback Machine lässt keine eindeutigen Rückschlüsse zu), startete dann endlich das richtige Weblog mit einer vernünftigen Blogsoftware. Also nicht etwa WordPress, das kannte man damals kaum, sondern natürlich das viel coolere Textpattern, das bis zum gestrigen Tage diese Seite zuverlässig ausgeliefert hat. Das Design im zeitgenössischen Dreispalter, reduziert und bereits mit erstem Wiedererkennungswert in Form der Farbe und des Logos. Der Markentransfer von Base-Box zu praegnanz.de war geschafft.

Screenshot von praegnanz.de v1

praegnanz.de v2 (Die Gras-Edition)

Das Gras war Kult – mein erstes Textpattern-Redesign, und vermutlich auch das Design, mit dem die meisten meiner alteingesessenen Leser erstmals auf meine Fachartikel aufmerksam geworden sind. Ich mag es bis heute, auch wenn alles natürlich brutal zeitgeistig und bis auf den Monat genau dem August 2004 zugewiesen werden kann, wenn man sich ein bisschen in der Webdesign-Historie auskennt: CSS-Sliding-Doors, Flickr-Fotostream und Pixel-Icons von Michael Preidel. Später habe ich ein WordPress-Theme mit diesem Design angeboten, das bis heute bei einigen Fußball- und Golfclubs in Verwendung ist.

Screenshot von praegnanz.de v2

praegnanz.de v2.5 (die Unveröffentlichte)

Nicht immer gelingt alles, und manche Entwürfe versanden auch komplett. Zum Glück habe ich dieses nette Mockup aber auf Flickr dokumentiert und bin neulich eher zufällig darauf gestoßen. Ich habe offenbar Weihnachten 2004 bis Ende Januar 2005 sporadisch dran gebaut, doch es ist kein echtes Template draus geworden:

Screenshot von praegnanz.de v2.5

praegnanz.de v3 (die Akkordeon-Hölle)

Regelrecht visionär ging es im April 2006 weiter. Da veröffentlichte ich ein Design, was heute unter Mobile-First-Gesichtspunkten total abräumen würde, doch tatsächlich gab es damals einen sehr kurzen Trend zu Einspaltern mit furchterregend großen Headlines, den ich natürlich nicht verpassen durfte. Die gesamten Meta-Informationen nur zum Aufklappen anzubieten hatte auch etwas sehr mobilehaftiges, wobei das iPhone ja erst ein Jahr später vorgestellt wurde.

Screenshot von praegnanz.de v3

praegnanz.de v4 (Windows-8-Edition)

Wie war das mit dem Metro-Design? Wer hat’s erfunden? Nun, sicher war ich nicht der erste, der mit quadratischen Kacheln versucht hat, ein Webdesign aufzubauen, aber ich war sicher einer der ersten, die verstanden haben, dass das im Grunde nicht funktioniert. Noch heute sehe ich viele Designagenturen damit bemüht, mehr schlecht als recht die konzeptionellen Schwierigkeiten zu bewältigen, die diese Layoutidee mit sich bringt. Bei mir hat es nur anderthalb Jahre gedauert (7. März 2008 bis Mitte 2009), bis diese Phase vorüber war. Besonders gut gefallen hat mir dieses Design tatsächlich nie, auch wenn es – ganz ohne Mediaqueries – bereits so etwas wie responsiv gewesen ist.

Screenshot von praegnanz.de v4

praegnanz.de v4.5 (die Unveröffentlichte II)

Hierzu gibt es nicht viel zu sagen. Der Versuch, der unpraktischen Kachelseite ein 08/15-Design hinterherzuschieben, ist zum Glück genau dabei geblieben – bei einem Versuch. Dennoch weise ich darauf hin, dass Serifenschrift, Schwarzweiß-Fotos und #090-Grün einfach dazu gehören, wenn praegnanz.de drauf stehen soll!

Screenshot von praegnanz.de v4.5

praegnanz.de v5

Nach zwei Jahren Selbstständigkeit war es am 27. Juli 2009 nun Zeit für eine Professionalisierung. Im Zentrum für die Layout-Idee war natürlich die geschickte Integration des Logo-Schriftzugs mit der Navigation. Die beiden Elemente werden eins, und diese Idee prägte auch die beiden noch folgenden Redesigns. Im Grunde stimmt hier alles: Wiedererkennbarkeit, Übersichtlichkeit, Blogcharakter. Es fehlt halt das letzte bisschen Prägnanz, sprich: ein aufsehenerregendes Designelement wie das Gras oder die Kacheln. Vielleicht ein bisschen zu glatt, aber hat immerhin über drei Jahre gehalten!

Screenshot von praegnanz.de v5

pragnanz.de v6 (GbR-Edition)

Aus eins mach zwei! Da praegnanz.de vier Jahre lang gleichzeitig mein Weblog und auch eine Zwei-Mann-Agentur gewesen ist, musste im August 2012 eine neue Website her, die das auch widerspiegelt. Gemeinsam mit Philip saß ich also viele Stunden im Büro und am Esstisch, damit die beiden Gesellschafter etwas vernünftiges zaubern konnten. Das bis gestern aktuelle Design wurde leider relativ stiefmütterlich behandelt, da es nur sehr wenig frischen Inhalt gab in den letzten Jahren. Traurig! Doch dafür kann das Design nichts. Es war responsiv (wenn auch nicht sehr hübsch, und außerdem nachträglich hinzugefügt), erneut eindeutig als praegnanz.de zu identifieren, und brachte zum ersten Mal echte Webfonts mit ins Spiel: Adelle für die Headlines und FacitWeb für den Fließtext. Da soll mal einer sagen! Und Textpattern läuft und läuft und läuft …

Screenshot von praegnanz.de v6

Abrundung

Sechzehneinhalb Jahre ins Internet schreiben – rund die Hälfte davon voller Gewissensbisse, dass man mal wieder bloggen müsste. Aber das gehört ja irgendwie dazu, sonst gäbe es Aktionen wie den Iron Blogger nicht. Ich werde in den nächsten Tagen noch ein paar Worte zum aktuellen Design und vor allem der aktuellen Technik verlieren – das dürfte für einige interessant werden. Ich für meinen Teil bin froh, dass ich hier alles unter einem Hut und meine Webtexte seit dem Jahr 2000 unter meiner eigenen Kontrolle habe. Mal sehen, wie es weitergeht – an Ideen mangelt es nicht, aber – oh Wunder! – an Zeit. Ihr kennt das.

]]>
Gerrit van Aaken 2016-11-11T00:00:00Z 2016-11-11T00:00:00Z BEM für Späteinsteiger tag:praegnanz.de,2016-11-11:9da0fe67e084cee5ede6c9d0fb96c8ca Es gibt bei uns eine gewisse Tradition, sich erst recht spät mit dem ganzen heißen Scheiß aus der WebDev-Hipster-Toolchain zu beschäftigen. Nachdem ich 2013 den staunenden Kollegen im Working-Draft-Podcast noch berichtete, dass wir außer jQuery quasi keine nennenswerten Frontend-Tools oder -Techniken verwenden, gab es in den letzten drei Jahren schon noch die eine oder andere Aufrüstungsmaßnahme in unserem Workflow. Aber es ist uns eben wichtig, nicht zuviel Energie in Lösungen zu stecken, die sich mittelfristig als Sackgasse erweisen. Gut abgehangene Technik schlägt jeden Hype.

Im Falle von BEM war es insbesondere die unfassbar schlechte Didaktik, mit der das System allerorts beworben wurde. Ich konnte schlicht keinen vernünftigen Fachartikel finden, der mich wirklich von den Vorzügen überzeugen konnte. Mit den nachfolgenden Zeilen kann ich diesen Zustand hoffentlich ein wenig verbessern!

Kurzer Hinweis

Ich werde hier aus Gründen auf die Bezeichnung „Element“ verzichten, wenn damit die nackten HTML-Strukturelemente wie <h1>Headline</h1> oder <img src="" alt="" /> gemeint sind. Ich nenne sie stattdessen Bausteine, um sie von den BEM-Elementen zu unterscheiden.

Das Problem

CSS ist zwar auf den ersten Blick kein sonderlich komplexes Styling-System, doch der Schein trügt: Jeder, der ein Projekt mit mehr als 2000 Zeilen CSS-Code gebaut hat oder gar vererbt bekommt, hat sich sicherlich schon darüber geärgert, dass es in CSS keine eingebaute, verpflichtende Systematik oder Architektur gibt, mit der sich große Projekte mit vielen unterschiedlichen, aber natürlich visuell verwandten Elementen besser organisieren lässt. Das einzige, was man sich üblicherweise zu Nutze macht, sind:

  • HTML: semantische, aber kurze Klassennamen, die irgendwie trotzdem das Styling erahnen lassen
  • HTML: multiple Klassen für unterschiedliche Stylings, die aus unterschiedlichen Kontexten geerbt werden können
  • CSS: lockere Gruppierung von irgendwie zusammengehörigen Selektoren
  • CSS: grobe Reihenfolge der Selektoren von allgemein zu speziell, von außen nach innen, und von oben nach unten
  • CSS: verschachtelte Selektoren mit zunehmender Spezifität – durch übersichtliche Einrückung in Präprozessoren verführerisch einfach!

Dies sind alles keine grundsätzlich schlechten Ideen, und die Fähigkeiten von CSS ermutigen uns ja auch, Dinge wie die Kaskade, die Hierarchie und die Spezifität auszunutzen. Jedoch stoßen viele der einstigen best practices schlichtweg an ihre Grenzen, wenn es um mehr gehen soll als nur das neue Blogdesign oder den One-Pager für den Friseurladen nebenan. Ganz speziell sind es drei Dinge, die auch mir als wirklich erfahrenen CSS-Artisten immer wieder Schwierigkeiten bereiten:

  1. Konsistentes Namenskonzept für Klassen
  2. Wiederverwendbarkeit von Styling-Regeln (in funktionierend)
  3. Überschreiben von Selektoren mit bereits zu starker Spezifität

Und genau bei diesen drei Dingen kann BEM uns behilflich sein. Es lohnt sich also, dranzubleiben!

Die Grundprinzipien

BEM ist eine freiwillige Konvention und eine Systematik, wie man Klassen in HTML vergibt und diese in CSS nutzt. Es ist eine Empfehlung und ein Vorschlag, aber kein festes Framework. Man könnte zwar theoretisch Software schreiben, die BEM irgendwie automatisch generiert, aber das ist alles Quatsch – wir nutzen BEM einfach als eine Möglichkeit, unseren CSS-Code gut zu organisieren, damit wir uns nicht mehr so oft an den Kopf greifen müssen.

Mit BEM vereinheitlichen und vereinfachen wir die Prinzipien von CSS noch stärker, so dass man von einer wirklich minimalistischen Struktur sprechen kann. Es wird auf so vieles verzichtet!

  • Alle(!) CSS-Selektoren bestehen aus lediglich je einer Klasse
  • Es gibt keine id-Selektoren (#header {}) und auch keine Baustein-Selektoren (h2 {})
  • Verschachtelungen jeglicher Art sind ebenfalls nicht erlaubt
  • Selbstredend ist auch !important kein Thema

Somit besitzt jeder Selektor die gleiche Spezifität und es entscheidet nunmehr ausschließlich die Reihenfolge im Quelltext, welche Regel greift. Peace of mind – die Spezifitätskriege sind vorbei!

Gleichzeitig hat dies aber zur Folge, dass jeder Baustein, welchen ich gezielt stylen möchte (also wirklich jeder!), mindestens eine Klasse erhalten muss, selbst wenn es sich um ein blödes a innerhalb eines li einer Navigation handelt. Das ist ganz schön hart! Es bläht den HTML-Code auf, macht ihn weniger gut lesbar und nimmt dem CSS-Code scheinbar seine Eleganz. Früher hätten wir beispielsweise so etwas geschrieben:

<ul class="navi">
    <li><a href="ueberuns.html">Über uns</a></li>
    <li><a href="vision.html">Vision</a></li>
    <li class="active"><a href="kontakt.html">Kontakt</a></li>
</ul>

ul.navi a {
    color: #090;
    text-decoration: none;
}

ul.navi .active > a {
    color: #000;
}

Mit BEM sieht das im Vergleich erstmal schlimm aus:

<ul class="navi">
    <li class="navi__item">
        <a class="navi__link" href="ueberuns.html">Über uns</a>
    </li>
    <li class="navi__item">
        <a class="navi__link"  href="vision.html">Vision</a>
    </li>
    <li class="navi__item navi__item--active">
        <a class="navi__link navi__link--active" href="kontakt.html">Kontakt</a>
    </li>
</ul>

.navi__link {
    color: #090;
    text-decoration: none;
}

.navi__link--active {
    color: #000;
}

Was stört uns intuitiv daran? Ich vermute, es ist zum einen die schiere Menge an langen, redundanten Klassen, und zum anderen die Klassennamen, die die Hierarchie des HTML-Konstruktes noch einmal doppeln. Warum nutzen wir nicht einfach die bereits vorhandene HTML-Hierarchie (ul als Container von li sowie li als Container von a) und machen damit sowohl das HTML als auch das CSS kürzer und eleganter?

Weil wir uns mit dieser „physischen“ Hierarchie jede Menge Ärger einhandeln, der am Anfang noch nicht als Ärger erkennbar ist, aber ab einer gewissen Projektgröße das Potenzial hat, den CSS-Code quasi unpflegbar zu machen. Auch wenn es ein Kernkonzept von CSS ist: Hierarchie auf Selektor-Ebene skaliert nicht. Deshalb verzichtet BEM darauf und bildet eine (vereinfachte) Hierarchie ausschließlich in den Klassennamen ab.

Die BEM-Klassennamen

Ich habe ganz bewusst darauf verzichtet, das Akronym BEM gleich am Anfang meines Textes zu erläutern, denn es verwirrt nur. (Genauso wie es keinen Sinn macht, die Cascade von CSS gleich am Anfang zu erläutern.) Doch nun ist der richtige Zeitpunkt gekommen! BEM steht für Block, Element und Modifier und beschreibt die Systematik, nach der die Klassennamen ausgedacht und vergeben werden. Keine große Sache.

Ein Block ist ein Container von grundsätzlich beliebiger Komplexität. Er enthält mehrere Elemente, die sinnvoll zum Block passen und diesen mit Leben füllen. Jeder Block und jedes Element kann außerdem einen optionalen Modifier haben, der das entsprechende Basis-Styling mit zusätzlichen CSS-Eigenschaften abwandelt und verfeinert, so dass es eben mehrere unterschiedliche Styling-Varianten dafür geben kann.

Die Schreibweise der BEM-Klassen ist zwar nicht platzsparend, aber einfach:

  • Blöcke haben ganz normale semantische Klassen: class="pagination"
  • darin enthaltene Elemente werden mit zwei Unterstrichen notiert: class="pagination__link"
  • Abwandlungen der Elemente erhalten, zusätzlich zur Originalklasse, eine mit Doppeltrennstrich ergänzte Variante: class="pagination__link pagination__link--active"
  • Aber auch Blöcke können direkt als Ganzes abgewandelt werden, insbesondere bei gewünschter Positionierung an anderer Stelle: class="pagination pagination--aside"

Übrigens: Styling-Varianten, die man im CSS über den Kontext eines im übergeordneten HTML-Bausteins realisiert, sind verboten, von daher kann es durchaus mal sein, dass man mehrere Elemente eines Blockes einzeln modifizieren muss, wie im oberen Beispiel mit dem --active-Modifier.

Übrigens 2: Natürlich zwingt euch niemand, absolut jeden Baustein mit einer Klasse zu versehen. Was ihr nicht stylen müsst, muss auch nicht verBEMt werden.

BEM als Parallel-„DOM“

Wichtig zu beachten ist, dass es im Verhältnis vom Block zu seinen Elementen nur eine einzige Hierarchie-Stufe gibt: alle Elemente eines Blocks sind – mit der BEM-Brille gesehen – auf einer Ebene, unabhängig davon, wie tief sie innerhalb des HTML tatsächlich verschachtelt sind. Somit bauen wir uns mit BEM im Grunde eine Parallel-Struktur auf, die sich auf zweierlei Arten vom HTML emanzipiert:

  1. Sie schafft eine eigene Hierarchie, die sich im Extremfall nur locker am vorhandenen HTML orientiert.
  2. Sie ist komplett „Tag-agnostisch“: Das Herumspielen mit h1- bis h6-Ebenen (SEO, anyone?) und das Anreichern mit HTML5-Semantik in Form von aside-, section- oder subhead-Tags hat keinerlei Auswirkungen auf das Styling. Ihr ahnt nicht, wie befreiend das ist!

Elemente, die gleichzeitig Blöcke sind

Ich schrieb oben, dass Blöcke eine grundsätzlich beliebige Hierarchie ausweisen können – und das stimmt auch. Denn wenn beispielsweise eine Gruppe von drei gleichartigen Teaserboxen nebeneinander dargestellt werden soll (für mobile natürlich untereinander), so habe ich ja zum einen das gesamte Teaserkonstrukt als Block, in dem die drei Teaser meine Elemente bilden. Zum anderen kann man sich aber auch jeden einzelnen Teaser als Block mit seinen unterschiedlichen Elementen wie Headline, Vorschaubild usw. vorstellen

Eine beispielhafte HTML-Struktur sähe nackt so aus:

<section>
    <article>
        <h3>Teaser 1</h3>
        <img src="" alt="" />
        <p>…</p>
    </article>
    <article>
        <h3>Teaser 2</h3>
        <img src="" alt="" />
        <p>…</p>
    </article>
    <article>
        <h3>Teaser 2</h3>
        <img src="" alt="" />
        <p>…</p>
    </article>
</section>

Unsere article-Bausteine könnten also Elemente der section sein, gleichzeitig aber als Blöcke für h3, img und p fungieren. Dies sähe in der Praxis dann so aus:

<section class="teasers">
    <article class="teasers__box box">
        <h3 class="box__headline">Teaser 1</h3>
        <img src="" alt="" class="box__image"  />
        <p class="box__intro">…</p>
    </article>
    <article class="teasers__box box box--highlight">
        <h3 class="box__headline">Teaser 2</h3>
        <img src="" alt="" class="box__image"  />
        <p class="box__intro">…</p>
    </article>
    <article class="teasers__box box">
        <h3 class="box__headline">Teaser 3</h3>
        <img src="" alt="" class="box__image"  />
        <p class="box__intro">…</p>
    </article>
</section>

Es hat sich als gute Konvention erwiesen, wenn der Name des untergeordneten Blocks identisch mit seinem Element-Anhängsel ist, in diesem Beispiel eben teasers__box und box. Somit macht man die Übergabe sichtbar. Es ist aber keine Pflicht.

Grundsätzlich lässt sich allerdings auch argumentieren, dass es hier keiner weiteren Block-Ebene bedarf. Man könnte auch den teasers-Block als Alleinherrscher walten lassen, etwa so:

<section class="teasers">
    <article class="teasers__box">
        <h3 class="teasers__headline">Teaser 1</h3>
        <img src="" alt="" class="teasers__image"  />
        <p class="teasers__intro">…</p>
    </article>
    <article class="teasers__box teasers__box--highlight">
        <h3 class="teasers__headline">Teaser 2</h3>
        <img src="" alt="" class="teasers__image"  />
        <p class="teasers__intro">…</p>
    </article>
    <article class="teasers__box">
        <h3 class="teasers__headline">Teaser 3</h3>
        <img src="" alt="" class="teasers__image"  />
        <p class="teasers__intro">…</p>
    </article>
</section>

Modularität auf Block-Ebene

Welches der obigen Beispiele euch besser gefällt, macht ihr am besten davon abhängig, wie komplex das Geschehen in den einzelnen Teasern sein soll, und ob man die Boxen auch evtl. einmal einzeln benötigt, ohne den teaser-Block drum herum.

Denn dies ist der Kern des Modularitäts-Versprechen von BEM: Wenn wir einen Baustein als Block ansehen, lässt er sich im HTML überallhin verpflanzen und sieht für sich genommen an jeder Stelle auch gleich aus. Sprechen wir hingegen den Baustein als untergeordnetes Element an, kann er von der Platzierung her mit ebenbürtigen Elementen interagieren – beispielsweise eine horizontale Reihe bilden, oder als Flexbox-Item noch viel interessanter im Kontext positioniert werden.

Ich nenne dies die duale Natur von BEM-Bausteinen: Sie können gleichzeitig Welle und Teilchen Block und Element sein. Oder, als CSS-Code formuliert:

.box { border: 1px solid #000; background: #ccc; }
.box--highlight { background: yellow; }
.teasers { display: table; }
.teasers__box { display: table-cell; }

BEM und Sass

Die unhandlichen Klassennamen von BEM-Projekten sind natürlich nicht nur im HTML ein visuelles Problem, sondern auch in handgeschriebenem CSS. Wer fuhrwerkt schon gerne in Code herum, der so aussieht:

.newsteaser {
    border: 1px solid #000;
    background: #ccc;
    padding: 1em;
}

.teasergroup {
    width: 80%;
    overflow: hidden;
}

.teasergroup__headline {
    font-size: 1.5em;
}

.teasergroup__newsteaser {
    float: left;
    width: 33%;
}

.teasergroup__newsteaser--emphasized {
    border-color: red;
}

Da viele von euch für das Schreiben von CSS sowieso einen Präprozessor verwenden, kann man beispielseise mit Sass die BEM-Hierarchie auch mit den entsprechenden Einrückungen abbilden:

.newsteaser {
    border: 1px solid #000;
    background: #ccc;
    padding: 1em;
}

.teasergroup {
    width: 80%;
    overflow: hidden;
    &__headline {
        font-size: 1.5em;
    }
    &__newsteaser {
        float: left;
        width: 33%;
        &--emphasized {
            border-color: red;
        }
    }
}

Wichtig dabei: Auch bei dieser scheinbar hierarchischen Verschachtelung verändert sich keineswegs die Spezifität der Selektoren. Alle Bausteine werden absolut gleichwertig angesprochen, lediglich die Reihenfolge entscheidet bei Konflikten, welche Regel gewinnt. Deshalb ist es auch sinnvolle Praxis, das für sich stehende Block-Styling eines dualen Bausteines zuerst zu behandeln, und erst im Anschluss daran die Platzierung und Anpassung im Kontext eine übergeordneten Blockes. Diese ist spezifischer und gehört von daher weiter nach hinten.

Fazit

Genau wie einige andere Ansätze (OOCSS oder SMACSS) versucht BEM, die negativen Erfahrungen, die jeder CSS-Entwickler in komplexen und sich agil entwickelnden Layouts unweigerlich macht, zu mindern. Dabei geht es nicht darum, eine Metasprache zu schaffen, wie es Sass tut. Sondern es geht darum, die vorhandenen Möglichkeiten von CSS sinnvoll zu nutzen sowie gefährliche Praktiken zu vermeiden.

CSS wurde, genau wie HTML, nicht von visuellen Designern erdacht, sondern von Informatikern. Trotzdem müssen wir heute Layouts damit umsetzen, die sehr wohl von Designern stammen. Manchmal sind es wir Designer selber, die mit CSS unsere Ideen umsetzen. Und die Projekte werden immer komplizierter, insbesondere in einem responsiven Web. Seien wir nicht traurig, dass wir superclever verschachtelte Child-Selektoren und mühsam erlernte Spezifitäten hinter uns lassen – sie haben sich einfach auf Dauer nicht bewährt und mehr Probleme aufgeworfen als gelöst.

Ich habe es selber ausprobiert und werde vorerst dabei bleiben; Ein Projekt mit BEM aufzubauen sorgt bei mir für gesunden Blutdruck und entspannte Gesichtszüge. Fast wie eine Wellness-Massage. Und das ist tatsächlich nur dezent übertrieben :-)

]]>
Gerrit van Aaken 2016-10-02T00:00:00Z 2016-10-02T00:00:00Z Kundenmissverständnisse ausräumen leicht gemacht! tag:praegnanz.de,2016-10-02:27b8e751ed92ecaf07f26f1d14007558 „Haben Sie es schon mal mit F5 probiert?“ ist das “Have you tried turning in off and on again?” für Webdesigner – ich weiß nicht mehr, wie oft ich diesen Satz in den letzten 15 Jahren gesagt habe. Jetzt ist damit Schluss, und ich hätte viel früher darauf kommen sollen, wie man das sauber löst. Wir wollen

a) auf Live-Websites den Browsercache für CSS- und JavaScript-Dateien nutzen
b) die Browser dazu zwingen, eine geänderte CSS- oder JS-Datei nicht aus dem Cache zu nehmen, sondern neu zu laden, um diese dann aber wiederum solange zu cachen, bis wir eine erneut geänderte Version anbieten.

Die simple Methode mit dem URL-Parameter (screen.css?v=42) ist offenbar nicht wirklich zuverlässig, sondern führt bisweilen dazu, dass gar nicht mehr gecacht wird. Von daher unser Vorschlag: Wir verwenden eine echte Dateinamenänderung, die mit einem Timestamp versehen ist, und nutzen die Power von .htaccess, um das für die Browser transparent zu gestalten. So geht’s:

Dateinamen dynamisch anreichern. Zum Beispiel mit PHP:

<link rel="stylesheet" href="/css/screen.<?= date('YmdHi', filemtime('/var/htdocs/screen.css')) ?>.css">

daraus resultiert ein Dateiname mit einem eingebauten Datum/Zeitangaben vom last modified der physischen CSS-Datei:

<link rel="stylesheet" href="/css/screen.201609301654.css">

Nun noch ein paar Eintragungen ganz oben in der .htaccess-Datei, und wir sind fertig:

RewriteCond %{REQUEST_FILENAME} (css/screen\.(.*)\.css)
RewriteRule ^(.*)$ /css/screen.css [L]

Das gleiche natürlich mit der print.css und der all.js, und alle können beruhigter ihre Websites deployen und sicher sein, dass sich Änderungen direkt im Kundenbrowser auswirken.

]]>
Gerrit van Aaken 2016-10-02T00:00:00Z 2016-10-02T00:00:00Z Doppelkompression mit Bluetooth-Audio tag:praegnanz.de,2016-10-02:593a85fd2e55c4bc0ed75cfe13309b6e Viel ist geschrieben und gesprochen worden über die fehlende Klinkenbuchse des iPhone 7, die Qualität des 9-Euro-Adapters von Apple (der tatsächlich einen eigenen DAC mitbringt), und über die Bereitschaft von Kopfhörer-Herstellern, Lightning-Modelle auf den Markt zu bringen. Alles im Grunde egal, denn die Zukunft scheint freilich Bluetooth zu sein für jede Art von modernen Kopfhörern (und für viele Raumbeschaller ebenfalls).

Ich hab da als alter Mann ein kleines Problem mit. Und damit höre ich mich sehr audio-esoterisch an, ist mir bewusst. Mir gefällt die Vorstellung ganz und gar nicht, dass beim Einsatz eines Musikstreaming-Dienstes über iPhone und Bluetooth-Kopfhörer die ursprünglich gemasterten Musikdaten zweimal über ein verlustbehaftetes Format umkodiert werden, bevor sie zu analog gewandelt an mein Ohr dringen.

Zum einen gibt es außer Tidal und Pono (haha!) kaum legale Möglichkeiten, online an verlustfreie Musik zu kommen. Zum anderen sieht der Bluetooth-Standard derzeit keine verlustfreie Audio-Übertragung in CD-Qualität vor. Je mehr Daten, desto schlechtere Verbindungsqualität und Reichweite und höherer Stromverbrauch. 345kbit/s sind das Maximum – und das reicht nicht ganz für FLAC!

Mit dem Beispiel Apple Music sieht es also derzeit so aus:

  • Die Musik wird nach dem Mastered for iTunes-Prinzip an Apple geliefert, also mit mindestens 44,1kHz / 16Bit (unkomprimierte CD-Qualität)
  • Beim Ausliefern an den Hörer wird üblicherweise eine 256kbit/s-AAC Datei genommen (erster Qualitätsverlust, den normale Menschen aber aller Erfahrung nach nicht hören können.)
  • Bei der Übertragung an Bluetooth-Kopfhörer wird die Musik ein weiteres Mal komprimiert, und zwar abhängig von den Fähigkeiten der beiden beteiligten Geräte. Macs und hochwertige Android-Smartphones bieten aptX an, was ebenso hochwertige Kopfhörer auch verarbeiten können. Ansonsten einigt man sich auf einen anderen A2DP-Codec wie AAC, MP3 oder SBC.

Auch wenn das iPhone für Bluetooth den AAC-Codec einzusetzen versucht – man darf nicht davon ausgehen, dass hier ein simpler Pass-Through der bereits vorhandenen AAC-Daten stattfindet, wie im ATP erläutert wird. Statt dessen wird tatsächlich doppelt kodiert.

Ich bin noch unschlüssig, ob nicht an dieser Stelle eine Akzeptanzschwelle bei mir überschritten wird. Ich konnte immer gut damit umgehen, dass eine vollständig analoge Recording- und Produktionskette bis hin zur Vinylscheibe die überlegene Klangqualität darstellt, wenn man Kratzer und Rauschen als Teil der Experience begreift. Ich habe aber gleichzeitig bisher nie Probleme mit digitalen CDs und hochwertig komprimierten MP3s oder AACs gehabt, das klang immer sehr gut für mich, sobald man die 192kbit/s überschritten hatte.

Aber eine zusätzliche Komprimierung der bereits auf ein Fünftel eingedampften digitalen Daten? Ich weiß nicht. Natürlich hört man keine schlimmen MPEG-Artefakte, soviel ist klar. Aber sind es bei anständigen Bitraten nicht vielmehr die fehlende Räumlichkeit und das stumpfe, matte Klangbild, welche das feine Ohr stören? Aktuelle Chartmusik (und auch viele sogenannte Remasterings) eignen sich ja nur begrenzt für diesen direkten Hörvergleich, weil hier zu Datenkompression auch noch eine irrwitzige Dynamikkompression hinzu kommt, die alle Nuancen von vornherein kaputt macht.

Es hilft nichts, ich werde wohl einmal einen direkten Hörtest machen müssen! Der technische Versuchsaufbau ist grob umrissen, es könnte interessant werden:

  • WAV/FLAC (über Kabelkopfhörer)
  • FLAC zu aptX (TIDAL auf dem Mac, Bluetooth)
  • FLAC zu AAC (TIDAL auf dem iPhone, Bluetooth)
  • WAV zu AAC zu aptX (Apple Music auf dem Mac, Bluetooth)
  • WAV zu AAC zu AAC (Apple Music auf dem iPhone, Bluetooth)

Zumindest kann ich abschließend sagen, dass ich froh bin, dass mein neuer Beoplay H7 auch ein optionales Klinkenkabel hat, und dass dieser Kopfhörer über Klinke auch exzellenten Klang bietet, sogar ohne störende Bluetooth-Kritzelkratzelgeräusche, die aber auch ein Softwareproblem sein können.

]]>
Gerrit van Aaken 2016-08-29T00:00:00Z 2016-08-29T00:00:00Z Die magische 500 – was steckt dahinter? tag:praegnanz.de,2016-08-29:d3abea84bfa951e5806501f5ef77eec5 In meinen Gesprächen mit traditionellen Automobilisten höre ich immer und immer wieder die Aussagen, dass man „ab 500 Kilometer Reichweite“ drüber nachdenken würde, sich auch ein Elektroauto zuzulegen.

Diese knackige Schwelle ist eine grobe Faustregel und funktioniert auch schon ganz prima und bequem, denn einerseits klingt das als Ziel absolut machbar, wenn die ZOE schon jetzt (offiziell) 240km bietet und Tesla mit (offiziell) 400 bis 600km wuchert. Andererseits muss man sich keine Sorgen machen, bereits innerhalb der nächsten Monate seine Fahrt- und Kaufgewohnheiten umzustellen, denn bis die 500km zu einem erschwinglichen Preis zu haben sind, dauert es sicher noch bis zum Jahr 2020.

(Die realistische Reichweite errechnet sich übrigens aus der einfachen Formel: Offizielle Reichweite × 0,66)

Aber im Grunde sind die 500km letztlich doch ein eher unbrauchbares und willkürliches Argument, denn sein Ursprung liegt in den aktuell typischen Verbrenner-Reichweiten auf Autobahnfahrten. Würden Verbrenner-Fahrzeuge im Durchschnitt nur 300km weit kommen, würden alle auch für Elektroautos genau diese Zahl einfordern.

Es steckt jedoch mehr dahinter. Denn was nützt mir ein 500km-E-Mobil, wenn es auf Autobahnen keine Ladesäulen gibt, oder wenn solche Ladesäulen für das Vollmachen der 500km-Batterie ganze drei Stunden bräuchten? Klar, ich erhöhe meinen Bewegungsradius für Fahrten ohne Nachladen. Doch hier kann man aus zwei Richtungen dagegen argumentieren:

  1. Für die allermeisten täglichen Stadtfahrten genügen heutige E-Autos mit realistischen 100–150km Reichweite. Wie hoch dieser Anteil in Bezug auf die Gesamtfahrten ist, mag bei jeder Fahrerin unterschiedlich sein, aber da muss man einfach mal ehrlich zu sich selber sein.
  2. Das Unterwegs-Aufladen ist zwar derzeit alles andere als perfekt und muss viel(!) besser werden. Es darf aber kein Argument sein, überhaupt keine längeren Fahrten anzutreten. Mit dem Tesla-Modell sehen wir hier ganz klar die Zukunft: Statt in 5 Minuten 500km Diesel nachzutanken, steht man halt 20–30 Minuten an der Säule, dafür ist Zeit (und Geld) für einen Kaffee und ein Brötchen drin. Keine große Sache.

Ich würde die 500km also umformulieren: Lieber 250 realistische Kilometer und die Möglichkeit, an jeder Autobahn-Tankstelle mit mindestes 100 kW aufzuladen, rund um die Uhr, ohne Mitgliedschaft, am besten an einer überdachten Ladesäule und mit extrem(!) zuverlässiger Verfügbarkeit. Viele Säulenbetreiber ahnen gar nicht, wie viel an E-Mobilität-Begeisterung sie kaputt machen, wenn eine ihrer Ladesäulen nicht funktioniert. Stichwort WAF.

Insgesamt muss man sich aber mal langsam von der Idee lösen, mit dem Elektroauto das Verbrenner-Langstreckenfeeling 1:1 nachbilden zu müssen. Man reist langsamer und entspannter. Stressige und gefährliche Hochgeschwindigkeitstrips von München nach Berlin, mit denen die beschlipste 50plus-Geschäftsführung so gerne beim Smalltalk vor dem Meeting angibt, sind es aus meiner Sicht nicht wert, unbedingt nachgeeifert zu werden.

Ach ja, bevor ich es vergesse: Auf der A81 auf der Hälfte zwischen Würzburg und Heilbronn gehört eine verdammte Ladesäule hin!

]]>
Gerrit van Aaken 2016-07-29T00:00:00Z 2016-07-29T00:00:00Z Mein neuer Bluetooth-Kopfhörer tag:praegnanz.de,2016-07-29:f00e82e318bf59ffb58c0e9d341e0781 Und schon wieder ein Hi-Fi-Artikel hier im Webdesign-Blog, aber was soll’s – ich hab früher sogar über Bundeswehr-Essen geschrieben. Und wir sind ja unter uns!

Relativ zeitgleich mit Kollege Schlingel-Wölfle habe ich mich die letzten Wochen auf dem Markt für hochwertige Bluetooth-Kopfhörer herumgetrieben, und zwar speziell bei solchen Modellen, die man als „Over-Ear“ oder sogar „Around-Ear“ bezeichnet. Dabei waren mir zwei Eigenschaften besonders wichtig: Exzellenter Klang und hoher Tragekomfort. Es gibt noch eine Reihe weiterer Faktoren (Bluetooth-Stabilität, Verarbeitung, Bedienung, Design, Street Cred), doch diese waren für mich nicht unbedingt ausschlaggebend.

Am Anfang dachte ich, es muss unbedingt ein Modell mit aktivem Noise Cancelling sein, denn NC ist Zukunft und High-Tech und alle coolen Menschen stehen drauf. Also habe ich mir drei entsprechende Geräte im direkten Vergleich angehört: Den frisch erschienenen Bose QC35, den MOMENTUM WIRELESS aus dem traditionsreichen Hause Sennheiser, sowie den in bunten Farben erhältlichen MDR-100ABN von Sony.

Das überraschende Fazit meines Tests: Ich stehe nicht auf Noise Cancelling! Beim Aufsetzen der Ohrmuscheln fühlt es sich an, als ob ein Unterdruck an meinen Ohren saugt, und die hermetische Abschottung von der Außenwelt fühlt sich befremdlich an.

Sennheiser

Dem Klang tut NC freilich gut. Dabei hat jeder der drei Kandidaten eine eigene Charakteristik: Sennheiser strotzt mit absolut stabilen Bässen, die wie ein Fels in der Brandung stehen und unbegrenztes Potenzial besitzen. Leider ist die gesamte Aussteuerung mir persönlich ein wenig zu stark auf diesen mächtigen Bass fokussiert und in den mittleren Bereichen zu schwach. Ein ähnliches Phänomen beobachte ich bei meinen bisherigen Kabelkopfhörern, den Sennheiser HD 590. Es gibt sicher viele, die das mögen – ich gehöre nicht dazu. Aber ich respektiere es, weil es trotz allem nichts mit dem übertrieben vulgären und inakzeptablen Bass der berüchtigten Beats-Modelle zu tun hat.

Sony

Der Sony macht einen ordentlichen Job, was die Ausgewogenheit des Klangbildes angeht, schlampt aber bei Präzision und Räumlichkeit, insbesondere im direkten Vergleich mit den Kontrahenten. Alles tönt ein bisschen verwaschen und flach, was schade ist und der Preisklasse 300+ nicht gerecht wird.

QC35

Mein Klangfavorit ist der QC35, bei dem mir die Aussteuerung und die Präzision außerordentlich gut gefällt. Man merkt zwar, dass der Bass nicht die akustische Power eines Sennheisers besitzt, doch es reicht immer noch dicke aus für die allermeisten Musikgenres.

Das Bose-Modell ist gleichzeitig auch Weltmeister im Tragekomfort, er sitzt völlig natürlich am Kopf und stört nicht im geringsten. Das kann man in dieser Form weder von Sony noch von Sennheiser behaupten. Für Leute mit großen Ohren dürfte Sony keine Option sein, und das Sennheiser-Gerät ist nicht unbedingt das leichteste, sitzt auch relativ stramm am Kopf.

Dennoch: Noise Cancelling ist offenbar nichts für mich, also gingen die drei Spitzenmodelle allesamt zurück und ich bestellte zwei weitere Kopfhörer, nämlich den Bose SoundLink around-ear II und den B&O Play H7.

Soundlink

Man könnte meinen, dass der „kleine“ Bose einfach nur ein QC35 ohne NC ist, denn er sieht fast genauso aus und trägt sich auch genauso toll. Doch dem ist ganz offensichtlich nicht so. Dem SoundLink fehlt leider eine ganz gehörige Portion Bass. Und das muss schon was heißen, wenn ich das so schreibe! Es hat mich sehr gewundert, wie unterschiedlich die beiden Bose-Modelle klingen, obwohl ihr Erscheinungsdatum weniger als ein Jahr auseinanderliegt. Das kann es also leider auch nicht sein, was schade ist, denn man bekommt dieses Modell gerade recht günstig bei diversen Online-Händlern (ab ca. 210 Euro).

Beoplay

Ein ganz anderes Kaliber ist hingegen der H7 von Bang & Olufsen bzw. deren Mainstream-Marke „B&O Play“ bzw. „Beoplay“. Dieser Kopfhörer klingt wirklich fantastisch und entspricht zu 95% dem Klangbild, was ich mir versprochen hatte, als ich mich auf die Suche gemacht habe! Stabile, differenzierte Bässe, eine selbstbewusste Mittelfraktion und sehr klare Höhen machen das Klangbild rund, natürlich und in angenehmer Dosierung auch druckvoll. Ein bisschen trauere ich zwar dem Tragekomfort der Bose-Geräte nach, doch auch der H7 trägt sich hinreichend bequem. Er filtert die Außengeräusche nicht so perfekt und wird auch ein bisschen warm nach einer gewissen Zeit, aber das liegt auch ein wenig in der Natur der Sache. Zugegeben – die Touchbedienung ist großer Quatsch und funktioniert nichtmal annähernd zuverlässig. Geschenkt! Ich navigiere eh primär über das iPhone.

Bei Amazon gab es die H7 neulich zu einem Schnäppchenpreis für alle Prime-Kunden, allerdings nur in der zweithässlichsten Farbe (beige). Die hässlichste Farbe (grau) kostet aber wohl dauerhaft 40 Euro weniger als das Standard-Schwarz, welches derzeit mit 356 Euro zu Buche schlägt. (UVP liegt bei 449 Euro)

Mir ist klar, dass mehr als 150 Euro für einen Kopfhörer eine absolute Luxus-Anschaffungen ist. Man kann sich auch für 50 Euro sehr anständige Bluetooth-Over-Ears shoppen, bei denen man hübsch Musik hören oder Podcasts lauschen kann. Mir ging es aber primär darum, das klanglich Beste und komfortmäßig Angenehmste zu kaufen, was man zu normalen Nicht-Esoterik-Konditionen bekommen kann.

Ich hoffe in jedem Falle, dass ich nun für die nächsten 10–12 Jahre viel Freude am Lauschen der Musik haben werden. Audiophile schwören ja auf verlustfreies TIDAL-Streaming, wenn es denn schon unbedingt Bluetooth sein muss, was ja ebenfalls nochmal böse Datenkompression betreibt. Ich denke aber, auch Apple Music ist in Ordnung :-)

]]>