Diese Website
janwestphal.dev ist mein Portfolio und ihr Aufbau ein eigenes Projekt. Das Ziel: eine Seite, die meinen Arbeiten eine Plattform gibt, schnell lädt, ohne Tracking und Cookies auskommt, auf Deutsch und Englisch erreichbar ist und die ich über ein CMS pflegen kann, ohne ständig Code anzufassen.
Leitlinie für die Gestaltung: Usability und Barrierefreiheit gehen vor Effekten. Das Layout folgt etablierten HCI-Prinzipien und Designnormen, Animationen sollen Orientierung geben und sind (fast) nie Selbstzweck.
Die Seite wird mit Eleventy erzeugt und liegt auf GitHub Pages. Der Quellcode ist öffentlich auf GitHub.
In naher Zukunft soll die Site die WCAG 2.2 (Web Content Accessibility Guidelines) erfüllen.
- Art
- Web
- Jahr
- 2026
- Details
- Website, Soloprojekt · Status: online, wird laufend weiterentwickelt

01 — Steckbrief
- Rolle
- Soloprojekt: Konzept, Gestaltung, Entwicklung und Inhalte
- Zeitraum
- Seit Frühjahr 2026, Überarbeitung im Sommer 2026 und aktuell Herbst 2026
- Werkzeuge
- Eleventy
- Nunjucks
- Markdown
- Sveltia CMS
- GitHub Actions
- GitHub Pages
- eleventy-img
- three.js
- Claude (AI assistant)
- Links
02 — Ziel
Die Seite hat zwei Zielgruppen: Arbeitgeber aus Embedded-Entwicklung, Medientechnik und Game Development und alle, die sich für meine Projekte interessieren. Beide sollen schnell sehen, was ich baue und wie ich arbeite. Daraus ergaben sich ein paar feste Anforderungen:
- Schnell und statisch: kein Server, keine Datenbank, nur HTML CSS und JS. Das hält die Seite schnell, sicher und kostenlos im Betrieb. Außerdem konnte ich so das Modul Webanwendungen im Sommersemester 2026 vertiefen.
- Zwei Sprachen: Deutsch als Hauptsprache, Englisch für alle anderen, mit eigenen Adressen, damit Suchmaschinen beide Fassungen finden.
- Pflegbar ohne Code: Neue Projekte und Blogbeiträge entstehen in einem CMS im Browser.
- Datenschutz: kein Tracking, keine Cookies, Schriften liegen auf der eigenen Seite. Videos und eingebettete Spiele laden erst nach einem Klick.
03 — Aufbau
Jedes Projekt und jeder Blogbeitrag ist eine Markdown-Datei. Eleventy macht daraus fertige HTML-Seiten. Das CMS (Sveltia) schreibt genau in diese Dateien und committet sie ins Repository, es gibt keinen zweiten Datenspeicher.
Bei jedem Push baut GitHub Actions die Seite und veröffentlicht sie auf GitHub Pages. GitHub Pages kann keine Weiterleitungen auf dem Server, deshalb bekommt jede alte Adresse eine kleine Seite, die sofort weiterleitet und Suchmaschinen per canonical die neue Adresse nennt.
04 — Zwei Sprachen ohne JavaScript
Die Vorlagen schreiben jede Seite nur einmal: englischer Text im HTML, beide Sprachen zusätzlich als Attribute (data-en, data-de). Nach dem Build liest ein kleines eigenes Skript jede Seite ein und schreibt daraus zwei fertige Fassungen, Deutsch unter /, Englisch unter /en/. Jede Fassung enthält nur ihre eigene Sprache, das richtige lang-Attribut, eigenen Titel und eigene Beschreibung, Querverweise für Suchmaschinen (hreflang) und eine gemeinsame Sitemap. Jeder Text wird an einer Stelle gepflegt, und Besucher wie Screenreader bekommen die richtige Sprache durch die Browsereinstellung, ohne Umschalten im Browser.
05 — Bilder
Fotos kommen direkt aus der Kamera und sind oft mehrere Megabyte groß. Ein Plugin (eleventy-img) ersetzt beim Build jedes Bild durch ein <picture>-Element: fünf Breiten, jeweils als AVIF und WebP, dazu die echten Maße, damit beim Laden nichts springt. Der Browser lädt nur die Größe, die er wirklich braucht.
Wirkung auf der Startseite: Die Bilder wiegen dort jetzt je nach Bildschirm zusammen 65 bis 125 KB, vorher musste ich alle Bilder über einen .webp Konverter erstmal umwandeln.

