Jens Oliver Meiert

Was ich beim Entwickeln von Googles Frameworks gelernt habe

Artikel vom 5. Oktober 2017. ISSN 1614-3124, #54.

Das hier oft erwähnte Buch zu Frameworks ist auch auf Deutsch erhältlich: Das kleine Buch der HTML-/CSS-Frameworks. Es beinhaltet auch diesen Artikel.

In The Little Book of HTML/CSS Frameworks habe ich eine Übersicht und viele Praxistipps zu Frameworks veröffentlicht; ich halte das Buch für eines meiner besseren Werke, auch wenn nicht jeder seinen Empfehlungen zustimmt (in den meisten Fällen sollten wir externe Frameworks vermeiden, weil sie die Vision beziehungsweise das erste Paradigma der Webentwicklung verletzen).

Nirgendwo habe ich jedoch über die Erfahrung gesprochen, manche größere Frameworks entwickelt zu haben – weder über das 2004er Framework (auch wenn wir es damals nicht so genannt haben) von GMX und Partner-Sites wie 1&1, was möglicherweise die erste europäische Milliarden-Besucher-Website bedeutete, die auf validem HTML und vollständig entkoppeltem CSS bedeutete (ich bin immer noch etwas stolz auf das damals von uns Erreichte), noch über die 2008er und 2012er Frameworks, die ich bei Google baute, die letztlich auf Zehntausenden Google-Webseiten verwendet und einige Milliarden Mal aufgerufen wurden. Was folgt, erzählt einen Teil der Google-Geschichte.

Diese Geschichte sollte vermutlich mit dem Zustand von Googles informationsbezogenen Websites in 2008 beginnen, als einige qualitätsbewusste Webentwickler, einer von ihnen ich, bei Google anfingen, zu arbeiten. Gelinde gesagt: Es war nicht schön, und wir erhielten viel Kritik von einer Vielzahl angesehener Entwickler (dies machte dann einen der Gründe aus, warum es aufregend war, sich dem Webmaster-Team anzuschließen).

Von außen, und so einige andere Googler waren sich dessen bewusst, bestand die Unschönheit hauptsächlich in der schlechten Code-Qualität von Googles Websites und Produkten. Die Google-Homepages erzielten dabei viel Aufmerksamkeit, und Produkte ließen Besucher zwar verzücken aber Qualitätsprobleme auch im Bereich Barrierefreiheit wurden von Fachleuten nicht übersehen.

Von innen, und von hier an werde ich nur noch von Google-Websites (und nicht mehr Produkten) sprechen, war klar, dass uns effektivere Prioritäten, Prozesse und – noch wichtiger – Werkzeuge fehlten; zu diesem Zeitpunkt wurden die meisten von Googles Websites händisch erstellt und gewartet.

An diesem Problem arbeitete das Team, speziell das Kernteam in Mountain View sowie ein paar Entwickler in Zürich, um ein Content-Management-System zu implementieren, das auch in Google-Dimensionen funktionierte. Wir veröffentlichten regelmäßig Websites und Landeseiten in Dutzenden Sprachen, und unsere Code-Basis, HTML-Dokumente mitsamt anderem Beiwerk, umfasste schon 2008 eine sechsstellige Zahl von Dateien.

Eine Herausforderung wie auch Gelegenheit war die Diversität der Sites und Seiten, die wir erstellten. Ja, es gab eine Google-Kernidentität und Google arbeitete an einem unternehmensweiten Styleguide (die UX-Organisation um Irene hatte sich dem angenommen) – aber viele unserer Websites, zumindest Elemente darauf, waren einzigartig und einmalig. Diese Einzigartigkeit machte einen Grund aus, warum es noch keine solide technische Basis gab, und ich begann proaktiv, das erste Google’sche HTML-/CSS-Framework zu entwickeln: Go (es ging der Programmiersprache voraus, dessen Team der Namenskonflikt entging).

Go

Go war speziell, was schlicht den einmaligen Umständen geschuldet ist. Go ist, und selbst in minifizierter Form kriegt man davon einen Eindruck, ein kompaktes Framework. Das ist by design. Aber wie wurde es entworfen, und warum? Dazu sollten wir nochmal auf Googles Landschaft an Websites blicken – ein Blick, der tatsächlich Pflicht ist, wenn wir Frameworks entwerfen (aber auch benutzen).

