Kompletter Neubau eines Industrieauftritts

Der alte Auftritt war ein WordPress-Theme mit Baukasten darüber. Die Überschriften standen in der Vorgabeschrift, der Titel im Browsertab schrieb den Firmennamen falsch, und über einer Rubrik namens Our Customer Stories stand nichts. Kein Projekt, keine Zeile. Die Navigation trug einen Punkt Projects, und wer ihn anklickte, landete im Kontaktformular.

Bebildert war das mit gekaufter Fotografie, die zu jedem beliebigen Unternehmen gepasst hätte: Menschen an Laptops, Besprechungen an hellen Tischen. Für eine Beratung, die Drehrohröfen auslegt, Ausschreibungen schreibt und auf der Baustelle bleibt, bis die Linie läuft, ist das nicht nur beliebig, es ist ein Widerspruch zum Gegenstand.

Und die Zahlen, die den Auftritt tragen sollten, waren rund: 12+ Jahre, 50+ Kunden, 200+ Projekte, 14 Länder. Runde Zahlen sind auf einer Referenzseite die schwächste Form von Beleg, weil sie sich nicht prüfen lassen und deshalb nichts kosten.

Entstanden für Colleagues Consultants Private Limited.

Der Kunde führt seit der Gründung eine eigene Referenzliste: jeder Auftrag, mit Kunde, Ort, Leistung und Geschäftsjahr. Sie lag als Präsentationsdatei vor und war noch nie veröffentlicht. Damit war die Frage nicht mehr, wie man den Auftritt glaubwürdig klingen lässt, sondern nur noch, wie man diese Datei in eine Website bekommt, ohne sie abzutippen.

Ein Skript liest die Datei direkt, mit einem eigenen kleinen Zip-Leser über die Standardbibliothek und ohne Fremdpaket, und schreibt daraus die Sammlung, aus der die Seite baut. Aus dieser Sammlung werden anschließend die Kundenliste und die Länderliste gerechnet, nicht gepflegt. Eine neue Ausgabe der Referenzliste ist damit ein Befehl und kein Redaktionsprojekt.

Was danach auf der Seite steht, ist gezählt: 343 Vorgänge, 55 namentlich genannte Auftraggeber, 16 Länder, 18 ununterbrochene Geschäftsjahre. Die runden Zahlen des alten Auftritts sind ersatzlos gestrichen.

Das hatte einen Grund, der über Ordnungsliebe hinausgeht. Beim Abgleich zeigte sich, dass ein Teil der alten Länderliste nicht belegbar war. Die falschen Einträge hatten fünf Prüfrunden überstanden, weil man einer Liste, die plausibel aussieht, beim Korrekturlesen nichts ansieht. Genau deshalb werden Kunden und Länder heute abgeleitet und nicht mehr geschrieben: eine Angabe, die aus dem Register gerechnet wird, kann nicht von ihm abweichen.

Die Stockfotografie ist nicht durch bessere Stockfotografie ersetzt worden, sondern durch zehn von Hand gezeichnete Schemata: die Zementlinie vom Steinbruch bis zur Verladung, der Schüttgutfluss, die Stahlroute, der Projektlebenszyklus und vier isometrische Sektorenbilder. Es ist die Bildsprache einer technischen Zeichnung, nicht die einer Bildagentur, und sie sagt in jedem einzelnen Bild etwas über den Gegenstand aus.

Die Regeln dahinter sind eng gehalten, damit die Sammlung als eine Handschrift liest: genau zwei Strichstärken, Beschriftungen in der Monospace-Ebene mit Führungslinien, und Rot ausschließlich dort, wo es etwas bedeutet, also an Flusspfeilen, heißen Zonen und aktiven Knoten. Gefärbt wird nicht im Bild, sondern über Variablen, weshalb dieselbe Datei im hellen und im dunklen Schema richtig aussieht, ohne zweimal zu existieren.

Beschriftungen in einer Zeichnung sind die Stelle, an der so eine Sammlung auseinanderfällt: eine rutscht über eine Kante, zwei überlappen, und niemand merkt es, weil niemand alle zehn Dateien nebeneinander ansieht. Ein Prüflauf misst deshalb bei jedem Build jede Beschriftung gegen ihre Nachbarn und gegen den Rahmen. Derzeit sind das 106 Beschriftungen, alle frei.

