Development
Warum MEMNO zwei Dashboards hat — Mobile und Desktop getrennt
Wir haben Mobile und Desktop nicht responsive gebaut, sondern als zwei bewusst getrennte UIs. Gleiche Route, gleiche Daten — unterschiedliche Komponenten. Warum das die bessere Entscheidung war.
Die letzte Woche stand bei MEMNO im Zeichen des Dashboards. Nicht weil etwas kaputt war — sondern weil wir eine grundlegende Architektur-Entscheidung treffen mussten: Wie bauen wir eine gute Erfahrung auf dem Handy und am Desktop, ohne dass eine Seite die andere ausbremst?
Entscheidung
Mobile und Desktop sind zwei bewusst getrennte UIs — keine responsive Variante eines Baums. Gleiche Route (/dashboard), gleiche Daten, unterschiedliche Komponenten.
Das Problem mit „einfach responsive“
Auf dem Handy nutzen Freelancer MEMNO unterwegs: schnell einen Link teilen, Status checken, zwischen Projekten wischen. Am Desktop sitzen sie länger dran — Sidebar, Split-View, mehrere Projekte im Blick. Das sind nicht zwei Breakpoints derselben UX, sondern zwei Arbeitsmodi.
Ein einziger Komponentenbaum mit `lg:`-Klassen würde bedeuten: überall `if (desktop)`-Logik, schwer testbare Zustände und Kompromisse bei beiden Seiten. Wir wollten das nicht.
Platform Gate bei 1024px
Der Breakpoint liegt bei 1024px — synchron mit Tailwind `lg:`. Ein `DashboardPlatformProvider` sitzt in der Shell und liefert über `useDashboardPlatform()` den aktuellen Modus. Kein verstreutes `useIsDesktop()` mehr in einzelnen Komponenten.
- Mobile: Swipe-Navigation, Bottom-Panels, Projekt-Overlay
- Desktop: Sidebar, Split-View, Settings als eigene Seite
- Shared: Filter, Views, Routing-Helfer in src/lib/
Navigation: gleiche Aktion, anderer Weg
| Aktion | Mobile | Desktop |
|---|---|---|
| Profil öffnen | Slide-Panel links | /dashboard/settings |
| Alle Projekte | Projects-Overlay | ?view=projects |
| Projekt öffnen | /dashboard/projects/:id | mit ?view= preserved |
Die Logik steckt in `useDashboardNavigation(view)` — eine Stelle, die plattformspezifisches Routing kapselt. So bleibt das Verhalten vorhersagbar, auch wenn die UI komplett anders aussieht.
Ordnerstruktur
Neu unter `src/features/dashboard/`: `platform/`, `mobile/`, `desktop/`, `shared/`. Der Entry-Point `dashboard-entry.tsx` ist der einzige Switch. Die Shell (`dashboard-shell.tsx`) hält Daten und Context — Mobile-Chrome und Desktop-Chrome bleiben getrennt.
Warum das für Freelancer zählt
Unterwegs willst du in drei Taps einen Nachtrag teilen. Am Schreibtisch willst du Pipeline, offene Freigaben und Projektdetails nebeneinander sehen. Beides soll sich nativ anfühlen — nicht wie eine gequetschte Website.
Was als Nächstes kommt
Optional: Desktop-Komponenten vollständig nach `features/dashboard/desktop/` verschieben, Shell in `MobileChrome` / `DesktopChrome` splitten. Die Basis steht — weitere Features bauen wir jetzt auf dem richtigen Fundament.