FrameQuery Figma plugin: Like CSS container queries in your Figma components and frames

I currently lead an enterprise digital Product Design team, and I'm also design co-lead (together with my dev co-lead) for our Design System. We already have multiple UI (code) components that use container queries. This is gonna be soooooooooo helpful on the design model side, because with this plugin, our designers don't have to remember when to manually swap layouts on our models.

First iteration took about 10-12 hours total, and about 100~ credits on my personal Pro account. Fixing the bugs took another 200 or so credits. Learned quite a bit of stuff along the way though. Adding support for components imported into libraries (without which the plugin is basically pointless) took another 300~ credits.

Still need to get it cleaned up, it's a mess, but at least the core bugs are fixed.

This is a working copy, and here's how to use it, if you're curious. :)

Load & use FrameQuery Figma Plugin

  1. In Figma desktop app ONLY, open a Figma file with components that you want frame queries on.
  2. Right-click on empty space in Figma canvas: Plugins > Development > Import Plugin from Manifest.
  3. In FrameQuery 1.0.30 > new-plugin > select manifest.json.
  4. Click on "Nugget's Frame Queries" and the plugin should load.
  5. In the component that you want to have frame queries on, add a new Property FQ-size. Needs to be exactly this string incl. capitalisation. You can name the variants anything you like, for a given value of "anything". Spaces are supported, but there are some other characters that might not be.
  6. FrameQuery should dynamically pull your variants from anything you set in FQ-size.
  7. With the component selected, turn FrameQuery on.
  8. Set your breakpoints. A max is needed for your biggest breakpoint, just make it something silly like 9999px.
  9. Pop a component instance onto the canvas, stick it in a frame, and resize the frame. The current version only cares about width, but I might enhance with height later.

FrameQuery appends 🤖 to component names that have FQ enabled, and prepends 🤖 to frames that contain component instances with FQ enabled, so we can keep track of 'em without messing up how our prototypes look in demos.

FrameQuery also works with components imported from libraries (1.0.30)

  1. Follow steps 1-8 from above in your library file, and publish the library.
  2. Close the library file (you don't need to have it open).
  3. In your target file, load FQ.
  4. Pop in the component instance from your library file, just like you normally would. This is the component with 🤖 appended to its name.
  5. Pop the component instance in a frame.
  6. 🤖 is prepended to the frame name, and the frame is now responsive.







That old chestnut again: Should designers code? No... and yes. ;)

Some ponderings as I learn the wonders of CSS-grid, fluid typography, and all the shiny new toys kids these days have.

Gosh, CSS has gotten so much nicer since the days when we had to haul water to the top of the hill both ways barefoot in the snow.

No, designers shouldn't code
I don't think designers need to be able to write production quality code. It stands to reason that I have a vested interest in this "no", as I haven't committed production code in over a decade. Plus, production quality code, especially at an enterprise-level, is a completely different beast from building a small static website. When it comes to enterprise code, scalability, maintainability, extensibility are all very important - and I prefer to leave them to the experts (my developers).

Yes, designers should code
Ideally, designers should have some familiarity with, and understanding of the basic "materials" used to build the digital products they design. Additionally, the "materials" will vary, even across digital products. Just because I can write js and css certainly does not mean I know the "materials" for native Windows, Mac, Android, or Linux.

With that as the caveat - being able to code just enough to know my materials is a very big plus. I did a basic Vue course fairly recently. Nothing fancy, just a single page app. However, what I learnt from that course gave me a much better idea of how Vue (and React, and Angular) work at a very high level, and how that can translate into implementation. It also made it collaborating with front-end web developers easier, as we had some degree of shared knowledge.

I've also been experimenting with the "new" (not so new, I know) CSS toys all the kids have these days. What's really cool about this is that unlike the Vue course, what I'm learning about CSS is changing the way I think and design - and think about design. These learnings change the bounds of what I know are possible.

For example, I have been reading about fluid typography on the web for a couple of years now - and before I started poking around the code, it's been a very abstract sort of interest. E.g. "Nice and interesting abstract concept, I should try to design for that when I have the opportunity". Now that I've poked around the code, and gotten a basic understanding of how things work, this has changed to a much more real and practical, "ZOMG now that I actually know how that bit of code holds together, I can actually set a typographic scale that way, and see it work. And I can see how I could make it work in so many places. Waoohh!"

Here's my supernoob code-pen, which I'm modifying on the fly as I learn more about css-grid and fluid typography.
All the noob inline comments, every noob inline comments!

See the Pen Flying Red Horse - CSS-Grid Experiments by JC (@nuggettyone) on CodePen.