Die Weltkarte ist überhaupt nicht gezeichnet. Sie wird aus offenen Grenzdaten gerechnet: Ringe entpackt, über den Datumsgrenzensprung hinweg zusammengesetzt, vereinfacht und flach projiziert. Dasselbe Skript schreibt aus denselben Konstanten die Umrechnung, mit der die Marker gesetzt werden. Karte und Marker können deshalb nicht auseinanderlaufen, weil beide aus einer Quelle stammen.

Die Startseite trägt keinen Aufmacher, sondern das Register selbst: eine Kugel, auf der jedes Land als Punkt sitzt, gewichtet nach der Zahl der dort ausgeführten Aufträge. Man dreht sie, greift ein Land heraus und liest die Zahl daneben. Der Beleg ist damit nicht ein Satz über den Beleg, sondern das Bedienelement.

Darunter steckt eine Zeichenmaschine, kein Framework. Die Küstenlinie ist vorberechnet, differenzkodiert und liegt bei etwa 56 KB gepackt; sie wird erst nach dem ersten Bild geladen, weshalb die gebaute Startseite selbst bei rund 42 KB gepackt bleibt und das größte Element beim Laden die Überschrift ist, nicht die Zeichenfläche. Darunter liegt als Ausgangsbild eine statische Zeichnung derselben Kugel, sodass vor dem Nachladen nichts blinkt und nichts springt.

Die Schleife hört auf, sobald sie nichts mehr zu tun hat. Wird nicht gedreht, ist nichts ausgewählt, ist die Kugel aus dem Bild gescrollt oder der Tab im Hintergrund, dann läuft sie nicht weiter, sondern hält an und startet beim nächsten Ereignis neu. Eine Startseite, die stundenlang sechzig Bilder pro Sekunde in ein unbeachtetes Fenster zeichnet, ist ein Fehler, den man nur an der Lüftung bemerkt.

Dieselbe Maschine bedient zwei Abnehmer, die Startseite und eine eigenständige Demo-Datei, und ein Prüflauf besteht darauf, dass es bei einer Datei mit einem Export bleibt. Sonst wäre in kurzer Zeit die zweite Kugel entstanden, die der ersten leise widerspricht.

Hell ist die Vorgabe, dunkel ist eine Entscheidung. Der Auftritt folgt bewusst nicht der Systemeinstellung, solange der Besucher nichts gewählt hat: eine Ingenieurberatung wird zuerst auf Papierweiß gelesen, und wer es anders will, sagt es einmal.

Getragen wird das von zwei getrennten Attributen. Das eine hält die Wahl, das andere das daraus abgeleitete Schema, und jede Komponente fragt nur nach dem Schema. Das klingt nach einem Attribut zu viel und ist der Grund, warum ein drittes Farbschema hier eine Ergänzung an einer Stelle wäre und keine Änderung an achtzehn Komponenten. Beide werden von demselben Skript vor dem ersten Bild gesetzt. Wer sie getrennt schreibt, bekommt eine Seite, die einen Frame lang dunkle Schrift auf dunklen Grund malt.

Eine Fläche verhält sich dabei anders als alle anderen, nämlich die invertierte: ihr Grund kippt mit dem Schema, also kippt auch die Lesbarkeit des Akzents auf ihr. Sie führt deshalb einen eigenen Akzentwert, der pro Schema aus dem passenden Ende der Rotrampe kommt. Ohne den stünde das Firmenrot dort bei gut 2:1 und wäre auf einem Laptop im Zug nicht mehr zu sehen.

Nachgemessen statt geschätzt: die Kontrasttabelle des hellen Schemas ist ausgerechnet, alle 28 geprüften Paare erfüllen AA, der schwächste liegt bei 4,90:1.

Der Auftritt lief zwischenzeitlich mit zwei Breiten, einer schmalen für Kopf und Aufmacher und einer weiten für Bildbänder. Das setzt zwei senkrechte Kanten auf dieselbe Seite, und sobald man es einmal gesehen hat, sieht man es überall. Heute gibt es genau eine Seitenbreite, Kopfzeile eingeschlossen.

Der Seitenrand ist an diese Breite gebunden und nicht gewählt: seine Obergrenze ist der Anteil, mit dem er mitwächst, mal der Maximalbreite. Wer die eine Zahl frei setzt, baut sich einen Fehler, der nach nichts aussieht. Der Rand steckt nämlich innerhalb der Maximalbreite. Wächst er weiter, nachdem die Breite bereits gedeckelt ist, dann wird der Inhalt schmaler, je breiter das Fenster wird. Genau das ist hier einmal passiert, mit einem Höchstwert kurz vor dem Deckel und einem Abfall dahinter.

