Lehrmittelfreiheit ist zunächst nur eine pekuniäre Freiheit.¹ Von der “Freiheit”, die Lehr- und Lernmittel “[…], zu kopieren, zu verbreiten, zu untersuchen, zu ändern und zu verbessern“², ist nicht die Rede. So auch in der Ausbildung zur Fachinformatikerin: hier ‘zaubert’ zuletzt doch jede Berufsschullehrerin ihr eigenes Stundenkonzept. Natürlich abgestimmt auf Rahmenlehrplan³ und Prüfungskataloge⁴. Und mit Verweis auf Fachbücher, um die Stoffwiederholung zu vereinfachen. Aber wieso? Warum so? Jede für sich ist doch doof. Und hat uns als Gesellschaft⁵ noch nie weitergebracht.

Lösung

Läge es da nicht nahe, wenn sich auch die Fachinformatiklehrerinnen ein Biotop an wirklich freien Materialien schüfen? Was wäre, wenn sie ihre Arbeit mit anderen Lehrerinnen und Schülerinnen unter einer Creative-Commons-Lizenz teilten? Was, wenn sie sie – wie in der Open-Source-Welt üblich — kollaborativ entwickelten?

Wäre es nicht ein Gewinn für alle, wenn die einzelne Lehrerin für ihr Spezialgebiet Stundenfolgen bereitstellte und sich für die anderen bei den Arbeiten der anderen bedienen dürfte — ohne urheberrechtliche Bedenken haben zu müssen? Sollte es nicht die Qualität erhöhen, wenn eine Community von Lehrerinnen und Schülerinnen über Issues auf Fehler hinweisen und mit Pull-Requests Verbesserungen direkt einbringen könnte?

Eben ganz so, wie auch Open-Source-Software entwickelt wird?

Den allgemeinen Kontext dafür setzt die UNESCO mit ihrem Begriff der Open-Educational-Resources. In Deutschland wird das von der OERinfo – der Informationsstelle Open Educational Resources – vorangebracht und vom Bundesministerium für Bildung, Familie, Senioren, Frauen und Jugend strategisch gefördert.

Genau darauf zielt das Projekt proTirone:

proTironeComputatri stellt freie Lehr- und Lernmaterialien für die Ausbildung zur Fachinformatikerin zur Verfügung — will sagen: Creative-Commons- bzw. FOSS-lizenzierte Dokumente und Skripte, die dem Rahmenlehrplan und den Prüfungskatalogen gerecht werden und deren Systematik der Lernfelder widerspiegeln.

Unter proTirone auf GitHub sollen Lehrerinnen und Schülerinnen

• fertige Lehr- und Lernmaterialien finden, für jeden Aspekt der Ausbildung zur Fachinformatikerin,
• die Quellen dazu herunterladen können, falls sie sie anpassen wollen,
• darauf vertrauen können, dass ihnen der Stoff mit Blick auf die Abschlussprüfungen I und II umfänglich und hochwertig aufbereitet wird und
• all das gebührenfrei und ohne urheberrechtliche Bedenken verwenden können.

Hintergrund

Ende 2024 sollte meine Arbeit als Principal OpenSource Advisor bei der Deutschen Telekom enden und meine reguläre Rentenzeit beginnen. Für so ein ganz losgelöstes Dasein war ich aber zu “jung”. Noch ein wenig Teilzeit wäre doch toll, dachte ich. Also habe ich auch beim Schulamt Weilburg nachgefragt. Weil ich ja im Lahn-Dill-Kreis wohne. Und was soll ich sagen: Ich hatte und habe die Ehre, als Lehrer für Fachinformatik an den Gewerblichen Schulen Dillenburg zu arbeiten. Vom ersten Tag der Rente. Hineingeworfen in die Lernfelder 9, 10–12c+d.

Da hätte ich gern auf fertige Unterrichtskonzepte zurückgegriffen. Schon Rahmenlehrplan und Lernfelder zu verstehen, war aufwendig. Noch mehr: meine eigenen Lehr- und Lernmaterialien zu erstellen. Was also lag näher als nachzufragen, ob es wirklich keine freien Repositories gäbe? Und warum sollte ich – nach erfolgloser Suche – nicht einfach mit einem solchen Projekt anfangen? Just for Fun!

Und was ist der größere Zusammenhang?

Auch unser Projekt proTirone beginnt mit dem wohin und wozu, gefolgt von einer kleinen Reorg und einer Generalisierung des Namens aus Anlass der OER-Konferenz 2026. Für das jeweilige Lernfeld den Scope zu klären, ist wichtig. Beim Unterricht heißt das nur anders, nämlich Curriculum. Die Lernfeldsystematik erlaubt es sogar, das Lernfeld 3 in den Lernfeld-9-Stunden für die AP1 zu wiederholen, systematisch und im Schnelldurchgang. Und es erlaubt AP2 spezifische Infos bereitzustellen, für die FIAE, die FIDV und die FIDP, samt AP2-Lösungen.

Im Übrigen: Männer sind mitgemeint.

1. vgl. https://kultus.hessen.de/schulsystem/lernmittelfreiheit
2. vgl. https://www.gnu.org/philosophy/free-sw.de.html
3. vgl. https://www.kmk.org/fileadmin/Dateien/pdf/Bildung/BeruflicheBildung/rlp/Fachinformatiker_19-12–13_EL.pdf
4. Die Prüfungskataloge werden von der Zentralstelle für Prüfungsaufgaben der Industrie- und Handelskammern herausgegeben. Sie bricht die Vorgaben des Rahmenlehrplans auf einen etwas konkreteren Level herunter. Der uform-Verlag macht die Kataloge kommerziell zugänglich. vgl. https://www.u‑form-shop.de/
5. vgl. https://www.linux-community.de/ausgaben/linuxuser/2012/12/von-der-freien-software-zur-freien-gesellschaft/

The post Lehrmittelfreiheit 2.0: proTirone appeared first on Freigiebigkeit.

Lösung

1. Konzipiere das Erscheinungsbild Deiner Site.
2. Wähle die entsprechenden Bootstrap-Farbcluster.
3. Schreibe die Funktionsfarben entsprechend um.
4. Definiere die eigenen CSS-Klassen gemäß Deines Konzeptes.
5. Weise die Klassen den intendierten Elementen Deiner Website zu.

Hintergrund

Bootstrap hat den RGB-Farbraum in 10 Farbcluster unterteilt: Blau (blue), Indigo (indigo), Violett (purple), Rosa (pink), Rot (red), Orange (orange), Gelb (yellow), Grün (green), Petrol (teal), Cyan (cyan), Grau (gray). Jeder Cluster beginnt mit einer entsprechend hellen Farbe und geht 9 Schritten bis zu einer entsprechend fast schwarzen Farbe. Definiert sind die Farben als SASS-Variablen, für jeden Cluster nach demselben Muster. Zugreifen können wir so etwa auf ein $green-100, $green-200, $green-300, $green-400, $green-500, $green-600, $green-700, $green-800, $green-900, wobei $green der Farbe $green-500 entspricht.

Wollen wir diese Farben in einem unserer Element verwenden, definieren wir in unserer Child-Themedatei scss/bscore_custom.scss eine CSS-Klasse .cdg600 { color: $green-600; } und weisen die dem intendierten HTML-Element zu, wie z.B. hier <code class="cdg600">$green-600</code>. Diese Technik verengt den RGB-Farbraum zwar, sie erleichtert es uns aber, farblich differenzierte und trotzdem einheitliche Themes zu erstellen.

