Skip to content

UI design system & visual identity — call for contributors #195

Description

@debba

I'm a backend dev. I built most of the current UI by eye, without any design background. It works, but it looks like what it is: a frontend assembled one modal at a time, with colors and spacing picked on the spot.

Some examples of what I mean:

  • the logo is a placeholder I never replaced
  • the color palette grew organically. The CSS variables in src/index.css (bg-base, bg-elevated, text-primary, etc.) are an attempt to centralize it, but the values themselves were chosen by trial and error
  • spacing is inconsistent across pages. You'll find p-3, p-4, p-5 on similar-looking containers depending on which file I was in that day
  • button, input and modal styles drift between the Connection modal, the Settings page, the plugin modals and the query editor toolbar
  • icons (lucide) get a different size or stroke depending on the component
  • light/dark themes are kept in sync manually, so they fall out of sync

What I'd like to do, eventually:

  • a real logo, in the sizes the app actually needs (titlebar, about, favicon, GitHub social preview)
  • a documented palette with semantic roles (surfaces, text levels, accent, success/warning/danger/info), with light and dark generated from the same source instead of maintained twice by hand
  • one type scale, one spacing scale, used everywhere
  • shared primitives for button/input/select/tab/modal/tooltip. SettingControls.tsx already does this for the Settings page — the same pattern should cover the rest of the app
  • a short doc somewhere that says "here's the palette, here's the spacing scale, here's how to build a modal," so the next contributor doesn't have to reverse-engineer my taste

To be clear: this isn't a UX rework. The sidebar, the tabs, the settings layout, the query editor flow — they're fine. This is purely about visual consistency and having a written-down system instead of vibes.

If you have a design background and want to weigh in (palette proposals, a logo concept, a Figma file, or just opinions on the current state), please comment. I'd rather do this once with someone who knows what they're doing than keep iterating on instinct.

For devs: once direction is decided the migration can be split into smaller follow-up issues, primitive by primitive.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is neededroadmapPart of the product roadmap

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions