Healthcare Website: terazjemy.pl

#Das Anmeldeformular ist der kleinere Teil der Arbeit

terazjemy.pl war ein polnisches Portal rund um gesunde Ernährung und Bewegung: Rezepte, Ratgebertexte und erklärende Beiträge. Die Seite ist seit einiger Zeit nicht mehr erreichbar, die folgenden Abschnitte beschreiben also Entwurfsentscheidungen und keinen aktuellen Zustand. Übergeben wurde das Projekt 2012, die Umsetzung dauerte rund sechs Wochen.

Ich beginne mit dem Newsletter, weil dieser Teil in Projektbeschreibungen fast immer in einem Halbsatz abgehandelt wird und in Wahrheit die meisten Fallstricke enthält. Ein Feld für die Adresse und eine Schaltfläche sind in einer Viertelstunde gebaut. Alles Schwierige liegt darunter.

Eine eingetippte Adresse ist eine Behauptung und keine Einwilligung. Solange sie nicht über einen Link in einer Nachricht bestätigt wurde, weiß niemand, ob sie überhaupt der Person gehört, die sie eingetragen hat. Die Anmeldung läuft deshalb zweistufig: das Absenden erzeugt einen wartenden Eintrag, erst die Bestätigung macht daraus ein Abonnement. Im deutschsprachigen Raum ist dieses Double-Opt-in-Verfahren ohnehin der Standard, den man erklären muss, wenn man ihn weglässt, und nicht umgekehrt. Ohne diesen Schritt kann jede Person eine fremde Adresse eintragen, und die Liste wächst um Einträge, die beim ersten Versand zu Beschwerden werden.

Genauso wichtig ist der Ausgang. Der Abmeldelink muss ohne Anmeldung und ohne Formular funktionieren, mit einem Klick, denn jede Hürde auf diesem Weg verlagert die Abmeldung in die Spam-Schaltfläche des Mailprogramms, und das kostet ungleich mehr als eine verlorene Adresse.

Der Versand selbst darf nicht innerhalb einer Nutzeranfrage stattfinden. Ein Versand an eine Liste dauert und scheitert auf Weisen, die mit der Person vor dem Formular nichts zu tun haben. Solche Aufgaben laufen über eine Warteschlange außerhalb der Anfrage, mit Wiederholung, denn eine vorübergehende Ablehnung durch einen Mailserver darf nicht bedeuten, dass die Nachricht verloren ist.

#Ein Rezept ist kein Artikel

Die Entscheidung, die alles Weitere prägt, sieht von außen banal aus. Ein Rezept ähnelt einem Artikel: Titel, Foto, Text. Es verhält sich aber völlig anders. Ein Artikel wird einmal gelesen, von oben nach unten, von einer Person, die still sitzt. Ein Rezept wird zweimal gelesen, einmal im Laden für den Einkaufszettel und einmal in der Küche für die Reihenfolge der Handgriffe, und der zweite Durchgang findet mit schmutzigen Händen und einem Bildschirm statt, der dauernd dunkel wird.

Ein Artikel hat eine Autorin und ein Datum. Ein Rezept hat eine Zubereitungszeit, eine Portionsangabe, einen Schwierigkeitsgrad, eine Zutatenliste mit Mengen und eine Reihe von Ernährungsmerkmalen, und all das sind Dinge, nach denen gesucht wird, keine Dekoration um den Text herum.

Ein Rezept konnte deshalb kein gewöhnlicher Beitrag mit Fließtext sein. Es brauchte eine eigene Struktur, in der Zutaten Listeneinträge mit Menge und Einheit sind, Schritte eine geordnete Folge bilden und Zeit, Portionen sowie Ernährungskategorien in eigenen Feldern liegen. Erst diese Struktur beantwortet eine Frage der Form “glutenfreies Abendessen unter dreißig Minuten”, und erst diese Struktur lässt sich so beschreiben, dass eine Suchmaschine sie wirklich liest.

