Jens Oliver Meiert

Was ich beim Entwickeln von Googles Frameworks gelernt habe

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

In The Little Book of HTML/CSS Frameworks habe ich eine Übersicht und viele Praxistips 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 stolz auf das von uns Erreichte), noch über die 2008er und 2012er Frameworks, die ich bei Google baute, die letztlich auf Zehntausenden Google-Webseiten verwendet und ebenfalls ein paar Milliarden Mal aufgerufen wurden. Was folgt, erzählt einen Teil der Google-Geschichte.

Google j9t.

Abbildung: Nochmals danke, Masa.

Diese Geschichte sollte vermutlich mit dem Zustand von Googles informationsbezogenen Websites in 2008 beginnen, als einige qualitätsbewusste Webentwickler, einer von ihnen dann 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 einige andere Googler waren sich dessen bewusst, bestand die Unschönheit hauptsächlich in der schlechten Code-Qualität von Googles Websites sowie 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 es 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, deren Team der Namenskonflikt entging).

Go

Go war speziell, und ich hoffe, ich kann das so erklären, dass es nicht einfach wie Eigenlob rüberkommt. 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 designen (aber auch benutzen).

Besagte Landschaft bestand aus einem international verteilten Team – dem Webmaster-Team – mit bunt gemischten internen Kunden, die von PR über Recht 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 kriegen sicher bereits den Eindruck, dass dieser übereinstimmende Teil klein war, und dass das, und nicht die hohe Zahl von Unterschieden, einen zentralen Teil von Gos Vision ausmachte: 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 bis hin zu verbesserter Wartbarkeit. Zum anderen führt Einfachheit zu guter Entwicklerbenutzerfreundlichkeit (Entwicklerfreundlichkeit?) mitsamt, etwas das sicher 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 erstellte; 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 versuchte es dann mit so wenigen IDs und Klassen wie möglich – und zwar den 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. Das alles, um einen Eindruck von der Simplizität und Benutzerfreundlichkeit zu geben. (#about beruhte auf meiner Präferenz gegenüber #footer, #nav spiegelte das dann noch zukünftige nav-Element.)

Wie befriedigte Go dann die vielen Bedürfnisse, die in den Projekten mit unseren internen Kunden aufkamen? Wie vielleicht schon durchscheinen mag: Go tat das nicht. Eines der Designziele war es 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 dann einfach 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 jeweiligen Webentwickler, der an dem jeweiligen Projekt arbeitete (so dass diese Go oder Go X in ihrem default.css-Projekt-Stylesheet importierten, und dann 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 ein oder zwei »Hooks« entfernen, um Gebrauch von mittlerweile weiter verbesserter HTML- und CSS-Unterstützung 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 es versäumt, Gos Vorteile besser zu erläutern, und damit mehr Unterstützung in Team und Management zu erfahren. Manche Reibung im Team und einige verlorene Zeit dabei, Go zum Standard zu machen, waren das Ergebnis davon. Ich musste einiges 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 unsere Frameworks haben würde. Als Leiter des Projekts mutete dies für mich auch erst nach einem Update für Go an. Ich änderte diese Ansicht jedoch angesichts unserer ambitionierten Pläne:

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 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 nochmal 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 selbst mir 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 Fehlschlagen 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 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 ist, 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 recht rasch 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 27. Juli 2015.

Jens Oliver Meiert ist ein Autor, Entwickler (O’Reilly, W3C, ex-Google) und Philosoph. Er experimentiert mit Kunst und Abenteuer. Hier auf meiert.com teilt und verallgemeinert und übertreibt er einige seiner Gedanken und Erfahrungen.

Mehr Jens gibt es im Archiv und bei Goodreads. 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:

Oder vielleicht auf Twitter, Google+ oder XING hallo sagen?

Flattr? Fehler entdeckt? E-Mail an jens@meiert.com.

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

Stand: 5. Oktober 2017

»Der Zweck heiligt nicht die Mittel