Live data from Hacker News

Will Figma become an awkward middle ground?

dive.club

101–110 of 134 posts

Re: Will Figma become an awkward middle ground?

#101
post #62

Earlier quoted context omitted.

I am not sure if you are joking but there is whole set of techniques called fluid typography that does this (using css math functions mainly clamp) https://fluidtypography.com/ It's not a silver bullet and many people simply don't prefer it to having a few breakpoints (that includes me too).

font-size: clamp(3.125rem, 3.464vw + 2.229rem, 5rem); From their website, this is not easy code to maintain. It’s not obvious how to increase/decrease the font size at a later date.

Virtualization tool may help.

https://modern-fluid-typography.vercel.app/

Re: Will Figma become an awkward middle ground?

#102
post #5

I feel seen! I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause. Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general d…

I agree with this sentiment. I built and led a "Product Design Team" of about 50, and there were no mockup designers on my team. Either the designers can write some code,, or they can design directly in HTML/CSS. The mockup designers work with the team, and I encourage them to understand the limitations and power of the engineering team. I found that many designers end up short at the "mockups to impress the client" stage and are more artistic than being designers.

Any styles/CSS generated by a visual tool will always be limited to the vicinity of that particular design. But in the real world, the design of an entire website/app/platform should be a cohesive network of patterns and consistencies in the whole ecosystem - this is why understanding and designing in HTML/CSS finally makes more sense.

Yes, the standalone designers will be there, but they will always be disabled and limited unless they, at least, learn how the whole thing fits in, and their designs are just the pieces that fit elsewhere in entirely different ways.

I'm lucky to have been able to play the role of a designer, a developer, and business-sy sales pitching to customers and closing the loop by answering questions from all personas. This also did left me being more of a generalist and not a specialist.

Figma and other tools, however good they become, will always be that prototyping tool for playground before the actual work starts.

Re: Will Figma become an awkward middle ground?

#103
post #5

I feel seen! I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause. Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general d…

> There's way too much to do with media break points As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier. It easily snowballs into you having 3 different CSS (phone/tablet/desktop). I wish there was something akin to 'light-dark' (where you can specific a different value conditional on the environment) but would be trigger based on window…

I'm way behind in the loop these days, but isn't it just a tiny screen (phones) and then large (Tablets and Desktops) these days? Tablets (medium) sizes are now well-sized, so you should ideally be just building for that segment of 1024-1200px width!

That should reduce the media query worry to one single breakpoint, no?

Re: Will Figma become an awkward middle ground?

#104
post #85

Earlier quoted context omitted.

Hard disagree here. Are you writing production code, or are you building mockups/prototypes? I don't want non software engineers touching production code. It's too hard, and the depth of skillset for a product/UX designer is already huge. If you find css and js faster for prototyping and mockups, then sure. I'm doubtful and still yet to see that work in the wild.

It would actually probably be pretty helpful if the designers knew their way around the production code, since they'd have a lot more context about what is going to be easy/hard to do. They won't be in some design vacuum. Silo-ing off code because someone isn't a "software engineer" also feels kind of funny to me.

it would be useful if anyone in the company - CEO, salesman, designers, "X department" knew their way around the production code so your statement feels funny to me. look at sports - it would be awesome if everyone on the team is a great linebacker but ...

Re: Will Figma become an awkward middle ground?

#106
post #5

I feel seen! I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause. Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general d…

> There's way too much to do with media break points As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier. It easily snowballs into you having 3 different CSS (phone/tablet/desktop). I wish there was something akin to 'light-dark' (where you can specific a different value conditional on the environment) but would be trigger based on window…

tailwind is pretty close IMO.

text-sm md:text-base lg:text-lg

Mobile: font-size: 0.875rem; /* 14px / line-height: 1.25rem; / 20px /

Tablet: font-size: 1rem; / 16px / line-height: 1.5rem; / 24px /

Desktop: font-size: 1.125rem; / 18px / line-height: 1.75rem; / 28px */

Re: Will Figma become an awkward middle ground?

#107
post #85

Earlier quoted context omitted.

It would actually probably be pretty helpful if the designers knew their way around the production code, since they'd have a lot more context about what is going to be easy/hard to do. They won't be in some design vacuum. Silo-ing off code because someone isn't a "software engineer" also feels kind of funny to me.

it would be useful if anyone in the company - CEO, salesman, designers, "X department" knew their way around the production code so your statement feels funny to me. look at sports - it would be awesome if everyone on the team is a great linebacker but ...

I know you're joking but I've worked in very engineering-heavy startups where this was the case and almost everyone had to write some code, production or not.

Re: Will Figma become an awkward middle ground?

#109
post #5

I feel seen! I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause. Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general d…

> There's way too much to do with media break points As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier. It easily snowballs into you having 3 different CSS (phone/tablet/desktop). I wish there was something akin to 'light-dark' (where you can specific a different value conditional on the environment) but would be trigger based on window…

Tailwind is pretty nice for this

  

Re: Will Figma become an awkward middle ground?

#110
post #5

I feel seen! I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause. Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general d…

Hard disagree here. Are you writing production code, or are you building mockups/prototypes? I don't want non software engineers touching production code. It's too hard, and the depth of skillset for a product/UX designer is already huge. If you find css and js faster for prototyping and mockups, then sure. I'm doubtful and still yet to see that work in the wild.

Hard counterdisagree here. To just have a blanket rule preventing "non-software engineers" from making production changes is completely arbitrary and suggests you may be lacking a rigorous process for determining which changes are actually important and ensuring they get proper review (no matter who made them). If you had a good process there's no reason anyone at all shouldn't be able to propose changes to production code.

What makes someone a software engineer in your scenario? I myself have worked as a software engineer for about 30 years at this point and have a degree and postgrad in Jazz, contemporary and popular music[1]. My work in software has encompassed writing software where making a mistake would have very significant real-world impacts[2].

I have worked with designers who are much more capable at making certain changes to production code than some titular software engineers.

Lots of changes to production code are not hard at all. I would go so far as to say the vast majority in fact.

[1] I can't play any more due to RSI which means I am now professionally qualified to explain to you why Steely Dan is the best pop band ever and harmonize things in 5 parts in the style of Duke Ellington and not much else.

[2] eg pricing, risk and decision-making with very large amounts of money on the line and even doing data analysis in regulatory and criminal investigations.

Post reply on HN