Neue Website, bewährte Grundsätze

Unsere bisherige Website war eine Visitenkarte: Sie nannte Namen, Anschrift und Kontakt. Was wir tatsächlich tun, stand dort nur in wenigen Sätzen. Das entsprach nicht mehr dem, was wir inzwischen leisten – deshalb haben wir sie neu aufgebaut.

Was sich geändert hat

Die neue Seite zeigt, wofür man uns beauftragt. Eine Leistungsseite beschreibt Migration, Individualentwicklung, Integration und Betrieb. Projektbeschreibungen zeigen am konkreten Beispiel, welche Aufgaben wir übernommen und wie wir sie gelöst haben. Und das Team stellt sich mit Namen und Schwerpunkten vor.

Ebenso wichtig ist uns, was man nicht sieht. Die Seite besteht aus statischen Dateien: kein Content-Management-System, keine Datenbank, keine Cookies, kein Tracking. Wir erfassen nicht, wer die Seite besucht – und die Datenschutzerklärung kann entsprechend kurz bleiben. Aus demselben Grund verzichten wir auf ein Kontaktformular und nennen stattdessen unsere E-Mail-Adresse. Welche Informationen Sie uns mitteilen, entscheiden Sie selbst.

Referenzen mit Namen

In den Projektbeschreibungen nennen wir unsere Kunden, soweit sie uns das freigegeben haben. Interne Produkt- und Projektbezeichnungen bleiben dennoch außen vor: Wir beschreiben die Anwendungen nach ihrer Aufgabe, nicht nach ihrem internen Namen.

Damit das auch bei künftigen Änderungen zuverlässig gilt, ist die Regel Teil des Builds. Ein Skript prüft bei jedem Durchlauf die fertigen Seiten gegen eine Liste von Begriffen, die nicht veröffentlicht werden – in Texten ebenso wie in Dateipfaden, denn Ordnernamen landen in URLs. Findet es einen Treffer, wird die Seite nicht ausgeliefert.

Womit sie gebaut ist

Eleventy als Static-Site-Generator, Tailwind CSS für die Gestaltung, Nunjucks als Template-Sprache. Der Build läuft in einer Pipeline, das Ergebnis liegt als statische Dateien auf S3.

Diese Wahl ist bewusst schlicht. Bei einer Unternehmenswebsite zählt weniger das Framework als die Frage, ob sich die Seite auch in einigen Jahren noch ohne Aufwand pflegen lässt. Markdown-Dateien in einem Git-Repository erfüllen diesen Anspruch. Barrierefreiheit, Kontraste und Seitenstruktur prüfen wir dabei automatisiert mit – in hellem wie in dunklem Farbschema.

Wie es weitergeht

Die Seite wird wachsen: Einige Portraitfotos folgen noch, ebenso weitere Projekte. Hier im Blog schreiben wir künftig über das, was uns in der Arbeit beschäftigt – Architektur, Migrationen und die Frage, was eine Anwendung auch nach Jahren noch gut wartbar macht.

Anmerkungen und Hinweise nehmen wir gern entgegen: Schreiben Sie uns.