Desktop UI Panels Boards

Panels, Boards & Tool Sections (Desktop)

Dockable / resizable panel systems

Common in editor-style apps (code editors, DAWs, 3D tools) that show several working areas at once.

• Every panel boundary should be a real drag handle (typically 4–6px hit area, visually a 1px hairline until hovered) — resizing panels is a core desktop interaction that a mouse/website user rarely needs but a power user relies on constantly.
• Give every panel a sane min-width/min-height so dragging can't collapse it into an unusable sliver — either enforce a floor, or let it snap fully closed past a threshold (with an easy way to reopen it, like a toolbar toggle) rather than leaving it stuck at 20px wide.
• Persist the user's panel arrangement (sizes, which panels are open/closed) between sessions — resetting layout on every launch is one of the more consistently frustrating things a tool app can do to a repeat user.
• If panels can pop out into their own window (common in DAW/creative-tool contexts) or be rearranged by dragging tabs between docks, make the valid drop zones visually obvious during the drag (a highlighted outline), not just functional-but-invisible.

Kanban-style boards

• Columns get a fixed or user-set width, with the column header showing the column name and a count of cards in it — the count alone helps users gauge board state without reading every card.
• Cards within a column are vertically stacked, individually draggable, with a clear "lift" affordance on drag start (slight scale-up plus a stronger shadow — see desktop-ui-motion for the transform-based approach) and a placeholder gap showing exactly where the card will land as it's dragged over other cards.
• Empty columns need their own empty state (a light dashed drop-zone outline with brief text), not just blank space — otherwise it's unclear whether the column is empty or hasn't loaded.
• If columns can overflow horizontally (more columns than fit the window), scroll the board horizontally rather than shrinking column width below a usable minimum (~240–280px) — see desktop-ui-scrolling-navigation.
• WIP (work-in-progress) limits, if the app has them, should show progress toward the limit directly in the column header (e.g. "4/5"), and shift to a warning color only once at or over the limit — not a constant warning tone.

Tool palettes / tool sections

The toolbox pattern from creative apps (a grid or column of icon-only tool buttons: select, brush, crop, etc.):

• One tool active at a time, shown with a clear, persistent selected state (filled background + accent color, not just a border) — this is a state the user needs to track at a glance while looking at their actual work, not at the toolbar.
• Group related tools together with a small gap or divider between groups (selection tools / drawing tools / view tools, for instance) rather than one undifferentiated row.
• Tools with variants (e.g. multiple selection modes) get a small flyout or press-and-hold menu off the main tool icon, indicated by a small corner marker — don't hide variant tools with no visual cue that more options exist.
• Always show each tool's keyboard shortcut in its tooltip (see desktop-ui-surfaces-overlays) — creative-tool power users learn the whole palette by keyboard within days and stop looking at the toolbar at all once they do; the tooltip is how they learn the shortcut in the first place.
• Icon-only is appropriate here specifically because the palette is used constantly and text labels would slow recognition down, not speed it up — but this only works if the icons themselves are unambiguous (see desktop-ui-icons) and consistently drawn.

Accessibility

Anything reordered or moved by drag alone (kanban cards, dockable panels) needs a keyboard-driven equivalent — a context menu action ("Move to next column," "Move up/down") or arrow-key reordering while a card has focus — since drag-and-drop alone excludes keyboard-only and many screen reader users completely. See desktop-ui-accessibility-i18n.

Review format