#Einheiten, die sich nicht aufräumen lassen

Sobald Zutaten Listeneinträge werden, muss man festlegen, was eine Einheit ist, und an dieser Stelle trifft ein sauberes Datenmodell auf eine Küche. Rezepte sprechen nicht in Millilitern. Im deutschsprachigen Raum stehen neben Gramm und Milliliter der Esslöffel, der Teelöffel, die Prise und das Päckchen, wobei ein Päckchen Vanillezucker oder Backpulver eine Mengenangabe ist, die nur funktioniert, weil eine Handelsüblichkeit dahintersteht. Backanweisungen unterscheiden zusätzlich zwischen Umluft und Ober-/Unterhitze, und dieser Unterschied ist keine Formulierungsfrage, sondern verändert die Temperaturangabe. Polnische Rezepte haben ihre eigene Variante desselben Problems, dort lebt neben Glas und Löffel das Dekagramm weiter, eine Einheit, die außerhalb der polnischen Hausküche kaum jemand benutzt.

Zwei naheliegende Wege gibt es, und beide kosten etwas. Alles metrisch erzwingen ergibt einheitliche Daten und Rezepte, die sich wie eine Laborvorschrift lesen. Alle Einheiten so belassen, wie sie geschrieben wurden, ergibt natürliche Sprache und keinerlei Möglichkeit, etwas automatisch umzurechnen.

Wir sind einen dritten Weg gegangen. Die Einheit ist ein Feld aus einer geschlossenen Liste, und wo eine Umrechnung ins metrische System existiert, steht sie daneben. Das Rezept erscheint dann so, wie es geschrieben wurde, und die Portionsumrechnung arbeitet dort, wo sie etwas zu greifen hat, und verweigert sich offen, wo nicht.

Die Umrechnung selbst wirkt trivial und ist selten sauber gemacht. Die doppelte Portionszahl verdoppelt weder die Backzeit noch eine Prise Salz. Ein Mechanismus, der alles mit zwei multipliziert, erzeugt Rezepte, die sich nicht kochen lassen. Umgerechnet werden deshalb nur Einträge mit numerischer Menge und messbarer Einheit, Zeiten und beschreibende Hinweise bleiben unangetastet.

#Strukturierte Daten müssen aus derselben Quelle kommen

Rezepte gehören zu den wenigen Inhaltstypen, für die Suchmaschinen ein eigenes, ausführliches Vokabular bereithalten. Zutaten, Schritte, Zubereitungs- und Garzeit, Portionen und Nährwerte haben darin einen Platz, und ein korrekt beschriebenes Rezept erscheint anders in den Ergebnissen als ein gewöhnlicher Beitrag.

Die wichtige Entscheidung ist hier organisatorisch und nicht technisch. Strukturierte Daten lohnen sich nur, wenn sie aus derselben Quelle entstehen wie der sichtbare Inhalt. Tippt die Redaktion Zutaten in einen Fließtext, während jemand anderes separat Felder für die Suchmaschine befüllt, laufen beide Bestände innerhalb weniger Monate auseinander, und zwar lautlos, weil niemand strukturierte Daten mit den Augen liest. Die Rezeptfelder sind deshalb die einzige Eingabestelle, und sowohl die menschliche Ansicht als auch die maschinenlesbare Beschreibung werden daraus erzeugt.

Dasselbe Prinzip verhindert einen zweiten verbreiteten Fehler. Ein Nährwert ist eine Aussage über ein konkretes Gericht und hängt davon ab, welche Produkte verwendet wurden. Das Feld dafür ist deshalb optional und bleibt leer, bis es jemand bewusst ausfüllt. Ein Feld, das hilfreich einen berechneten Wert voreinträgt, erzeugt etwas, das wie eine Messung aussieht und keine ist.

#Der Kalender bestimmt die Last

