Why MEMNO has two dashboards — mobile and desktop kept separate
We did not build mobile and desktop as one responsive UI, but as two deliberately separate experiences. Same route, same data — different components. Here is why that was the better call.
Last week at MEMNO was all about the dashboard. Not because something was broken — but because we had to make a fundamental architecture decision: How do we deliver a great experience on phone and desktop without one platform holding the other back?
Decision
Mobile and desktop are two deliberately separate UIs — not a responsive variant of one component tree. Same route (/dashboard), same data, different components.
The problem with “just make it responsive”
On mobile, freelancers use MEMNO on the go: share a link quickly, check status, swipe between projects. On desktop they work longer sessions — sidebar, split view, multiple projects in sight. Those are not two breakpoints of the same UX, but two work modes.
A single component tree with `lg:` classes would mean `if (desktop)` logic everywhere, hard-to-test states, and compromises on both sides. We did not want that.
Platform gate at 1024px
The breakpoint is 1024px — in sync with Tailwind `lg:`. A `DashboardPlatformProvider` lives in the shell and exposes the current mode via `useDashboardPlatform()`. No more scattered `useIsDesktop()` calls in individual components.
- Mobile: swipe navigation, bottom panels, project overlay
- Desktop: sidebar, split view, settings as its own page
- Shared: filters, views, routing helpers in src/lib/
Navigation: same action, different path
| Action | Mobile | Desktop |
|---|---|---|
| Open profile | Slide panel on the left | /dashboard/settings |
| All projects | Projects overlay | ?view=projects |
| Open project | /dashboard/projects/:id | with ?view= preserved |
The logic lives in `useDashboardNavigation(view)` — one place that encapsulates platform-specific routing. Behavior stays predictable even when the UI looks completely different.
Folder structure
New under `src/features/dashboard/`: `platform/`, `mobile/`, `desktop/`, `shared/`. The entry point `dashboard-entry.tsx` is the only switch. The shell (`dashboard-shell.tsx`) holds data and context — mobile chrome and desktop chrome stay separate.
Why this matters for freelancers
On the go you want to share a change request in three taps. At your desk you want pipeline, open approvals, and project details side by side. Both should feel native — not like a squeezed website.
What comes next
Optional: move desktop components fully into `features/dashboard/desktop/`, split the shell into `MobileChrome` / `DesktopChrome`. The foundation is in place — we are building new features on the right base now.