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

docs: week 3 task 1 docs

Browse Source
This commit is contained in:
anshk 2026-04-13 17:15:28 +05:30
parent 2724f4e475
commit 2a7f7561b6
2 changed files with 88 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Week-3/Task-1/ProductLens.md
View File

@ -1,5 +1,17 @@
## 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 inspection: users switch between front/side/top detail viewpoints.
- Guided tours: sequenced camera jumps between key points of interest.
- Storytelling/marketing: deliberate framing changes to control narrative focus.
- Does Thob feel strong enough for this use case?
- What would improve the experience?
- Partial.
- From my Task 1 test, there are two ways:
- Way 1: three separate meshes/scenes with one perspective camera setup each, then toggle visibility using radio buttons. This was stable.
- Way 2: one mesh + three perspective cameras, toggling `Make Default` using radio buttons. This was unreliable (sometimes appears, then disappears after repeated toggles; sometimes works only at certain positions).
- So today, Thob is okay for workaround-based flows, but direct camera preset switching reliability is not strong enough yet.
- What would improve the experience?
- Native camera preset system with explicit position + target/focus per preset.
- Clear interaction binding: control -> target camera/preset -> action.
- Deterministic behavior under fast repeated switching.
- Better visual/debug indication of which camera is active and why.

95
Week-3/Task-1/TaskNotes.md
View File

@ -1,60 +1,113 @@
# Task: [Feature Name]
# Task: Camera Preset Consistency Audit
## Objective
What is the feature trying to do?
Stress test camera preset switching with 3 presets and verify reliability under repeated and rapid switching, focus/target consistency, transition behavior, and final state correctness.
## Vanilla three.js
-Possible: Yes / Partial / No
-Possible: Yes
-Reliability verdict: Reliable
-Notes:
- Code uses one `PerspectiveCamera`, a fixed `target` vector, and three preset positions (`front`, `side`, `topAngled`).
- Repeated switching is reliable because each switch only updates `desiredPosition`; no competing camera instances.
- Rapid switching is predictable: latest click/key wins, and camera lerps toward that final preset.
- Focus is consistent because `camera.lookAt(target)` runs every frame.
- Transition is smooth (`lerp` with factor `0.08`).
- Final camera state matches the selected preset in practice (converges over frames; not mathematically exact in one frame due to lerp).
-Key concepts:
-Complexity: Easy / Medium / Hard
- Preset map
- Single camera state machine
- Frame-loop interpolation
- Deterministic target locking
-Complexity: Medium
## R3F
-Possible: Yes / Partial / No
-Possible: Yes
-Reliability verdict: Reliable
-Notes:
- Uses React state (`preset`) with a `CameraController` that updates camera in `useFrame`.
- Repeated and fast switching stay stable because only one active preset state is used at a time.
- Focus is predictable (`camera.lookAt(target)` each frame).
- Transitions are smooth and consistent (same lerp strategy as vanilla).
- Final state converges to whichever preset was selected last.
-What R3F abstracted:
-Complexity: Easy / Medium / Hard
- Input/state separation from camera movement logic
- Render-loop integration via `useFrame`
- Cleaner UI-to-camera flow with less manual wiring
-Complexity: Easy
## Thob Page Builder
-Possible: Yes / Partial / No
-Possible: Partial
-Reliability verdict: Partially Reliable
-Notes:
- I found two ways to approach this.
- Way 1 (reliable workaround): I built 3 individual meshes/scenes with one perspective camera per setup and fixed positions, then toggled mesh visibility with radio buttons. This worked consistently.
- Way 2 (direct preset intent, unreliable): I tried one mesh/geometry with 3 perspective cameras and toggled `Make Default` with radio buttons. This was unreliable.
- Observed behavior in Way 2:
- Sometimes works once, then does not appear after 1-2 toggles.
- Sometimes appears only at certain positions and fails at others.
- Final camera state is not always the expected selected preset.
- Conclusion: direct multi-camera preset switching feels fragile in current builder flow; multi-mesh visibility toggle is a workaround, not true camera-preset reliability.
-Builder steps:
-Complexity: Easy / Medium / Hard
1. Built three separate mesh setups with one camera and fixed positions.
2. Added radio buttons to toggle visibility and verified stable behavior.
3. Rebuilt as single mesh + three cameras.
4. Tried toggling camera `Make Default` via radio buttons.
5. Stress tested repeated and fast toggles, then observed instability.
-Complexity: Hard
## Comparison Summary
-Possible in all 3? Yes / Partial / No
-Possible in all 3? Partial
-Main differences:
- Vanilla/R3F keep one camera pipeline and update only target position.
- Thob direct multi-camera default switching can become inconsistent under rapid toggles.
- Thob workaround (visibility switching) can look stable but does not validate true camera preset authoring reliability.
-Where Thob is better:
- Fast visual assembly and no-code experimentation.
-Where Thob is weaker:
- Camera state authoring clarity.
- Deterministic behavior when switching default camera repeatedly.
-What feels awkward or unclear:
- How radio/button interactions should safely control camera default state and final active camera.
## Use Case Suitability
-Product inspection: Vanilla/R3F = good. Thob = partial (workaround possible, direct camera preset flow unreliable).
-Guided tours: Vanilla/R3F = good. Thob = partial to fragile if relying on rapid camera default switching.
-Storytelling: Vanilla/R3F = good. Thob = partial for simple flows, risky for frequent camera jumps.
## Limitation Type (if any)
-[ ] Editor UX limitation
-[ ] Runtime limitation
-[x] Editor UX limitation
-[x] Runtime limitation
-[ ] Schema / data model limitation
-[ ] Component limitation
-[ ] Event system limitation
-[x] Component limitation
-[x] Event system limitation
-[ ] Asset pipeline limitation
-[ ] Unknown / needs investigation
## Workaround
-Is there a workaround?
- Yes, partial workaround.
-If yes, what is it?
- Build separate meshes/scenes and toggle visibility with radio buttons while keeping camera setup simple per view.
- This gives stable visual switching but is not the same as robust camera preset switching on one shared scene/camera model.
## Suggested Improvement
-What should improve in Thob?
- Add first-class camera preset authoring (preset list with position + target/focus).
- Add one explicit "switch to preset" action for buttons/radios.
- Ensure deterministic final state when interactions fire quickly.
- Improve `Make Default` behavior and lifecycle when multiple cameras exist.
- Show active camera and target/focus clearly in editor and runtime inspector.
-Is it:
-editor
-runtime
-component
-UX
-schema/data
- editor
- runtime
- component
- UX
## Difficulty Estimate
-Easy / Medium / Hard
-Hard
## Business Value
-Low / Medium / High
-High
## Recommendation
Should Thob support this better? Why?
Yes, Thob should support this better. Camera preset reliability is critical for product inspection, guided tours, and storytelling, and current direct multi-camera switching behavior is not predictable enough for production confidence.