Besagte Landschaft bestand aus einem international verteilten Team – dem Webmaster-Team – mit bunt gemischten internen Kunden, die von Google Corporate Communications über Legal bis hin zu Marketing reichten, das eine große Zahl von sehr unterschiedlichen, lokalisierten – bis zu 40, manchmal 50 Sprachen – Websites betrieb. Das erschuf einiges an Einzigartigkeit. Gleichzeitig geschah alle Arbeit unter dem Schirm von Google, einige Designaspekte wurden also von allen Seiten geteilt.

Sie nehmen sicher schon wahr, dass dieser übereinstimmende Teil klein war, und dass das, und nicht die hohe Zahl von Unterschieden, einen zentralen Teil von Gos Vision ausmachen musste: Go sollte nicht versuchen, »alles« abzudecken, was wir taten, sondern gut an der Basis funktionieren. Den kleinsten gemeinsamen Nenner finden und abbilden, das war die Idee.

Das nächste Prinzip hinter Go war Einfachheit, da diese Einfachheit große Gewinne versprach: Zum einen hat Einfachheit eine große Zahl großer technischer Vorteile, von höherer Geschwindigkeit über größere Robustheit bis hin zu leichterer Wartbarkeit. Zum anderen führt Einfachheit zu guter Entwicklerbenutzerfreundlichkeit (Entwicklerfreundlichkeit?) mitsamt, etwas das für die Arbeit an Go relevant war, einer besseren Chance auf Akzeptanz und Annahme.

Diese Chance resultierte dann in etwas, das ich auswendig illustrieren möchte, fünf oder sechs Jahre, nachdem ich die letzte Go-Seite erstellt habe; man konnte ein HTML-Dokument wie folgt schreiben:

<!DOCTYPE html>
<title>Google Test</title>
<meta charset=utf-8>
<link rel=stylesheet href=/css/go.css>
<h1><a href=/><img src=/logo alt=Google></a> Test</h1>
<p>Das ist nur ein Test [mit validem HTML].

Ebenso auswendig hervorgekramt, Go verwendete dann so wenig Klassen und IDs wie möglich – und zwar die folgenden: .rtl, .compact, #about, #nav und #aux. Die Grundseitentypen waren ganze Breite, ganze Breite mit Navigation, kompakte Seite (schmal) und kompakte Seite mit Navigation. Zentrierung wurde durch die .compact-Klasse erzielt (auf body); das Hinzufügen einer Navigationsliste (#nav) erzeugte »automatisch« die Navigationsseitentypen; &c. Alle Seitentypen waren liquid und inhärent mobil-bereit. Soviel, um einen Eindruck von der Simplizität und Benutzerfreundlichkeit zu geben. (Als HTML 5 noch weiter keimte und es noch keine logischen Eigenschaften in CSS gab, beruhte #about auf meiner Präferenz gegenüber #footer, und #nav spiegelte das sich dann noch in Planung befindliche nav-Element wider.)

Wie befriedigte Go dann die vielen Bedürfnisse, die in den Projekten mit unseren internen Kunden aufkamen? Wie auch schon durchscheinen mag: Go tat das nicht. Eines der Designziele war tatsächlich, das gar nicht erst zu probieren. Go definierte den Kern von Googles Websites auf eine Weise, die so einfach wie möglich gehalten wurde, und erkannte die Einzigartigkeit und systemische Nicht-Managebarkeit all der unterschiedlichen Google-Sites durch zwei andere Entscheidungen an:

  1. das Definieren anderer populärer Seitenelemente (wie Formulare) in einer Bibliothekserweiterung, »Go X« (man importierte in diesem Fall go-x.css, was sehr wenig und damit akzeptable kognitive Zusatzbelastung darstellte);

  2. das Teilen der Verantwortung und das Überlassen von allem anderen an den Webentwickler, der an dem jeweiligen Projekt arbeitete (so dass diese Go oder Go X in ihrem default.css-Projekt-Stylesheet importierten und ihr eigenes Ding machten).