Neben der rein technischen Farbbehandlung geht Bootstrap auch konzeptionell neue Wege: Es gäbe — so der Gedanke — Site-übergreifende kommunikative Aufgaben, die von verschiedenen Elementen einer Site ausgeführt werden (können). Bootstrap erlaubt es, diesen Funktionselementen typische “Funktionsfarben” zuzuordnen. Welche Elemente einer Site welche Funktion übernehmen, entscheidet die Web-Designerin — und ordnet diesen die entsprechend “Funktionsfarbe” zu.

Konkret geht Bootstrap davon aus, dass es in Sites typischerweise (mehrere) Elemente gibt, die Erfolg signalisieren, die abschrecken, warnen oder informieren. Oder, dass es primäre Elemente gibt, sekundäre oder teriäre¹, dunkle oder helle Elemente. Für diese seitenübergreifenden kommunikativen Funktionen definiert Bootstrap ‘funktionale Farben’. Das entsprechende Bootstrap-color-Howto zeigt die Vorbelegung dieser ‘Funktionsfarben’.

Ein Bootstrap-basiertes Theme muss also nur noch seine Elemente entsprechend der vorgesehenen Funktionen mit den zugehörigen CSS-Klassen auszeichnen, um ein minimal konsistentes Farbkonzept zu realisieren. Das hat bootScore vorbereitet. Allerdings verwendet es die Standard-Funktionsfarben von Bootstrap. So entsteht ein recht “buntes” Farbkonzept. Wir können die Farbwahl jedoch ‘entschärfen’, indem wir die CSS-Definitionen der ‘Funktionsklassen’ überschreiben und so die konzeptionell passende Farbe auf alle entsprechend markierten Elemente übertragen. bootscore demonstriert diesen Ansatz, indem es die Primärfarbe von Blau auf Rot umsetzt — mithilfe der Zeile $primary:#FF0000; in der Datei bscore_variables.scss.

Dabei müssen wir den Wert der gewünschten Farbe jedoch explizit zuweisen, anstatt eine der Variablen aus den von Bootstrap definierten Farbclustern zu verwenden. Das ist nicht das, was wir eigentlich wollen. Intuitiv würden wir $primary:$red; schreiben. Leider ist das nicht möglich, weil die bootScore-Datei bscore_variables.scss vor der entsprechenden Bootstrap-Datei geladen wird.². Um also die von Bootstrap definierten und von bootScore verwendeten Funktionsfarben anzupassen, müssen wir die bestehenden Definitionen überschreiben, in denen wir explizit die Werte der beabsichtigten Clusterfarben verwenden. Dazu nutzen wir unserer Datei bscore_variables.scss.

Die Umdefinition einer Funktionsfarbe passt dann allerdings auch abgeleitete Farben an: Setzen wir die Primärefarbe auf rot, werden die Links rot eingefärbt, die Hintergrundfarbe der Badgets auf ein helleres Rot und deren Linktext auf ein dunkleres. bootScore reicht dabei ’nur’ die Entscheidungen von Bootstrap durch.³

