92 lines
4.7 KiB
Markdown
92 lines
4.7 KiB
Markdown
# Ansh Week 4 — Scene Priority Recommendations
|
|
|
|
## 3 Quick Wins
|
|
|
|
### 1) Binding Lifecycle Cleanup For Interaction Handlers
|
|
- Problem
|
|
- Across Week 2 and Week 3 Tasks 2 and 3, repeated warnings like GetBindingData already registered, update-static-component-prop already registered, and resetPOI already registered strongly indicate duplicate handler registration.
|
|
- Why it matters
|
|
- One trigger to many updates becomes inconsistent, causing missed or duplicated state changes in camera, visibility, and transforms.
|
|
- Recommendation
|
|
- Enforce single registration per handler key with teardown on unmount/rerender.
|
|
- Add a lightweight runtime guard to log and skip duplicate registration attempts.
|
|
- Expected user impact
|
|
- More reliable one-click scene changes and fewer random interaction failures.
|
|
- Confidence level
|
|
- High
|
|
|
|
### 2) Property Panel State Stability (Controlled/Uncontrolled)
|
|
- Problem
|
|
- Repeated uncontrolled to controlled warnings in Week 2 and Week 3 suggest unstable form state in critical interaction setup flows.
|
|
- Why it matters
|
|
- If controls are unstable, users lose trust while wiring multi-target actions.
|
|
- Recommendation
|
|
- Standardize control initialization and enforce explicit default values for all bindable properties.
|
|
- Add immediate validation feedback when a binding value is invalid or incomplete.
|
|
- Expected user impact
|
|
- Lower setup confusion, fewer broken bindings, and faster authoring for non-technical users.
|
|
- Confidence level
|
|
- High
|
|
|
|
### 3) Transition Controls For State And Step Switching
|
|
- Problem
|
|
- Week 3 proved state and step switching can be reliable through prebuilt visibility states, but transitions are instant and feel abrupt.
|
|
- Why it matters
|
|
- Instant jumps limit storytelling quality for demos, onboarding, and product explainers.
|
|
- Recommendation
|
|
- Add per-action transition duration and easing for camera and transform changes.
|
|
- Keep visibility switches deterministic while interpolating transform and camera values.
|
|
- Expected user impact
|
|
- Immediate quality lift in guided narratives without changing existing state authoring patterns.
|
|
- Confidence level
|
|
- Medium-High
|
|
|
|
## 2 Medium Features
|
|
|
|
### 1) Atomic Multi-Target Action Bundles
|
|
- Problem
|
|
- Tasks 2 and 3 repeatedly show that mapping one button to many coordinated updates is hard and often non-atomic.
|
|
- Why it matters
|
|
- Real customer flows need camera plus visibility plus transform updates to happen together as one scene event.
|
|
- Recommendation
|
|
- Introduce an action bundle model: one trigger, many target updates, single transaction apply.
|
|
- Include per-target success/failure reporting so users can debug quickly.
|
|
- Scope estimate
|
|
- Medium
|
|
- Risk
|
|
- Medium risk of edge cases around partial failures and rollback behavior.
|
|
|
|
### 2) Perspective Camera Rotation Reliability Fix
|
|
- Problem
|
|
- Week 2 and Week 3 Task 4 identified a critical issue: rotating the Perspective Camera can make objects disappear.
|
|
- Why it matters
|
|
- This blocks confidence in guided camera storytelling, even when hierarchy and parent-child motion are otherwise strong.
|
|
- Recommendation
|
|
- Prioritize camera rotation bug isolation and fix, then add regression tests for axis rotation and repeated step switching.
|
|
- Scope estimate
|
|
- Medium
|
|
- Risk
|
|
- Medium because root cause may involve rendering lifecycle, transform update order, or camera state sync.
|
|
|
|
## 1 Deeper Architecture Concern
|
|
|
|
### Missing First-Class Scene Orchestration Model
|
|
- Problem
|
|
- Current reliable flows often depend on workarounds (prebuilt states plus visibility toggles) instead of a native orchestration system.
|
|
- Why it matters
|
|
- The platform can set up scenes quickly, but advanced storytelling still struggles with reusable, debuggable, scalable interaction logic.
|
|
- Why it is deeper than a quick fix
|
|
- This is not only a UI issue. It spans runtime state model, event execution semantics, transaction guarantees, and authoring ergonomics.
|
|
- What kind of spike or investigation is needed
|
|
- Build a small orchestration spike with:
|
|
- Step bundle schema (camera, visibility, transforms, transition config)
|
|
- Atomic apply semantics with rollback strategy
|
|
- Debug panel showing exactly which target updates succeeded/failed
|
|
- Performance test on repeated rapid switching
|
|
|
|
## Final Recommendation
|
|
- If only one scene/architecture-facing thing should be built first, build atomic multi-target orchestration (one trigger to one transactional state change across camera, visibility, and transforms).
|
|
- Why first:
|
|
- It addresses the most repeated pain across Task 2 and Task 3.
|
|
- It compounds value with existing strengths (fast visual setup and reliable hierarchy).
|
|
- It creates the foundation needed for smoother transitions and guided-flow primitives afterward. |