Moving the Sidebar to the Top

The first version of the desktop app had a sidebar on the left. Five tabs stacked vertically. Essentially the mobile bottom tab bar, rotated.

It worked. But after a few days of use, the awkwardness piled up. The sidebar took up horizontal space, and on a desktop screen, horizontal space is the most precious resource. And desktop users tend to look up for menus — operating systems, browsers, almost every desktop app puts its navigation up there.

Patterns that work on mobile don’t always carry over.

Moving It Up

Deciding to move the tabs to the top was simple. A horizontal bar across the top, with the logo and five tabs laid out left to right. Removing the sidebar gave the main content more horizontal room.

But this raised one more question. Back when the sidebar existed, each page had its own auxiliary menu. The calendar page had “Manage Routines” and “Open Reviews.” The library had “Sort” and “Filter.” If the sidebar disappears, where do those menus go?

The Page Carries Its Own Menu

We could have stuffed every page’s auxiliary menu into one global sidebar. But then menus from other pages would always be visible even when irrelevant. A menu detached from its page context loses meaning.

Instead, each page now carries its own menu. There’s a hamburger icon at the top right corner of the screen, and tapping it reveals whatever menu the current page has registered. On the calendar page, you get the calendar’s menu. On the library page, the library’s. The slot stays the same; the contents change.

Each page registers its menu in shared state on mount, and clears it on unmount. The top bar reads from that state and renders accordingly. The code stays simple, and adding a menu to a new page is now a single line.

The result is that menus always sit next to their page. The reachable menu items shift based on where the user is.

When a Menu Item Is a Whole Surface

Some menu items are simple toggles or short actions. Others — “Manage Routines,” “All Reviews” — need a whole screen of their own.

For these, we open a fullscreen overlay rather than navigate to a new route. The calendar stays underneath; the new surface drops on top, and dismissing it returns you to the calendar exactly where you were.

The reason is continuity of flow. If a user opens “Manage Routines” briefly while working in the calendar, that’s part of the calendar work, not a separate journey. Switching routes makes the browser back button behave oddly, and once dismissed, the user has to find their way back. An overlay doesn’t break that thread.

Desktop Isn’t Mobile, Bigger

This work clarified something for us. The desktop version isn’t the mobile app on a larger screen. Different environment, different usage patterns, different conventions.

On mobile, the bottom is the gold zone — that’s where the thumb falls. On desktop, gaze flows from top to bottom. Mobile screens are tall; desktop screens are wide. Mobile users hold the device close in one hand. Desktop users sit back, working with keyboard and mouse from a distance.

Even from a shared codebase, the texture of the interface needs to be cut differently. Moving the sidebar to the top was one small starting point in that recognition. Since then, we’ve started asking “what feels natural in this environment” before “how does the mobile version do this” — across most parts of the desktop build.

The same app, but it doesn’t have to feel the same in your hand.