Auf rasche Annahme und Akzeptanz hoffte ich nicht nur durch Benutzerfreundlichkeit – die Stylesheet-URL verinnerlichen und in ein einfaches HTML-Dokument mit Google-Logo packen –, sondern auch durch ein paar weitere Faktoren, die an qualitätsverwandte Logistik erinnern:

Aus technischer Sicht halte ich Go für eines der elegantesten Dinge, die ich bisher entwickelt habe. Go war einfach, leicht, robust, erweiterbar, skalierbar und wartbar. Bis heute erscheint es basal und unspektakulär, und genau das war sehr sorgfältig überlegt und funktionierte außerordentlich gut. Acht Jahre später gibt es wenig, das ich ändern würde (ich würde Gebrauch von neueren HTML- und CSS-Features machen, um Go noch kompakter zu machen).

Bei alldem aber muss ich auch sagen, dass ich aus technischer und leitender Perspektive damit gescheitert war, größere Akzeptanz für Go zu finden. Ich hatte Fehler gemacht, andere erfahrene Entwickler im Team einzubeziehen und mit ihnen zu arbeiten. Ich hatte versäumt, Gos Vorteile besser zu erläutern und damit mehr Unterstützung in Team und Management zu gewinnen. Manche Reibung im Team und einige verlorene Zeit dabei, Go zum Standard zu machen, waren das Ergebnis davon. Ich musste lernen.

Maia

Vorwärts. Eine der dringendsten Fragen, die ich mir 2012 stellen musste, war, wann wir ein neues Framework bauen würden. (Wann würden Sie?) In meinem Kopf war das Denken bislang zu aktualisieren, iterieren, ohne Versionierung, weil Webdesign, ebenso Webentwicklung, ein Prozess ist – und trotzdem wich ich das erste Mal von dieser Position ab. Warum?

Als wir – immer noch Googles Webmaster-Team – an einem neuen Design für alle informationsbezogenen Google-Sites arbeiteten, war absehbar, dass dies Konsequenzen für den Einsatz von Frameworks haben würde. Als Leiter des Projekts mutete dies für mich erst nach einem Update für Go an. Ich änderte diese Ansicht jedoch angesichts folgender Überlegungen:

Diese Punkte führten mich dazu, Bemühungen zu unterstützen und dann anzuführen, ein neues Google-Web-Framework zu entwickeln, ein Framework, dass ich »Maia« taufte (es ist ebenfalls noch in Gebrauch, obwohl ich nicht weiß, ob es gewartet und wie sehr es modifiziert wurde) – »Maia« wegen eines Faibles für griechische Mythologie: Maia, Mutter von Hermes.

Die Geschichte von Maia ist sehr anders als die von Go, dadurch dass Maia eine offiziell abgesegnete Teamunternehmung war, mit einem Team von fünf Webmastern, für deren Arbeit ich verantwortlich war. Der Prozess und die Organisation waren ähnlich zu dem, was ich in The Little Book of HTML/CSS Frameworks beschreibe – angefangen bei der Motivation, eine zugeschnittene Lösung zu den eigenen (Design-)Problemen zu schaffen, über die Gründung eines Team, das über entsprechende Ziele und Werkzeuge verfügte, bis hin zur Kommunikation an eine nochmal größere Organisation. Ich glaube, dass The Little Book of HTML/CSS Frameworks ein nützliches Buch ist, um mehr über solche Entwicklung zu erfahren, aber es folgen hier die Eckpfeiler für die Arbeit an Maia:

Abgesehen von den komplexeren visuellen und technischen Anforderungen war die Entwicklung von Maia als Team der größte Unterschied zur Arbeit an Go, und zusammen mit umfangreicherem Management-Support wohl der wesentliche Faktor dabei, weitreichende Akzeptanz zu gewährleisten und gar zu beschleunigen.

Es fällt auf, dass ich Maias Geschichte sehr knapp halte, sie gar abrupt beende; aber genau der Umstand, dass Maia Teamarbeit war, lässt es mich bevorzugen, hierüber – wenn das möglich wäre – mit dem Team zu schreiben.

