HilkeBuss.de Redesign Teil 2

Aus dem Entwurf wurde eine Website

In den vergangenen beiden Wochen habe ich geplant, verworfen und neu entworfen. Diese Woche ging es an die Umsetzung. Damit hat das Redesign insgesamt drei Wochen gedauert.

Die sichtbare Veränderung ist das neue Design. Die Startseite sieht jetzt wie ein Arbeitsplatz aus, das Projektjournal wie eine Pinnwand mit Notizzetteln. Dahinter hat sich allerdings noch deutlich mehr verändert.

Meine erste Website war vor allem dafür gedacht, meine Lernreise zu dokumentieren. Sie musste minimalistisch sein und mir ermöglichen, neue Beiträge zu veröffentlichen. Dafür hat WordPress seinen Zweck erfüllt.

Inzwischen ist aus der Lernreise ein Projektjournal mit mehr als 30 umgesetzten Projekten geworden. Viele davon sind Werkzeuge, die tatsächlich laufen oder von mir verwendet werden. Das Journal ist damit immer stärker zu einem Portfolio geworden. Die Website sollte diese Entwicklung jetzt auch widerspiegeln.

Wenn man ohnehin umzieht

Der Wechsel war eine gute Gelegenheit, einige Dinge gründlicher anzugehen als bei der ersten Version.

Alle Bilder haben Alternativtexte bekommen, damit ihr Inhalt nicht nur visuell zugänglich ist. Ich habe die Darstellung auf verschiedenen Bildschirmgrößen überprüft, die mobile Navigation angepasst und mehr auf Ladezeiten und Dateigrößen geachtet.

Die neue Website kommt außerdem ohne WordPress, Datenbank und visuelle Seitenverwaltung aus. Sie wird statisch gebaut und besteht am Ende aus fertigen Dateien, die der Server nur noch ausliefern muss. Das macht sie technisch überschaubar und sorgt für kurze Ladezeiten.

Ich habe die Website mit Claude Code umgesetzt und dabei nicht nur den sichtbaren Aufbau prüfen lassen. Barrierefreiheit, Performance, mobile Darstellung und der sichere Umzug der bestehenden Inhalte waren von Anfang an Teil der Aufgabe.

35 Beiträge umziehen, ohne 35-mal zu kopieren

Der riskanteste Teil war nicht das Design, sondern die Migration.

Im Projektjournal liegen inzwischen 35 Beiträge mit Bildern, Zusammenfassungen und bestehenden Adressen. Einige dieser Adressen sind bereits an anderen Stellen verlinkt. Beim Umzug durfte deshalb kein Beitrag verschwinden und keine veröffentlichte Adresse plötzlich ins Leere führen.

Jeden Beitrag von Hand aus WordPress zu kopieren und neu zusammenzusetzen, wäre langsam und fehleranfällig gewesen. Stattdessen habe ich einen Ablauf entwickelt, bei dem die vorhandenen Inhalte aus dem WordPress-Export gelesen und mit Unterstützung eines Sprachmodells in das neue Beitragsformat übertragen wurden.

Danach habe ich prüfen lassen, ob alle alten Adressen weiterhin vorhanden sind, ob die Bilder gefunden werden und ob die Beiträge vollständig gebaut werden können. Die Adressprüfung läuft künftig bei jedem neuen Bau der Website mit. Fehlt eine der bisherigen Seiten, bricht der Vorgang ab, bevor die fehlerhafte Version veröffentlicht werden kann.

Was aus einem Beitrag geworden ist

Ein neuer Beitrag ist jetzt keine Seite mehr, die ich in Elementor aus einzelnen Elementen zusammensetze. Er besteht aus einer Datei mit Titel, Datum, Wochennummer, Zusammenfassung und Inhalt.

Aus diesen Angaben erzeugt die Website automatisch:

• die vollständige Beitragsseite
• den Eintrag im Projektjournal
• den Notizzettel auf der Pinnwand
• die Vorschau auf der Startseite
• die Navigation zur vorherigen und nächsten Woche
• den Eintrag im Feed
• die Informationen für Suchmaschinen und geteilte Links

Auch die Gestaltung der Notizzettel ist vom Inhalt getrennt. Die meisten Papiersorten werden automatisch und stabil vergeben. Ein Beitrag behält seine Darstellung also auch nach einem neuen Bau der Website.

