Kickoff: Styling System Overhaul

[kmcginnes]

Note

Kickoff — Wayfinder not yet run, no chart yet. This is the placeholder child of the Styling System Overhaul initiative (#2005), holding a brain dump of paths to explore and potential blockers until scoping happens. "Placeholder" means only that there's no chart — the content below is real. Run /wayfinder against the initiative to create the map; this kickoff closes when that map is created, and the map takes over the scoping route.

Rough intent

Decide the future of the Graph Explorer styling system from the user's perspective — what a style is, how users edit one, and where the editing controls live. The eventual destination (a spec to hand off? a locked decision on sidebar-vs-settings? both?) is named when the map is charted.

Notes

• Domain: graph styling — how vertices/edges are visually styled on the Graph View and Schema View canvas.
• Skills to consult when charting: /wayfinder to chart; /prototype for the UI-shape questions; /domain-modeling for the style vocabulary.
• Interrelated: the model determines what the dialogs and sidebar edit, so it likely gates the UI work rather than running beside it.

Paths to explore

Educated guesses at what needs investigating. Each notes its likely ticket type — the charting session confirms, splits, or drops them.

• Style model / abstraction layer (research + grilling) — Today a "style" is raw Cytoscape values (a hex color, a border width) stored per type. Should styles instead describe intent ("emphasized", "muted", a palette slot, a coordinated theme) with the system computing the Cytoscape values? How does an intent-based model layer onto the Source × Scope cascade (App/Shared/User × Default/Custom) already shipped in User Default Styles: type-less global styling #1881, and onto the typed element contract planned in Make the Cytoscape abstraction a deep, performant module #1891? (Absorbs the model questions from the superseded Spike: scope the revamped style system #1944.)
• Presets (grilling) — what preset vocabulary do we offer (color palettes, coordinated themes, shape sets), and how does a preset interact with per-type overrides and the styling file format?
• Label options (grilling) — which additional label style options are worth offering (placement, background, size, wrapping), and what do they require from the rendering layer?
• Migration (research) — how do existing stored styles and shared styling files map into a new model without breaking users? (Absorbs migration questions from Spike: scope the revamped style system #1944.)
• Style dialog redesign (prototype) — the legacy per-type dialog layout is dated. What's the redesigned layout and interaction: how is the live preview presented, how do the Default dialog and per-type dialog relate visually, is the shape catalog curated? (Absorbs Spike: visual redesign of the style dialogs #1885. The dialog can't be finalized until the model is decided — it edits whatever the model defines.)
• Style sidebar rethink (prototype) — the current styles sidebar is nearly useless. Redesign it in place, or move its options into the Settings page? This is the key sidebar-vs-settings decision.
• Show all styles + quick options (prototype) — currently only styles for the current schema's types are shown. Should we show all available styles, with quick options for common changes (color, icon, node label, edge label)? Entangled with the sidebar-vs-settings decision above.

Potential blockers & pitfalls

Educated guesses at what could block the initiative — or block a particular way of implementing it. Captured from v3.3 planning so charting doesn't re-derive them.

• Dependency order (blocks a path): the model gates the UI. Prototyping dialogs/sidebar before the model is decided risks designing controls for a style shape that then changes. Charting should sequence model-first (or fold model discovery into the first prototype).
• Migration (first-class risk): any new model must convert existing stored styles and shared styling files without breaking current users (see User Default Styles: type-less global styling #1881's shipped cascade and shared-file format).
• Shared styles cross-cut: a shared styling file must carry whatever the new model produces (relates to Shared user styles #1896).
• Cytoscape rework cross-cut: the style model should target the typed element contract from the Cytoscape deep-module work (Make the Cytoscape abstraction a deep, performant module #1891), not fight it.
• Property-based styling ([Feature Request] Property-based node styling (dynamic icons/colors from property values) #1785): a candidate consumer of the new model — keep in view so the model doesn't preclude it.

Related / superseded issues

• Supersedes Spike: scope the revamped style system #1944 (Spike: scope the revamped style system) — its model/presets/label/migration questions are folded into the paths above.
• Supersedes Spike: visual redesign of the style dialogs #1885 (Spike: visual redesign of the style dialogs) — its dialog-redesign questions are folded in.
• Related: Styling System Overhaul #2005 (initiative), [Roadmap] Improved Style Options #1943 (roadmap), User Default Styles: type-less global styling #1881 (Source × Scope cascade), Make the Cytoscape abstraction a deep, performant module #1891 (Cytoscape deep module), Shared user styles #1896 (shared styles), [Feature Request] Property-based node styling (dynamic icons/colors from property values) #1785 (property-based styling).

Important

Internal only — this issue is maintained by the core team and is not accepting external contributions.