06 — Interaktion
Die Seite soll sich anfühlen wie meine Projekte, ein bisschen verspielt, aber nicht laut. Jede Bewegung hat eine Aufgabe, sie zeigt woher etwas kommt, was ausgewählt ist oder was sich anklicken lässt. Kein Inhalt hängt von einer Animation ab.
- Fächer: Auf der Startseite liegen die aktuellen Projekte wie Spielkarten in der Hand. Beim Überfahren hebt sich eine Karte mit leichtem Nachfedern heraus und neigt sich zum Zeiger.
- Variable Schrift: Bricolage Grotesque ist eine variable Schrift. In den großen Überschriften wird jeder Buchstabe kräftiger, je näher der Zeiger ist.
- 3D-Modelle: Modelle aus Blender lassen sich im Browser drehen (three.js). Die Ansicht „Wireframe“ zeigt die Kanten so, wie ich sie modelliert habe.
- Bilder und Galerien: Angeklickte Bilder öffnen sich von ihrer Position mit einem Übergang zur Großansicht, lange Galerien bekommen links einen Index der der Scrollposition folgt sobald die Galerie mehr als 4 Bilder hat.

07 — Gestaltungsprinzipien: Usability vor Effekt
Auffällige Effekte sind zwar eindrucksvoll, können aber schnell überfordern und sind oft nur Beiwerk der vom Inhalt ablenkt. Deshalb folgt die Gestaltung etablierten Prinzipien statt Trends:
- Interaktionsprinzipien (DIN EN ISO 9241-110): Die Seite erklärt sich selbst (Beschriftungen statt reiner Symbole, die aktuelle Seite ist in der Navigation markiert), verhält sich erwartungskonform (Links sehen überall gleich aus und reagieren gleich) und bleibt steuerbar (Animationen lassen sich abschalten, Videos und Spiele laden erst auf Wunsch).
- Sichtbarer Zustand: Was gerade aktiv ist, ist zu sehen, die unterstrichene Seite in der Navigation, die gehobene Karte mit „01 / 04“, das markierte Bild im Galerie Index und der Zustand des Animationsschalters.
- Lesbarkeit: rund 65 Zeichen pro Zeile, im Browser gemessen, eine Schriftskala mit sieben Größen und klaren Abständen die Zusammengehöriges gruppieren.
- Gut zu treffen: Klickflächen von mindestens 44 px, ganze Listenzeilen sind anklickbar statt nur der Titel.
Barrierefreiheit gehört dazu und ist kein Zusatz. Ziel ist WCAG 2.2, Stufe AA:
- Bewegung ist freiwillig: Der Schalter „Animationen“ stellt alle Bewegungen ab, und ohne eigene Wahl folgt die Seite der Einstellung des Betriebssystems (
prefers-reduced-motion). - Screenreader: Animierte Überschriften enthalten ihren Text ein zweites Mal unsichtbar, damit das Wort vorgelesen wird und nicht einzelne Buchstaben; das Menü auf dem Handy meldet, ob es offen ist; jedes inhaltliche Bild hat eine Beschreibung in beiden Sprachen, rein dekorative werden für Screenreader ausgeblendet.
- Tastatur und Kontrast: Alles ist mit der Tastatur und sichtbarem Fokus bedienbar, ein Sprunglink führt direkt zum Inhalt, und alle Texte erfüllen die AA-Kontrastwerte.
- Formular: Fehler erscheinen direkt unter dem Feld, in der Sprache der Seite.

08 — Was ich gelernt habe und anders machen würde
- Neu bauen statt überschreiben: Die Überarbeitung ist als Schicht über den alten Stilen gewachsen. Das funktioniert, aber zwei Stylesheets mit vielen Überschreibungen sind schwerer zu pflegen als ein sauberes. Sie zusammenzuführen ist der nächste Schritt.
- Messen statt schätzen: Zeilenlänge, Bildgrößen und Ladegewicht wurden erst richtig gut, als ich sie im Browser gemessen statt geschätzt habe.
- Die Plattform kennen: GitHub Pages kann keine Weiterleitungen auf dem Server, und Windows unterscheidet in Ordnernamen nicht zwischen Groß- und Kleinschreibung. Beides hat bestimmt, wie die Weiterleitungen funktionieren.
- Techstack besser planen: Im Laufe der Entwicklung sind einige Komponenten wie Eleventy und Sveltia CMS erst später hinzu gekommen, nächstes mal würde ich mehr Zeit in die Planung investieren. Außerdem würde ich die Architektur besser durchplanen.
Fragen, Ideen oder Feedback? Ich freue mich über eine Nachricht.
Schreib mir