Erkenntnisse

Das Geschilderte ist schon mit einigen Fehlschlägen und Lektionen versehen, aber dies ist was ich hervorheben möchte.

  1. Auch wenn ich das nicht direkt bei Google lernte – ich bin Idealist –, will ich es doch erwähnen, weil es mir wichtig erscheint: Nicht nur durch die Fokussierung und Segmentierung von Framework-Verantwortlichkeiten (wie bei Go und Go X getan) ist es absolut möglich, zugeschnittene, effiziente und trotzdem benutzbare Frameworks zu bauen und zu warten. (Das ist auch ein Kernpunkt in The Little Book of HTML/CSS Frameworks. Es gibt keinen Grund, unnötigen Code und schlechte Qualität einfach hinzunehmen.)

  2. Um eine hochwertige Lösung zu bauen, ist Kommunikation wichtiger als Konsens. Ich habe meine Probleme mit Demokratie als Entscheidungswerkzeug, da ich diese selten die beste Lösung erbringen sehe – und im Technischen gibt es oft so etwas wie ein »bestes«. Aber ich habe auch Probleme gehabt, als ich ein Team vernachlässigte, um einfach die Lösungen voranzutreiben, die ich für am besten erachtete. Eine Alternative ist, die beidseitige Kommunikation zu verbessern: dem Team zuhören, andere Experten aus dem Team involvieren, Unterstützung vom Management einholen, &c.

  3. Dies kam gar nicht auf, als ich über Maia sprach, und ich widerspreche auch meinem vergangenen Selbst: Es ist kritisch, zu vermeiden, ein zusätzliches Framework zu bauen. Die Vision muss sein, zu iterieren und zu warten, niemals »Fire and Forget«. Ich hatte nichts großartig probiert, nicht gekämpft; ich hatte den Gewinn mitgenommen, den ich mit Go hatte, und dann den bequemen Weg beschritten, halbherzig ein kleines Team zu führen, um Konfrontation innerhalb der Organisation zu vermeiden (Unternehmenspolitik hatte dann auch mich erreicht, so scheint es). Das ist ein sehr anderer Schnack so plötzlich, aber ich hatte den wohl technisch inferioren Pfad genommen, als ich uns zugestand, an einem anderen Framework zu arbeiten, und damit einiges von dem geopfert, von dem wir zuvor so profitierten und was Go auszeichnete.

❧ Zum Abschluss wünsche ich, dass hier einige Dinge dabei sind, die für Ihre eigenen Framework-Entscheidungen nützlich sind, so dass Sie ernten können, was wir geerntet haben, ohne die Fehler zu machen, die ich gemacht habe. Selbst wenn ich diese eher anschnitt. (Und wenn Sie noch mehr mögen, werfen Sie einen Blick auf The Little Book of HTML/CSS Frameworks und meine englischen Beiträge zum Thema Webentwicklung.)

Mit herzlichen Wünschen an das alte Webmaster-Team. Die Arbeit mit euch allen war eine große Ehre und ein großes Vergnügen. Ich denke gerne daran zurück.

Über den Autor

Jens Oliver Meiert, Foto vom 19. April 2019.

Jens Oliver Meiert ist ein technischer Leiter und Autor (sum.cumo, W3C, O’Reilly). Er experimentiert gerne, auch in den Bereichen Philosophie, Kunst und Abenteuer. Hier auf meiert.com teilt und verallgemeinert und übertreibt er einige seiner Gedanken und Erfahrungen.

Wenn Sie eine Frage oder ein Anliegen (oder eine Empfehlung) zu dem haben, was er schreibt, senden Sie gerne jederzeit eine Nachricht.

Ähnliche Themen

Das könnte Sie ebenfalls interessieren:

Schwerpunkt:

Auf dem Laufenden bleiben? Am einfachsten per Feed oder auf Twitter.

Fehler entdeckt? E-Mail an jens@meiert.org.

Sie sind hier: StartseitePublikationen → Was ich beim Entwickeln von Googles Frameworks gelernt habe

Stand: 5. Oktober 2017

»Niemand ist wirklich ›gut dran‹ wenn er gut dran ist, während andere sterben.«