diff --git a/Week-3/Task-2/ProductLens.md b/Week-3/Task-2/ProductLens.md index ba487ce..c05215e 100644 --- a/Week-3/Task-2/ProductLens.md +++ b/Week-3/Task-2/ProductLens.md @@ -1,5 +1,14 @@ ## Product Lens -- Is this pattern useful for real customers? Yes / Partial / No +- Is this pattern useful for real customers? Yes - What kind of customer use case does this support? + - Product configurators that show preset layouts (compact, expanded, exploded view). + - Guided feature walkthroughs where object arrangement changes by step. + - Visual storytelling pages that switch between predefined composition states. - Does Thob feel strong enough for this use case? -- What would improve the experience? \ No newline at end of file + - Yes for deterministic, discrete state switching. + - In my test, creating three separate meshes and toggling visibility using radio buttons was very reliable in any order and after repeated toggles. + - Partial for premium presentation quality, because switching is instant and lacks transition animation. +- What would improve the experience? + - Native animated transitions between authored states. + - Transition controls (duration/easing) directly on state-switch actions. + - Optional blend mode for transform and visibility changes instead of instant hard cuts. \ No newline at end of file diff --git a/Week-3/Task-2/TaskNotes.md b/Week-3/Task-2/TaskNotes.md index e8be752..666d26a 100644 --- a/Week-3/Task-2/TaskNotes.md +++ b/Week-3/Task-2/TaskNotes.md @@ -1,32 +1,72 @@ -# Task: [Feature Name] +# Task: Scene Preset / Transform State Switching Consistency Audit ## Objective -What is the feature trying to do? +Test reliability of scene state switching with 3 presets, including deterministic transforms, visibility correctness, isolation between states, drift checks, and default/reset behavior. ## Vanilla three.js --Possible: Yes / Partial / No +-Possible: Yes +-Reliability verdict: Reliable -Notes: + - Uses a single `states` object (`state1`, `state2`, `state3`) with explicit `position`, `rotation`, and `visible` values for each mesh (`center`, `left`, `right`). + - Switching in any order remains deterministic because each state write fully overwrites target transforms and visibility. + - Repeated and fast switching stays stable; latest state selection becomes the active target. + - No cross-state contamination observed in logic because each object gets fresh target values per `applyState` call. + - `state1` acts as reset/default and consistently restores baseline layout. + - Transitions are smooth due to per-frame lerp of position and rotation deltas. -Key concepts: --Complexity: Easy / Medium / Hard + - Central state map + - Visibility + transform synchronization + - Target-based interpolation + - Deterministic overwrite model +-Complexity: Medium ## R3F --Possible: Yes / Partial / No +-Possible: Yes +-Reliability verdict: Reliable -Notes: + - Uses `SCENE_STATES` config and React state (`stateKey`) to switch presets. + - `useEffect` applies state values to target vectors/eulers and visibility; `useFrame` handles smooth interpolation. + - State isolation is clear because every switch writes full values for every object. + - Different switching orders and rapid changes should remain deterministic from current code structure. + - `state1` functions as default/reset and is straightforward to trigger. + - Transition quality is smooth and predictable (same interpolation approach as vanilla). -What R3F abstracted: --Complexity: Easy / Medium / Hard + - Declarative state-driven updates + - Frame-loop orchestration through `useFrame` + - Better separation of UI intent and object motion +-Complexity: Medium ## Thob Page Builder --Possible: Yes / Partial / No +-Possible: Yes +-Reliability verdict: Reliable -Notes: + - I made three different meshes, each arranged exactly as needed for one state. + - Then I used radio buttons to toggle mesh visibility between those state setups. + - Switching worked in any order and stayed correct even after many repeated toggles. + - Visibility/state isolation was clean and no drift/mismatch appeared. + - Default/reset is effectively the default selected radio state. + - Main gap: state change is instant; no transition animation while switching. -Builder steps: --Complexity: Easy / Medium / Hard + 1. Create three separate mesh setups representing the three scene states. + 2. Position models in each mesh as desired for each state. + 3. Add radio buttons for state selection. + 4. Bind each radio option to visibility toggles. + 5. Stress test repeated toggling and random order switching. +-Complexity: Easy ## Comparison Summary --Possible in all 3? Yes / Partial / No +-Possible in all 3? Yes -Main differences: + - Vanilla and R3F implement true transform-state interpolation on shared objects. + - Thob implementation is reliable through visibility swapping of prebuilt state meshes. + - Thob currently changes state instantly, while vanilla/R3F can make transitions smoother. -Where Thob is better: + - Fast no-code setup for deterministic state switching. + - Very stable for discrete preset jumps. -Where Thob is weaker: + - No built-in smooth transform interpolation in this setup. -What feels awkward or unclear: + - How to add animation/transition between two authored states without manually rebuilding logic. ## Limitation Type (if any) -[ ] Editor UX limitation @@ -35,26 +75,29 @@ What is the feature trying to do? -[ ] Component limitation -[ ] Event system limitation -[ ] Asset pipeline limitation --[ ] Unknown / needs investigation +-[x] Unknown / needs investigation ## Workaround -Is there a workaround? + - Yes. -If yes, what is it? + - Author each scene state as a separate mesh group and toggle visibility with radio buttons for predictable switching. ## Suggested Improvement -What should improve in Thob? + - Add optional transition animation between preset states (position/rotation/visibility easing). + - Provide a native state preset system where authored states can blend over time. + - Add a simple transition duration/easing control per state switch action. -Is it: - -editor - -runtime - -component - -UX - -schema/data + - runtime + - component + - UX ## Difficulty Estimate --Easy / Medium / Hard +-Easy ## Business Value --Low / Medium / High +-High ## Recommendation -Should Thob support this better? Why? \ No newline at end of file +Yes, and this should be improved with transitions. Current state switching is reliable for deterministic preset jumps, but animation support would make it production-ready for smoother demos and storytelling. \ No newline at end of file