And thats how you get designers whining that their design looks great in figma but not in a real webpage
And thats how you get designers whining that their design looks great in figma but not in a real webpage
I work on a large web based application, with designers, who use Figma. It's just too easy to lose the plot and come up with things that don't work well. Not because of Figma. Something about the balance between the software stack(s), the domain, the focus of designers today, the front end engineering, and product management is broken. It's interesting that Figma did (IMO) a great job at addressing the stack so they can build a product that does what they want it and then is used by so many to build products that don't always do what their customers want. Asking Figma to use the wrong stack for their product (which is what I'm reading between the lines) is not really the right answer...
I'll call Google and I'm sure they'll get right on aligning their browser's rendering engine with figma's
What about other browsers? Versions? Platforms? OS? Resolution/screen size? My huge frontend team can't handle this, even before we used Figma.
Isn't the problem trying to get this "web platform" do something it was never meant to do? How would this be solved by Figma using a rendering engine that would grind their product to a halt?
I'm old enough to have done a lot of native platform UI work, the web stack in many ways was a step backwards. It has obviously a lot of advantages (run anywhere) but in some ways it's more like IBM terminals on a mainframe vs. a native UI where you have full control. I (obviously) use and make web apps all the time, but they often suck, and this isn't Figma's fault.
I'm sure there's something fundamentally wrong with the font files. In both cases, they're not standard, widely available fonts. With that said, browsers render the fonts consistently with each other, but not Figma.
There's also a lot of ways that figma can lead designers down the unhappy path. They'll put together two different screens that look great, wave their hands around the idea of "just make it responsive" and when you go in and look, there's nonsensical crap like absolute positioning on elements, or arrangements that don't work with block layouts and force you into convoluted grid stuff.
Figma is clearly built to be useful for web development. It has tons of gaps that lead designers off the happy path. Take out all the "browsers / versions / os / screen size" differences from the argument; my points above would apply to any design tool built for any product. If it doesn't accurately reflect what is possible or how something is done, it's not a perfect fit.
PS: I prefer figma over pretty much every other tool I've used. With that said, there's no pretending that it is perfect, nor any reason to deflect accurate criticism elsewhere.
I’ve been thinking about a box-first approach to design tooling. The overall layout workflow would consist only of adding boxes (block-level elements) to a blank web page, or inside other boxes. Boxes could also contain other elements like inputs, buttons, images, etc.
More like ”no-code design directly in HTML and CSS”, but with familiar Figma/Sketch-line controls for sizing, alignment, etc. Responsive by default, boxes full-width and vertically sized by content by default, manual pixel sizing of elements heavily discouraged in favor of block/inline-block/inline. Sane defaults for theme tokens, but easily customizable.
In other words, a hands-on design tool for web layouts, working directly on the DOM and stylesheet, preferring the flow for positioning and leveraging (normalized) HTML/CSS defaults.
My thinking is mostly born out of frustration with the performance of flexbox-inside-flexbox layouts and the total disparity of text layout between web and existing design tools.
Is the book that good?
This thread started about "boxes", I probably should've linked directly to this page: https://every-layout.dev/rudiments/boxes/