The Layout Conundrum

When laying out an application’s elements there are 2 possible ways that you could approach it

Poster-style, where you meticulously place the pieces together spatially, relating each element to the other by color, size, shape and placement.
Or the algorithmic approach, where a routine ‘tiles’ elements together within a view. The elements attributes are related to each other by a simple set of rules and are thus placed accordingly.

Both views are correct, each useful within it’s own domain. A generic algorithmic approach to layout routines is always useful when you have a file manager navigating through various layers of data and files. Take for example Microsoft’s Explorer. The ‘views’ are themselves simple layout algorithms. The various layouts are ‘List’ view, ‘Thumbnail’ view, ‘Details’ view, etc…

However the algorithmic approach is a very poor tool for laying out an application interface (or even a simple dialog box). It is akin to force-feeding a round peg through a square hole. This challenge is seen as a wonderful exercise for the software ‘engineers’ (problem solvers by nature) but is seen as a risky proposition by software managers. Anything not previously solved or designed (algorithmically) always introduces some element of risk to the project.

Layout managers handle only 10% of all layout requirements (listboxes, tables, file managers etc…). But what about the remaining 90% (dialogs, main views, side bars etc…). Currently the majority of developers are either to forced to fit round pegs through square holes or recode the layout routines by hand when resizing, reordering, adding or removing controls within a panel.

Three basic metaphors greatly simplify this layout process: containers, anchors and attachments. ‘Containers’ are already being widely used within the software development community; ‘Anchors and attachments’ however still have not caught on yet in any significant manner within today’s frameworks.

Designers need to be able to adjust individual controls, placing, anchoring and attaching them its parent (or sibling) panel. Whenever the parent panel is resized or relocated, so will their children be adjusted accordingly, based on which anchors and attachments were used. There are 3 basic layout metaphors that could encompass almost all layout routines in use today. From resizing dialogs to attachments within collapsible menus.

It is the process of embedding one control within another. The clipping, placement, visibility and enabling of the ‘contained’ controls are now managed to a certain degree by the root container. This method of managing controls has been around for the past 20 years and is currently widely used among today’s software platforms.

This is the process of ‘anchoring’ a child control to its parent control. There are 4 sides that can get anchored, left, top, right and bottom. If the sides are anchored to its parent then resizing the parent directly affects the children controls. This is a very powerful idiom that is currently not incorporated into today’s major frameworks. (read more)

A control can be attached to another control either by location or size. Whenever the main control changes location, the ‘attached’ control is sure to follow. This change can either be of location or size, and the ‘attached’ control can respond either by resizing or relocating. This is idiom is also a non-standard in today’s UI frameworks and in some cases available only as a third party plug-in. (read more)

Bambookit 2.0 incorporates all the above layout metaphors within its framework, exposed via its XML interface. This is a powerful and simple way of managing layout within an application. Ease of use is paramount to allowing developers to create complex, flexible and robust layouts for today’s applications. Otherwise with complexity of design comes rigid or inflexible designs, bloated code and delayed release dates.