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

docs: update week2 task3 docs

Browse Source
This commit is contained in:
anshk 2026-04-21 17:17:29 +05:30
parent e47831aaec
commit ee8e2c3342
3 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -5,7 +5,8 @@
- Guided demos for feature highlights, onboarding walkthroughs, and education content. - Guided demos for feature highlights, onboarding walkthroughs, and education content.
- Presentation flows where some objects appear later and camera framing adapts per step. - Presentation flows where some objects appear later and camera framing adapts per step.
- Does Thob feel strong enough for this use case? - 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. - Partial. We can approach the same result by toggling Make Default on Perspective Camera and toggling object components, but my first instinct was button-driven step switching and that was hard to make reliable end-to-end.
- A practical fallback is radio-button switching across preconfigured step states.
- What would improve the experience? - What would improve the experience?
- Improve the button UX. - Improve the button UX.
- Make it easier and more intuitive for buttons to connect to and change component prop values. - Make it easier and more intuitive for buttons to connect to and change component prop values.

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

@ -32,9 +32,11 @@ Create a 3-step guided flow where each step changes camera position/look target
-Possible: Partial -Possible: Partial
-Notes: -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. - 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.
- My first intuition was to drive the guided steps with buttons, but I was not able to make that flow work reliably end-to-end.
- Same as before, the button UX needs improvement. - 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. - 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. - I was not able to clearly figure out how to make the button functional end-to-end.
- A practical fallback is using radio buttons to switch between preconfigured step states.
- Builder steps: - Builder steps:
- Add Perspective Camera component and toggle Make Default. - Add Perspective Camera component and toggle Make Default.
@ -68,6 +70,7 @@ Create a 3-step guided flow where each step changes camera position/look target
- Partial workaround. - Partial workaround.
- If yes, what is it? - If yes, what is it?
- Use Make Default and object toggles for basic/static setups. - Use Make Default and object toggles for basic/static setups.
- Use radio buttons to switch between preconfigured step states (camera + object presets) as a preset-like fallback.
- For complete multi-step transitions, implement custom interaction logic outside the current builder button flow. - For complete multi-step transitions, implement custom interaction logic outside the current builder button flow.
## Suggested Improvement ## Suggested Improvement

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

@ -3,7 +3,7 @@
## Thob Observations from Task Notes ## Thob Observations from Task Notes
- **Possible:** Partial - **Possible:** Partial
- **Implementation used:** Perspective Camera with Make Default toggle, object visibility toggles, and attempted button bindings for step transitions. - **Implementation used:** Perspective Camera with Make Default toggle, object visibility toggles; first intuition was button-driven step transitions, but that setup was not reliable end-to-end.
- **What worked as expected:** - **What worked as expected:**
- Camera can be set as default quickly. - Camera can be set as default quickly.
- Object visibility/state can be adjusted manually. - Object visibility/state can be adjusted manually.
@ -20,7 +20,7 @@
5. Validate step transitions and check repeatability. 5. Validate step transitions and check repeatability.
- **Complexity:** Hard - **Complexity:** Hard
- **Main limitation signals:** Editor UX + Event system + Runtime stability concerns. - **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). - **Workaround status:** Partial workaround only (manual/static states are possible, and radio buttons can switch preconfigured step-state presets; robust step orchestration via button bindings remains difficult).
## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning ## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning
@ -72,6 +72,7 @@
## Overall Read ## 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. - Task 3 behavior is partially achievable in thob: static setup and manual state toggles work, but robust multi-step interaction wiring is still difficult.
- A practical fallback is radio-button-driven switching between preconfigured step states.
- The repeated registration warnings (`GetBindingData`, `update-static-component-prop`, `resetPOI`) strongly align with the core issue: unstable button-driven multi-prop updates. - 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. - 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. - Runtime instability signals (`404`, `Context Lost`) reduce trust during validation and should be addressed alongside interaction UX improvements.