Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Figma starts designing us

designsystems.international

Post reply on HN
Print view View original

121–130 of 145 posts

Re: When Figma starts designing us

#121

Post by screye »

sillyfluke wrote: post #119
screye wrote: post #36

Earlier quoted context omitted.

Isn't this the problem with all no-code / low-code platforms ? Code is merely the leanest human-readable representation for loss-less specification of requirements. We're seeing this same pattern with 'K8s YAMLs' and 'prompt engineering'. There is an entire industry that's re-inventing new DSLs which inevitably converge to a scripting language as requirements get more complex. Instead of reinventing the abstraction,…

>Code is merely the leanest human-readable representation for loss-less specification of requirements. I think you might have meant "loss-less specification of the current design." requirements are aspirational, and signifies the intent, code is the loss-less version of how the system will actually behave.

No, I meant requirements.

Stated otherwise: "Sufficiently advanced requirements are indistinguishable from code".

Abstracted requirements define outcomes. Fine-grained requirements define code.

Re: When Figma starts designing us

#122

Post by immibis »

miiiiiike wrote: post #32
spookie wrote: post #30

Earlier quoted context omitted.

Yeah... Just do pictures on the design phase and then code.

There’s a lot that goes into creating the pictures. Consistent spacing, colors that change depending on platform, breakpoints, containers, and on and on and on. There’s no reason that a tool can’t model a design system and make producing consistent designs that use it trivial. I think the problem with Figma is that it tries to appeal to visual designers, UX designers, and programmers. Good for business, bad for users…

Don't create every possible picture. Create a representative set.

Draw each screen at least once. If you have dark mode, you don't have to fully redraw each screen in dark mode, just enough to show how dark mode should look. If it has to work on desktop, you probably do have a completely different desktop version of each screen (from the default mobile) so draw that - but don't redraw every detail of a widget that's identical to mobile.

Testing every combination should be for the testing stage. It's good if you can foresee clashes (like the desktop version of this widget looks bad on this page in dark mode) in the design stage but it's not really an excuse to prolong the design so long that it lasts until you would have been finished with testing anyway.

Having a computer generate all the combinations for you in the design stage isn't that great unless you can pay individual attention to them - there's no point producing artefacts that nobody looks at.

Re: When Figma starts designing us

#123

Post by PaulHoule »

gherkinnn wrote: post #117
PaulHoule wrote: post #40

Earlier quoted context omitted.

From my viewpoint the benefit of low-code is that the average business application is a matter of people filling out forms. If you want to radically lower development time you have to solve all the problems https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p... For instance, a 2025 no code platform is likely to have "one click" deployment of a cloud application. That's great if you can accept that but if you…

> Another example that kept turning up was that the ticket "1 phone number for a customer is not enough, support 2 phone numbers" is inevitably followed by "2 phone numbers is not enough, support 3 phone numbers" Zero. One. Infinity. https://en.m.wikipedia.org/wiki/Zero_one_infinity_rule YAGNI, handle a singular case, and once you have multiple treat it like a list.

In the case of the phone number or email it is just so frickin' predictable what will happen.

Adding multiple non-list fields is seductive because going to the list is a "structural instability" that requires using different coding techniques.

Right now I really like https://www.react-hook-form.com/ for forms that have list values. Back in the day there were a set of techniques that seem forgotten (like how the Egyptians built the pyramids) that some developers knew and others didn't.

It isn't hard at all to make a no-JS form where you had an "add" button next to a list of values. When you click on that button the POST data contains everything in the form as well as the key/value pair for that particular button (and not other buttons) so the back end can tell which button was pressed and redraw the form with another field. Delete can be handled the same way. If your form is not junked up with 50MB of trackers and ads and metadata for every social platform it is really fast, it was really fast even on dialup.

With a handful of helper functions and a "router" that can display different forms depending on what you enter you can make powerful no-JS forms but that knowledge didn't quite reach 100% penetration before Angular came along, but developers who came on after that never learned it.

Re: When Figma starts designing us

#124

Post by sghiassy »

miiiiiike wrote: post #10

No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…

I think the authors point, is that, designers are incorrectly choosing the wrong tool.

In my experience in FAANG, designers use Figma for everything. Like literally everything.

So when you say, they should use a sketch tool when they need free form, they don’t

Re: When Figma starts designing us

#125

Post by mananaysiempre »

brailsafe wrote: post #104
wx196 wrote: post #26

Earlier quoted context omitted.

Figma actually now has grids: https://help.figma.com/hc/en-us/articles/31289469907863-Use-...

To me, things like mobile-first responsive design and grid-based graphic design thinking are core components of designing for the web, so it's a bit wild to me that Figma, with such popularity, is just now getting grids, and as far as I'm aware no GUI tool has ever succeeded at building a capable visual responsive design tool close to on-par with just designing in the browser.

This does not seem that surprising to me.