Ein Rezeptportal hat keinen gleichmäßigen Verlauf. Es hat scharfe saisonale Spitzen, und im deutschsprachigen Raum ist die Spargelzeit dafür das klarste Beispiel: ein Zeitfenster von wenigen Wochen, das traditionell am Johannistag endet, mit Nachfrage nach Gerichten, die den Rest des Jahres niemand sucht. Weihnachten wirkt ähnlich, und Anfang Januar verschiebt sich nicht das Gericht, sondern die Absicht, weil dieselben Speisen in einer leichteren Fassung gesucht werden.

Daraus folgen zwei Dinge. Das erste ist eine Kapazitätsfrage, und sie ist enger, als sie klingt. Die Last verteilt sich nicht über das Jahr, also kann eine Konfiguration, die im März bequem reicht, in der Woche vor einem Fest nicht mehr reichen, und der Druck landet auf einem Dutzend konkreter Adressen und nicht auf der ganzen Seite. Ein schmaler Strom auf wenige Seiten ist gefährlich und zugleich leicht vorzubereiten, weil genau diese Seiten sich vorher im Zwischenspeicher aufwärmen lassen.

Das zweite ist redaktionell. Saisonales Material, das elf Monate stillliegt, ist schlafend und nicht tot, das Löschen nach der Saison also ein Fehler. Saisonale Rezepte behalten ein Erstveröffentlichungs- und ein Aktualisierungsdatum, und in dem Zeitfenster, in dem sie gesucht werden, kehren sie über thematische Verweise an sichtbare Stellen zurück und nicht über eine Neuveröffentlichung desselben Textes unter frischem Datum.

#Bilder sind die Nutzlast

Das Foto eines Gerichts ist hier Inhalt und keine Illustration. Ein Rezept ohne Bild funktioniert kaum, weil die Entscheidung mit den Augen fällt, bevor die erste Zutat gelesen wird. Food-Fotos sind zudem ungewöhnlich teuer in der Übertragung: viel Struktur, wenige gleichmäßige Flächen, schlechte Komprimierbarkeit, und oft mehrere Ansichten.

Die Performancearbeit ging deshalb dorthin, wo die Masse liegt. Dateien werden beim Hochladen in genau die Größen umgerechnet, die vorkommen: Kachel in der Übersicht, Hauptbild des Rezepts, gegebenenfalls Schrittfotos. Die Kachel ist nie das im Browser verkleinerte Hauptbild, denn eine Verkleinerung im Browser spart Pixel und keine Bytes, und auf die Bytes wartet die Leserin.

Bilder unterhalb des ersten Bildschirms laden erst, wenn sie in die Nähe des Sichtbereichs kommen. Die Grenze dieser Technik gehört dazu, weil sie oft gedankenlos angewendet wird: das Hauptbild eines Rezepts ist meist das wichtigste Element des ersten Bildschirms, und ausgerechnet dieses Bild zu verzögern verschlechtert den Eindruck, statt ihn zu verbessern.

#Was überhaupt zwischengespeichert wird

Ein Inhaltsangebot ist ein dankbarer Fall für Zwischenspeicherung: fast alles, was es zeigt, ist für alle gleich und ändert sich selten. Der Gewinn entsteht vor allem daraus, dass eine Anfrage nach einem bestehenden Rezept gar nicht erst bis PHP durchdringt.

Die tatsächlich veränderlichen Elemente sind wenige und lassen sich aufzählen: Kommentarzähler, Block mit den neuesten Beiträgen, Anmeldestatus. Jedes davon macht, direkt ins Dokument eingebettet, den Zwischenspeicher der ganzen Seite ungültig. Sie werden deshalb herausgelöst und getrennt nachgeladen, was nach zusätzlicher Komplexität klingt und das Gegenteil bewirkt: der Rest der Seite bleibt lange gültig, statt bei jedem Kommentar neu gebaut zu werden.