Ein Screenshot zeigt so etwas nie, weil jedes einzelne Bild für sich plausibel ist. Ein Prüflauf zeigt es sofort: er misst die Inhaltsbreite je Seite und je Fenstergröße, druckt sie als Reihe, und eine Delle irgendwo in der Reihe ist der Beweis. Derselbe Lauf geht auf drei Telefonbreiten jedes Element durch und benennt alles, was über den Dokumentrand hinausragt.

Zwei Fundstücke daraus sind allgemein genug, um sie mitzunehmen. Ein zentriertes Rasterkind wird auf seine Maximalbreite gezogen, weshalb eine lange Bildunterschrift das Raster sprengt, bis man es ausdrücklich begrenzt. Und Überlauf greift bei einer Tabellenbox nicht, weshalb die Hilfsklasse, die Inhalte für Vorleseprogramme verbirgt, eine nackte Tabelle nicht wegschneidet, sondern sie stehen lässt.

Neben der Website steht eine Broschüre über 37 A4-Seiten, und sie ist keine Kopie. Sie ist eine einzige HTML-Datei, mit Schriften und Bildern eingebettet, die im Browser gelesen und aus ihm heraus gedruckt wird. Was auf ihr steht, kommt aus den Inhaltsdateien der Website. Wer eine Leistungszeile ändert, ändert beide Ausgaben.

Der Umbruch ist gerechnet, nicht gesetzt. Der Bauschritt bewertet jede Zeile in gedruckten Einheiten und füllt Seiten, bis sie voll sind. Die dafür nötigen Konstanten sind nicht geschätzt, sondern gemessen: ein Prüflauf zeichnet das fertige Dokument und liest die Kästen zurück. Der erste Anlauf hatte sie geraten, und zwölf Seiten hintereinander liefen über.

Genau deshalb steht am Ende ein Tor, das bestehen muss. Eine überlaufende A4-Seite sieht am Bildschirm unauffällig aus und verliert beim Drucken ihren unteren Rand, ohne dass irgendwo eine Meldung erscheint. Ein Fehler, der erst auf Papier sichtbar wird, ist auf Papier zu spät. Dazu kommt ein Export in ein bearbeitbares Dokument, geprüft gegen den Satz des Originals, mit einer verbliebenen Abweichung von zwei Hundertstel Pixeln.

Nichts davon erzwingt die Synchronität automatisch. Die Inhalte werden bewusst in die Broschüre übernommen und nicht zur Laufzeit geholt, damit eine Änderung an der Website ein fertig gedrucktes Dokument nicht rückwirkend verändert.

Die Projektbeschreibungen sind der eine Teil des Auftritts, der weiterwachsen soll, und der einzige, für den es eine Oberfläche braucht. Es gibt sie, sie liegt unter einer eigenen Adresse und läuft nur auf dem Rechner des Bearbeiters: eine Liste der vorhandenen Datensätze, ein Formular für jedes Feld, eine Vorschau der Karte und der fertigen Seite daneben.

Bearbeitet werden dieselben Dateien, aus denen die Seite baut, ohne Datenbank und ohne Konto. Jedes Feld prüft beim Speichern gegen dasselbe Schema, gegen das auch der Build prüft. Ein Datensatz, der hier durchgeht, bricht den Build nicht: das ist der ganze Zweck der Übung, und der Ablauf ist über dreißig Prüfschritte durchgespielt.

Wo Beschreibungen keinen unterschriebenen Beleg hinter sich haben, sind sie als repräsentativ gekennzeichnet, sichtbar auf der Übersicht und an jedem einzelnen Eintrag. Was belegt ist, steht im Register; was daneben steht, gibt sich nicht als Vertragsakte aus. Diese Trennung ist die Bedingung, unter der die eine Hälfte des Auftritts überhaupt etwas wert ist.

Ausgeliefert wird statisch aus einem Container: gebaute Dateien hinter einem schlanken Server, ein Anstoß auf dem Hauptzweig baut neu. Eine Fußzeile nennt uns als Urheber, in der leisesten Schriftgröße der Seite.