Feature Owner: Joshua Uriel Tribiana
Module: Design ( Dual Editor )
Priority: P2
Status: Implemented in Current Codebase
Date: 07-01-2026
EXECUTIVE SUMMARY
What is this feature?
Per Node Fullscreen allows creators to expand an individual node in the visual canvas into a focused, full-screen editing experience. This helps reduce visual clutter and improve editing comfort for content-heavy nodes.
Why does it matter?
In the visual canvas, editing a node while surrounded by other nodes and edges can feel cramped and distracting. Fullscreen mode gives creators a cleaner, more focused authoring surface for a single node.
What’s in scope today?
A fullscreen action from supported node headers
A modal overlay that displays the selected node in a focused layout
A secondary expanded mode for a more immersive view
Close and escape handling for the modal experience
1. USER PAIN POINT & SOLUTION
Current State (Without Feature)
Creators working in a dense canvas have to edit content within a constrained node card, which can make long-form text, media, or structured question content harder to manage.
Pain Point
Emotional: Friction and visual overload while authoring content inside a busy canvas
Functional: Limited real estate for editing and reviewing node content
Business Impact: Slower content creation and a less polished authoring experience
Future State (With Feature)
Creators can open a specific node in fullscreen and focus on editing that content without losing the rest of the canvas context.
Product Angle
“Create and review content with less distraction by focusing on one node at a time.”
2. CODEBASE ASSESSMENT
Current Implementation Status
The feature is implemented and available in the visual canvas explorer page.
Primary Files
hooks/visual-canvas/useNodeFullscreen.ts
Stores the currently selected node and manages fullscreen open/close/toggle state
app/quest-editor/[questID]/(sections)/content/visual-canvas/exploration/page.tsx
Wires fullscreen state into the visual canvas page and renders the fullscreen modal
components/quest-editor/visual-canvas/NodeFullscreenModal.tsx
Modal shell with header, close button, toggle action, and backdrop behaviors
components/quest-editor/visual-canvas/NodeFullscreenContent.tsx
Resolves the selected node and renders its full node component in fullscreen mode
Current Behavior Summary
Supported nodes expose a fullscreen action from their header UI
Clicking that action opens a modal with the selected node rendered in a focused layout
The modal can expand into a larger full-screen state inside the overlay
The modal closes on Escape, the close button, or backdrop click in the default view
Strengths Already Present
Reuses existing node components rather than building a separate renderer layer
Keeps the experience lightweight and localized to the editor canvas
Works with most existing node types through a renderer mapping
Gaps / Hardening Opportunities
The fullscreen renderer uses a manually maintained mapping of node types
Only the visual canvas exploration view currently supports this experience
No persistence or cross-session state is implemented
3. 4D FRAMEWORK MAPPING
Diagnose
Editors need a calmer and more focused way to author content in the visual canvas.
Design
Use a modal-based overlay that temporarily replaces the surrounding canvas context with a single node view.
Develop
The canvas page tracks a selected node in local state and uses a shared modal/content pair to render the node.
Deliver
Creators can inspect and edit a node in isolation without losing the surrounding canvas interaction model.
4. USER FLOWS
Entry Point
A creator clicks the fullscreen action button on a supported node in the visual canvas.
Success Criteria
The selected node opens in a focused fullscreen view
The node content remains editable and consistent with the canvas renderer
The creator can return to the canvas view cleanly
Happy Path
Creator sees the fullscreen action on a supported node
Creator clicks it
A modal overlay opens with the selected node content
Creator reviews or edits the content in the focused view
Creator exits via the header control, close button, backdrop, or Escape key
Edge Cases
Unsupported node type → fallback message shown
Node missing from current node list → fallback message shown
Modal opened while another overlay is active → state remains isolated to the fullscreen modal
Decision Points
If the node exists and is supported → it renders in fullscreen mode
If not → a fallback message is displayed
5. INFORMATION ARCHITECTURE
Primary Information
Selected node ID
Selected node type
Optional node number for header display
The fullscreen toggle state
Actions
Primary CTA:
Fullscreen / Exit Fullscreen
Secondary CTA:
Close
State Changes
The modal opens with the target node selected
The modal can expand into an immersive mode inside the overlay
The modal closes and resets state on exit
6. WIREFRAMES
The experience is a lightweight modal overlay layered on top of the visual canvas.
Key Screen:
Fullscreen modal with node title and action controls
Annotations:
The canvas remains visually present behind the overlay
The focused node occupies the main content area
7. WIREFLOWS
+----------------------------+| Canvas Node UI |+----------------------------+ | v+----------------------------+| openFullscreen |+----------------------------+ | v+----------------------------+| useNodeFullscreen Hook |+----------------------------+ | v+----------------------------+| NodeFullscreenModal |+----------------------------+ | v+----------------------------+| NodeFullscreenContent |+----------------------------+ | v+----------------------------+| Node Renderer || (Selected Node Type) |+----------------------------+ | v+----------------------------+| Fullscreen UI |+----------------------------+
8. PROTOTYPE
Figma Prototype Link: Not available
How to test:
Open the visual canvas editor
Click the fullscreen button on a supported node
Verify the modal opens and the node renders in the focused layout
Toggle the expanded mode and close the overlay
9. DATA MODEL
No backend data changes are required for this feature.
Client State Managed Locally
nodeIdnodeTypenodeNumberisFullscreen
This state is held entirely in the fullscreen hook and consumed by the canvas page and modal components.
10. API CONTRACT
No API endpoints are introduced for this feature.
The feature is entirely client-side and relies on the existing node data already available in the canvas page state.
11. DATA REQUIREMENTS
Frontend Needs
The current set of nodes from the canvas state
The selected node’s type and content payload
The ability to render the correct node component for that type
Backend Needs
None beyond the existing canvas data already flowing through the page
Who can access this feature?
Creator: ✓
Learner: ✗
Reviewer: ✗
This is an editor-only experience. It is available in the visual canvas authoring UI and does not introduce any new permission boundary.
13. ERROR HANDLING
Common Errors
Missing node in current canvas state
Unsupported node type
Modal state mismatch when closing or reopening
Handling Guidance
Show a friendly fallback message instead of crashing the canvas
Keep the modal close behavior predictable through the shared state hook
14. TESTING CHECKLIST
Happy Path
Fullscreen opens for supported nodes
The node renders correctly in the modal
The expanded mode works
Close and escape behavior works as expected
Edge Cases
Unsupported node type displays fallback state
Missing node displays fallback state
Reopening the modal after closing behaves correctly
15. OPEN QUESTIONS
For Product
Should fullscreen be available for all node types or only a subset?
Should the feature be exposed in other canvas contexts beyond exploration mode?
For Engineering
Should the node renderer mapping be moved to a shared registry to reduce future maintenance?
Should fullscreen state be made persistent for accessibility or multi-step editing workflows?
16. OUT OF SCOPE
Not currently implemented:
Canvas-wide fullscreen mode
Backend persistence for fullscreen state
Fullscreen for learner-facing or reviewer-facing experiences
17. SUCCESS METRICS
How will we know this feature is working well?
Creators can focus on one node without distraction
Editing speed and clarity improve for content-heavy nodes
Fewer support requests are needed for node-level authoring issues
18. DEPENDENCIES
This feature depends on:
Existing node components in the visual canvas
React Flow state and node data
The canvas editor page integration
This feature supports:
Better authoring experience for complex nodes
More focused content editing workflows
19. TIMELINE & OWNERSHIP
Implementation Ownership
Owner: Joshua Uriel Tribiana
QA: Joylynne Esportuno ( teruterubozuuu )
Estimated Completion
The feature is already implemented in the current codebase.