figmaMar 8, 2021

Behind the feature: comments, contextually | Figma Blog (opens in new tab)

Figma’s Community comments feature was designed to turn a mostly one-way publishing platform into a space for direct creator–audience communication. The team combined general feed comments with spatial, in-editor-style comments, while carefully adapting interactions to preserve the file-viewing experience. Technical constraints mattered, but the hardest work involved resolving subtle interaction and edge-case decisions. ## Why Community Comments Were Needed - Community users could browse, duplicate, and install resources, but had no straightforward way to contact creators. - Figma wanted the Community to support deeper engagement through questions, feedback, and discussion. - The feature introduced two comment types: - **General comments**, displayed in a feed beneath the file. - **Contextual comments**, attached to specific locations within the design. ## Adapting the Existing Commenting System - The team initially expected to reuse Figma’s existing in-editor comments with minor changes. - They replaced the previous iframe-based file preview to enable communication of viewport information. - They also had to consider performance when files contained many comments. - The larger challenge was interaction design: - Community files traditionally supported one-way creator-to-audience communication. - Comments created a two-way channel between audiences and creators. - Contextual comments required spatial navigation rather than a simple linear feed. - Users needed to inspect comment locations while still being able to pan across the canvas. - The team aimed to encourage commenting without diminishing the existing view-only experience. ## Exploring the User Experience - Engineering, design, and product worked in a close feedback loop. - Designers used animated prototypes and GIFs rather than only static wireframes because commenting depended heavily on interaction behavior. - Explorations considered: - Sidebar comment feeds. - Different ways to embed comments around the viewer. - Mini-viewers and canvas interactions for locating comments. - Prototypes helped the team evaluate ideas against technical feasibility, UI edge cases, and the launch schedule. ## Launch Priorities and Design Decisions The team prioritized three goals: - Make entering the commenting experience quick and intuitive. - Give contextual comments enough surrounding space to understand their position in the file. - Deliver a technically feasible, appropriately simple solution within the project timeline. As a result, contextual comments were limited to fullscreen view, where users had enough space to understand the design context. Clicking the minimized canvas expanded it into fullscreen mode, while clicking and panning were disabled in the smaller preview to avoid compromising the primary browsing experience. The feature ultimately required more than porting existing code: it demanded a new interaction model for combining comments, spatial context, and file browsing. Figma’s approach shows the importance of iterative cross-functional prototyping when adapting a familiar feature to a fundamentally different product environment.

iframefigmainteraction-designuser-interface+2

figmaAug 21, 2019

How to build a plugin system on the web and also sleep well at night | Figma Blog (opens in new tab)

Figma’s plugin system had to let untrusted third-party JavaScript interact with a powerful, browser-based design editor without compromising security, performance, or stability. The team evaluated several isolation strategies, ultimately favoring JavaScript Realms because they supported synchronous APIs and avoided the performance costs of a full interpreter. Figma later replaced that implementation with a JavaScript VM compiled to WebAssembly after a vulnerability was found in the third-party Realms shim. ## Why Plugin Isolation Was Difficult - Plugins needed access to Figma’s document model while remaining isolated from: - User data and credentials - Figma’s internal application state - Other plugins - The host page and browser APIs - Simply calling `eval(PLUGIN_CODE)` would execute arbitrary code in Figma’s main environment. - Figma’s architecture added constraints: - The editor relied heavily on WebGL and WebAssembly. - Parts of the interface used TypeScript and React. - Multiple users could edit files simultaneously. - Plugins also needed to remain performant and avoid breaking as Figma evolved. ## Attempt 1: The `<iframe>` Sandbox - The team first considered the browser’s standard isolation mechanism: sandboxed `<iframe>` elements. - An iframe could separate plugin code from Figma’s main page and restrict access using browser security policies. - Communication between the plugin and Figma would use mechanisms such as `postMessage`. - However, this created an important limitation: iframe communication is asynchronous. - Figma’s plugin API needed synchronous access to document operations, making an iframe-based architecture awkward and potentially expensive. - The iframe approach also introduced additional browser contexts and messaging overhead. ## Attempt 2: A JavaScript Interpreter Compiled to WebAssembly - The second approach was to run plugin code inside a JavaScript interpreter rather than the browser’s native JavaScript engine. - The interpreter could expose only explicitly approved Figma APIs, providing a strong security boundary. - Compiling the interpreter to WebAssembly offered a way to integrate it efficiently with Figma’s existing WebAssembly-heavy architecture. - The drawbacks included: - Interpreted JavaScript would be slower than native execution. - The interpreter would require ongoing maintenance and compatibility work. - Supporting the full JavaScript language and modern features would be difficult. - Although attractive from a security perspective, this approach appeared to impose too much performance and implementation cost at the time. ## Attempt 3: JavaScript Realms - Realms provided a separate JavaScript global environment within the same browser process. - Figma could execute plugin code in a distinct Realm while exposing a carefully controlled plugin API. - Unlike iframes, Realms allowed plugin calls to remain synchronous. - Unlike a custom interpreter, plugin code could use the browser’s native JavaScript engine. - The implementation required carefully controlling built-in objects and preventing plugins from escaping their isolated environment. - This approach offered the best balance of: - Native JavaScript performance - Synchronous API access - Isolation from Figma’s application state - A relatively small integration surface ## Later Security Change - After publication, Figma discovered a security vulnerability in the third-party Realms shim used by its original implementation. - The vulnerability was fixed before public disclosure, and Figma reported no evidence that it had been exploited. - Figma subsequently changed its sandbox to use a JavaScript VM written in C and compiled to WebAssembly. Figma’s experience shows that plugin systems require more than simply restricting access to browser APIs. The isolation boundary must also preserve performance and API usability, while being robust enough to withstand vulnerabilities in the underlying sandbox technology.

iframereacttypescriptjavascript+3

figmaSep 27, 2017

Introducing Figma’s Live Embed Kit | Figma Blog (opens in new tab)

Figma’s Live Embed Kit lets anyone place continuously updated Figma designs and prototypes on websites or inside third-party tools. Embeds use a simple iframe and remain synchronized with the original file, eliminating repeated exports and uploads. Figma presents the kit as a way to improve team communication and signals future platform tools, including a planned API. ## Simple Embedding for Websites and Tools - Users can select **Share → Public embed** in a Figma file and copy the generated iframe code. - Developers can integrate Live Embeds into their own products using Figma’s embed documentation. - Third-party platforms such as Trello, JIRA, and Dropbox Paper can enable Figma embeds for their users. ## Always-Up-to-Date Designs - Because Figma runs on the web, embedded files stay synchronized with the source document. - Small changes—such as adjusting padding or replacing an icon—appear automatically in every embed. - Teams no longer need to re-export designs or upload updated files manually. ## Collaboration Use Cases - Internal wikis can display live designs alongside project and feature documentation. - Team messaging apps can let users share the latest design versions in conversations. - Blogs and project pages can show designs that remain current for readers. ## Broader Platform Direction - Figma aims to reduce the confusion caused by outdated files scattered across email, Slack, and file-sharing services. - The Live Embed Kit is described as an early step in expanding Figma’s platform. - Figma planned to release an API for retrieving additional information from files and incorporating it into new workflows. The kit is recommended for teams and developers that want design updates to flow automatically into the places where people communicate, document, and build products.

iframefigmareal-time-collaborationapi+3