Skip to content

PRODUCT.md

Latest commit

 

History

History
52 lines (31 loc) · 4.51 KB

PRODUCT.md

File metadata and controls

52 lines (31 loc) · 4.51 KB
Raw

Product

Register

product

Users

Enterprise knowledge workers who keep Rocket.Chat open all day, often in the background. Many work inside regulated or self-hosted environments (government, healthcare, finance, on-prem IT). A meaningful subset are power users juggling multiple Rocket.Chat workspaces (work + community + customer tenants) and depend on the desktop client for fast cross-server switching, OS-level notifications, and native integrations the browser cannot offer.

Primary context: long-session use on a work machine, alongside other native apps. Users alt-tab in and out; they do not study the chrome, they reach for it.

Product Purpose

Rocket.Chat Desktop is the native shell around one or more Rocket.Chat server webviews. Its job is to make managing multiple workspaces fast: server list switching, notification badges, deep links, certificate handling, screen sharing, downloads, tray presence, auto-update. The webview is the chat product; the desktop client is the connective tissue that makes running several at once feel like one tool instead of several browser tabs.

Success looks like: users forget the shell exists during normal use, and reach for it instinctively the moment they need to switch servers, recover from a stuck webview, or configure something the browser cannot do.

Brand Personality

Reliable, professional, focused. Voice is plain and unornamented: short labels, no marketing flourishes, no playful microcopy. The interface should feel like a tool an IT admin would trust on a regulated network, while remaining warm enough for end users who live in it eight hours a day. Confident, not loud. Capable, not clever.

Anti-references

  • Discord / gamer chat aesthetics. Neon accents, drenched dark purple, playful empty states, animated reactions in chrome. Wrong register for enterprise and public sector.
  • Old Skype / legacy Teams chrome. Heavy gradients, layered drop shadows, busy toolbars, decorative iconography in titlebars. Dated, visually noisy, undermines trust.
  • Generic SaaS marketing patterns inside the app. Gradient hero numbers, identical icon-and-title card grids, "modern dashboard" aesthetics. The desktop shell is not a marketing surface.
  • Pure brand minimalism (Linear-empty for its own sake). Multi-server power users need information density in the sidebar. Sparse-for-sparseness-sake hides the value of the shell.

Design Principles

  1. Shell disappears, servers shine. Desktop chrome must not compete with the webview. Sidebar, titlebar, and dialogs exist to switch, notify, and configure, then recede. If a chrome element draws the eye during normal chat use, it is wrong.

  2. Density without clutter. Multi-workspace power users need many servers and signals visible at once. Earn every pixel: tight rhythm, considered hierarchy, no decorative padding. Density and clarity are compatible; sparse is not automatically better.

  3. Native, not web-pretending. Respect OS conventions per platform: macOS traffic lights and vibrancy, Windows titlebar buttons and Mica, Linux menubar fallbacks. The desktop edge over the browser IS the native feel. Cross-platform consistency matters less than per-platform correctness.

  4. Trust through restraint. Enterprise, government, and healthcare users need confidence. No surprises, no flourishes, no theatrical motion. Predictable beats clever. Errors are quiet and actionable, not dramatic.

  5. Fuselage first, custom last. Visual coherence with the Rocket.Chat web app is a feature for users who move between web and desktop. Use @rocket.chat/fuselage primitives by default. Introduce custom components only where the desktop shell has no web equivalent (server sidebar, native dialogs, platform-specific affordances).

Accessibility & Inclusion

Target: WCAG 2.2 AA, with attention to extras commonly required by Rocket.Chat's public sector and healthcare deployments.

  • Full keyboard navigation across the shell (sidebar, menus, dialogs). No mouse-only affordances.
  • Screen reader labels on every interactive shell element, including server sidebar entries and notification badges.
  • Honor prefers-reduced-motion for all shell motion (sidebar transitions, dialog enters, badge animations).
  • Honor system-level high contrast and forced colors on Windows.
  • Contrast meets 2.2 AA against the active theme; verify against both light and dark.
  • Do not rely on color alone to convey state (unread, error, connecting). Always pair with shape, icon, or text.
  • Color-vision-deficient safe accent choices when introducing new status colors.