Designers almost always work in grid systems, not in collections of arbitrary measurements between screen elements. I suspect one of the reasons that Bootstrap has become so popular is that its grid system makes it fairly easy to implement the grid-based layouts that designers typically employ. Things like Bootstrap and flexbox make implementing grids easy. Constraint systems are at entirely too low a level of abstraction for this.

> That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em.

Yes, but that's because those designers were asked to specify the layout in engineer terms. :) That doesn't mean that that's the way they think and conceive the UI.

Actually - learning to draw, one of first thing to learn is proportions.

Distance between eyes is equal to one additional eye; nose lies on a line that connects it to bottom of the ear; mouth are about halfway between chin and nose; body is about seven heads tall, etc.

I'd say constraint solving is pretty much in line with that kind of thinking.

You're right. The drawing canons are, in a way, constraints.

However, it's not relevant for this, I think. Drawing is very different, goal-wise, from design. Designers do learn how to draw early on their education, but I think it's more a matter of learning how to "see" and developing other useful skills. The approach to drawing doesn't translate directly to the approach used while designing.

Actually that's exactly the way they think. "These items should be aligned at their bottom ends", "this group of items should have space between them and take the whole width of the page" etc.

And some designers tools also let them express it in exactly that way.

Yeah, that's the engineer perspective on it. Focusing on the details, on deconstruction, and not on the whole.

It's true that rules such as "bottoms aligned" and "equal heights" exist frequently. And it's also true that there are tools to express these rules (align and arrange tools in Adobe software). However, those are the "implicit" parts, the minor details that one attends to while designing but without giving it much thought. Of course, for the technical guy who implements, those details are important. And that's why they're specified in design specs, so to speak.

But the layout, the major composition, is thought (typically) out of a grid system. And that's what, I believe, a designer focus on. Not on individual element rules, but on the whole.

Of course, if a engineer spends hours making a detail in the implementation look like the design, then he'll think that the designer gave it a proportional amount of attention. Typically, not true. :)

>But the layout, the major composition, is thought (typically) out of a grid system. And that's what, I believe, a designer focus on. Not on individual element rules, but on the whole.

That might be true for print designers of yore, but we've moved beyond that in the last 10 years or so.

Designers today know that it's not about some static composition on top of some grid. And they also know that individual elements are important (e.g. how a callout or a profile pic responds to a page resize).

Heck, it's the same designers that had to suffer using floats for layout (and if there was ever a "engineering driven idea" and at odds with grids it was that). Compared to that constraints is designer heaven!

Moved beyond grid systems? I can't agree with that.

Also, I don't really see the connection you're implying between using a grid and having a static composition or not considering individual elements behaviour. I do compose out of a grid system; the best designers (or the real designers) I worked with do the same. And that doesn't mean that we won't specify how the profile pic responds to resize - we do. It's just that it is a detail. It's not layout, it's not the composition. The specification of such details should not be the basis for your layout implementation framework.

>Moved beyond grid systems? I can't agree with that.

Good, because I haven't said so. I said we've moved beyond static designs on top of some grid.

When you add different screen sizes, resizing and interaction to the mix, the grid itself gets dynamic, and relationships between items (constrains) matter more than visual placement.

>It's just that it is a detail. It's not layout, it's not the composition.

The thing is that seems to me a relic of print design.

In modern UI design there's no fixed composition as such. Even whole elements might appear and disappear at will, based on the app's state.

Designers have to add these lines and numbers after the fact, and they don't always reflect the intent behind the layout. As screen sizes, typefaces and other layout details change, fixed numbers quickly become obsolete.

The ideal is to encode that original intent behind the layout into your program. As far as I can tell, any set of constraints simple enough to solve efficiently will not be powerful enough to model your designer's intent. The design will eventually become complex enough that your layout will need to be represented as a procedure. Once that happens, the constraint system becomes just another pointless layer of abstraction.