| name | OpenAIDE | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| description | Modern cross-platform desktop workspace for inspectable agent work. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| colors |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| typography |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| rounded |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| spacing |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| components |
|
Creative North Star: "The Focused Desktop Workspace"
OpenAIDE should feel like a polished application designed specifically for sustained agent work on macOS and Windows. It combines the clarity and keyboard fluency of excellent developer tools with the spatial confidence, finish, and platform integration expected from a modern desktop product.
The desktop application defines the visual standard. Web and VS Code shells share the product language and behavior, then adapt platform-specific window chrome, menus, focus rules, tokens, and file access. VS Code is a supported environment, not the aesthetic template.
Key Characteristics:
- Clear visual hierarchy with purposeful whitespace.
- Project and task navigation optimized for repeated daily use.
- Controls whose shape and emphasis reflect their role.
- Agent chat with folded, inspectable activity rather than raw logs.
- Native shell integration for folders, menus, shortcuts, notifications, and windows.
- Refined light and dark themes with consistent semantic roles.
- Motion that explains state changes and otherwise stays out of the way.
OpenAIDE is restrained, but restraint does not mean grey, tiny, flat, or anonymous. The interface should have recognizable proportions, confident typography, carefully tuned surfaces, and precise interaction states.
Use whitespace to separate concepts, not to imitate a marketing page. Use density where users compare or scan many items, such as Task Navigation. Use more breathing room where users compose, read, decide, or recover from an error.
- Start with the relationship that needs to be communicated, then choose alignment, typography, spacing, containers, borders, and surfaces that make it clear.
- Choose persistent or transient control surfaces according to discoverability, context, input method, and visual hierarchy.
- Choose equal or content-driven sizing according to the meaning of the options, the realistic value range, and the surrounding composition.
- Balance breathing room with information density so space supports comprehension rather than following a fixed aesthetic preference.
- Prefer a coherent icon language, while allowing intentional variation when a platform or concept benefits from it.
- Judge optical alignment from screenshots. Mathematical centering is not sufficient when icons, labels, and chevrons have different visual weight.
OpenAIDE supports first-class light, dark, and system themes. Theme selection belongs in Settings and follows the operating-system preference when set to System.
The palette uses lightly tinted neutrals rather than pure black, pure white, or cold default grey. Accent color is reserved for focus, selection, progress, and the primary safe action. Status colors always pair with text or iconography.
Desktop implementation uses OpenAIDE semantic tokens as its shared vocabulary. A host shell may map or extend those roles when platform conventions materially improve the experience.
- App background: the primary reading and working plane.
- Sidebar background: a distinct navigation plane with enough contrast to establish structure without a heavy divider.
- Surface: composers, popovers, menus, inputs, and grouped interaction.
- Raised: hover, active, transient, and selected-adjacent states.
- Selected: current project, task, option, or navigation destination.
The Accent Rarity Rule. Accent is a state signal, not decoration. Large accent-filled regions require a specific product reason.
The Theme Parity Rule. Light and dark themes must preserve hierarchy and state clarity. Neither theme is a recolored afterthought.
The Border Purpose Rule. Borders communicate a real boundary, input affordance, focus, or selection. They are not the default method for making every item visible.
The system UI stack provides native text rendering on macOS and Windows. One sans family carries the interface. Monospace is reserved for paths, commands, revisions, terminal output, and other code-like values.
- Screen title (20px, 650): primary page question or destination title.
- Title (14px, 600): task titles, popover headings, and meaningful group names.
- Body (14px, 400): controls, settings, descriptions, and ordinary interface copy.
- Chat (15px, 400): user and agent prose.
- Label (12px, 550): compact metadata and short structural labels.
- Mono (12.5px, 400): paths, commands, branches, and technical identifiers.
Use weight, size, color, and spacing together. Muted text can support hierarchy, but important selected values and actions remain comfortably readable.
Use the spacing scale as a starting vocabulary, then tune optical relationships. Repeating the same gap everywhere produces a mechanical interface.
- Related icon and label:
4pxto6px. - Controls inside a compact group:
4pxto8px. - Label to supporting description:
2pxto4px. - Related sections:
12pxto16px. - Major page regions:
24pxto32px.
Desktop layouts should make deliberate use of the window. Navigation may remain dense, while the main work surface should have a readable maximum width and stable alignment. Narrow windows change structure at explicit breakpoints rather than squeezing desktop controls until they fail.
Choose centering when it supports focus or balance, such as empty and start states. Choose scan-oriented alignment when users compare or read active work. Other compositions are valid when they better serve the task.
Use tonal layers first. Transient UI such as menus, popovers, and floating inspection surfaces may use a restrained shadow plus a soft boundary. Persistent surfaces should not float without reason.
Corner radius follows scale and role:
- Small controls and list selections:
6px. - Menus, inputs, and compact grouped surfaces:
10px. - Composer and larger focused surfaces:
14px.
Shared radius, fill, and border can create useful coherence. Vary them when role, scale, hierarchy, or interaction calls for a different silhouette.
- Primary buttons use accent fill for the main safe action.
- Secondary buttons use a visible but quieter surface when they must remain discoverable.
- Ghost buttons are transparent at rest and gain a surface on hover, focus, or open state.
- Icon buttons need a clear accessible name and a hit target appropriate to the shell.
- Button width follows the composition: content-driven, equal, fluid, or fixed sizing are all available when their behavior is deliberate.
- Inline selectors should read as editable values within their surrounding sentence or context.
- Use a semantic icon, selected value, and chevron where they improve recognition.
- Choose permanent or transient surfaces based on how much affordance the selector needs in its current context.
- Selected values use intentional emphasis. Frequency alone does not determine whether an option should appear quieter.
- Long values truncate only when the full value is available in the opened menu and, where useful, nearby context.
- Inputs use a clear surface and focus treatment because typing requires a stable boundary.
- Labels and errors stay near the input, with tooltip support used only as an additional explanation.
- Provide a persistent label when the field's purpose would otherwise become ambiguous.
- Menus align to their trigger and remain within the current window.
- Use one concise heading only when the choices need role or consequence explained.
- Rows have stable icon, label, metadata, selection, and action positions.
- Technical consequences, such as Isolation behavior, belong inside the relevant popup rather than bloating the main composition.
- Use restrained elevation so transient surfaces are clearly above the page without appearing detached.
- Task Navigation uses scan-friendly rows, stable action placement, and clear selected, unread, failed, waiting, and active states.
- Choose navigation density from scanning needs, pointer and keyboard behavior, window size, and realistic content.
- Project groups clarify ownership; cards, indentation, separators, or other structures may be used when they communicate that hierarchy well.
- Archive access stays near search or filtering rather than becoming a permanent secondary section.
- Runtime health, support export, and telemetry details do not live in Task Navigation.
- Narrow windows truncate metadata before actions and avoid unstable wrapped row controls.
- The composer anchors the active task flow and aligns with the readable chat column.
- The input grows until it would crowd history, then scrolls internally.
- Place context actions where their effect is understandable. A consolidated toolbar is appropriate when it improves discovery and remains coherent at realistic widths.
- Send becomes stop or cancel during active agent work.
- Agent chat prioritizes readable conversation with compact folded activity.
- Sequential tool calls group under one meaningful natural-language summary.
- Individual calls usually render as supporting details, but richer cards, logs, or terminal treatments are appropriate when the underlying content needs them.
- Long user content and noisy tool output collapse with controls outside clipped content.
- Respect native menu placement, keyboard conventions, traffic-light safe areas, fullscreen behavior, and system file dialogs.
- Use macOS typography and focus behavior through the system stack rather than drawing a fake macOS theme.
- Respect native window controls, keyboard access, snap layouts, scaling, notifications, and system file dialogs.
- Verify common display scaling levels and adapt intentionally across device-pixel ratios.
- Provide deliberate browser-safe substitutes for operating-system file and folder access.
- Preserve product structure and visual quality while designing explicitly for browser capabilities and limitations.
- Integrate commands, focus, file reveal, and host capabilities where useful.
- Map semantic roles to host tokens when useful for legibility and integration. Adopt VS Code density or component styling where it genuinely improves that shell, without assuming it should transfer elsewhere.
Most interaction transitions use 120ms to 180ms ease-out timing. Other timing and motion models are appropriate when they clarify spatial change, direct attention, express product character, or support a platform convention. Prefer compositor-friendly animation; use layout animation when its explanatory value justifies the cost.
Respect reduced-motion preferences across every shell.
Before presenting a UI direction:
- Review the complete composition, not an isolated component crop.
- Capture realistic desktop and narrow-window screenshots in both light and dark themes when color or elevation changed.
- Exercise default, hover, focus, open, selected, loading, empty, error, disabled, and long-value states that affect the decision.
- Check overflow and display scaling.
- Ask whether each border, fill, icon, label, and container has a specific job.
- Ask whether each control's treatment is the strongest fit for its role, including when a simple rectangle is the clearest answer.
- Evaluate asymmetry, empty space, hierarchy, and density in the complete composition rather than treating any of them as inherently good or bad.
- Treat peer critique as evidence, not approval. The final judgment comes from the rendered composition and the product intent.
No component, visual effect, layout family, or aesthetic is prohibited by name. Cards, modals, gradients, glass effects, dense layouts, sparse layouts, equal-width controls, asymmetric compositions, editor-inspired patterns, decorative moments, and unconventional interactions can all be excellent choices in the right context.
For any significant design choice, ask:
- What user problem or product quality does this choice improve?
- Why is it a better fit here than the credible alternatives?
- Does it remain effective with realistic content, states, themes, platforms, and window sizes?
- Is its familiarity useful, or is it being copied without the original context?
- Does consistency help the user transfer knowledge, or would meaningful distinction improve comprehension?
- Does the visual expression support the work, product character, or moment being designed?
- Is the execution polished enough for the ambition of the idea?
Use these questions to challenge defaults and weak reasoning, not to narrow the available design vocabulary.