53 lines
3.1 KiB
Markdown
53 lines
3.1 KiB
Markdown
# 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
|
|
1. The user drags a new **Selection Group** node into the Logic/Layers panel.
|
|
2. The user drags the desired meshes (e.g., Wheel_A, Wheel_B, Wheel_C) into this group.
|
|
3. The group has a property called **Selection Mode** (Single / Multiple / Exactly One).
|
|
4. 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
|
|
1. User defines Variants on a Material as usual (Red, Blue, Green).
|
|
2. User drags a **Material Variant UI Block** onto their 2D Canvas.
|
|
3. User selects the Target Mesh in the block's properties.
|
|
4. 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.
|