Browsers are by and large black boxes—less because of their architecture and more because of the sheer size of the code, although Firefox, for example, seems to have been moving towards a less open architecture for most of its history as well (deCOMtamination, death of XULRunner, Quantum, etc.).

What you really want in a parametric web design tool is to crack open the layout engine and the CSS cascade and inheritance, at the very least. That’s a lot of work to target a demographic of designers and programmers who by now have largely decided to ignore CSS in favour of reinventing inline styles badly (Tailwind) and insert markup as necessary for the desired visual effect. (Is there a tool to do CSS in terms of React/etc. components, with proper cascading, custom pseudoclasses and pseudoelements and so on? I haven’t seen one.)

Re: When Figma starts designing us

#126

Post by sillyfluke »

screye wrote: post #121
sillyfluke wrote: post #119

Earlier quoted context omitted.

>Code is merely the leanest human-readable representation for loss-less specification of requirements. I think you might have meant "loss-less specification of the current design." requirements are aspirational, and signifies the intent, code is the loss-less version of how the system will actually behave.

No, I meant requirements. Stated otherwise: "Sufficiently advanced requirements are indistinguishable from code". Abstracted requirements define outcomes. Fine-grained requirements define code.

I respectfully disagree.

The customer has given a requirement that states the variable has to be calculated as y= x +1.

However, the code that exists has been implemented such that is calculated as y= x - 1.

y=x-1 is how the current system behaves. However it conflicts with the actual requirement, which is y=x+1.

Re: When Figma starts designing us

#127

Post by gherkinnn »

PaulHoule wrote: post #123
gherkinnn wrote: post #117

Earlier quoted context omitted.

> Another example that kept turning up was that the ticket "1 phone number for a customer is not enough, support 2 phone numbers" is inevitably followed by "2 phone numbers is not enough, support 3 phone numbers" Zero. One. Infinity. https://en.m.wikipedia.org/wiki/Zero_one_infinity_rule YAGNI, handle a singular case, and once you have multiple treat it like a list.

In the case of the phone number or email it is just so frickin' predictable what will happen. Adding multiple non-list fields is seductive because going to the list is a "structural instability" that requires using different coding techniques. Right now I really like https://www.react-hook-form.com/ for forms that have list values. Back in the day there were a set of techniques that seem forgotten (like how the Egypt…

I must say, React Hook Form offers a good way for React to interact with forms. There are many things to dislike in that ecosystem but that lib is excellent.

Re: When Figma starts designing us

#128

Post by carlosjobim »

miiiiiike wrote: post #10

No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…

> If there’s something better than Figma out there, please, let me know.

HTML+CSS works very nice for these mock-ups. Tried Figma and Sketch for a small project, never again.

Re: When Figma starts designing us

#129

Post by karaterobot »

markbao wrote: post #106
karaterobot wrote: post #102

> A concrete example is Auto Layout... In practice, this locks the design in place and severely limits the possible expressions. You can’t drag things around freely or try odd combinations of layouts. I'm a designer, I've used Figma since 2018, and this is incorrect. And not even incorrect in an "I feel differently, but I see what you mean" way. It's the opposite of correct. It's categorically wrong. Autolayout makes…

I don’t see how it could be categorically wrong. To me it’s categorically right: Auto Layout specifically is intended to restrict the possible layout options. You trade off adding limitations for how much you can do in a design and move things around freely, and in return you gain more convenience and less work needed to organize designs. You can change designs around quickly… as long as they’re within the rather con…

> To me it’s categorically right: Auto Layout specifically is intended to restrict the possible layout options.

Except that you do not need to use Auto Layout if you don't want to mimic the flow of objects inside a flexbox container. You can just use a regular frame, and position things freely within it. Or, you can use an Auto Layout, but then absolutely position arbitrary elements inside that Auto Layout frame if you want. Auto Layout does not restrict a designer's layout options, it only adds to them.

Re: When Figma starts designing us

#130

Post by The5thElephant »

no_wizard wrote: post #80
The5thElephant wrote: post #51

Earlier quoted context omitted.

Exactly this. Thank you. We need a Blender-like design tool specifically for product design. Using HTML/CSS for rendering so it covers most web needs and that usually more than encompasses native app-layout emulation. Open source, technical, and not expected to be picked up in a day or fully understood top-to-bottom by everyone. The reason Figma is putting us into a design box is because it doesn't have all the CSS f…

as much as folks hate electron, I think if Figma was electron, it would at least have the entire chromium web engine to work with

Figma on desktop is an Electron app I believe. Figma chose to build a custom webGL rendering engine for their design canvas, so the core issue is that technical decision early on (probably allowed for some better performance and multiplayer back then). Figma is stuck with wanting to control their rendering and allow for non-product stuff like Figjam or the new Draw tools, but it will inherently hold them back from providing a really good design/dev handoff and always will hold designers back because it doesn't use CSS web rendering.
Post reply on HN