builder-research/Week-4/Task-2.md

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.