Fullscreen Plugin Behavior – UX Considerations and Feature Request

[vc6XFSA]

Hello! We've already tested the new window fullscreen-mode feature and it's a game changer, it's something we've been waiting for. 🙂 

During our testing, however, we ran into an important question, and we'd really appreciate your thoughts on it.

When we launch our plugin and switch to full-screen mode to begin editing the topography and adding elements, there’s a risk that users might click the “Collapse Plugin” button and lose it, or even click the “Close Plugin” button and lose all the information they were working with. (see pictures below)

 

I've also noticed that if we start editing topography in a Forma, we lose the collapsed tab and can't find it again.

So our question is: would it be possible to expand the full-screen panel with a slightly different logic—not just a “Close” button, but rather a “Finish Editing” action? 

Why is this important to us?

Well, this idea didn’t come from nowhere. You already have similar UX patterns in Forma. For example, when editing a terrain layer, the user enters a kind of dedicated editing mode, and a “Back” button appears on the left side. Like this (see pictures below)

 

That’s exactly the kind of header we would love to have for our plugin—because it clearly gives the user the impression they are entering a controlled editing environment for Forma geometry.

And in such a mode, the user doesn’t just close the window; they either go back or finish editing. This creates a clear separation of states. That’s exactly what we’re aiming for: to avoid ambiguity between geometries.

When the user is editing topography in our tool, we want to ensure they’re not interacting with other Forma geometry during that time.

Essentially we'd just like something that creates an open and close transaction effect that doesn't allow the user to leave the plugin without deciding to “undo” or “accept” the changes.

Or, at least be able to at least subscribe to notifications when the plugin has been closed or minimized to notify the user that they are leaving edit mode. (But the first option is better, of course)

I would be very happy to hear your opinion on this.  🙂

[budibanyu778]

The new fullscreen-mode feature is definitely a game changer, and it's something I’ve been excited about too. I can see how users might accidentally click the ‘Collapse Plugin’ or ‘Close Plugin’ button while in fullscreen, which could cause them to lose progress. Maybe adding a warning or confirmation before closing could help prevent that. By the way, this feature could work wonders for creating immersive mega game where user progress matters.

[syed_ammar_abbas_naqvi]

Hey,

Thank you for sharing your experience with the fullscreen-mode feature! It’s great to hear it has improved the workflow. 😊

Regarding your concerns about users accidentally collapsing or closing the plugin while editing topography, I completely understand the need for a more controlled and user-friendly approach. To address this, I recommend using the SDK functions designed to manage embedded view states.

Here are two functions from the Forma Embedded View SDK that might be helpful:

onEmbeddedViewClosing:

onEmbeddedViewClosing(
handler: (payload: { timeoutDuration: number }) => Promise<void>,
): CreateSubscriptionResult

This function allows you to register a handler that will be called before the embedded view is removed from the DOM. The handler must resolve before the timeout duration.

Example:

const { unsubscribe } = Forma.onEmbeddedViewClosing(async ({ timeoutDuration }) => {
await new Promise((resolve) => setTimeout(() => {
console.log(`The embedded view will be removed from DOM within ${timeoutDuration}ms`)
resolve(null)
}, 5000))
})

// Later, when you want to stop listening for changes:
unsubscribe()

onEmbeddedViewStateChange:

onEmbeddedViewStateChange(
handler: (
payload: {
embeddedViewId: string;
state: "disconnected" | "connected" | "closed" | "opened";
},
) => void,
): Promise<CreateSubscriptionResult>

This function listens to the state changes of an embedded view belonging to the current extension.

Example:

Forma.onEmbeddedViewStateChange(({ embeddedViewId, state }) => {
console.log(`Embedded view ${embeddedViewId} has changed state to ${state}`)
})

For more detailed documentation, please refer to the following link: Forma Embedded View SDK Documentation.

While there may not be a perfect solution to prevent accidental closures entirely, I highly recommend implementing auto-saving functionality to ensure users have a consistent experience with Forma.

I hope this helps! I’m looking forward to hearing your thoughts. 😊

Best,
Ammar