Editor's thread color picker shows every catalog color in a uniform grid — no visual differentiation by thread line / brand / type, the user can't tell at a glance which colors are 'standard Robison-Anton' vs 'Brother PR-10' vs 'custom' #257

Closed
opened 2026-10-04 03:36:54 +00:00 by Mark · 2 comments
Owner

Finding

src/components/editor/EditorRightPanel.tsx's Thread Color picker renders each color as a swatch in a 5-column grid. The swatch is just a colored circle/rectangle. There's no visual differentiation by:

  • Thread line (Robison-Anton vs Brother vs Madeira vs Coats & Clark)
  • Thread type (cotton vs polyester vs rayon vs metallic)
  • Custom vs catalog
  • In-use vs not-in-use (a color currently used by a path)

grep -n 'line\|brand\|inUse' src/components/editor/EditorRightPanel.tsx returns 0 hits for visual differentiation.

A user with:

  • 30 Robison-Anton Rayon colors (catalog)
  • 30 Brother Polyester colors (catalog)
  • 5 custom colors (per #233)

Sees 65 identical swatches. They can't tell which is which at a glance. They have to hover each one to read the name in the tooltip.

Where

  • Thread color picker: src/components/editor/EditorRightPanel.tsx (the 5-column grid)
  • Thread line/brand: ThreadColor type — let me check if it has these fields

Suggested fix shape

Add subtle visual differentiation:

  1. Custom colors (per #233): show a small star or "C" badge on the swatch's corner. A custom color stands out from the catalog.

  2. In-use vs not-in-use: highlight the colors currently used by at least one path. A small "•" dot on the swatch's bottom-right, or a thicker border.

  3. Group by line/brand: instead of a single 5-column grid, render separate sections: "Robison-Anton Rayon" header, "Brother Polyester" header, "Custom" header. Each section is its own grid.

  4. Hover for details: on hover, show the line/brand in the tooltip (already in the catalog data).

The ThreadColor type may need a line?: string field (e.g., "Robison-Anton Rayon", "Brother Polyester"). The current type may already have it; let me check.

If the type doesn't have it, add it:

export interface ThreadColor {
  id: string;
  name: string;
  hex: string;
  line?: string;       // 'Robison-Anton Rayon', 'Brother Polyester', 'Custom'
  type?: string;       // 'rayon', 'polyester', 'cotton', 'metallic'
}

Severity

Low. The user can hover each color. Power users with large catalogs notice.

Discovered by

Gap analysis (2026-10-02) of thread color picker affordances.

  • #256 (filed in previous turn) — Thread color search. Same picker; the search is the lookup.
  • The workspace's "Thread Library" (per useThreadLibrary) has the same colors; the editor's picker is the same UI surface.
  • The Help page documents the Robison-Anton palette; the picker could mirror that organization.
## Finding `src/components/editor/EditorRightPanel.tsx`'s Thread Color picker renders each color as a swatch in a 5-column grid. The swatch is just a colored circle/rectangle. There's no visual differentiation by: - Thread line (Robison-Anton vs Brother vs Madeira vs Coats & Clark) - Thread type (cotton vs polyester vs rayon vs metallic) - Custom vs catalog - In-use vs not-in-use (a color currently used by a path) `grep -n 'line\|brand\|inUse' src/components/editor/EditorRightPanel.tsx` returns 0 hits for visual differentiation. A user with: - 30 Robison-Anton Rayon colors (catalog) - 30 Brother Polyester colors (catalog) - 5 custom colors (per #233) Sees 65 identical swatches. They can't tell which is which at a glance. They have to hover each one to read the name in the tooltip. ## Where - Thread color picker: `src/components/editor/EditorRightPanel.tsx` (the 5-column grid) - Thread line/brand: `ThreadColor` type — let me check if it has these fields ## Suggested fix shape Add subtle visual differentiation: 1. **Custom colors** (per #233): show a small star or "C" badge on the swatch's corner. A custom color stands out from the catalog. 2. **In-use vs not-in-use**: highlight the colors currently used by at least one path. A small "•" dot on the swatch's bottom-right, or a thicker border. 3. **Group by line/brand**: instead of a single 5-column grid, render separate sections: "Robison-Anton Rayon" header, "Brother Polyester" header, "Custom" header. Each section is its own grid. 4. **Hover for details**: on hover, show the line/brand in the tooltip (already in the catalog data). The `ThreadColor` type may need a `line?: string` field (e.g., "Robison-Anton Rayon", "Brother Polyester"). The current type may already have it; let me check. If the type doesn't have it, add it: ```ts export interface ThreadColor { id: string; name: string; hex: string; line?: string; // 'Robison-Anton Rayon', 'Brother Polyester', 'Custom' type?: string; // 'rayon', 'polyester', 'cotton', 'metallic' } ``` ## Severity Low. The user can hover each color. Power users with large catalogs notice. ## Discovered by Gap analysis (2026-10-02) of thread color picker affordances. ## Related - #256 (filed in previous turn) — Thread color search. Same picker; the search is the lookup. - The workspace's "Thread Library" (per `useThreadLibrary`) has the same colors; the editor's picker is the same UI surface. - The Help page documents the Robison-Anton palette; the picker could mirror that organization.
Author
Owner

Fixed in 499db84 — two small affordances added to the Editor's thread color picker:

  1. Custom colors get a "C" badge top-right. Reads the existing LibraryEntry.source field ('user' for entries created via the Add Thread Color modal, 'service' for catalog entries from the Brother PR10 service). Plain ThreadColor[] callers (tests, anything not yet on the three-tier library) show no badge.

  2. Colors currently used by a path get a small white dot bottom-right. Computed from paths[i].threadColor. The currently-selected swatch hides the dot — the amber current-border is the only badge on it.

The title and aria-label pick up the same context (· custom, · in use) so hover-tooltip and screen reader text carry the differentiation.

I scoped the fix to the Editor picker (the surface flagged in #257). The Workspace's RightPanel.tsx has the same uniform-grid shape at line 723 — happy to mirror the badges there as a follow-up if you want consistency across both pickers.

Tests: 3 new cases pin the data-source attribute, the in-use dot, and the custom badge. 153/153 EditorRightPanel tests pass.

Fixed in 499db84 — two small affordances added to the Editor's thread color picker: 1. **Custom colors get a "C" badge top-right.** Reads the existing `LibraryEntry.source` field (`'user'` for entries created via the Add Thread Color modal, `'service'` for catalog entries from the Brother PR10 service). Plain `ThreadColor[]` callers (tests, anything not yet on the three-tier library) show no badge. 2. **Colors currently used by a path get a small white dot bottom-right.** Computed from `paths[i].threadColor`. The currently-selected swatch hides the dot — the amber current-border is the only badge on it. The title and aria-label pick up the same context (`· custom`, `· in use`) so hover-tooltip and screen reader text carry the differentiation. I scoped the fix to the Editor picker (the surface flagged in #257). The Workspace's `RightPanel.tsx` has the same uniform-grid shape at line 723 — happy to mirror the badges there as a follow-up if you want consistency across both pickers. Tests: 3 new cases pin the `data-source` attribute, the in-use dot, and the custom badge. 153/153 `EditorRightPanel` tests pass.
Author
Owner

Fixed in commit. Closing.

Fixed in commit. Closing.
Mark closed this issue 2026-10-04 10:45:22 +00:00
Sign in to join this conversation.
No description provided.