Interface Details Worth Borrowing from 37signals' Desktop Companions

Escaping the Browser Tab Illusion

What separates a web app wrapped in a basic shell from a desktop companion that feels native to macOS? The gap is measurable in pixels. A stock web wrapper renders its first pixel of app content roughly 52 points below the top of the window, combining a 28pt system title bar with a 24pt page header. 37signals bridges this gap in Basecamp and HEY through three specific micro-interactions: window chrome integration, intentional sidebar density, and restrained badge behavior. These companion apps put authored content at the very top edge and let the header colour run under the traffic lights.

Frame-by-frame capture analysis of the companion apps produced a raw difference list that ran past two dozen entries. Cursor states, scrollbar overlay timing, focus ring colour, and sheet animation curves all presented slight variations from standard web rendering. The engineering approach relied on a strict three-part decision rule. Any visual difference between the wrapped tab and the companion app that traced back to title-bar treatment, sidebar row rhythm, or notification restraint was kept. Anything inherited from the rendering engine, such as scroll elasticity or context-menu ordering, was struck from the list.

During the 9–15 working-day retrofit effort evaluated for this interface analysis, developers isolated the specific variables that dictate native application feel. A realistic retrofit of all three patterns into an existing wrapped web app requires this dedicated time block for a single developer. The title-bar work consumes the first 3–4 days of the sprint. The sidebar rhythm pass consumes most of the remainder. These small, deliberate choices prevent the application from feeling like a detached browser tab.

Engineering the Frameless Window Chrome

Early attempts to own the visual aesthetic often involve building a fully frameless window with hand-drawn close, minimise, and zoom circles. This approach typically fails under basic system interactions. Hand-drawn buttons fail to dim when the window loses key status. They refuse to expand into the full-screen arrows on hover. They land in the wrong place entirely once the window is toggled into full-screen mode.

HEY and Basecamp handle the macOS title bar by utilizing the system's native inset style, avoiding the standard, disconnected web-wrapper look. System traffic lights are 12pt circles spaced 20pt apart, with the first circle's centre sitting 20pt from the window's left edge. The inset title-bar style leaves them at a 12pt vertical offset. A header taller than 40pt needs the button group pushed down by hand to stay optically centred.

Defining specific drag regions using CSS is mandatory for natural window movement. The drag region needs to be an explicitly declared band, typically the top 38–44pt of the window. Every interactive child inside it requires a reset to no-drag. If a search field, avatar menu, or segmented control lacks this exception, the control swallows the first click and the window jumps on the second.

Drag Region Configuration

A drag band shorter than roughly 28pt is reachable but unforgiving. Users overshoot it with the pointer on 27-inch displays and hit the first row of app content instead. Providing a generous, explicitly defined -webkit-app-region: drag area ensures users can move the window naturally without accidentally highlighting text or triggering unintended navigation events.

Compressing the Navigation Rhythm

Standard web spacing favors touch targets and generous white space. Native Mac sidebar spacing favors information density. Measuring line-box heights settled the density debate for these companion apps. Rows in the system file browser and mail client were sampled at their default sizing and their line-box heights compared against a typical responsive web nav item. The web version was consistently taller by roughly one text line.

Native sidebar rows run about 24pt at small sizing, 28pt at medium, and 32pt at large. A conventional web nav item with 12px vertical padding around 16px type lands near 44px. To match the rhythm of native macOS applications like Finder or Mail, the padding drops to 4–6px per side to hit the medium target. Shrinking the typography to close the gap makes labels look like footnotes, so the decision was to keep the label size and compress the padding.

Selection states require specific geometric constraints. Selection highlights in the companion apps avoid full-bleed rectangles. The fill is inset 8–10pt from each sidebar edge with a 5–6pt corner radius. The label flips to the high-contrast inverted colour only while the window is key. On resign, the fill drops to a muted grey and the label returns to its normal weight.

Sidebar translucency uses the dedicated sidebar material rather than a generic blur. In a web-rendered shell, the body background must be fully transparent for the material to show through. Every wrapper element between the HTML root and the nav list needs its own background explicitly cleared. Translucency operates as a rendering preference rather than a system guarantee. When a user switches on Reduce Transparency in macOS settings, the material collapses to a flat opaque fill, meaning label and selection contrast must be verified against that solid colour.

Establishing a Quiet Notification Hierarchy

The badge rules in these apps read as a hierarchy decision based on event authorship. Indicators are sorted by who authored the event: things the user explicitly asked to be told about, things another person did directly to the user, and things the system generated on its own. The dock-edge boundary enforces strict rules for these categories.

Sender rules the user typed in themselves may light a red badge. Direct human replies get a 6–8pt grey dot inside the window and nothing more. System-generated events get no indicator at any layer and are found only by opening the view. This philosophy rejects the use of aggressive red dots for every minor update, contrasting sharply with the standard web approach of persistent, algorithmic engagement bait.

In-window unreads are carried by weight and a small dot. A 6–8pt grey dot at the row's trailing edge pairs with a semibold label. This dot clears on scroll-past, eliminating the need for explicit dismissal clicks. Red dock badges are reserved strictly for critical, user-defined interruptions. In a mail-style app, that typically means a single-digit count that stays under 10 for weeks at a time, versus the three- and four-digit totals a conventional inbox badge accumulates.

Notification Coalescing Logic

Coalescing windows matter more than raw notification counts. Grouping arrivals from the same conversation inside a window of something like 90–120 seconds turns a burst of five notifications into one. This timing adjustment substantially reduces perceived noise in a multitasking session, keeping the desktop environment focused and calm.

Sequencing the Desktop Retrofit

Implementation order dictates the stability of the project. The sequence is chosen to keep the app shippable at every step. The title bar goes first because it changes window geometry and invalidates every screenshot in the repository. The sidebar rhythm goes second because it is pure CSS and can be tuned against a running build. The badge policy goes last because it touches the notification permission flow and needs a full testing cycle.

The concrete surface area in an Electron-style shell is surprisingly small. The required changes include one window constructor option for the inset title bar, one traffic-light offset object, one sidebar material declaration, a drag-region rule plus its no-drag exceptions, and a single root font-size override. This amounts to five to seven changed lines before any component CSS is touched. Borrowing these details requires restraint rather than adding complex new features.

Teams must budget a settling period of somewhere around 5–8 days after the density pass. Using a tightened sidebar feels cramped for the first two days, give or take, even when the measurements are correct. Changes made inside that initial adjustment window tend to undo the precise mathematical work required to match the native system rhythm.

Apple's macOS Human Interface Guidelines establish 13pt as the default system font size for standard body text—a subtle, specific shift from the web's standard 16px default that instantly changes the physical scale and feel of an application.