Per Node Fullscreen

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

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

  1. Creator sees the fullscreen action on a supported node

  2. Creator clicks it

  3. A modal overlay opens with the selected node content

  4. Creator reviews or edits the content in the focused view

  5. 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:

  1. Open the visual canvas editor

  2. Click the fullscreen button on a supported node

  3. Verify the modal opens and the node renders in the focused layout

  4. Toggle the expanded mode and close the overlay


9. DATA MODEL

No backend data changes are required for this feature.

Client State Managed Locally

  • nodeId

  • nodeType

  • nodeNumber

  • isFullscreen

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


12. SECURITY & AUTHORIZATION

Who can access this feature?

  • Creator:

  • Learner:

  • Reviewer:

Authorization Logic

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.


Was this article helpful?