Polaroids vergebe ich dagegen bewusst. Sie eignen sich besonders für Projekte mit einer ansprechenden Oberfläche oder einem guten Vorschaubild. Ein Werkzeug, das hauptsächlich in der Konsole läuft, kann fachlich genauso interessant sein, braucht aber nicht unbedingt einen großen Bilderrahmen auf der Pinnwand.

Das Portfolio musste nicht leer anfangen

Für die Startseite hatte ich zunächst geplant, mehrere neue Projekte eigens für das Portfolio umzusetzen. Dabei habe ich gemerkt, dass die leeren Plätze eher Druck erzeugen als gute Ideen.

Wenn jedes neue Projekt sofort eine besonders vorzeigbare Portfolio-Anwendung werden muss, beeinflusst das die Auswahl. Dann baue ich möglicherweise das Projekt, das gut auf eine Karte passt, statt das Projekt, das mich gerade wirklich interessiert.

Deshalb zeigt das Portfolio zum Start drei bereits vorhandene Projekte aus dem Projektjournal. Zwei davon werde ich langfristig wahrscheinlich durch andere Projekte ersetzen. Für den Moment zeigen sie aber, dass hinter der Website funktionierende Anwendungen stehen. Neue Projekte können hinzukommen, wenn sie tatsächlich entstanden sind.

Das Steuer-Cockpit ist jetzt eine öffentliche Demo

Eines dieser Projekte ist das Steuer-Cockpit aus Woche 32 und 33.

Die ursprüngliche Anwendung läuft lokal mit meinen eigenen Buchhaltungsdaten. Für das Portfolio habe ich daraus eine eigene Demo mit erfundenen Daten gebaut. Einige Funktionen sind dort eingeschränkt, damit keine privaten Daten oder internen Abläufe nach außen gelangen.

Diese Demo ist jetzt veröffentlicht und direkt auf der Startseite verlinkt. Interessierte können sich durch Dashboard, Buchungen und Steueransichten klicken und selbst sehen, wie das Werkzeug funktioniert.

Damit ist auch die Ankündigung aus Woche 33 eingelöst. Damals stand die eigentliche Anwendung, während die öffentliche Version noch in Arbeit war.

Eine Grundlage für bessere Entscheidungen

Zusätzlich habe ich die Website in der Google Search Console eingetragen. Dort kann ich künftig sehen, über welche Suchanfragen die Seite gefunden wird, wie oft sie in den Suchergebnissen erscheint und welche Seiten darüber besucht werden.

Mir geht es dabei zunächst darum, eine Grundlage zu haben. Wenn ich später Inhalte oder technische Details optimieren möchte, kann ich sehen, wo ein sinnvoller Anfang liegt, statt nur nach Gefühl Änderungen vorzunehmen.

Die Website ist fertig, der Veröffentlichungsprozess noch nicht

Einige Entscheidungen im neuen System habe ich bereits mit Blick auf das nächste Projekt getroffen.

Weil jeder Beitrag aus wenigen klar definierten Bausteinen besteht, kann darauf eine Beitrags-Pipeline aufbauen. Ich möchte ihr künftig die Informationen zu einem Projekt geben und daraus gemeinsam mit ihr einen Beitrag entwickeln. Am Ende soll eine vollständige Beitragsdatei entstehen, die bereits alle Kopfdaten, Bildverweise und Inhalte enthält.

Sobald diese Datei im richtigen Ordner liegt, übernimmt die Website den Rest. Der Beitrag erscheint im Projektjournal, bekommt seinen Notizzettel, wird in die Navigation aufgenommen und für die Veröffentlichung vorbereitet.

Ein Rohbau dieser Pipeline existiert bereits. Ob sie nächste Woche schon zuverlässig genug für eine Vorstellung ist, muss ich noch testen. Sie ist aber das nächste geplante Projekt und gleichzeitig der Grund, warum manche Entscheidungen beim Umbau der Website so früh feststehen mussten.

Fazit

Woche 36: ✅

Nach insgesamt drei Wochen sind Planung, Umsetzung und Umzug der neuen hilkebuss.de abgeschlossen. Die Website spiegelt meine Arbeit besser wider, das Projektjournal ist übersichtlicher und die ersten Projekte stehen mit laufenden Demos im Portfolio.

Unter der sichtbaren Gestaltung liegt jetzt ein System, das bestehende Adressen schützt, Beiträge automatisch einordnet und den nächsten Schritt vorbereitet.

Als Nächstes möchte ich die Beitrags-Pipeline fertigstellen und gründlich testen. Wenn das funktioniert, wird der nächste Beitrag nicht nur von dieser Pipeline handeln, sondern bereits mit ihr entstanden sein.