Humans are not constraint solvers
Layout is as important today as it was many years ago when the first user-interface based computers were becoming popular.
In spite of being used in a wide array of systems over the years there was never a generally accepted way of specifying how elements are sized and positioned on the screen.
As the variety of devices continues to grow, it becomes more and more important to be able to design your content so that it appears in the best possible way to the final user.
We could try to provide a finite number of layouts specifically designed for a particular viewing configuration but as the number of possible setups increases that option becomes more and more unrealistic.
First proposed in 1994 by Håkon Wium Lie, the CSS language was a much needed step in the right direction to allow web content layout to be properly specified in a declarative and modular way. It had its share of controversy, adoption problems and to this day, some things that ought to be really simple to use are still painful, like centering an element.
Apple had its own frame based system layout with minimal responsive capabilities through the use of the Springs and Struts via NSAutoResizingMask. While this proved sufficient with the first couple of devices, the advent of the iPad and iPhone 5 meant two more aspect ratios that the app designers had to deal with.
Most of the times this resulted in several layouts, each suited for a particular device. After awhile everyone realised this was no scalable solution.
Cassowary constraint solver
OS X Lion introduced Auto Layout, a new layout system for Cocoa. It had a constraint-based layout engine that uses the Cassowary constraint solver as its underlying mechanism that outputs elements positions and sizes given a number of constraints.
Here is a quick example on specifying a layout consisting of two buttons separated by 12 pixels using Auto Layout's textual counterpart, Visual Format Language:
[button1]-12-[button2]
Since adopted by Apple, this idea of constraint-based layout eventually picked up and is now being proposed as an alternative to CSS in the web world with Grid Style Sheets
While seeing their talk on Fluent 14 about their idea there were a couple of things that stroke me as odd.
Source-order independence
One of the benefits hailed by constraint-based layout supporters is the idea of source-order independence. This means that the hierarchy of the elements inside you viewport doesn't matter to the layout engine. You can have two unrelated components be involved in a constraint.
Lets imagine the following layout
Here we have an yellow group with one child button (Button A) and another button (Button B) that is a sibling of the yellow group. Conceptually we can represent this relation with a diagram:
If we were to say that we wanted both buttons to always be at the same Y position
buttonA.y == buttonB.y
we would end up with this relation (dependency represented by a blue arrow):
I don't know about you but this image rang some alarms in me. In a traditional layout system like CSS, or even Android, you design your system with an hierarchy in mind, and the layout system allows you to specify how an element behaves in relation to its siblings, but there is no possibility of propagation of effects between unrelated components.
In those traditional layout engines, even if we had a more complex layout like this one:
we could be confident that any change made to a group would only affect elements within its scope, namely its children. Even if the changes ended up changing its size, meaning its siblings would also be affected, it would always be a trivial task to predict how it would end up since it was a simple side-effect.
Using the blue line as depedency indicator we would have a diagram very similar to its hierarchy counterpart:
I have used a light blue to denote the dependency between siblings as a way to highlight the notion of it being a side-effect and not an explicit rule specified by the designer.
It looks pretty clean and every change on a given element is propagated in an understandable and predictable manner.
Dependency hell
Back to constraint-based layout, despite all the power source-order independence might seem to provide at first, we could easily end up with a layout like the one below, if we are not careful:
This would mean that even the slightest change in one element could cascade in a number of seemingly unrelated effects on the rest of the elements, much like what happens in a chaotic system.
Look at the previous image as if it were an application architecture diagram. You would never want to end up with something like that right? Why? Because we have been told, time and time again that we must strive to reduce our mental overload as much as possible since we don't have much bandwidth to spare and there is nothing worse in that regard than a system tangled in a web of dependencies.
The thing is that it's easy to make these kinds of mistakes in constraint-based layout systems and the only way to fight it is to always keep an internal clear and accurate model of the dependencies in your head, which can be quite easy at first, but a nightmare once the layout gets complex enough.
The good parts
One could argue that the designer doesn't need to use all the power that comes with theses systems, and that by sticking with a reasonable subset that satisfies most of the needs everything will be alright.
The problem with that mindset is that, by following it, you are agreeing to the fact that the power that comes with it is pretty much useless, since it will result on unmaintainable work. Since the thing that, at first, seemed to be its most unique advantage is, in reality, not so good, one starts to wonder why not simply use another system, like CSS or Android's layout engine, that allows the same range of expressiveness and flexibility without the headaches.
So...
When talking about this subject, we are constantly told that the constraint-based layout engine is doing all the work for us and we don't even have to think about it, that everything can be represented in an declarative way.
This is not true. As the layout grows, you have to basically do the same thing the layout engine is doing in your head in order to predict how the system will end up so that you know what to change.
In the end, this is what I think is the fundamental flaw of the constraint-based layout system. It was designed for machines, not for humans.
What do you think? Leave a comment below or get in touch with me through email, LinkedIn or Twitter