Redis trägt die Schicht darunter, also Abfrageergebnisse, die auf vielen Seiten wiederkehren: Kategorielisten, Beziehungen zwischen Rezepten, Auswertungen der Ernährungsmerkmale. Keines davon ist für sich teuer. Alle werden bei jedem Aufruf berechnet, und diese Art von Kosten zeigt sich erst unter Last und nie auf einer sauberen Testinstallation.

Das Ungültigmachen ist in dieser Anordnung schwieriger als das Füllen. Die Veröffentlichung eines Rezepts verändert nicht nur dessen Seite, sondern auch Kategorieübersicht, Startseite, Verwandtes-Block und Sitemap. Wird nur das Erste geleert, tut der Rest der Seite eine Stunde lang so, als gäbe es das Rezept nicht. Wird alles geleert, wirft jede Veröffentlichung den Zwischenspeicher der ganzen Seite weg. Der vernünftige Mittelweg leert genau das, was vom geänderten Objekt abhängt, und diese Abhängigkeit muss beim Bauen ausgeschrieben werden, weil kein Mechanismus sie von selbst kennt.

#Sicherungen und die Probe, die niemand macht

Sicherungen liefen automatisch und lagen außerhalb des Servers der Seite, mit Versionierung, damit sich nicht nur der Zustand vor einem Ausfall wiederherstellen ließ, sondern auch der Zustand vor einem redaktionellen Versehen von vor drei Tagen. Das sind zwei verschiedene Fälle, und nur der zweite kommt häufig vor.

Ein Punkt gehört wiederholt, weil er in Projektbeschreibungen fast nie auftaucht. Eine Sicherung, die niemand je zurückgespielt hat, ist eine Vermutung und keine Absicherung. Die Rückspielung muss mindestens einmal auf einer getrennten Umgebung stattfinden, damit bekannt ist, wie lange sie dauert und was in ihr fehlt, denn Lücken in Sicherungen zeigen sich ausschließlich beim Zurückspielen.

#Betreuung und nicht gebaute Richtungen

Die laufende Betreuung umfasste Aktualisierungen von Kern, Theme und Plugins, die Durchsicht der Protokolle, die Beobachtung der Indexierung und das Aufräumen von Datenbankabfragen, die mit der Zahl der Rezepte wuchsen. Getestet wurde auf einer Umgebung mit einer Kopie echter Daten, denn ein Angebot mit mehreren hundert Rezepten und umfangreichen Taxonomien verhält sich völlig anders als eine leere Installation mit Demo-Theme.

Ein Essensplaner, eine Anbindung an Ernährungs-Apps und ein Community-Bereich wurden als Richtungen besprochen. Gebaut wurde keine davon, und deshalb stehen sie hier als Richtungen und nicht als Funktionen. Jede hätte außerdem den Charakter des Projekts verändert: ein Planer führt Daten ein, die einer namentlich bekannten Person gehören, eine App-Anbindung führt eine Abhängigkeit von einer fremden Schnittstelle ein, und ein Community-Bereich führt Moderation ein, also fortlaufende menschliche Arbeit, die ein Inhaltsangebot bis dahin nicht brauchte.

#Was übertragbar ist

Übertragbar ist die Arbeitsweise: ein Rezept als Daten führen und nicht als Fließtext, menschliche Ansicht und maschinenlesbare Beschreibung aus einer Quelle erzeugen, beim Planen des Zwischenspeichers stabile Inhalte von veränderlichen Fragmenten trennen, alles nach außen Gehende über eine Warteschlange schicken und gegen eine Kopie der Produktion testen.

Nicht übertragbar ist das Inhaltsmodell dieses Projekts. Es entstand für eine Redaktion und für einen Auftrag aus der Kategorie Strony www. Der Feldsatz eines Rezepts spiegelt die Entscheidungen dieser Redaktion, und die Liste der Ernährungsmerkmale ist eine fachliche und keine technische Festlegung. Die nächste Umsetzung beginnt mit einer Analyse des Umfangs, und das Angebot folgt darauf.