Alle Projekte
aktiv

HomeLab Website

Bauen einer Website zur präsentation meines HomeLabs


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:

  1. Überblick geben, ohne zu überladen (Homepage als Landingpage)
  2. 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:

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


Ausgangssituation

Ursprüngliche Struktur (Navigation)

Problem in der Praxis

Die Homepage hatte Inhalte, die sich mit /lab überschnitten:

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

Warum:
Der Hero ist die klare „Entry“-Zone. Er muss nicht viel erklären, nur richtig leiten.

2) „Das System, auf einen Blick.“

Kennzahlen:

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

Warum:
Das ist das mentale Modell der Seite. Es sagt: „Das hier ist ein System, nicht nur Devices.“


Inhalte, die entfernt wurden

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:

Design-Anforderungen:

2) „Aus dem Blog.“

(Bei mir später über blog.nico-grim.me angebunden.)

Aufbau:

Design-Anforderungen:


Designsystem & UI-Entscheidungen

„Apple-like“ als Designrichtung – was das konkret bedeutet

Nicht „Apple kopieren“, sondern Prinzipien übernehmen:

Dark Mode First

Komponenten-Strategie


Tech Stack & Begründung

Astro (latest)

Warum Astro:

Tailwind CSS

Warum Tailwind:

MDX + Content Collections

Ziel:


Content Modell (Projects)

Dieses Projekt ist selbst als MDX-Project angelegt, damit:

Beispiel-Felder:


Deployment & Domain Setup

Vercel

Subdomain Wechsel (Lineup → HomeLab)

Ein Thema im Projekt war, dass die Domain/Subdomain geändert wurde:

Wichtig dabei:

(Je nachdem, wie du es final gelöst hast, kann man hier später konkretisieren: CNAME, A-Record, Vercel Verification, etc.)


Performance & Quality

Ziele:

Maßnahmen:


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)


Offene Punkte / Roadmap

Option:

2) Architektur-Preview

Option:

4) Content-Erweiterung


Fazit

Der wichtigste Schritt war nicht „mehr Content“, sondern weniger auf der Homepage.

Durch die klare Trennung von:

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.

Ähnliche Projekte