Kurzüberblick
Dieses Projekt ist eine eigenständige Website zur Darstellung meines HomeLabs: Hardware, Dienste, Architektur und Entwicklungsschritte – aber nicht als „Wiki“, sondern als strukturierte Plattform mit klarer Nutzerführung.
Live:
Kernidee:
Die Website soll zwei Dinge gleichzeitig können:
- Überblick geben, ohne zu überladen (Homepage als Landingpage)
- Details dokumentieren, ohne die Startseite zu „übernehmen“ (Lab/Hardware/Builds als Deep Dives)
Motivation & Zielsetzung
Ich wollte mein HomeLab nicht nur intern dokumentieren, sondern so präsentieren, dass auch Außenstehende verstehen:
- welche Systeme laufen
- welche Dienste genutzt werden
- wie das Ganze zusammenspielt (Architektur)
- wie sich das Setup über Zeit verändert (Builds/Verlauf)
Am Anfang war die Seite eher eine „schöne Hardware-Übersicht“. Mit der Zeit wurde klar:
Ein reines Hardware-Grid zeigt nicht, wie das Lab funktioniert.
Was ich erreichen wollte
- Apple-like UI: minimal, ruhig, premium, viel Weißraum, klare Typografie
- Informationshierarchie: nicht alles auf einmal, sondern strukturiert
- Trennung von Rollen: Homepage ≠ Lab-Doku
- Static-first: schnell, robust, wenig JS
- Content-getrieben: Inhalte sollen leicht erweiterbar sein (MDX/Collections)
- Saubere URL-Struktur: klare, merkbare Routen (z. B.
/lab,/hardware,/builds)
Ausgangssituation
Ursprüngliche Struktur (Navigation)
- Start (Homepage)
- Lab (
/lab) - Verlauf (
/builds) - Über
Problem in der Praxis
Die Homepage hatte Inhalte, die sich mit /lab überschnitten:
- zu viele Geräte sichtbar
- zu wenig Story / Übersicht
- wenig Hierarchie
- „Homepage fühlt sich an wie eine Übersichtsliste“
Dadurch hatte die Startseite keine klare Rolle. Wenn Homepage und Lab-Seite gleich wirken, fehlt die Nutzerführung.
Konzeptentscheidung: Rollen sauber trennen
Das war die wichtigste Entscheidung im ganzen Projekt: Seiten bekommen Rollen.
Homepage (Landingpage)
Zweck:
„Was ist das hier?“ + „Was läuft grundsätzlich?“ + „Wie ist die Philosophie?“
Darf NICHT sein:
Komplette Gerätelisten, vollständige Service-Übersichten, Detailtabellen.
Lab (/lab)
Zweck:
Vollständige Dokumentation: Hardware, Software, Architektur, vollständige Übersicht.
Hardware (/hardware)
Zweck:
Geräte-Details, Specs, ggf. einzelne Device-Pages.
Builds (/builds)
Zweck:
Änderungen und Entwicklungsschritte (kein Changelog-Spam, eher „Build Log“).
Diese Trennung löst nicht nur UI-Probleme, sondern macht die Seite langfristig wartbar:
Neue Inhalte landen dort, wo sie hingehören – ohne die Homepage zu sprengen.
Homepage Redesign: Struktur & Sections
Sektionen, die bleiben sollten (und warum)
1) Hero
- Titel: „HomeLab.“
- Subline
- 2 Buttons:
- „Das Lab erkunden“ →
/lab - „Hardware ansehen“ →
/hardware
- „Das Lab erkunden“ →
Warum:
Der Hero ist die klare „Entry“-Zone. Er muss nicht viel erklären, nur richtig leiten.
2) „Das System, auf einen Blick.“
Kennzahlen:
- 8 Geräte
- 15 Dienste
- 100% self-hosted
- 0€ Cloud-Kosten
Warum:
Kennzahlen sind ein schneller Einstieg ohne Detail-Overload.
Das ersetzt Listen – und wirkt trotzdem „technisch“.
3) Philosophie
Eine erklärende Sektion, warum Self-Hosting, warum diese Struktur, worauf Wert gelegt wird.
Wichtig:
Philosophie darf nicht zu einer zweiten Navigation werden (also keine „hier ist alles verlinkt“-Sektion).
4) System-Säulen
- Hardware
- Software
- Architektur
Warum:
Das ist das mentale Modell der Seite. Es sagt: „Das hier ist ein System, nicht nur Devices.“
Inhalte, die entfernt wurden
- vollständige Geräte-Grid auf der Homepage
- „alles auf einmal“
- Teile, die das
/labfaktisch ersetzt hätten
Begründung:
Die Homepage soll Interesse wecken und Orientierung geben.
Details gehören in die jeweiligen Deep-Dive-Seiten.
Neue Sektionen auf der Homepage
1) „Aktuelles.“
Ziel: Die Seite soll „leben“, ohne als Changelog zu wirken.
Aufbau:
- Titel: „Aktuelles.“
- Subline: „Woran ich aktuell arbeite.“
- 3 kleine Premium-Cards (Beispiele):
- Migration auf Raspberry Pi 5
- Monitoring-Erweiterung
- Workflow-Automatisierung
- Link: „Zum Verlauf“ →
/builds
Design-Anforderungen:
- subtile Glass-Optik
- ruhige Cards (keine lauten Icons)
- klare Typografie
- kein „Ticket“-Stil, kein Log-Feeling
2) „Aus dem Blog.“
(Bei mir später über blog.nico-grim.me angebunden.)
Aufbau:
- Titel: „Aus dem Blog.“
- Subline: „Technische Einblicke & Dokumentation.“
- 2 Teaser-Artikel
- Link: „Zum Blog“
Design-Anforderungen:
- editorial Look
- ruhiger als „Aktuelles“
- Fokus auf Lesbarkeit
Designsystem & UI-Entscheidungen
„Apple-like“ als Designrichtung – was das konkret bedeutet
Nicht „Apple kopieren“, sondern Prinzipien übernehmen:
- Whitespace als Layout-Tool
- Typografie als Hierarchie
- Subtile Divider & Borders
- Hover-Effekte nur minimal
- Cards nicht als Default für alles
- Keine Animationen, die Aufmerksamkeit ziehen (lieber micro-interactions)
Dark Mode First
- Dark Mode ist nicht nur ein Theme, sondern Default-Design-Basis.
- Kontraste und Lesbarkeit sind wichtiger als „cool“.
Komponenten-Strategie
- Sections als eigene Komponenten, wenn sie wiederverwendbar oder komplex werden.
- Layouts konsistent halten (Container widths, vertical rhythm).
- Keine Tailwind-Klassen-Wüste: lieber wiederkehrende Patterns.
Tech Stack & Begründung
Astro (latest)
Warum Astro:
- Static-first Output
- Content Collections / MDX sehr gut integrierbar
- Perfekt für content-lastige Seiten
- Minimal JS by default (Performance)
Tailwind CSS
Warum Tailwind:
- schnelle Iteration
- konsistente spacing/typography scale
- für ein „design system light“ gut geeignet
MDX + Content Collections
Ziel:
- Projekte als Content (nicht als Hardcode)
- klare Frontmatter-Felder (title, tags, status, etc.)
- später leicht erweiterbar (z. B. images, gallery, highlights)
Content Modell (Projects)
Dieses Projekt ist selbst als MDX-Project angelegt, damit:
- Projektliste automatisch generiert werden kann
- Filter/Tags funktionieren
- „active“ vs „archived“ sauber abbildbar ist
- später „featured“ möglich ist
Beispiel-Felder:
titledescriptionpubDatetagsstatusdraftfeatured
Deployment & Domain Setup
Vercel
- GitHub Repo verbunden
- Auto-deploy on push
- Preview Deployments für Pull Requests / Branches
Subdomain Wechsel (Lineup → HomeLab)
Ein Thema im Projekt war, dass die Domain/Subdomain geändert wurde:
- von
lineup.nico-grim.me - auf
homelab.nico-grim.me(geplant/umgestellt)
Wichtig dabei:
- Vercel Domain Settings aktualisieren
- DNS Records bei Cloudflare/Provider anpassen
- Redirects prüfen (optional)
- Canonical URLs + Sitemap/SEO prüfen
(Je nachdem, wie du es final gelöst hast, kann man hier später konkretisieren: CNAME, A-Record, Vercel Verification, etc.)
Performance & Quality
Ziele:
- schnell auf Mobile + Desktop
- keine unnötigen Client-Skripte
- saubere Lighthouse-Baseline
Maßnahmen:
- Static Rendering
- minimal JS
- optimierte Images (Astro Image, wenn genutzt)
- konsistente Layoutstruktur (weniger Layout Shift)
- klare Typografie
Typische Probleme & Lösungen (aus dem Build)
Problem: Homepage wird zur „Lab“-Seite
Lösung:
Inhalte raus, Rollen trennen, Teaser statt Listen.
Problem: Zu viele gleichwertige Elemente
Lösung:
Typografie + Spacing als Hierarchie, weniger Cards, weniger „Grid überall“.
Problem: „Aktuelles“ wirkt wie Changelog
Lösung:
Cards als „Focus Topics“ schreiben, nicht als Datumseinträge. Link zu /builds für Details.
Ergebnis (Stand heute)
- Homepage ist eine Landingpage mit Vision/Überblick
/labbleibt die vollständige Systemübersicht- klare Navigation
- Apple-like, ruhig, premium
- gute Basis für Erweiterungen (Blog, Architektur-Preview, Featured Devices)
Offene Punkte / Roadmap
1) Featured Devices auf der Homepage?
Option:
- 2–3 featured Devices als Teaser
- kein vollständiges Grid
- Link zu
/hardware
2) Architektur-Preview
Option:
- kleines Architektur-Snippet (Diagramm/Preview)
- Link zu
/laboder/architecture
3) Premium Footer
- klare Links
- Kontakt / GitHub
- ggf. Status/Monitoring Link
4) Content-Erweiterung
- Builds als echte „Build Log“-Einträge
- Hardware detailreicher (Specs + Bilder)
- Software/Services strukturierter (z. B. Kategorie: Monitoring, Media, Automation)
Fazit
Der wichtigste Schritt war nicht „mehr Content“, sondern weniger auf der Homepage.
Durch die klare Trennung von:
- Überblick (Homepage)
- Details (Lab/Hardware/Builds)
wurde die Seite langfristig nutzbar und wirkt deutlich hochwertiger.
Das Projekt ist eine Grundlage, die mit dem HomeLab wachsen kann, ohne dass die UX auseinanderfällt.