Lessons Learned About One-Way, Dataflow Constraints in Garnet and Amulet (2001) [pdf] | Hacker News Reader

Lessons Learned About One-Way, Dataflow Constraints in Garnet and Amulet (2001) [pdf]

isi.edu

17 pointsmpweiher7 comments

I feel like constraints for UI layout have kind of died out. I used them a bit with macOS/iOS before SwiftUI, and found them to be unwieldy.

Are there any toolkits using them as their primary layout method?

Constraints are a layout paradigm that seems conceptually perfect to engineers, but is almost unusable to designers.

I think Apple's capitulation in SwiftUI to abandon constraints has marked their end in mainstream UI design, at least until we have AI tooling that can manipulate constraints in a more intuitive way.

Funnily, CSS flexbox and grid models can be seen as a kind of constraint layout system. Penpot, the Figma competitor, has even implemented a flexbox subset as its layout mechanism.

The moral of the story, if there's one, is that constraints may be useful if they reflect common design rules and the system is built around those cases with high level abstractions, but simply allowing any possible low-level constraint may be too complex for the case of designing GUIs.

What makes them unusable? It seems like simple constraints in CSS are fairly common, eg. percentage widths. Is it that only simple constraints are understandable / usable?

They're useful quite frequently but just don't work well as the core or only way to manage elements. Size / spacing / proportion are very subjective based on the context, expectations, information being presented, even colors and animation etc.

They often don't "scale" in a way that's easy to represent with constraints. Like yes, a width or a border might work fine as a percentage, and it's good to have it there. But for example the size of a graphical figure relative to the text describing it on different screen sizes. It may be 50% or more of the screen on a small display, much much less on a larger one.

Or for a really concrete example, imagine a container element with internal spacing of 10px. Triple the size of the element; the ideal internal spacing is likely neither 10px, nor 30px, but some other thing you need your eyes to figure out. Arithmetic is simply the wrong tool to model the relationship.

> It may be 50% or more of the screen on a small display, much much less on a larger one.

So maybe simple constraints + breakpoints, eg. 10% for size X, 30% for Y, ...? That seems to be what CSS has settled on but I'm not sure if that's really the best approach.

I'm just trying to understand what the recommended design approach is in an ideal world. Constraints are a straightforward unified model, so if that's no good, is the suggestion that there is no known unified model so just use heuristics X, Y and Z as "appropriate" by some metric, or is some other unified model better?

I suspect there's no unified model that is ideal, yes. But I'm not a designer or ui expert at all, just have built some interfaces using it. CSS's approach seems more practical, basically letting you define a set of constraints for different scenarios with overrides and defaults available.

Again and I really want to stress this because it's important and maybe unintuitive or hard for us to accept as engineering minded folks. You can't sit down with a pen and paper and numbers that describe a good interface in a given scenario (size, ratio, pixel density, colorspace, etc), and using only math transpose that interface to a different scenario. If you can do this, it's because you have enough experience and intuition with the measures to make good estimates. But these are not properties of the numbers. The numbers describe a good interface, they don't create it.

Reply on news.ycombinator.com