3

So, there's this idea, which you already know: Define the layout of your UI by creating a tree of panels. The leaf nodes on the tree are what we used to call 'controls' way back in the day-- the things that the user interacts with, radio buttons and listboxes and such. The internal nodes are mostly concerned with layout; this kind of panel stacks its child panels vertically, that kind puts its children into a grid, etc.

It's COMMON. Most of the UI-generating systems I've seen in the past twenty years are implementations of this, and the ones that aren't borrow from it.

What's the word for this idea?

EDIT: I'm looking for a word, or a phrase, for the pattern I'm describing. It's a big, high-level pattern, and it's become nearly universal. AWT, HTML forms with the controls in table cells, Swing, XAML, Android, and ASP.NET all use it or borrow from it. There's an idea here, on the same level as concepts like "windowing system" or "mesh network." What do we call it?

I suspect that the real answer is, "there's no consensus on a name for it yet." Which would, itself, be really interesting.

Improve this question
5
  • WIMP? Windows, Icons, Menus, Pointers?
    – Mark Canlas
    Commented Apr 6, 2012 at 20:59
  • Perhaps you're thinking of inheritance, a property of many object-oriented systems. In theory, inheritance can describe all sorts of things; a car, a biological system, a taxonomy chart. In practice, it is used extensively in graphical systems, and only occasionally elsewhere (where composition is preferred).
    – Robert Harvey
    Commented Apr 6, 2012 at 22:36
  • 1
    In HTML/CSS you're referring to a relational display model. Where elements are positioned based on their relationship to the elements that come before/after them in the tree. The alternative is an absolute positioning model where the structure doesn't matter and every element's position is explicitly placed in relation to the top left corner. Relational is generally preferred because it allows you to make changes to parts of the whole without requiring a full re-calculation of all the offsets within the page.
    – Evan Plaice
    Commented Apr 7, 2012 at 1:01
  • @Evan: I think that should be an answer because it's the correct one. Relative or relational layout systems have become prevalent because fixed or absolute layouts have proven to be too inflexible, and a tree of containers and components plus a rendering/layout engine seems to be the natural way to implement relative layouts.
    – Michael Borgwardt
    Commented Apr 7, 2012 at 9:11
  • @MichaelBorgwardt OK, I'll add it.
    – Evan Plaice
    Commented Apr 8, 2012 at 4:50

6 Answers 6

Reset to default
4

In HTML/CSS you're referring to a relational display model

Where elements are positioned based on their relationship to the elements that come before/after them in the tree.

The alternative is an absolute positioning model where the structure doesn't matter and every element's position is explicitly placed in relation to the top left corner.

Relational is generally preferred because it allows you to make changes to parts of the whole without requiring a full re-calculation of all the offsets within the page.

For example, if you change the offset for a panel that is 5 generations/nodes removed from the main panel; in a relational mode, everything re-flows to compensate automatically; in an absolute model, the offset for all 5 generations/nodes of parent panels need to be re-calculated in cascading order because no child can calculate it's offset in relation to its parent until the parent is updated first.

The tricky part about HTML/CSS layout models is, you can mix them.

For instance, a 5th child panel can be placed using relative positioning (display:relative) but the child elements of that node can be placed using absolute positioning (display:absolute) within that element. Ie Instead of calculating the top-left offset from the window corner, it's taken in relation to the top-left of the box it resides in (5 generations deep).

The power of the relative positioning model is that no child has to be aware of its parent's positioning. Child elements can be blissfully unaware. The difficulty comes in when there are issues/inconsistencies (ie as has happened a lot with browser inconsistencies in the past). Then you'll have to crawl back up the tree one element at a time until you can determine the one causing the trouble.

Fortunately, with tools like FireBug and Google Chrome Developer Tools, it's really easy to crawl through the tree and visualize the layout boxes, padding, margins, etc interact with each other.

Unfortunately, once you adopt a relational model it becomes really difficult to design a typical drag-drop GUI builder tool so most relational GUI development happens in code only. Maybe that will change in the near/distant future.

Note: For completeness sake, I feel like I should also mention the fixed positioning model. It's basically the same as absolute positioning but it is not affected by scrolling. That's how those annoying toolbars that stick to the bottom/side of the page are created on most websites.

Improve this answer
2
  • "Relational display model" is a tolerably good general term. I've always called the things "panel-based layout systems," probably because I've done form layouts in half a dozen different systems but never in HTML :)
    – mjfgates
    Commented Apr 8, 2012 at 9:46
  • @mjfgates IMHO, you should definitely try HTML/CSS then; even if only for learning/experimentation. Desktop platforms are starting to pick up the HTML/CSS style of layout more and more because it works well. For instance, QML and WPF. The combo of a declarative syntax and a powerful/flexible layout model is something desktop development has been lacking all along. Plus, with a simple declarative layout language, you can hire designers that specialize in the look-and-feel while developers are allowed to focus exclusively on the plumbing.
    – Evan Plaice
    Commented Apr 8, 2012 at 19:01
3

I usually see it called something similar to a container hierarchy, with the 'controls' being called widgets.

Improve this answer
2
  • "Container hierarchy" is a good description of the thing that this pattern <i>produces</i>... an instance of the result of using an implementation of the pattern, if you get what I mean.
    – mjfgates
    Commented Apr 6, 2012 at 19:51
  • All of the examples you've given have a view hierarchy where you have a simple understanding of what a view component is and then you have additional generic or ad-hoc components built on top of it. The fact that you have a view hierarchy would suggest that that is the pattern itself and not merely some product of it's use.
    – Filip Dupanović
    Commented Apr 7, 2012 at 13:57
1

The generic term for such a tool is "GUI Builder". As you've clearly noted, that these tools can range from being completely drag-n-drop WYSIWYG, to something that is more expert-programmer oriented, where the design approach isn't exactly WYSIWYG, but represented using a hierarchical relationship of bunch of widgets (example XUL) in a more textual / programmatic form.

Improve this answer
1
  • GUI builders are not really related to this. There are plenty of those that use the "position your controls at fixed x,y coordinates" kind of layout system.
    – mjfgates
    Commented Apr 6, 2012 at 20:03
1

You described it yourself in the question:

Define the layout of your UI by creating a tree of panels. The leaf nodes on the tree are what we used to call 'controls' way back in the day

I've always called it variations of: "tree layout", "tree hierarchy [of UI controls/widgets]", and so on. Sometimes I have to specify "variable-width" since binary trees tend to be what pop into mind, but "tree" applies well in general.

Improve this answer
0

A website wireframe is a visual guide that represents the skeletal framework of a website. The wireframe depicts the page layout or arrangement of the website’s content, including interface elements and navigational systems, and how they work together. http://en.wikipedia.org/wiki/Website_wireframe

Improve this answer
0

I would call it declarative definition. (ie you define 'what' the UI looks like, not the steps of 'how' to draw it).

The UI may be defined as a tree, but that is because the UI is a tree by it's own nature. The UI would still be a tree if defined in an imperative way with pointers to parent/child objects. I think declarative versus imperative is what matters.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.