diff --git a/Week-2/Task-3/ProductLens.md b/Week-2/Task-3/ProductLens.md index ba487ce..4ec5a91 100644 --- a/Week-2/Task-3/ProductLens.md +++ b/Week-2/Task-3/ProductLens.md @@ -1,5 +1,12 @@ ## 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? + - Step-by-step product storytelling where the camera and object states change per stage. + - Guided demos for feature highlights, onboarding walkthroughs, and education content. + - Presentation flows where some objects appear later and camera framing adapts per step. - Does Thob feel strong enough for this use case? -- What would improve the experience? \ No newline at end of file + - Partial. We can approach the same result by toggling Make Default on Perspective Camera and toggling object components, but button-driven prop updates are still hard to wire clearly. +- What would improve the experience? + - Improve the button UX. + - Make it easier and more intuitive for buttons to connect to and change component prop values. + - Add a clearer flow for mapping one button to multiple prop changes across camera and objects. \ No newline at end of file diff --git a/Week-2/Task-3/TaskNotes.md b/Week-2/Task-3/TaskNotes.md index e8be752..8015a4a 100644 --- a/Week-2/Task-3/TaskNotes.md +++ b/Week-2/Task-3/TaskNotes.md @@ -1,60 +1,90 @@ -# Task: [Feature Name] +# Task: Step Guided Scene Flow (Camera + Object State Changes) ## Objective -What is the feature trying to do? +Create a 3-step guided flow where each step changes camera position/look target and object states (visibility, position, rotation). ## Vanilla three.js --Possible: Yes / Partial / No --Notes: +- Possible: Yes +- Notes: + - Defines a step configuration array with camera and object state for each step. + - Buttons and keyboard shortcuts switch between steps. + - Animates transitions with interpolation for camera position, look target, object transforms, and visibility changes. -Key concepts: --Complexity: Easy / Medium / Hard + - Step/state data model + - Camera target and lookAt transitions + - Object visibility toggling + - Smooth lerp-based animation +-Complexity: Medium ## R3F --Possible: Yes / Partial / No +-Possible: Yes -Notes: + - Uses React state for active step and a shared STEPS config. + - Uses refs for objects and useFrame for smooth interpolation each frame. + - UI stays declarative while scene updates are handled in a guided controller pattern. -What R3F abstracted: --Complexity: Easy / Medium / Hard + - Render loop integration through hooks + - Scene update flow tied to React state + - Cleaner composition for scene and controls +-Complexity: Medium ## Thob Page Builder --Possible: Yes / Partial / No +-Possible: Partial -Notes: --Builder steps: --Complexity: Easy / Medium / Hard + - We can create the same result by toggling multiple combinations of the Make Default button of the Perspective Camera component and by toggling the visibilty object component. + - Same as before, the button UX needs improvement. + - The button should connect to and change component prop values in an easier and more intuitive way. + - I was not able to clearly figure out how to make the button functional end-to-end. + +- Builder steps: + - Add Perspective Camera component and toggle Make Default. + - Add object components and configure visibility states. + - Add step buttons and try to bind button actions to camera and object prop changes. +- Complexity: Hard ## Comparison Summary --Possible in all 3? Yes / Partial / No --Main differences: --Where Thob is better: --Where Thob is weaker: --What feels awkward or unclear: +- Possible in all 3? Partial +- Main differences: + - Vanilla and R3F both support full step transitions with explicit logic. + - Thob can represent the setup, but interaction wiring for step-driven prop updates is still difficult. +- Where Thob is better: + - Fast visual setup of scene components without writing all code. +- Where Thob is weaker: + - Button-to-prop binding discoverability and ease of use. +- What feels awkward or unclear: + - How to make one button reliably update multiple target props (camera + object states) per step. ## Limitation Type (if any) --[ ] Editor UX limitation --[ ] Runtime limitation --[ ] Schema / data model limitation --[ ] Component limitation --[ ] Event system limitation --[ ] Asset pipeline limitation --[ ] Unknown / needs investigation +- [x] Editor UX limitation +- [ ] Runtime limitation +- [ ] Schema / data model limitation +- [ ] Component limitation +- [x] Event system limitation +- [ ] Asset pipeline limitation +- [ ] Unknown / needs investigation ## Workaround --Is there a workaround? --If yes, what is it? +- Is there a workaround? + - Partial workaround. +- If yes, what is it? + - Use Make Default and object toggles for basic/static setups. + - For complete multi-step transitions, implement custom interaction logic outside the current builder button flow. ## Suggested Improvement -What should improve in Thob? --Is it: - -editor - -runtime - -component - -UX - -schema/data + - Improve Make Default button UX. + - Make button binding to component props simpler and more intuitive. + - Provide a clear mapping UI for action -> target component -> prop -> value. +- Is it: + - editor + - UX + - component ## Difficulty Estimate --Easy / Medium / Hard +- Medium ## Business Value --Low / Medium / High +- High ## Recommendation -Should Thob support this better? Why? \ No newline at end of file +Yes, Thob should support this better because guided camera/object step flows are common in demos, onboarding scenes, and product explainers. Better interaction UX would make this practical for non-technical users. \ No newline at end of file diff --git a/Week-2/Task-3/builder/BuilderNotes.md b/Week-2/Task-3/builder/BuilderNotes.md index e69de29..633757b 100644 --- a/Week-2/Task-3/builder/BuilderNotes.md +++ b/Week-2/Task-3/builder/BuilderNotes.md @@ -0,0 +1,77 @@ +# Builder Notes (Thob) — Task 3: Step-Guided Camera and Object State Flow + +## Thob Observations from Task Notes + +- **Possible:** Partial +- **Implementation used:** Perspective Camera with Make Default toggle, object visibility toggles, and attempted button bindings for step transitions. +- **What worked as expected:** + - Camera can be set as default quickly. + - Object visibility/state can be adjusted manually. + - Basic static scene states can be assembled in the editor. +- **Main limitation observed:** + - One button driving multiple prop updates (camera + objects) is difficult to configure reliably. + - Button-to-prop mapping is not intuitive for multi-step behavior. + - Could not complete a fully reliable end-to-end guided step interaction purely in current builder flow. +- **Builder flow used:** + 1. Add Perspective Camera and toggle Make Default. + 2. Add scene objects and configure visibility/transform states. + 3. Create step buttons. + 4. Attempt to bind each button to camera and object prop changes. + 5. Validate step transitions and check repeatability. +- **Complexity:** Hard +- **Main limitation signals:** Editor UX + Event system + Runtime stability concerns. +- **Workaround status:** Partial workaround only (manual/static states are possible; robust step orchestration via button bindings remains difficult). + +## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning + +### warn: `Found both blacklist and siteRules — using siteRules` +- **Type:** Configuration precedence warning. +- **Probable meaning:** Two policy/rule sources are present and runtime is choosing `siteRules`. +- **Impact:** Usually non-blocking, but indicates overlapping config paths. + +### warn: `undefined is changing from uncontrolled to controlled` and `RadioGroup is changing from uncontrolled to controlled` +- **Type:** React state-management warning. +- **Probable meaning:** Controls mount with unstable/default values, then switch to controlled values. +- **Impact:** Can cause inspector/control jitter and unreliable interaction setup. + +### warn: `Permissions-Policy header: Unrecognized feature: 'browsing-topics'` +- **Type:** Browser/header compatibility warning. +- **Probable meaning:** Response header contains a policy directive unsupported by the current browser. +- **Impact:** Low direct impact on scene logic; mostly environmental noise. + +### warn: `Unchecked runtime.lastError: The message port closed before a response was received` +- **Type:** Browser runtime/extension messaging warning. +- **Probable meaning:** A message channel closed before callback completion. +- **Impact:** Typically low for core feature behavior; adds noise during debugging. + +### warn: `GetBindingData method already registered` (repeated) +- **Type:** Duplicate registration warning. +- **Probable meaning:** Binding handlers are re-registered on rerenders/remounts/reconnects without cleanup. +- **Impact:** High for this task because step-driven interactions depend on stable bindings; duplicates can trigger repeated or inconsistent updates. + +### warn: `update-static-component-prop method already registered` +- **Type:** Duplicate update pipeline warning. +- **Probable meaning:** Static prop update method is attached multiple times. +- **Impact:** Can cause repeated writes and make multi-prop step transitions unreliable. + +### warn: `resetPOI method already registered` +- **Type:** Duplicate command registration warning. +- **Probable meaning:** Camera/POI reset command handler is mounted repeatedly. +- **Impact:** Camera state may jump/drift, reducing confidence in guided camera steps. + +### error: `Failed to load resource: the server responded with a status of 404 ()` +- **Type:** Network/resource error. +- **Probable meaning:** A required project/resource endpoint is missing or stale. +- **Impact:** Missing resources can break expected editor behavior and complicate reproduction. + +### error: `THREE.WebGLRenderer: Context Lost.` +- **Type:** Graphics runtime error. +- **Probable meaning:** WebGL context dropped due to resource pressure, remount loops, or browser/GPU reset. +- **Impact:** Preview instability/blackouts can invalidate interactive step-flow testing. + +## Overall Read + +- Task 3 behavior is partially achievable in thob: static setup and manual state toggles work, but robust multi-step interaction wiring is still difficult. +- The repeated registration warnings (`GetBindingData`, `update-static-component-prop`, `resetPOI`) strongly align with the core issue: unstable button-driven multi-prop updates. +- Controlled/uncontrolled warnings indicate editor form-state instability, which likely contributes to confusion during binding setup. +- Runtime instability signals (`404`, `Context Lost`) reduce trust during validation and should be addressed alongside interaction UX improvements.