anshk/builder-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: task3 notes

Browse Source
This commit is contained in:
anshk 2026-04-07 11:13:12 +05:30
parent c49060e09a
commit 4a52963fc5
3 changed files with 149 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
Week-2/Task-3/ProductLens.md
View File

@ -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?
- 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.

64
Week-2/Task-3/TaskNotes.md
View File

@ -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
- 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:
- 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:
-Complexity: Easy / Medium / Hard
- 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
- 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
- [x] Editor UX limitation
- [ ] Runtime limitation
- [ ] Schema / data model limitation
- [ ] Component limitation
-[ ] Event system limitation
- [x] Event system limitation
- [ ] Asset pipeline limitation
- [ ] Unknown / needs investigation
## Workaround
- 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?
- 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
-runtime
-component
- UX
-schema/data
- component
## Difficulty Estimate
-Easy / Medium / Hard
- Medium
## Business Value
-Low / Medium / High
- High
## Recommendation
Should Thob support this better? Why?
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.

77
Week-2/Task-3/builder/BuilderNotes.md
View File

@ -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<id> 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.