Thoughts on layout


This topic overviews our thinking on layout engines.
It should convey at a high level our intent and vision, and explain why we are pursuing (or not pursuing) specific features in the layout engine.
I'll keep this topic up to date with our thinking.

Goals / tradeoffs

Digital products must render across a wide variety of device sizes.
But designing for multiple sizes in print-lineage graphic design tools is a tedious, error prone, manual process.
As such, an automated layout engine is a core differentiating feature of Subform.

The goals of the layout engine are:

  • Better responsive designs: The engine should allow designers to quickly explore the consequences of design decisions across different sizes. It should reduce "iteration time" caused by, e.g., handing off a preliminary design to devs, waiting for a prototype, and seeing responsive consequences days or weeks later.

  • Reduced time pixel-pushing: The engine should enable designers to build necessary comps faster than print-lineage tools. Time spent pushing pixels should be reduced in favor of high-value design activities (clarifying requirements, user testing, etc.).

  • Streamlined communication: The engine should unambiguously capture responsive design intent, and convey that intent to developers and other stakeholders. Subform's layout engine should be able to reduce designer/developer back-and-forth re: "what is supposed to happen at size X?" (Imagine if design tools only worked in black and white, and all color decisions needed to be communicated in redlines or over Slack.)

These goals form a framework by which a layout engine can be evaluated.

We should also evaluate possible solutions with an eye towards their downsides:

  • Unfamiliar: Some designers have never used automatic layout systems and may have a hard time learning one without extensive tutorials/documentation. Can the engine be learned in a reasonable amount of time/effort?

  • Different: Some designers are used to other layout systems (e.g., HTML+CSS). Shared terminology may interfere with understanding if the semantics are different. (E.g., "padding" or "borders" may behave differently in Subform than in CSS). Inherent capability differences may also lead to implementation troubles (Can you design a layout in Subform that cannot be built easily on web or iOS? Should you be able to?)

  • Limited designs: Tools influence work in a Sapir Whorf sort of way. Will Subform push everyone into designing simple rectangular things? (Or is this already the case, regardless of Subform, given the Cartesian bias of typical implementation media and, for that matter, written human languages?)

With these goals and downsides in mind, lets look at a few principles to guide our thinking.


Designers should be able to fully internalize the layout semantics

It's crucial that we understand our tools so that we can work quickly and confidently.
Part of that responsibility is on us to put in a few hours of deliberate study and practice.
But the rest falls on the tool designer (yours truly) to build something comprehensible.

My goal is to minimize "I didn't know you could do that" and "wait, what is going on here?"

Subform's layout semantics should be similar to the target medium

The design intent captured by Subform should be translatable by developers into the final implementation media (web, iOS, Android, etc.)
This is why, for example, the layout engine is built on hierarchical relationships along the horizontal and vertical directions rather than, say, polar coordinates or parametric differential equations --- because the web, iOS, and Android all use hierarchical, horizontal/vertical layout systems.

However, Subform will not have a 1:1 correspondence to any other layout system --- it is not an IDE for HTML/CSS, iOS, or Android.