Als Ausgleich für die Komplikation können wir dann alle vordefinierten Bootstrap-Variablen in unseren eigenen CSS-Definitionen verwenden, die wir in unserer Bootscore-Datei bscore_custom.scss definieren. Mehr noch: wir können auch die von Bootstrap vordefinierten CSS-Klassen (text|bg|…)-(primary|secondary|…|danger|…‘) direkt unseren HTML-Elementen zuordnen, sodass auch diese unseres Konzeptes entsprechend eingefärbt werden. Und noch weiter und feiner: Wir können auch bestehende Klassen — wie etwa die CSS-Klasse card — mit der SASS orienierten Definition .card { backgroundcolor: var(--#{$prefix}dark); in unserer Datei bscore_custom.scss auf einen schwarzen Hintergund umsetzen.⁴ Damit würden alle Karten in unseren Übersichtsdatei ‘verdunkelt’.⁵

Weil wir jedoch oft genug nicht alle Elemente ändern wollen, die mit vordefinierten Klassen ausgezeichnet sind, landen wir zum Schluß doch wieder bei der traditionelle Methode: wir definieren unsere eigenen Klassen, nutzen dabei Farben aus den Bootstrap-Clustern, und weisen unsere Klassen dann in den Templates den von uns intendierten Elemente zu. Und wie finden wir diese? Indem wir den Quellcode unserer bisherigen bootscore-Seiten studieren — und etwas ‘rumprobieren.

Um es zusammenfassen: Für einheitliches und technisch eingebundenes Farbkonzept, müssen wir

1. unsere Ziele definieren (hier:
   • Unsere Site soll blau-weiß-grau erscheinen = in Datei _bscore_variables.scss einfügen:
     • $primary: #0d6efd; // Wert von $blue-500
     • $secondary: #6c757d; // Wert von $gray-600
     • $info: #6ea8fe; // Wert von $blue-300
   • Hervorstechende Elemente sollen violett erscheinen = in Datei _bscore_variables.scss einfügen:
     • $danger: #520dc2; // Wert von $indigo-600
     • $warning: #8540f5; // Wert von $indigo-400
   • Nebensächlicher Text soll lesbar ausgegraut sein.
   • Die weißen Artikelteaser sollen schwach-blau umrandet sein = in Datei _bscore-sustom.scss einfügen: .card { border-color: $blue-600; }
   • Die Teaser auf der Landingpage und auf den Übersichtsseiten sollen auf einem leicht blauen Hintergrund abgelegt werden. = in Datei _bscore-sustom.scss einfügen: .page-template-mylap , .hfeed { background-color: $blue-100;}
   • Header und Footer sollen weiterhin auf grauem Hintergrund dargestellt werden.
2. die funktionalen Farben entsprechend umschreiben — in unserer Datei bscore_variables.scss
3. unsere Siteelemente entsprechend ihrer Funktion mit den Funktionsklassen auszeichnen⁶
4. unsere eigenen CSS-Klassen entsprechend unserer Ziele definieren — in unserer Datei bscore_custom.scss
5. unsere Klassen den vorgesehenen Elementen unserer Site zuweisen⁷

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, einmal angefangen mit Verbesserungen der Bildbehandlung, werden der Web-Designerin auch die verwischten ‘primären Beitragsgilder’ auffallen. Sie wird Lösungen ausprobieren und verfeinern. Und sie wird sie u.U. auch mit neuen HTML‑5 Techniken angehen. Denn damit wird eine ausgefallenere Bildstrategie samt integrierter Lizenzerfüllung und das eigene Logo erst richtig sinnvoll. Wie auch immer: Bilder bringen Farbe ins Leseleben. Zuletzt sollte all das also auch in ein eigenes Farbkonzept eingebunden sein. Zu dieser Thematik trägt auch dieser Post etwas bei.

Im Übrigen: Männer sind mitgemeint.

1. semantisch ist dies wohl eine Abstufung der Wichtigkeit
2. bootScore sagt, dass es damit der Bootstrap-Richtlinie folgt.
3. Mehr noch: Gefragt danach, welche HTML-Elemente welcher Funktion zugeordnet sind, empfiehlt bootScore, das einfach auszuprobieren.
4. oder wie auch immer die Funktionsfarbe ‘dark’ gerade definiert ist
5. Das ginge zugegebenermaßen auch einfacher, nämlich mit der Anweisung .card { backgroundcolor: $dark}.
6. wie in u.a. Tabelle demonstriert
7. wie oben vorgeführt

The post Das eigene Farbkonzept mit bootScore appeared first on Freigiebigkeit.

Das Plugin bs-Cookie-Settings selbst liefert nur die Cookie-Abfrage. Wie man die aktiviert, hatte ich bereits beschrieben. Die entsprechende Semantik zu implementieren, sieht bootScore als Aufgabe der jeweiligen Web-Designerin. Hier eine Variante, die gern allgemein wiederverwendet werden darf:

Lösung

• Lade die JS-Cookie-Bibliothek von z.B. cdnpkg.com herunter und lege sie (entpackt) unter dem Namen js/js.cookie.min.js in Deinem Child-Theme-Ordner ab.
• Erweitere in Deiner Datei functions.php die Funktion bootscore_child_enqueue_styles() um den Eintrag

wp_enqueue_script('js-cookie',get_stylesheet_directory_uri().'/js/js-cookie-min.js',false, '', true););

• Erweitere die Datei js/custom.js Deines Child-Themes so:

jQuery(function ($) {

  $(document).ready(function(){
    const bsCookieSettings='bs_cookie_settings';
    const analytics = 'analytics';
    const advertising = 'advertising';
    const analyticDemoCookie='bsAnalyticCookie';
    const advertisingDemoCookie='bsAdvertisingCookie';
    const necessaryDemoCookie='bsNecessaryCookie';
    const demoCookieValue='demo-cookie';

    // alert("adding cookie writing algorithm");
    const bsv=Cookies.get(bsCookieSettings);
    if (bsv) {
      const allowedCookies=JSON.parse(bsv);
      // alert(allowedCookies.level);

      if (allowedCookies.level.includes(analytics)) {
        // alert("writing analytic cookies");
        if (!(Cookies.get(analyticDemoCookie))) { 
          Cookies.set(analyticDemoCookie, demoCookieValue, { expires: 100, path: '/' });
        };
      };
      if (allowedCookies.level.includes(advertising)) { 
        // alert("writing advertising cookies"); 
        if (!(Cookies.get(advertisingDemoCookie))) { 
          Cookies.set(advertisingDemoCookie, demoCookieValue, { expires: 10, path: '/' });
        };
      };
      // alert("writing necessary cookies"); 
      if (!(Cookies.get(necessaryDemoCookie))) { 
        Cookies.set(necessaryDemoCookie, demoCookieValue, { expires: 14, path: '/' });
      };
    };
  });

  // Do your other stuff here

}); // jQuery End

Hintergrund

Cookies könnten wir mit nativem Javascript setzen und evaluieren. Mit fertigen Bibliotheken geht es einfacher. WordPress bringt jQuery bereits mit. Und bootScore hat dies schon aktiviert und uns eine Möglichkeit geschaffen, eigene JavaScript-/JQuery-Funktionen in unser bootScore-Childtheme einzubauen.

Früher gab es für das Cookie-Management ein echtes jQuery-cookie Plugin. Das ist mittlerweile archiviert und in eine von jQuery unabhängige Javascript-Bibliothek js-cookie überführt worden. Um die zu nutzen, laden wir Datei js-cookie-min.js herunter und legen sie im JavaScript-Ordner unseres Child-Themes ab. Außerdem erweitern wir die Funktion bootscore_child_enqueue_styles() in unser Datei functions.php so, dass die Bibliothek js/js.cookie.min.js auch geladen wird.

Den Algorithmus zur Evaluation der Cookie-Settings implementieren wir danach in der Datei js/custom.js. Er wirkt so:

• Zuerst versuchen wir den vom bs-Cookie-Plugin unter dem Namen bs_cookie_settings abgelegten Cookie zu lesen.
• Wenn es ihn noch nicht gibt, hat unsere Leserin der Nutzung von Cookies noch nicht zugestimmt. Also dürfen wir noch keine schreiben.((Übrigens auch die technisch notwendigen nicht. Die dürfen wir zwar von gesetzeswegen ablegen, wir müssen unsere Leserin aber zuvor informieren, dass wir das tun. Und dass wir das getan haben, können wir wiederum anhand des Cookies bs_cookie_settings ‘belegen’. ))
• Sobald unsere Leserin den Cookie-Dialog in welchem Umfang auch immer ‘bestätigt’ hat, legt das bs-Cookie-Plugin den Cookie bs_cookie_settings ab. Sein Wert enthält ein JSON-Objekt:

{  "level": 
    [   "necessary",
        "analytics",
        "advertising"
    ],
    "revision":0,
    "data":null,
    "rfc_cookie":false
}

• Das müssen wir also erst parsen lassen, bevor wir — auf JavaScript-Ebene — auf die Liste der erlaubten Cookie-Gruppen via allowedCookies.level zugreifen und über die Methode includes eines Listenobjektes abfragen können, welche der Cookie-Gruppen necessary, analytics und /oder advertising uns unsere Leserin zu schreiben erlaubt hat.
• Und zu jeder zugelassen Gruppen schreiben wir dann die entsprechenden Cookies.((wobei wir uns bei den technisch notwendigen Cookies auf die gesetzliche Erlaubnis berufen.))

Und ein letzter Tipp noch: JavaScript erzeugt Seiten dynamisch. Gecacht werden die Ergebnisse. Deshalb müssen wir gelengtlich den Cache löschen, um die Ergebnisse unserer Veränderungen sehen zu können.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, zuletzt muss die Web-Designerin im Rahmen ihrer Anpassungen auch rechtliche Vorgaben beachten, seien es die der DSGVO, die für eine Cookie-Zustimmung und deren Beachtung oder die zur Erstellungen einer Datenschutzerklärung. In diesen Kontext gehören dann auch die Fragen nach dem Zweck eines Bildverzeichnisses, nach einem adäquaten Impressum oder nach einer hinreichenden Open-Source-Lizenzerfüllung. Dies ins rechte Licht zu rücken, will auch dieser Post unterstützen.

Im Übrigen: Männer sind mitgemeint.

The post Ein sauberes Cookie-Management — mit bootScore appeared first on Freigiebigkeit.

Um die Konsequenzen ihres Diktats zu verstehen, hier zuerst noch einmal meine aus dem YOAST-Angebot extrahierten 11 Gebote, mit deren Umsetzung ich YOAST bisher stets grüne Ampeln abringen konnte, eine für ‘SEO’ und eine für die Lesbarkeit. Unnötig zu erwähnen, dass ich di so aufbereiteten Seiten Google habe erfolgreich zum Indexieren((als Einzellinks via Search-Konsole, nicht per Sitemap allein)) übergeben können.

Lösung

• Definiere Dir eine Key-Phrase, die das Topik Deiner Seite((Der wolf-of-seo sagt, dass die Key-Phrase nicht erfassen sollte, worum es in Deinem Beitrag gehe, sondern wofür er perfekt sei. Wendet man jedoch die Regeln 2 und 3 an, schrumpft der Unterschied zwischen diesen Standpunkten erheblich.)) wiedergibt.((Achtung: 2 Wörter, allenfalls drei. Denn diese Key-Phrase muss in dieser Form an den Anfang des Titels passen und auch in den Fließtext eingebunden werden können. Vertraue nicht darauf, dass YOAST die syntaktischen Feinheiten der deutschen Sprache analysieren kann — auch wenn es das zu tun verspricht.))
• Setze die Key-Phrase((so, wie definiert)) an den Anfang Deines Seitentitels.((Wenn Du den so entstehenden slug’ Deiner Seite verkürzt, bleibe in Deiner URL wenigstens bei sprechende Syntagmen.))
• Integriere diese Key-Phrase((so, wie definiert)) in den ersten Absatz Deiner Seite.
• Baue die Key-Phrase((möglichst so, wie definiert)) in die mindestens 120 und höchstens 156 Zeichen lange Meta-Description Deiner Seite ein.
• Verlinke Deine Seite auf andere Seiten Deines Blogs zu dem Thema.
• Verlinke Deine Seite auf fremde Seiten zu dem Thema.
• Schreibe nur wenig Sätze mit mehr als 25 Wörtern.
• Nutze (logische) Konjunktionen, um (kurze) (Haupt)Sätze miteinander zu verknüpfen.
• Lasse Deine Absätze nicht über 150 Wörter ‘anschwellen’, bleib aber auf jeden Fall unter 200.
• Nutze nur wenig Passivkonstruktionen, mache aktive Aussagen.
• Beantrage in der Search-Konsole für Deine neue Seite explizit, dass Google sie indexiert((Verlass Dich nicht nur auf Deine aktualisierte Sitmap.))

Hintergrund

Eins gleich vorab: Wem jetzt schon schwant, dass dieser Post diesen Geboten nicht so richtig folgt, dem sei gleich gesagt: Yeep. Absichtlich. Testen wir doch einfach mal, was passiert, wenn wir unsere Posts nicht dem vereinheitlichenden Diktat von Google und YOAST unterwerfen.

Aus diesen ‘Empfehlungen’ ergibt sich nämlich ein anderer Schreibstil, als er Dir und mir (gelegentlich) vorschwebt. Dass passive Satzkonstruktionen schwieriger zu verstehen sind und damit mehr Lesearbeit erfordern, ist nachvollziehbar.((Wer’s nicht glaubt’, mag sich bewusst durch diesen absichtlich passivierten Absatz ‘quälen’)) Dass unser Lese(er)leben durch kurze Sätze erleichtert wird, ebenso. Werden wir von den Suchmaschinen gezwungen, so zu schreiben, tun sie unseren Leserinnen etwas Gutes. Auch wenn wir über die Drohung, unsere Texte würden nicht indexiert, ’sanft’ vom akademischen Schreibstil weggebracht werden.

Dies ärgert mich also nicht. Die Sache mit der Key-Phrase aber schon. Denn die verhindert, dass ich mit einem nur andeutenden Titel Leselust wecken und seine konkrete Bedeutung und seinen Kontext erst aus den ersten Sätzen erwachsen lassen kann. Freie Fahrt den Assoziationen — damit arbeite ich gern. Eigentlich. Darf es aber nicht, wenn ich die Gebote befolgen will. Ein Beispiel: Früher hatte ich meinen Artikel ‘Wolken und Listen — Zwei auf einen Streich!’ nur ‘Zwei auf einen Streich’ betitelt — und damit sogar ein wenig assoziative Nähe zum ‘tapferen Schneiderlein’ hergestellt.((Auch wenn mir das jetzt, wo ich das Märchen noch einmal ganz gelesen habe, selbst etwas unangenehm aufstößt. Es ist schon ein arger Blender, das kleine Schneiderlein, nicht nur ein Schlitzohr. Eigentlich kein Kontext, in den ich mich eingeordnet wehen möchte.)) Nur Zwei auf einen Streich, das ist ein eleganter Titel. Ihm die Key-Phrase ‘Wolken und Listen’ voranzustellen, nimmt dem Titel den Witz und macht ihn sperrig. Und spätestens, wenn wir die Key-Phrase im ersten Absatz noch einmal wiederholen, werden wir zu aufdringlichen Plapperinnen — nur um unsere grünen YOAST-Ampeln zu bekommen, will sagen: um indexiert zu werden.

Als ein aus SEO Sicht gutes Beispiel mag die Seite https://wolf-of-seo.de/was-ist/fokus-keyphrase/ betrachtet werden. Hier wird die Key-Phrase Fokus Keyword an den Anfang des Titels gestellt und gleich noch einmal im ersten, sehr kurzen Absatz wiederholt — zusammen mit ihrem Zwilling Fokus Keyphrase. Und in den ersten 6 Sätzen((was hier gleichbedeutend ist mit: in den ersten 6 Absätzen)) kommen die dann mehr als 10 ‘mal vor. Der ‘wolf of seo’ wird keine Schwierigkeit gehabt haben, seine Seite indexiert zu bekommen. Und mehr noch: inhaltlich ist dieser Artikel richtig gut! Nur stilistisch — stilistisch ist er grottig. Lest ihn einfach mal langsam, und Euch fällt dieses redundante Wortgeklingel sicher auch auf. Das Ärgerliche an dem Diktat einer guten SEOzität ist, dass wir offensichtlich so schreiben müssen, wenn wir indexiert werden wollen. Denn nur das, was indexiert ist, kann ja überhaupt gefunden und gerankt werden.

Habt Ihr den ’seo-wölfischen’ Text langsam gelesen, lest auch meinen Artikel so. Und es wird Euch direkt auffallen, dass er noch viel grottiger ist, als jener. Ich habe hier nämlich absichtlich viele der o.a. Gebote verletzt:

• Meine Key-Phrase ‘StilXpolizei’ kommt weder im Titel noch im ersten Absatz oder sonst wo vor, also auch nicht im slug.((Ich kann das Wort nicht riochtig schreiben, sonst meint YOAST: ”The keyphrase was found 1 time. That’s less than the recommended minimum of 3 times for a text of this length.”))
• Ich habe eine ‘Metadescription’ eingebaut, die absichtlich zu kurz ist und am Thema vorbeigeht.((Einfach mal den Sourcecode ansehen.))
• Dieser Post verwendet zwar Links nach extern, aber keine auf andere Seiten meiner Site.
• Mein Text verwendet zu viele Passivkonstruktionen((“15% of the sentences contain passive voice”)) und hat einen zu langen Absatz.((“1 of the paragraphs contains more than the recommended maximum of 150 words.”))

So bekomme ich für diesen Post eine orange YOAST-Ampel in Sachen SEO und eine rote in Sachen Lesbarkeit.

Damit können wir jetzt einfach mal testen, wie lange Google braucht, um diesen Artikel zu indexieren.((Um nicht Birnen mit Äpfeln zu vergleichen, werde ich Google zuerst nur über die Sitemap von dem neuen Post informieren. Und erst nach ein paar Monaten beantrage ich bei Google die Indexierung dieses Posts auch manuell.)) Sobald er im Index aufgenommen worden ist, sage ich Euch hier Bescheid. Ihr könnt es aber auch selbst testen. Sucht einfach nach SEOzität. Das Wort gibt es nämlich (bisher) nur in diesem Artikel.

• Sitemap aktualisiert: 2023-08-27 / evaluiert: 2023-08-28
• Post gefunden: 2023-08-28 / gecrawlt: 2023-08-28 / indexiert: 2023-08-28

Erstaunlich. So schnell. Ohne manuelle Bitte um Indexierung, ohne innere Verlinkung. Und das englische Pendant ist am 30.08. immer noch nicht gefunden, gecrawlt

The post Mein ‘googlierter’ Schreibstil appeared first on Freigiebigkeit.

Lösung

• Ersetze alle schematischen Slugs durch sprechende.
• Verlinke jeden Post und jede Seite mit allen anderen internen verwandten Posts oder Seiten.
• Installiere YoastSEO.
• Setze so viele seiner Verbesserungsvorschläge um, dass seine Ampeln auf grün springen.
• Beantrage bei Google für jede Seite und jeden Post gesondert die Indexierung.

Hintergrund

Was hatte mich zu dieser Einsicht getrieben? Nach der Anmeldung meiner Sitemap irgendwann im April hatte Google in 3 Monaten nur 6 meiner 109 Seiten indexiert. Über deren Qualität hatte es nicht gemeckert. Nur schlicht verkündet, dass es 81 Seiten oder Posts zwar gefunden und 17 zwar gecrawlt, aber nicht indexiert habe. Offensichtlich hielt Google meine Texte des Indexierens nicht für würdig. Trotz meines an sich ja interessanten Themas ‘bootScore’. Und trotz der ja immerhin so relevanten Artikel, dass sie das Projekt ‘bootScore’ zu Verbesserungen angeregt hatten. Über ein gutes Ranking brauchte ich also vorerst nicht nachzudenken. Ich musste mich ‘findbar’ machen.

Es hat mich eine Weile gekostet, zu verstehen, was passiert war. Und noch eine größere, es zu bereinigen:

Mit meiner Migration nach bootScore wollte ich auch meine Site verdichten. Sie leserinnen-freundlicher gestalten. Ihr die Redundanz austreiben. Weniger Schnick-Schnack sollte sie enthalten. Darum hatte ich meine thematischen Cluster sauber auf Kategorien und Tags abgebildet und denen meine Texte zugeordnet. Denn bootScore bot ja von Haus aus auf jeder Seite an, sich für jedes Schlagwort die zugehörigen Artikel anzeigen zu lassen. Warum also sollte ich in den einzelnen Seiten/Posts zusätzlich auf thematische verwandte Seiten/Posts verweisen? Warum händisch Seiten und Posts verlinken? Zu viel Schnick! Und warum sollte ich in mein Menü einzelne Seiten oder Posts einhängen? Zu viel Schnack! Ein Leitsystem aus den Kategorien und Tags sollte reichen. Damit hätten meine Leserinnen immer auf die zu diesem Thema auch relevanten Artikel zugreifen können. Eine zusätzliche ‘innere Verlinkung’ im Text, das wäre doch redundant. Dachte ich.

Genau das aber sieht Google anders! Seiten, auf die nicht einmal andere eigene Seiten verlinken, sind doch offensichtlich nicht einmal der Autorin wichtig. Sonst würde sie doch ihre Leserinnen dahinführen wollen. Warum also sollte Google sie indexieren? Darauf hatten meine Lehrbücher immer schon hingewiesen.((Pars pro toto: vgl. Czysch, Stephan: SEO mit Google Search Console, 2. Aufl., Heidelberg 2017, S. 168ff)) Mein Fehler, es zu ignorieren.

Wie der Fehler, meine Beiträge mit nichtssagenden ‘Slugs’ zu gruppieren. Wenn ich — zum Beispiel — ein Cluster ‘image’ benutzte, dachte ich, ich könnte meine Beiträge ‘image‑a’ , … ‘image‑i’. So hatte ich die gleichen Seitennamen auf der deutschen und der englischen Site. An sich keine schlechte Idee. Nur veranlasste da Google dazu, die Beiträge für unwichtig zu halten.((pars pro toto: vgl. Dziki, Julian: Suchmaschinenoptomierung für dummies, 2. Aufl., Weinheim 2021, S. 62)) Sie waren mir ja nicht mal einer Botschaft wert.

Nachdem ich diese Nebeneffekte verstanden hatte, überarbeitete ich alles. Ich ersetzte die symbolischen Seitennamen durch sprechende. Ich installierte YoastSeo und setzte so viele seiner Maßnahmen zu den Themen ‘SEO’ und ‘Lesbarkeit’ um, dass die entsprechenden Ampeln von rot auf grün wechselten. Oder zumindest auf gelb. Alles in allem eine sehr zeitaufwendige Arbeit.

Trotzdem fehlte damit noch die innere Verknüpfung. So schrieb ich für jedes Themencluster eine Zusammenfassung und verlinkte deren Wörter mit den verwandten Beiträgen und Seiten. Und da ich diese Zusammenfassungen in Zukunft absehbar häufiger würde aktualisieren müssen, erleichterte ich mir diese Tipparbeit, indem ich je Zusammenfassungen als ShortCodes implementierte. Jetzt reichte eine einfache Zeichenkette am Ende eines jedes Beitrags und er wäre intern passend verlinkt.

Den wirklichen Durchbruch in Sachen Indexierung erlebte ich aber erst, als ich jeden Post und jede Seite einzeln und händisch in der Google-Search-Konsole zur Indexierung angemeldet hatte — was auch hieß, jedes Mal zeitaufwendig die Indexierbarkeit überprüfen zu lassen. Heute hat Google von meinen 74 Artikeln und 18 Seiten meiner deutschen Site 84 indexiert. Und was nicht indexiert ist, muss — aus Leserinnensicht — nicht über Google gefunden werden. Wie z.B. meine Datenschutzseite oder der Bildernacheweis. Auf meiner englischen Site sieht es sogar noch besser aus: von den 53 Post und 15 Seiten sind 114 indexiert — was nur besagt, dass auch noch veraltete Links im Index enthalten sind. Diesmal bin ich den diesbzgl. Empfehlungen der Lehrbücher aber gleich gefolgt und habe die entsprechenden Weiterleitungen((pars pro toto: vgl. Eisenmenger, Richard u. Florian Brinkmann: WordPress 6. Das umfassende Handbuch, 2. Aufl., Bonn 2022, S. 517)) aktiviert — hier mit dem Plugin ‘Quick 301 Redirects’.

Was war nun die entscheidende Maßnahme für den Erfolg? Ich fürchte, es braucht alle. Auch wenn ich dafür meinen Schreibstil ändern musste. Vor allem bei der Umsetzung der YoastSEO-Empfehlungen. Aber dazu später mehr. So bald Google diese Artikel indexiert hat. Immer das Wichtigste zuerst.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun: Muss eine Web-Designerin ihr bisheriges WordPress-Theme aufgeben, braucht sie Ersatz. Ein freies Theme von der Stange wird sie personalisieren wollen. Zuerst etwas kosmetisch, dann in Sachen Grauwert, Mehrsprachigkeit und innerer Verweistechnik und Verlinkung. Schließlich wird sie besondere Footer aktivieren, ein Zweitmenü oder einen Copyright-Hinweis, bevor sie die ‘SEO-zität’ überprüft. Diesen Weg unterstützt auch dieser Post.

Im Übrigen: Männer sind mitgemeint.

The post Innere Verlinkung — ein Reset appeared first on Freigiebigkeit.

Lösung

• Verwende die JavaScript-Bibliothek Bootstrap so, wie sie von bootScore bereitgestellt wird
• Verwende die JavaScript-Bibliotheken so, wie sie von WordPress geliefert werden
• Erstelle eine Tabelle mit den Informationen zur JavaScript-Konformität
• Erstelle für jede von bootScore oder WordPress gelieferte JavaScript-Bibliothek eine entsprechende Zeile in der JS-Tabelle.
• Binde diese Tabelle in Deine Open Source Compliance Page ein.
• Mache die Open Source Compliance Page über den ‘Footer’ Deiner Seiten zugänglich

Hintergrund

bootSCore enthält einige JS-Komponenten. Zum Beispiel seine eigenen entfalteten JavaScript-Bibliotheken((vgl. ./bootscore/js/theme.js)) — implizit lizenziert unter der MIT, aber ohne explizites Lizenzierungsstatement — und die minifizierte Bootstrap JavaScript-Bibliothek((vgl. ./bootscore/js/lib/bootstrap.bundle.min.js)) — durch ein entsprechendes Lizenzierungsstatement explizit unter der MIT-Lizenz gestellt. Aber keine davon enthält den Lizenztext selbst. Auch WordPress bringt einige eigene und einige minimierte JavaScript-Bibliotheken von Drittanbietern mit((vgl. https://codex.wordpress.org/Javascript_Reference bzw. ./wp-includes/js)), wie z.B. die jQuery-Bibliothek¹, die ebenfalls unter der MIT lizenziert ist und ein entsprechendes Lizenzstatement enthält, aber nicht den Lizenztext. Unabhängig davon, von wem die Website-Besitzerin diese Bibliotheken erhalten hat — von bootScore oder WordPress -, ist sie es letztendlich, die die Lizenzanforderungen erfüllen muss. Denn es ist ja ihr System ist, das die JavaScript-Bibliotheken an ihre Leser weitergibt.

Aber worin besteht denn nun eigentlich die Herausforderung?

Wie die JavaScript-Bibliotheken von Bootstrap und jQuery auch, sind die meisten JS-Bibliotheken MIT lizenziert. Diese FOSS-Lizenz verlangt, dass beides — die Copyright-Zeile und der Lizenztext — zusammen mit dem Open-Source-Programm verteilt wird. “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”((cf. MIT License))

Für (L|A)GPL-lizenzierte JavaScript-Bibliotheken gilt fast dasselbe: Diese Lizenzen erlauben die Weitergabe des Quellcodes, “[…] provided that one conspicuously and appropriately publishes on each copy an appropriate copyright notice and disclaimer of warranty […] and gives any other recipients of the Program a copy of this License along with the Program”.((pars pro toto vgl. GPL‑2.0. Zusätzlich verlangt die (A)GPL, dass jeder Code, der die (A)GPL-lizenzierte Bibliothek usw. verwendet, ebenfalls unter der (A)GPL lizenziert ist (Copyleft-Effekt). Aber darum geht es in diesem Zusammenhang nicht.))

Wir haben hier also einen Widerspruch: Auf der einen Seite lädt ein Browser nicht nur den Seitentext (HTML) herunter, sondern auch die JavaScript-Bibliothek. Dieser Download verbreitet den Code und löst damit die Notwendigkeit aus, die Anforderungen der Open-Source-Lizenz zu erfüllen. Auf der anderen Seite enthalten die komprimierten Bibliotheken — selbst wenn sie als Paket von den Autorinnen angeboten werden — in der Regel nicht mehr die notwendigen Lizenzinformationen. Denn je kleiner die Bibliotheken sind, desto schneller erscheinen die Seiten auf den Rechnern der Leser angezeigt.

Der Website-Betreiberin bieten sich zwei Möglichkeiten, mit dieser Herausforderung umzugehen: Entweder sie heilt die implizit von WordPress und bootScore übernommenen Pakete nachträglich (und (halb)manuell). Oder sie verwendet sie so, wie sie sie bekommen hat. Es ist klar: Heilen würde bedeuten, dass wir diese Aufgabe jedes Mal wiederholen müssten, wenn wir WordPress oder bootScore aktualisieren. Also wäre der andere Weg weniger aufwendig. Also besser — sofern es eine Option gäbe, die Idee und die Anforderungen freier Softwarelizenzen dabei (doch) nicht zu verletzen.

Die Lösung ist dies:

Geben Entwickler ihre JavaScript-Bibliotheken als ‘minified’ Versionen weiter, gehen sie davon aus, dass ihre JS-Bibliothek auch in dieser Version verwendet wird. Daraus schließen wir, dass die Copyright-Owner diese Art der Nutzung implizit (konkludent) zulassen. Auch, wenn die Bibliotheken dabei gegen die von den Entwicklern selbst gewählte Lizenz verstößt. Trotzdem sollten wir unseren Benutzern eine andere Möglichkeit anbieten, diese Informationen zu erhalten. Wir zeigen damit, dass wir die FOSS-Idee verstanden haben und respektieren. Außerdem müssen wir darauf achten, nur die minifizierten JavaScript-Bibliotheken in unsere Site einzubinden. Also nur die Form, die die Entwicklerin selbst zur Verfügung gestellt hat. Sonst unterliefen wir ja unsere Argumentation. Im Falle der Bootstrap-JS-Lib in bootScore und der jQuery-JS-Lib etc. in WordPress dürfen wir davon ausgehen, dass sie dies getan haben.

Wir haben so im Falle eines Rechtsstreits um die Lizenzerfüllung bei JS-Bibliotheken((Ich habe noch nie von solch einem Disput gehört!)) ein starkes Argument für die Legalität unseres Vorgehens. Und wir befinden uns in sehr guter Gesellschaft: Die Sekundärliteratur diskutiert es in diesem Sinne((vgl. https://www.iusmentis.com/computerprograms/opensourcesoftware/license-notices-web-applications/)) und sogar die FSF schlägt vor, so vorzugehen.((vgl. https://www.gnu.org/licenses/javascript-labels.en.html und https://www.gnu.org/licenses/javascript-labels-rationale.html)) Und die hat nun wirklich nicht den Ruf, die Einhaltung von Lizenzen auf die leichte Schulter zu nehmen.

Und in welchem Zusammenhang …

… steht das mit einer systematischen Erfüllung von FOSS-Lizenzen? Nun, dazu müssen wir halt auch politische Konnotationen bedenken, konzeptionelle und kontextuelle Aspekte analysieren — einzeln oder gemeinsam auf Konferenzen. Wir müssen konkrete Fälle und allgemeine Nebenwirkungen durchdenken, für Software, Bilder oder Dokumente. Wir müssen Trends benennen und Leitfäden erstellen. Vornehmlich aber müssen wir die Automatisierung der Lizenzerfüllung vorantreiben, unser Lizenzwissen frei zur Verfügung stellen, es in kleinere Tools gießen und in größere Systeme einbringen: Denn FOSS lebt von der Freiheit durch Lizenzerfüllung, im Großen und im Kleinen.

Im Übrigen: Männer sind mitgemeint.

1. vgl. wp-includes/js/jquery/

The post Lizenzkonformes Javascript appeared first on Freigiebigkeit.

Als Ausgangspunkt hatte ich (bereits) WordPress installiert¹, (Test-) Daten eingegeben², bootScore installiert und es als Theme aktiviert³. So entstand — als Reihe von pimp your bootScore posts — folgender Weg:

1. Font Awesome — ein Symbol sagt mehr als 100 Worte: ShortCodes und CSS-Klassen
2. SEO von Anfang an: HTML-Semantik, Schlagwörter und Sitemaps und keine toten Links, bitte!
3. Das ‘(Un)Wichtige’ nach unten: Der dezente und umfassende Footer-Bereich für den ’nachrangigen’ Legalkram, das nachrangige Zweitmenü und die eigene Copyrightline
4. Mehrsprachigkeit mitdenken: Bilingualität ohne WP-Globus
5. Die Übersichtlichkeit: Das tiefer verzweigte Menü mit integrierten Shortcodes, sauberen Ebenen und lesbarer Stapelung, das dennoch kein H‑OVER-Menü sein muss.
6. Nicht frickeln, sondern automatisieren: Die eingebaute Silbentrennung
7. Ein Bild sagt mehr als 1000 Worte:
   • Das kann ein ‘manuell’ mit einer fancy Box in den Text eingefügtes Bild sein — gerne auch beschleunigt ausgeliefert per WordPress vorberechneter Bildgröße oder als SVG.
   • Oder ein automatisiert verwaltetes ‘Primäres Beitragsbild’. Nur sollte es möglichst wenig verwischt sein, wenn es des Responsiv-Designs wegen angepasst wird. Das organisiert das moderne IMG-Tag mit den Source-Angaben wohl am Besten. Schneller umzusetzen, aber weniger effektiv wäre es, WordPress eine weitere Bildgröße im Voraus berechnen zu lassen.
   • Wirklich freie Bilder gibt es im Netz, wenn wir ein Bildverzeichnis vorsehen, um die Lizenzvorgabn zu erfüllen.
   • Und die kleinen Browserbildchen neben der Url? Oder das Logo? Dafür nutzen wir bootScoores Logo- und Favicon-System.
8. Das Finden erleichtern: TAG-Wolken und Beitragslisten in der Sidebar
9. Der ‘gemauerte’ Überblick: Die Masonry-Beitragsliste
10. Das Wichtigste zuerst: eine eigene Landing-Page — selbst gestaltet - und dann weg mit dem, was ablenkt, auch mittels kontextsensitiven Sidebars und dezenterem Hinweise auf jüngere Posts
11. Designte Lesbarkeit: bootScore und der eigene generelle Font und ein Font für besondere Anlässe
12. Recht muss Recht bleiben: Datenschutz, DSGVO und Cookies, der Cookie-Dialog und seine Semantik mit bootScore
13. Der erste Eindruck: das Nutzerinnen orientierte Farbkonzept

So entsteht eine bootScore-basierte Website mit Responsive Design, die den Weg dorthin in sich selbst dokumentiert, auf dass ich auch in Zukunft nachschlagen kann, wie ich es in der Vergangenheit gemacht habe. Wenn dies auch anderen nützt, wäre das ein willkommener Nebeneffekt.

Im Übrigen: Männer sind mitgemeint.

1. Anleitung dazu gibt es zu Hauf, auch eine von WordPress selbst.
2. z.B. mit denen der zu migrierenden Site oder des Theme Unit Tests
3. z.B. gemäß bootScore-Anleitung

The post bootScore pimpen appeared first on Freigiebigkeit.

Lösung

• Definiere in Deiner Child-Theme-Datei scss/_bscore_variables.scs noch die Variable $menu-font-family: 'PT Sans', sans-serif, !default; (mit einem Menufont Deiner Wahl.)
• Trage in Deiner Child-Theme-Datei scss/_bsscore-custom.scs die folgenden Zeilen ein:

#bootscore-navbar{
  font-family: $menu-font-family;
}

.footerSubMenu {
  font-family: $menu-font-family;
}

• Weise über das WP-Backend den Widgets Footer 1 bis Footer 4, die eine Liste als Menü enthalten, mit <ul class="footerSubMenu"> die neue Klasse zu.

Hintergrund

Noch einmal kurz: Wie kann dieser Bedarf eigentlich entstehen?

Menüs sehen in der Regel mit serifenlosen Fonts besser aus. Haben wir in der Variable $font-family-base eh einen serifenlosen Default-Font festgelegt, ist alles gut. Verwenden wir aber einen Serifenfont, müssen wir — wenn wir es denn so wollen — nicht nur den Überschriften einen serifenlosen Font zuweisen, sondern auch die Menüs. Das Hauptmenu ist seitens bootScore in einem Bereich mit der ID bootscore-navbar eingebettet. Diese ID können wir weiterverwenden. Für die Submenüs im Footerbereich müssen wir uns eine entsprechende Klasse definieren und den Listen manuell zuweisen.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, hat Web-Designerin im Rahmen ihrer Anpassungen die Frage einer guten Bebilderung beantwortet, kann sie entspannt Tags und Wolken in ihre Site einbinden, ihre Überblicksseite verbessern und eine eigene Landingpage gestalten. Ob die entstandene Fülle der eigenen Leserin wirklich nutzt, ob es nicht schlanker geht und wie, ob dezentere Verweise und spezielle Fonts auch für besondere Anlässe die Lesbarkeit erhöhen, all das gilt es zu bedenken. Das tut auch dieser Post.

Im Übrigen: Männer sind mitgemeint.

The post Fonts für besondere Anlässe appeared first on Freigiebigkeit.

Lösung

• Wähle aus den Google Fonts Deine Schriften aus:
  • eine Schrift mit Serifen (z.B. pt-serif oder noto-serif),
  • eine dazu passenden serifenlose Schrift (z.B. pt-sans oder noto-sans),
  • eine dazu passende Monospace-Schrift (pt-mono oer noto-sans-mono)
  • und vielleicht noch eine spezielle Schrift für Überschriften (z.B. arima-madurai oder eb-garamond)
• Wähle jede Schrift im google-webfonts-helper an und
  • belasse den Zeichensatz (charset) auf latin
  • selektiere — so weit vorhanden — die Größen 400 und 700.
  • selektiere dazu — so weit vorhanden, die Stile regular, regular italic, bold und bold italic.
  • kopiere den im google-webfonts-helper dazu erzeugten font-face-code in die Datei scss/_bscore_custom.scss
  • lade das Zip-Paket aus dem google-webfonts-helper herunter.
• Erzeuge einen Ordner fonts in Deinem Child-Thema.
• Entpacke alle heruntergeladenen Zip-Pakete im Ordner fonts
• Erweitere die Datei scss/_bscore_variables.scss um die Zeilen:

  $font-family-base: 'Noto sans', Verdana, sans-serif !default;
  $font-family-sans-serif: 'Noto Sans', Verdana, sans-serif, !default;
  $font-family-monospace: 'Noto Sans Mono', 'Courier New', monospace, !default;
  $font-family-code: 'Noto Sans Mono', 'Courier New', monospace, !default;
  $headings-font-family: 'EB Garamond', Garamond, serif !default;
  $display-font-family: 'EB Garamond', Garamond, serif !default;

Hintergrund

Schriften sind — begrifflich und inhaltlich gesehen — ein weites Feld¹:

In der Typografie ist es üblich zwischen Serifen-Schriften und serifenlosen Schriften zu unterscheiden. Serifenschriften seien — heißt es — für gedruckten Fließtext besser, weil sie durch ihre horizontalen Verlängerungen am Buchstaben das Auge besser führen. Im Web galt dagegen lange, dass seriflose Schriften am Bildschirm lesebarer seien. Je feiner aber die Bildschirme über die Zeit wurden, desto feiner ließen sich auch die Serifen darstellen. Das Auge ermüdete weniger. Und so wird heute gesagt, es gäbe von der Lesbarkeit her keinen wirklich Unterschied mehr: Serifenschriften und serifenlose Schriften können gleichermaßen verwendet werden.

Für alles nur eine einzige Schrift zu verwenden, langweilt allerdings. Wenigstens die Überschriften und die Textkörper sollten sich unterscheiden. Andererseits reduzieren zu viele Schriften — der Unruhe im Gesamtbild wegen — die Lesbarkeit. Und Lesbarkeit und unmittelbare Wahrnehmbarkeit ist nun einmal der Qualitätsmaßstab. So arbeitet die moderne Web-Designerin mit Paaren, mit einem Font für die Überschrift, einem für den Fließtext. Und eben deshalb werden uns heute so oft Fontpaare ‘empfohlen’, bei denen die Fonts doch recht wild kombiniert werden.

In diesem Kontext wichtig ist auch die Unterscheidung zwischen font-familiy und font-face. Mit der CSS-Anweisung font-family: XYZ; teilen wir dem Browser — ungenau gesprochen — mit, dass er den Text in einem HTML-Tag mit dem Font XYZ darstellen solle. Tatsächlich weisen wir ihn aber an, den Text mit einem passenden Font aus der Font-Familie XYZ darzustellen. Mit der CSS-Anweisung @font-face {...}² haben wir ihm zuvor gesagt, dass eine bestimmte durchgestaltete Schrift aus einer bestimmten Schriftfamilie (font-family: XYZ) mit einem bestimmten Stil (font-style: [normal|italic]) und einer bestimmten Stärke (font-weight: [<400<...<700<]) zur Verfügung steht und wo er sie findet. Es ist dann Aufgabe des Browsers, die für eine bestimmte Stelle im HTML-Quelltext am besten passende Schrift konkret herauszusuchen. Denn er muss ja nicht nur die Schrift selbst darstellen, sondern auch die Spezifikationen normal, italic, bold, bold-italic berücksichtigen.³

Wenn ein spezifizierter Font doch nicht zu Verfügung steht — etwa, weil der Browser ihn nicht hat herunterladen oder verstehen können -, dann wählt der Browser einen anderen, möglichst ‘ähnlichen’ Font aus seinem Bestand. Und ‘ähnlich’ meint hier nur, ob es sich dabei auch um einen serifenlosen Font oder auch um eine serifenlose Schrift handelt. Wenn für die anderen geforderten Eigenschaften kein genau passender Font einer Familie bereitsteht, kann der Browser diese Eigenschaften ‘herstellen’, indem er den gewählten Font rechnerisch kippt oder verstärkt. Solche ‘berechneten’ Schriftypen sehen aber schlechter aus, als die explizit so gestalteten.⁴

Im Prinzip kann die Web-Designerin also nicht sicher sein, wie ihr Text auf dem Rechner einer Leserin tatsächlich aussieht. Um die Wahrscheinlichkeit zu erhöhen, dass die Designerin ihrer Leserin das liefern kann, was sie vorhat, dürfen in der CSS-Anweisung font-family: XYZ; mehrere Font-Familien kombiniert werden — bis hin zur generischen Familie serif, sans-serif oder monospace. Der Browser sichert zu, — für jeden Buchstaben — den ersten Font aus einer der Familien zu nehmen, mit dem er den Buchstaben wie gefordert darstellen kann. Ob und wie gut das klappt, hängt auch von Art und Güte des Browsers ab. Und um der Designerin noch mehr Gewissheit zu bieten, ist das Konzept der Web Safe Fonts entstanden⁵: Fonts, von denen frau weiß, dass sie auf den Geräten (meistens) zur Verfügung stehen. Aus diesen wählt sie ersatzweise die, die ihren Designvorstellungen zwar nicht optimal, aber noch gut gerecht werden.

Damit entsteht eine Strategie, Google-Fonts lokal zu integrieren⁶:

Wir entscheiden uns für eine Font-Paar und nutzen — wie von bootScore empfohlen — den google-webfonts-helper, um die entsprechenden Google-Fonts herunterzuladen und die auch generierten @font-face-Anweisungen in Datei scss/_bscore_custom.scss einzufügen.

In der Datei scss/_bscore_variables.scss legen wir dann fest, wofür die Schriften überhaupt verwendet werden sollen. Dazu nutzen wir die Boostrap-Methodik:

Bei Bootstrap legen wir über die Variable $font-family-base die ‘Hauptschrift’ fest. Das kann die Familie einer Serifenschrift oder einer serifenlosen Schrift sein. Über die Variable $font-family-sans-serif legen wir die serifenlosen Hauptschrift fest. Eine Variable $font-family-serif gibt es nicht. Wollen wir für die Überschriften eine andere Familie nehmen, als die der generellen Hauptschrift, wären dafür die Variablen $headings-font-family und $display-font-family zuständig. So lassen sich alle Kombinationen einfach abbilden.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, hat Web-Designerin im Rahmen ihrer Anpassungen die Frage einer guten Bebilderung beantwortet, kann sie entspannt Tags und Wolken in ihre Site einbinden, ihre Überblicksseite verbessern und eine eigene Landingpage gestalten. Ob die entstandene Fülle der eigenen Leserin wirklich nutzt, ob es nicht schlanker geht und wie, ob dezentere Verweise und spezielle Fonts auch für besondere Anlässe die Lesbarkeit erhöhen, all das gilt es zu bedenken. Das tut auch dieser Post.

Im Übrigen: Männer sind mitgemeint.

1. vgl. https://kinsta.com/de/blog/html-fonts/
2. vgl. https://www.w3schools.com/cssref/css3_pr_font-face_rule.php
3. vgl. https://technicalcommunicationcenter.com/2020/06/10/whats-a-font-font-family-typeface-font-face/
4. Deshalb ist es wichtig, die gewünschte Schriftfamilie mindestens in den Stärken ‘400’ und ‘700’ und die jeweils in den Typen ‘regular’ und ‘italic’ bereitzustellen.
5. vgl. https://www.w3schools.com/cssref/css_websafe_fonts.php
6. Die Alternative wäre, die Fonts fallweise direkt von Google-Font-Servern hinzuladen zu lassen. Das erleichtert Deine Arbeit. Und kompliziert Dein Datenschutzkonzept: Denn beim Herunterladen fragt Google Nutzerdaten ab, also die Deiner Leserin. Das verursacht Deine Site. Mithin müsstest in Deinem Datenschutzkonzept darauf hinweisen. Besser also, Du lädst die Fonts selbst herunter, integrierst sie in Deine Site und lieferst sie selbst mit aus.

The post Passende Web-Schriften appeared first on Freigiebigkeit.