3.1 KiB
Divya Week 4 — Visual UX / Product Micro-Proposals
Proposal 1: The "Selection Group" Logic Node
Problem
Currently, managing "Single-Select" behavior (where choosing one option automatically deselects others) requires building individual "Reset" triggers for every single button. This leads to State Explosion—as the number of parts grows, the logic becomes unmanageable and fragile.
User Story
"As a configurator designer for an automotive brand, I want to add 20 different wheel options to my scene and ensure that only one wheel is active at a time, without having to manually code 400 mutual-exclusivity triggers."
Proposed Builder Experience
- The user drags a new Selection Group node into the Logic/Layers panel.
- The user drags the desired meshes (e.g., Wheel_A, Wheel_B, Wheel_C) into this group.
- The group has a property called Selection Mode (Single / Multiple / Exactly One).
- Any UI button linked to a mesh inside this group automatically follows the group's "Radio Button" rules.
Proposed Primitive / Block / Pattern
A Logic Container primitive that acts as a state coordinator for its children. It intercepts visibility/state calls and enforces exclusivity rules at the architecture level rather than the manual trigger level.
Why This Matters
It transforms Thob from a "Simple Toggler" into a professional "Product Configurator Engine." It removes the #1 source of logic errors in complex scenes.
Complexity Guess
- Medium (Requires a new logic-controller node type but uses existing visibility/selection states).
Proposal 2: The "Material Variant" UI Block
Problem
Creating a color-switcher UI is currently a manual process: Drag a button, style it, link it to a variant, repeat 10 times. It is repetitive and prone to "Sync Drift" (where the UI doesn't match the actual variants available on the material).
User Story
"As a furniture designer, I have a sofa material with 15 fabric variants already defined. I want to generate a polished 'Fabric Selection' menu in my UI with one click, rather than building 15 manual buttons."
Proposed Builder Experience
- User defines Variants on a Material as usual (Red, Blue, Green).
- User drags a Material Variant UI Block onto their 2D Canvas.
- User selects the Target Mesh in the block's properties.
- The UI Block automatically generates a list of buttons (or a dropdown) based on the variants it finds on that mesh's material.
Proposed Primitive / Block / Pattern
An Atomic UI Component that is "schema-aware." It reads the Material.variants array and dynamically renders the corresponding interaction UI at runtime.
Why This Matters
It reduces "Time-to-Value" for the most common 3D web use case (swappable colors). It ensures the UI is always 100% in sync with the scene data.
Complexity Guess
- Medium (Requires the UI engine to be able to reach into the 3D Material definitions).
Optional Tiny Demo (Concept)
- Refer to Week 3 Task 1 & 2 reports. The "Simulated" buttons used in those audits are the exact patterns this block would automate.