On UI Layout

Michael Lucas-Smith posted an interesting summary of UI layout models. I tried to leave the following as a comment, but the blog server swallowed it without posting. Fortunately, I half-expected this and copied the text before submitting. I’m posting it here instead, with some further edits.

Overall, this is a good summary, but there is a very important model it misses.

The model is a variant of constrained-based layout called linear constraints. In that model widget positions are expressed as a system of linear equations. This more formalized approach, unlike “intuitive” models with springs, wires and other pseudo-real life accessories, isn’t fiddly at all. There are algorithms (Cassowary is the most famous) to efficiently solve such constraint systems.

Also, importantly, many other models: fixed, relative, stacked and grid layouts are special cases of linear constraints. Only flow cannot be expressed this way. Thus, the models are not all incompatible. Also note that I’m listing “relative” as an additional model, which is the correct way to describe the VW approach (first proposed, most likely, by Luca Cardelli). (“Fixed” would be the case when the widget’s bounds are expressed as coordinates in some coordinate system, usually relative to the containing widget’s top left corner).

I’m not sure what it means to say that layout should not be part of the widget framework proper, without first defining the proper. One extreme is Windows which provides no automatic layout capabilities at all. That is indeed the pure fixed model. The other are frameworks with container visuals. In those frameworks the specific layout model is indeed dictated by the container. But still, the only difference between the two is that something like Qt has containers that do layout and Windows doesn’t. In neither of them layout is part of widgets (by widgets I mean atomic leaf components such as buttons or list views).

The important question is how hard or easy it is to introduce new containers with different layout models, but it is a matter of the overall framework design. The main complication here are performance constraints. The framework should reasonably quickly respond to incremental layout changes, and reconciling that need with pluggability of containers and their layout policies is where the devil lies. I’d estimate about 70% (if not more) of Brazil design effort has had something to do with layout management.

3 Responses to “On UI Layout”

  1. [] says:

    What’s the Brazil Design?

  2. Ross Judson says:

    I’ve had good results using Choco to do layouts of swing components. With it you can do everything that you thought you could with SpringLayout, but discovered you couldn’t after SpringLayout sneaks up behind you and hits you in the head.

    Generalizing Choco into a proper layout manager is somewhat tricky, but something I’m hoping I’ll get to.

    There are higher level concepts involved as well. There are geometric roles (parent container, child) and conceptual roles (focus objects, primary and second information, etc). In the best case we provide a small number of orthogonal concepts with well-known intents, and generate the necessary interface in context, much like styling HTML.

    A table view and a force-directed layout of graphical nodes are not really very far apart.

  3. Jo Vermeulen says:

    I worked with constraint-based layouts for my Master’s thesis, and ported the Cassowary algorithm to C# for this (Cassowary.net). I agree that you can realize many layouts with constraints, but I also noticed that flow layouts are a notable exception :-)

    The coolest technique so far in automatic layout and beyond in my opinion is SUPPLE by Krzysztof Gajos. It uses an optimization algorithm to generate user interfaces for different users and devices. A list of papers on SUPPLE can be found at Krzysztof’s page.

Leave a Reply

For spam filtering purposes, please copy the number 7275 to the field below: