50 lines
3.6 KiB
Markdown
50 lines
3.6 KiB
Markdown
# Divya Week 4 — Visual Priority Recommendations
|
||
|
||
## 3 Quick Wins
|
||
|
||
### 1. Asset Pipeline Validation & Feedback
|
||
- **Problem**: Texture uploads larger than 5MB fail silently without informing the user.
|
||
- **Why it matters**: It creates "Invisible Walls" for professional designers, leading to wasted time troubleshooting missing assets.
|
||
- **Recommendation**: Implement a simple file-size check and "Error Toast" notification when an upload is rejected.
|
||
- **Expected user impact**: Immediate reduction in "Unreliable Asset" complaints and faster authoring loops.
|
||
- **Confidence level**: High (This is a standard frontend validation).
|
||
|
||
### 2. $Context Syntax Dropdown / Autocomplete
|
||
- **Problem**: Binding UI triggers to Mesh IDs requires memorizing proprietary `$context` syntax.
|
||
- **Why it matters**: It is the single biggest friction point during the "Logic Linking" phase of building a configurator.
|
||
- **Recommendation**: Add a simple "Logic Picker" dropdown in the Binding panel that pre-fills valid $context paths.
|
||
- **Expected user impact**: Drastic reduction in "Interaction Drift" and a much lower learning curve for new designers.
|
||
- **Confidence level**: High.
|
||
|
||
### 3. Configurator Default State Persistence
|
||
- **Problem**: Active selections (like a chosen planet texture) reset to default on browser refresh.
|
||
- **Why it matters**: Makes "Reviewing" or "Sharing" specific configurations impossible during the build process.
|
||
- **Recommendation**: Store the active variant indices in the local editor session or URL params.
|
||
- **Expected user impact**: Improves the "QA and Review" workflow for design teams.
|
||
- **Confidence level**: Medium.
|
||
|
||
## 2 Medium Features
|
||
|
||
### 1. The "Selection Manager" Logic Primitive
|
||
- **Problem**: Managing mutual exclusivity (Single-Select) across 10+ parts is currently manual and fragile (State Explosion).
|
||
- **Why it matters**: This is the #1 requirement for complex retail configurators (e.g., choosing 1 wheel out of 20 options).
|
||
- **Recommendation**: Build a "Selection Group" node. Any mesh added to this group follows a "Radio Button" rule automagically.
|
||
- **Scope estimate**: 1–1.5 weeks.
|
||
- **Risk**: Low product risk; high engineering leverage.
|
||
|
||
### 2. Material Variant Block (Atomic UI)
|
||
- **Problem**: Creating a color switcher requires building individual buttons and linking manual visibility logic.
|
||
- **Why it matters**: It’s the most common task but also the most repetitive.
|
||
- **Recommendation**: A dedicated UI component that automatically generates buttons for every Variant defined on a Material.
|
||
- **Scope estimate**: 2 weeks.
|
||
- **Risk**: Requires a tight bridge between the Material Schema and the UI Engine.
|
||
|
||
## 1 Deeper Architecture Concern
|
||
- **Problem**: Absence of Native 3D Raycasting (Interaction Engine).
|
||
- **Why it matters**: Without the ability to click 3D objects directly, Thob is a "UI Overlay" tool rather than a truly immersive 3D experience. Interaction remains shallow and limited to 2D buttons.
|
||
- **Why it is deeper than a quick fix**: This requires integrating a robust Pointer/Event system into the core Three.js render loop and exposing it through the Editor's Node system.
|
||
- **What kind of spike or investigation is needed**: A technical spike on "Pointer Event Propogation" in the Thob Fiber layer to see how to expose onClick and onPointerOver triggers to the user.
|
||
|
||
## Final Recommendation
|
||
- If only 1 visual/product-facing thing should be built first, it is the **Selection Manager Logic Primitive**. Direct interaction is the ultimate goal, but a "Selection Manager" would immediately unlock the ability to build massive, professional configurators that are currently too "Fragile" to maintain.
|