Sbktech

I did some poking around how Flipboard lays out content, and here are my observations.

1. The portrait and landscape layouts are identical -- the internal content of an article reflows when the orientation flips, but the overall article layout remains exactly the same. So in the rest of this, I'll only refer to the portrait orientation.
2. The layout process is almost certainly "recursive rectangle cutting" rather than packing a set of rectangles. In other words, start with a big rectangle, then make a complete cut horizontally or vertically, and recursively cut each smaller rectangle. The tell-tale sign of such a process is you never see a layout like on the right. Ie, there is always at least one cut that goes from one side of the rectangle being cut to its opposite side, and so on, recursively.
3. You can therefore associate a "cut tree" with any layout, where each node represents a cut -- horizontal or vertical -- and is labelled with the location of the cut position(s). The choice of cutting positions are heuristics, and Flipboard's approach seems to be to pick small integer ratios of the parent.
   If you ignore "dual" ratios (eg: 1/3 and 2/3 would be duals of each other) Flipboard picks cut positions that are located 1/2, 1/3, 1/4, 2/5, and 3/8 of the parent. Which one to pick at any step is possibly a combination of how large the content is, and some randomization.

For example, this layout: corresponds to this cut tree. There are very likely more constraints in use, for example vertical cuts never use the 1/4 ratio, and further, a "vertical cut node" avoids vertical cut children in its subtree. For instance, a layout that has a root vertical cut (so it goes from top to bottom) never has any other vertical cuts. There can of course also be more than one cut tree that produces the same layout -- eg: a layout that's divided into four equal-sized quadrants has two equivalent cut trees, depending on whether you start with a horizontal or a vertical cut.

That said, there's more than one way to approach the problem, and it can be useful to understand the underlying design goals, rather than view it as purely a problem of "packing" content. (Example via Gridness)

Many modern designers and magazines layout content within a grid, and you can see an example about the underlying ideas here.

In essense, the page is divided into a grid that resembles a checkerboard, and each element of interest is reflowed into a contiguous subset of blocks. The intent is to establish a visual structure to the content, which the grid helps to maintain. Whitespace is often just as important as content, and eventually each grid block ends up being either used as content or whitespace. (This is often overlooked in many "packing" approaches to layout, though you may be able to incorporate it as "blank content" to be packed along with everything else.)

Being aware of an underlying grid can potentially simplify algorithms as well as allowing internal content to settle along grid lines. A fairly basic approach can still use rectangle cutting, but just select one of the grid lines at each cut (rather than ratios of the parent, as Flipboard does.) It can also allow you on occasion, to create non-rectangular areas, especially with reflowable content. For example, you may be able to subtract a set of blocks out of an enclosing rectangular set, to add related content, and so on. You can see it in the pullquotes in this example from the Behance Network.

I spent a couple of weekends playing with a simple scheme-ish interpreter in Flex, you can see the results below.

Click the Scheme! button to open up a console, click on the Eval button in the console to do some simple calls into flex.

It's not really scheme, and it's pretty crude -- but it has enough (lambdas and static scoped ariables) that you can do a reasonable amount of flex prototyping, or "within-app-extensions" fairly comfortably. Always assuming that you find scheme comfortable, but that's another story...

I've used a subset of Javadot notation to call objects and methods within flex. So for instance, if you want to reposition the button, you can simply eval

(.y$ my-button 200)

which is the notation to set a property on an instance. To call a method, you provide the method followed by the object. For example, the underlying canvas in the app is referenced by the variable workspace, so to add a new child you eval

(.addChild workspace (mx.controls.ColorPicker.))

which also shows how you can make a new instance of a class (by appending a "." to the class name.)

You can also create functions that can be registered within Flex. For example, you can register a listener for click events on the button with

(.addEventListener my-button "click" (lambda (event) (mx.controls.Alert.show event)))

and now clicking the button should put up an alert.

You can also load existing scheme code by using the .loadFile method in the interpreter. And As an extra bonus, I also wrote a little inspector (in Flex, not scheme) that examines variables, properties and methods in any object. To see both these things, eval

(.loadFile evaluator "http://schemeflex.googlecode.com/svn/trunk/src/scheme/util.scm")

followed by

(inspect my-button)

and you should see (rather slowly) an inspector and you can play with the various settings in the button, click on referenced objects to open new inspectors, etc. The inspector is quite inefficiently implemented, but adequate to explore some of the hidden nooks in Flex and see what they do.

A couple of magic variables: workspace is the canvas where the evaluator runs, and evaluator is a reference to the currently running interpreter object.

Get the source code here Enjoy!