As such, the limitations of some media shouldn't restrict Subform's expressiveness.
There is value in allowing designers to express "unbuildable" ideas.
If Subform captures that intent clearly, developers are in a better position to consider implementing it.
(Of course, if they can't, they should communicate with their designers: "Please stop with the multiple borders --- we can't do that in CSS.")

Features should be required to design and communicate a product idea

Each feature of Subform should be justified by the need to design/communicate a particular product idea.
E.g., percentage values are justified because designers need a mechanism to design/communicate the idea that a child's size is proportional to their parent's.

Conversely, if a feature does not meet a specific need --- or if that need can be met by other features --- then it should not be included in Subform.

The need to hide/show specific elements at different artboard sizes, for example, does not imply that Subform needs "breakpoints", as one can design and communicate this using multiple artboards containing shared components.

Full fidelity is a trap

There are some matters of fidelity --- pixel-perfect positioning, millisecond animation timing, full network/data behavior, etc. --- which cannot be captured by a design tool without effectively becoming an IDE and transforming the designer into a developer.

Designers must acknowledge this fact and understand the level of fidelity beyond which they must work closely with developers on actual prototypes in the target medium.

All design tools exist to serve the final product.
The artifacts created by design tools shouldn't be confused with (or be an unnecessary facsimile of) the product.
Forgetting this is akin to working obsessively on slides at the expense of the presentation.

As such, Subform will not attempt to reach "full fidelity" for any medium.

Any tool that promises such fidelity (either explicitly or implicitly via certain features) encourages designers to stay within the familiar (their tool) to the detriment of their responsibility to maintain design integrity across the actual production workflow.

Open questions

Can "layout" be fully separated from "styles"?

If they are fully separate, then semantics are smaller, which enables both better understanding as well as performance benefits (e.g., repainting styles can be done faster if it is known that styles cannot affect layout).

However, there are arguments to let some styles affect layout.
E.g., borders:

What other conceivable style properties could/should affect layout?

What are the mechanisms for reusing / composing "layout" properties?

Should layout properties be sharable?
If so, should that reuse occur via existing mechanisms (e.g., classes) or a new one (variables?)?

Given that an element can have multiple classes, how should layout properties combine?
Should it be "last class wins" (as it is now, for style properties), or should they merge piecewise, allowing, say, a height defined on one class and width defined on another?

What element size constraints are necessary?

The layout engine will likely support min/max width and height, which override the general width/height (e.g., "max-width" overrides "width").

Are there other size constraints that we should consider.
Say, "aspect ratio"?

What are the necessary "casual directions" of layout?

I feel that Subform needs three:

  • top-down (child is 50% as wide as the parent)
  • bottom-up (parent is as wide as the sum of all of its children)
  • sibling (elements expand or position themselves to share space within their parent)

Having three directions complicates the semantics, but I feel that this complexity is inherent in responsive design --- removing one would unreasonably limit the expressiveness of the engine.

How do we avoid undefined configurations?

With three casual directions, it's possible to run into undefined situations.
For example, what happens when a child with 50% width (top-down causality) is underneath a parent with an "auto" width (bottom-up causality).

Together these constraints don't make sense, they're "undefined".

Note that ill-defined constraints can occur even within an element.
For example, "width" and "aspect ratio" fully constrain "height", so an element that has all three values set is overdetermined and its layout undefined.

Should we allow people to get into such situations?
Or is it possible to keep them out of trouble?

Possible solution: UI control validation

Can we prevent undefined configurations by having the UI reject input values?
E.g., a parent's width input box would refuse an "auto" value when one of the children has a percentage width/height.

I don't think this solution will work, for two reasons:

  • we may want to define layout to via composition (of components, classes, etc.), and so there may not always be a single UI input that can reject invalid inputs --- we'd also need UI to reject the addition or removal of classes, check interpolated variable values (if we support variables), etc.

  • in addition to property setting, topological changes can also lead to undefined situations, so we'd also need to design a "reject" UI for operations like tree dragging (to prevent an element w/ 50% width from being dragged into an auto-width parent), for placing new component instances, hotkeys that affect element topology, etc.

Said another way, Subform UI offers many expressive and powerful operations, and ensuring that all of them can "reject" undefined layouts would complicate both the technical implementation as well as the conceptual overhead when using them.
Furthermore, even if we could reliably prevent undefined layouts via UI checks, we still need to explain to the user why they cannot input a value or drag an element, as such operations are usually allowed.

Possible solution: limit constraints to an orthogonal set (just width and height, or just width and aspect ratio).
This may work for overdetermined constraints for a single element, but it's not obvious that it can solve issues within relationships between elements.

Even if it could, limiting the constraint set limits Subform's ability to capture design intent.
If the designer wants to sometimes constrain an "aspect ratio" and other times constrain "height", it is better to let them use the constraint that best captures their intent.

Possible solution: prioritize constraints relative to each other.

Priorities are clear in some situations (max-width should take precedence over width), but not all (When width, height, and aspect ratio conflict, which one is ignored?)

If there's no "obvious" priority order, then any order will be arbitrary, and requiring that designers memorize an arbitrary order would be hostile.

There's an analog here with arithmetic: The "order of operations" is a band-aid on the shortcomings of infix notation --- a better solution is fixed-arity prefix (Polish) or parenthesized notation that eliminates ambiguity without imposing a cognitive tax.

Possible solution: allow, but draw attention to undefined layouts

If Subform cannot prevent undefined situations, then it should ensure that users notice, understand, and resolve them.

For example, A warning icon on undefined elements in the tree could be coupled with a popover that explains the situation: "Box 32 has a percentage width, but its parent has an auto width --- set an explicit width on the parent or non-percentage width on Box 32 to resolve."

How should Subform tolerate undefined situations?
Should the undefined elements be rendered somehow, or should they be hidden?
Should artboards containing undefined layouts be drawn or grayed-out?

If Subform is too lenient, it risks sending trouble downstream (e.g., developers are given an exported style guide w/ undefined layouts).
But if Subform is too strict (forcing people to complete a "resolve all ambiguity" 110-step wizard, refusing to save files with undefined layouts, etc), it will aggravate designers and they will curse my name.

Analogous situations: Dynamically checked vs. statically checked programming language type systems; using text editors on code rather than AST-aware, every-transformation-is-valid editors

What about breakpoints?

Breakpoints (CSS rules that apply only under certain viewport conditions) are a CSS feature.
But what is the need that breakpoints address?

  • To conserve bandwidth by allowing the same HTML markup to encode several different visual designs? If so, that's a platform implementation need, not a design one.

  • To allow a team to assert a consistent identity across something that varies greatly between manifestations? E.g., that the app "homescreen" on a smart watch is the same "homescreen" on a large tablet. If so, what does this consistent identity accomplish? When do the designs diverge enough to be considered two separate entities, "the watch homescreen" and "the tablet homescreen"?

  • To allow anonymous or "local" reuse? E.g., for some elements that only appear on the "homescreen", is it preferrable to reuse them across watch and tablet by keeping them under "the same" artboard rather than reifying those elements as reusable components?

Regardless of the underlying need, if breakpoints are implemented like they are in CSS, we should consider the implications:

  • Breakpoints conceal intent: Artboards cannot be taken "at face value", since any change in size could yield a radically different apperance.

  • Communication w/ developers: Are developers expected to understand the semantics of Subform's breakpoint system so they can translate it into the final medium? Or would it be easier for developers if Subform "expanded" an artboard across all of the different breakpoints, showing concrete examples for each? If the latter, what is the advantage of breakpoints vs. letting the designer specify the examples as distinct artboards?

Analogous situation:
My take is that CSS-like breakpoints have more tradeoffs then benefits.
They remind me of implementation inheritance in OO-languages: great for simple examples, shitshow in practice.
Breakpoints would complicate both Subform's UI and the underlying semantics.
This complication would bleed into designer/developer communications, without adding capabilities beyond Subform's existing mechanisms for reuse (style classes, components, etc.)

I'm curious to hear about needs that are better solved by breakpoints than by, say, duplicating and customizing individual artboards.

Wrapping objects
Trigger words for sizing

Thanks for sharing the thought process you have both been going through for this. I've been continuing my exploration into layouts based off relative typographic units and have gotten pretty far.

This is also another good read It points out that designing purely with viewport dimensions in mind doesn't achieve what we may think it does. So when designing for TV on the web it will be necessary to use the TV media query. I am quite happy to use separate artboards for different screen sizes and media. Perhaps a way to obtain media queries without hiding intent would be to constrain the max and min dimensions of artboards then linking/swapping artboards when doing live preview such as rotating an iPad.

I'm very interested in repositioning of elements similar to flex-wrap. I reach for this quite a lot and it keeps the need for breakpoints down significantly for me.

There is a lot to think about and that's all I can add for now.


Thanks for sharing your thoughts on this, guys.

It's a really interesting problem space, and one that I have found myself navigating for many years, having worked variously in HTML/CSS on the web, WPF/XAML/Silverlight for apps, and -- of course -- the traditional world of print-oriented design tools that still dictates most designers' thinking today.

I think you're right not to aim for 100% "fidelity" to any given medium. There are just some inherent foibles/edge cases in the various media that make such a goal unattainable so long as you wish to remain platform-agnostic. That said, I think it would be worthwhile to put a stake in the ground and look at the layout models of the common target media.

In every case, I think there's a good argument for pursuing what you call the "top-down" layout paradigm -- that is, where the parent exerts a strong/opinionated influence over the layout of its children. I firmly believe that having a small collection of container 'types' with very specific, learnable layout rules would be the best route forward, as opposed to the current "Freeform/Computed" layout switching on child elements themselves.

I also believe you should have, as part of your vision, the expectation that designers are EXPECTED to learn or adjust their mental models somewhat. While designers shouldn't need to learn the (horrendously complex) syntax of something like Flexbox, I do think that some level of mindset change should absolutely be expected as designers become aware of the relationship between parent containers and their children. Making this simple and fully 'internalizable' ought to be your goal in designing Subform, in my opinion.

If you were to strongly pursue this "top-down" approach as the primary layout mentality for Subform, then I can see a small selection of container layout types covering pretty much every conceivable use case...

Children stack up horizontally or vertically within their container. Surely a strong contender for many, many application UI’s that will for now and forever more have strong needs for lists of stuff. Children could exert a fixed or automatic (content-based) width/height in the cross-axis, or be set to span 100% of the height/width of the parent container.

Children line up in a row (or column) and wrap onto subsequent rows (or columns). By definition, this means all child items must have fixed or automatic (content-based) width/height. Like a WrapPanel in XAML or a FlexBox with flex-wrap enabled in CSS. Reflowing lists

Children are placed in cells within a grid-based parent that is made of rows and columns. Cells in the parent can be merged/spanned across multiple rows/columns. Nothing new here… It’s HTML tables, CSS Grid layouts, and XAML Grids all over again. To me, this is a no brainer. Even though this could be considered ‘redundant’ in that much the same effect can be achieved with other layout tools, I do believe the grid remains the best all-rounder in terms of a layout paradigm that is both flexible and easily understandable. Web designers/developers did all that horribly non-semantic HTML table-based layout stuff back in the day for a good reason – because it was incredibly simple and flexible to learn and use. CSS Grid, when if finally takes off, promises to bring much of this layout power back into play without the need for the horrible HTML markup.

Children stick to the top, bottom, left or right of their parent container. End of story. While this may be somewhat redundant is this could possibly be achieved via other methods, I would argue that docking UI elements to one edge of their parent is now and will ever be a common and desirable use case so long as screens are rectangular and so long as ‘lining stuff up’ remains a visually-desirable thing to do.

Children “do what they want”. Basically, this is the ‘exit route’ for any designer who really doesn’t want to use any form of box-model type layout. To me, this ought to be a low priority as this is the world of Photoshop and Illustrator and all the rest of those previous-generation tools. That said, I can see this being expected by some folks and would ‘round out’ the overall set of layout types.

Anyway, I'm sure you've given this much thought, and maybe my opinions here don't align (pardon the pun) with your own... However, having been in this realm for many years, and as a person who has been longing, begging, hoping for someone to come along and create a solid, layout-aware UI design tool, I thought I'd share my opinion.

Hope this helps.

2017.01.02 Status update
2017.07.17 Subform release 3338

@andy.thelwell Excellent post. That should cover the current responsive, data-driven requirements for layout on 2D digital screens.

The next level in my mind would be to have meta-level control over the elements, to reorder a layout on the fly without having to re-populate or re-assign all the content blocks to fit. My main problem for example is not the creation of one layout but the rapid iteration and testing of what works in a specific case.

It's interesting to think about the incredibly creative flash layouts back in the days of theFWA, that is the only style of layout that comes to my mind that did not conform to any standards at all. 2advanced, derBauer,; basically any site where you entered a whole new world.


Hey David.

Totally agree. Definitely not wanting to limit your thinking / vision too much as no doubt there's plenty room for exploring a tool to allow super-creative, freeform, non-conventional layouts. That said, I firmly believe that there's gold to be had in nailing a conventional box-model-based UI layout tool in a way that is both 'familiar' to designers, while 'close enough' to the internal models of the major delivery mediums. When I see the amount of back-flipping excitement the community pours out for a rudimentary Sketch plugin that allows designers to 'kind of' simulate constrained layout, it leaves me nothing short of confounded. Of course, you know this already.

If, as I hope you will, you pursue a top-down, 'opinionated parent' paradigm, then I would hypothesise that you could do some clever stuff around best-guessing -- and/or providing alternative options -- when the designer wants to experimentally switch from one layout type to another. That is, don't just switch to some fixed default when switching layout types, but do something smarter. Not sure exactly what that would look like, but hopefully you get my gist.

Still, I'm probably getting ahead of myself and as a good Agile-trained UX/product guy, I know that's getting into the far-off realms. I wish you the best of luck in whatever direction you choose with your re-write of the layout engine. I will be watching, trying things out, and more than happy to weigh in with my opinions (I'm never short of those) :slight_smile:


So you decided to build a bridge.

Question Group 1

  • Is this bridge connecting two entities that previously were unconnected?
  • Is this bridge merely offering a more convenient route between two entities?
  • Is this bridge connecting two entities whose worlds will both be unequivocally improved by the existence of this bridge?

My 2 cents:
No. Potentially. It better.

Question group 2

  • When this bridge is complete, how many other bridges will exist that offer a similar or more convenient connection between the two entities?
  • When this bridge is complete, will there remain a need for these two entities to even communicate?
  • When this bridge is complete, will either entity be daring enough to cross it?

My 2 cents:
Hundreds. Yes, more than ever. If it can successfully deliver on item 3 in Agenda item 1, then yes.

One last question

  • Will this bridge require any sort of modification to the mental model of those intending to cross the bridge?

My 2 cents:
It appears so, though I hope not too much.

What I meant by all that

  • A layout engine sounds like a game-changer for design professionals working today [keyword: today]. But others have built or are building them now and will release them before Subform is ready, to potentially massive audiences using existing products. Therefore, a bar may be set that 'the layout engine came for free'.
  • The stated goal here is to ease the communication burden that currently exists between designers and...developers, sure, but also everyone else building a product that may not see themselves as a designer. Most designers have one or more tools. But what about those that are just starting to become designers and haven't decided on their tool? Should we focus on convincing seasoned designers to take up even one more tool, or should we design something that makes the practice of design more accessible to everyone else on the team that deserves to have their intent represented? I think we need more and better designers. Subform could be what designers and not-yet-designers alike been searching for.
  • Designers already have enough layout engines to learn, battle, overcome, and be horribly surprised by. They exist in browsers, in operating systems, and soon in places we never thought possible. Designers are not seeking yet another layout engine to fuss with. So, I agree, it better be intuitive, but not after hours or days...after seconds. Because by the time Subform is released, chances are good that there will be more reasons not to add Subform to a tool belt.

I'm excited. But I also acknowledge that what we are building must appeal to the most self-righteous of human beings

We are Designers. We cannot be held back by layout engines or any other sorts of constraints that may even slightly impose on our creative genius. Because we are paid for our ideas. And if we have to spend even a second thinking about how a tool works where we could have spent a second naturally using a tool to convey our design intent to others, then it will be that much harder to convince us to use (or keep trying to use) that tool.

I'm committed to ensuring that the layout engine that Kevin and Ryan intend to build is the best that it can be. And I know you both understand what is at stake if you get it right or wrong. I also think you both understand why so many other design tools have foregone a layout engine in favor of freeform manipulation.

It's incredibly difficult to design for the future, let alone understand the future problems we are designing for. But that is exactly what we must do.

You have decided that a layout engine is the solution to a very real design problem. I look forward to more posts and conversations about what led you to make that decision, and what other decisions you have made about several other design problems not currently being solved by the various tools available today.

I plan to share my ideas over time, and hope the creators and the community will weigh in.

Those are my initial thoughts on a layout engine and on the market you are designing for.


"Intuitive" comes up in design discussion a lot—and I think it's a dangerous word. I want to talk briefly about it, as it relates to designing products in general, and in feedback for Subform specifically.

  • The very definition of the term is unclear. If we assume that intuition roughly means "something that is known or understood without proof or evidence" — what does that mean for a product? It implies that the production would be unconsciously usable, with no learning or knowledge required. That's clearly not the case for most (if not all) products. So what are we aiming for? Do we really mean "easy-to-use?" Or is it "easy-to-learn?"

  • There is no universal intuition. Instinctive behavior varies across experience, culture, language, geography, &c. One person's "intuitive" product is an impenetrable wall to another person.

  • Without specifics, it's not an actionable criticism. Because there is no universal intuition, it doesn't serve well as a design constraint. "It should be intuitive" — For whom? In what manner?

  • Prioritizing ease-of-use often comes at the expensive of productivity/power. Douglas Engelbart would use the analogy of a tricycle vs. a bicycle:

(If you're interested in this topic, this 99% Invisible episode is a good place to start. And I'd also recommend reading some of Engelbart's writings.)

With Subform, Kevin and I are interested in developing a learnable tool aimed at expert users. The most powerful tools come with a bit of inherent complexity. You don't just walk into a metal shop and start pushing buttons on a CNC milling machine. But what a milling machine enables you to create is transformational. It's worth the time investment to learn.

All this said, I absolutely think that Subform can improve quite a bit in terms of learnability. (And we've gotten a lot of great feedback to that point) But I think it's important to keep in mind that learnability is not always the same thing as ease-of-use. And valuing the latter above all else often does not push our tools forward.

Scrubbing numbers!

This 'expert users' part concerns me most.

After reading this highly enlightening article titled The Languages Which Almost Were CSS, my biggest takeaway was this short passage:

Compared to many of the other proposals, one notable fact of CSS is its simplicity. It can be easily parsed, easily written, and easily read. As with many other examples over the history of the Internet, it was the technology which was easiest for a beginner to pick up which won, rather than those which were most powerful for an expert.

I don't apologize for using the word 'intuitive' in my reply. In fact, I stand by it, but under this exact definition, proposed by the wonderful Joe Natoli in his PDF, 10 Commandments of UI Design [Specifically on pages 3-5]

What intuitive does mean is that when something is designed well, in an intuitive manner, we catch on pretty quick — and one time is all it takes. Do it once, remember it forever. Intuitive interfaces share 4 main characteristics: control, consistency, context, corroboration

The expert users you seek are already using a slew of other tools. I realize many of them helped fund this project, and while I'm no expert, I am certainly one of the thousand people who think Subform has great potential as the tool that can help designers more effectively convey their intent to those willing to receive it. My point is that it may take a world of hurt just to convince the people you consider expert users to give this tool a chance, let alone have the patience to learn it.

However, if we build something in the vein of CSS - that may or may not have intentionally been designed with inclusion in mind, but certainly found widespread adoption almost certainly for that very reason - then we are far more likely to capture the hearts of far more (if not all) designers and through learnability and ease-of-use quickly transform them into experts that still find immense value in our product.


@rmion I agree with what you are saying regarding it being intuitive. I think both is possible, a tool can be for experts and still be intuitive. CAD programs from experience require quite a bit of getting to know how they work because there is a lot to them. But once you learn one it is quite quick to pick up another.

However I think CSS won mostly because the limited media didn't require advanced layout functionality. Layouts are growing in complexity which is requiring more advanced CSS functionality and hackier tricks to make it work.

@Ryan have you seen this? they are creating way to style websites based on constraints and then will be working on a way to generate CSS from it so it can work with static site generators instead of being purely ran in JS. Edit: This project is dead. I should have investigated further before sharing


Thanks @kevin for detailing all this thinking out. The goals/tradeoffs and principles establish a strong framework for this discussion. @Ryan the tricycle/bicycle analogy is excellent.

Undefined Configurations
I'm in favor of allowing people to get into some difficult situations if it allows designers to meaningfully push the limits of what's buildable. I'm interested in the exploration of a solution where Subform prioritizes a constraint while making the other possibilities available. Perhaps the history is flagged when Subform makes a choice that resolves an ambiguity but the alternatives are accessible from the history. There may be problems in generating and displaying the possibilities for resolving an ambiguity. Presenting options in the history changes its purpose but is less annoying than being presented with a modal every time you drag a box around in the tree.

I've never had to spend much time thinking about breakpoints. It sounds like they are a method of developing. If so, what are the alternative methods? I'm sure one alternative is to have a single design that can flex to any size (a single box of text, maybe) but we know that's limiting. Can different sets of HTML be loaded for different viewport sizes?

Intuitive Design
@rmion Does this definition mean there exist computers that elderly people can use and rely on? Please point me to one - my grandmother could really use it.


@Wade I appreciate you agreeing.

To clarify a bit, I'm trying to say that what will make a product like Subform successful is its ability to conform well enough to targeted users' mental models of how comparable tools function, while simultaneously teaching users how to successfully use the new layout engine in a way that not only starts to feel comfortable after a single try, but quickly enables users to feel like experts. This is no small task, and I'm sure the creators are aware of the challenge.

Regarding your comment on CSS, I disagree. Layout was not something CSS sought to solve. Applying presentation styles to HTML elements was. And of all the languages at the time that tried to solve that problem, CSS was the easiest to parse, write and read. So it won over developers AND designers AND likely other members of web projects.

@nicki I'd argue yes. I appreciate your sarcasm, trust me, but allow me to clarify. Most computers are internet-enabled, and are therefore capable of connecting to the web through a browser. As long as your grandmother is capable of using an input device that the computer's browser recognizes and your grandmother is directed towards a website that complies with ADA WCAG 2.0 Level A, AA, or AAA standards, then she should become gradually more successful with continued use of that website and hopefully the computer itself.

Therefore, I'd argue that there are several potential reasons why your grandmother may not yet have discovered the ability to use and rely on computers. It's certainly possible, though, and is highly likely to involve intuitive design.

Removing the text/dataset system

@Ryan For what it's worth I am with Ryan on this. The fact that all the other tools conform to a standard behavior is exactly what excites me about the layout power of subform. I don't want another Fireworks clone or InDesign clone or Quark Clone - I want something that understands layouts on the web are calculated and programmatic. Since we are throwing around quotes, I don't want a faster horse - I want a car.


Thanks for the long writeup @andy.thelwell, I'm interested in your perspective as someone who has worked with several layout systems.

Can you elaborate on this?
A strict "top-down" approach makes my life as an implementor easier, but it's too restrictive: There are plenty of layout problems where you want to to make a container that takes the size of its contents (a button containing text, a drop down menu containing several items, etc.)
You can't accomplish this unless you also allow "bottom-up" causality, no?

Right now we have just two kinds of elements: boxes, which can have children, and variants (text), which can't.
(Component instances are just an indirection to a state's box.)
"Freeform" and "Computed" are two layout modes, which affect both the element's size and position within its parent.

It sounds like you are proposing that we get rid of the generic "box" and instead have different types of boxes: "box with stacked children", "box with wrapped children", etc.

So, rather than have layout modes that you can switch between, you can only choose the layout once, at construction time when you pick the "type" of box to create.
Then, the layout of each child is determined according to both the parent's type and the child's type.

One advantage of this scheme is that the UI can be simplified in many cases.
E.g., if you have a "Grid Box" then you don't need to have any controls regarding wrapping.

Of course, this can also be a disadvantage since designers may not understand why a control is missing.
("I could have sworn the wrapping controls lived over here...")

Another disadvantage --- if I understand the proposal correctly --- is the layout semantics are defined across all typed parent/child combinations.
So if you have 5 types, you have 25 possible layout semantics, one for each parent > child type combination.

Even if those semantics are just "you can't do this" (as in your example where a "Wrap" parent must have children with fixed or automatic width/height only), it still puts a burden on the designer --- they must remember what parent > child combinations are allowed and which are not.
This also opens up a big can of worms with components, since instances would occur across different layout "contexts" (this issue has already come up with flex direction).

I'm definitely interested in this approach, as it's a very different direction compared to what I've been thinking about (getting rid of the two modes).
I'd love to hear more or see pointers to systems with this approach.
I know Unity has typed containers like this, but I haven't used it extensively.

2016.12.19 Status update