Coordinate Versus Nested Gui

GUI systems seem to use two different positioning systems: coordinate-based and nested.

The coordinate approach seems to lend itself to better visual positioning (WYSIWYG), while nesting seems to be more conducive to re-sized screens. I think coordinate-based approaches better fit corporate culture because you can make it very close to how the customer or boss wants it. Plus, nesting often creates surprises when things don't wrap as anticipated.

Examples of coordinate-based GUI: VisualStudio (VisualBasic, VisualCee?), Delphi

Examples of nested GUI: JavaAwt and JavaSwing using LayoutManagers, MozillaXul, HTML tables with no height or width attribute, TclTk, GTK+, Qt.

Meldings of the two: Apple's InterfaceBuilder, SpringsAndStruts, Java EclipseIde Visual Editor.

CSS doesn't really fall into either category, does it? Most of its work is done without explicit coordinates... of course I refer only to pure HTML with CSS here; Javascript muddies things.

CSS falls into the melding category IMO. (is that what you said?) normally it's nested, but specifying <tt>position:relative</tt> or <tt>position:fixed</tt> turns it into a coordinates based system for that element, with its descendents being nested.

Be aware that this title seems to present a FalseDichotomy. Examples of non-coordinate-based non-nested GUIs include declarative relative-layout (with statements such as 'above', 'below', 'left of', 'right of', 'behind', 'in front of', 'within', conditional appearance, etc. These are, admittedly, less common than some other systems, but they are also relational (no 'hierarchy' of rules as per nested GUI) and delightfully composable (in the sense that the 'automatic' positioning rules may be combined for AutomaticVsManualPlacement). I don't know of any frameworks for this that I haven't written myself, though.

There is also coordinate-relative, such as '5 pixels from the upper-left corner'. This isn't as composable in the sense that a composition cannot simply insert something 'between' two other display items without first explicitly moving the items around. A claim is made below that 'Nested GUIs' are often coordinate-relative in this sense.

Summary of Arguments

Advantages of Nested Gui's

Disadvantages I personally think that each has its strengths and weaknesses and each is better for different situations. Thus, ideally a GUI kit should make both available. Some GUI kits have "layout managers" that include a coordinate-based placement as one of the layout techniques for the given "panel". Generally they include at least:

The panels can be nested so that one can mix-and-match. HTML does this to some extent by mixing tables (grid) with relative placement. Each "cell" in the table is like an independent panel where you can use the (default) relative placement or define yet another table within it.

-- top

Limitations of absolute positioning are very apparent if we will try to see site like cnn.com on a screen with fine resolution and small size ( 1400x1050 on my 15 in. notebook screen ), everything looks small and makes it difficult to read and use. Sites like java.sun.com use relative positioning and fit nicely on my screen and very useful when I use Mozilla's CTRL(+) for zooming.

Coordinate-based does not necessarily preclude zooming. It may just be bad design. A good design would perhaps make it so that only ads or menus go out of direct view when zooming, not specific articles.

One of the alleged drawbacks of the coordinate approach is that things are not "grouped". In practice, I think I would rather have set-based grouping anyhow rather than nested. For example, the group that may belong to a given entity may be different from or orthogonal to the group that you want to put a square around. Hierarchies are too limited in my opinion with regard to grouping options. See LimitsOfHierarchies.

[What do you mean by this? Obviously, a logical grouping of controls doesn't necessarily (but probably should) have anything to do with how they're displayed on your screen. But when you're talking about 'layout', then of course controls have to be grouped with the box around them. Logical/programmatic grouping and layout grouping don't have to have anything to do with each other.]

That is true, but generally tools tend to assume they are the same. But if they allow/implement orthogonal grouping for non-visual stuff, then why not also allow it for visual stuff? I suspect because it requires more training to work effectively with sets than trees.

IME, the coordinate approach has a great inertia against change. Want to add a new field? Shift everything over manually, the position of every control depends on the size and position of every other controls. With nested, you just add the field and you are done.

True, but it is usually easier to find the add location to begin with with coordinates, and a good IDE usually makes it simple to select a group of widgets to move down as a group. Then again, it depends on the particular form arrangement.

(I don't know if "tab order" comes into play. If tab order allows decimals, then inserting something in between is usually not a problem. It is the integer-based tab orders which are a headache IMO.)

I assume you really mean it is easier to find the add location to begin with in the visual tool you are using, because I find that, in the source, "add(control, 123, 234)" is just as tough to find as "add(control)". If we are comparing visual tools, it is just as easy, if not easier, to find the location to add your control, at least in VAJ the last time I used it, (it list a tree view of all the controls starting from your main window, making the nesting of the controls very clear).

For complex GUI's, trees often stink IMO - LimitsOfHierarchies. For example, I often want to group, filter, or move by rather orthogonal criteria. Trees don't handle orthogonality very well.

[You're talking about your convenience at design-time vrs. functionality at run time again. Regardless, it's a functionality of a specific visual tool, not any sort of consequence of coordinate based layout]

I am not sure what you mean.

Or StructuredGraphics versus StructuredDocuments?. The former appeals to graphical artists, those with a visual orientation, the latter to textual artists, those with a language orientation.

I didn't understand the term "nested" until the examples were added. How about "flowed" instead? -- KrisJohnson

I think we're actually talking about static vs dynamic... i.e., hardcoding the relationships numerically between componenents/sizes vs dynamically assigning them through constraints of some form.

The fact that a dynamic layout is 'flowed' as opposed to 'nested' (widgets in containers in containers etc) isn't really the issue

The "HTML tables with no height or width attribute" example is what led me to believe that "flowing" is the issue rather than "nesting", as does the "when things don't wrap as anticipated" phrase in the prologue.-- kj

But if it does have height or width attributes in parts of it, is it something in-between? I am okay with "flow" if you want to change the title, but perhaps there is a non-hierarchical flow approach possible, although I cannot envision it right now.

[delete when section when forces resolved]

"Flowing" is a consequence of the second way, but not its defining characteristic. When you're discussing HTML, this tension is characterized as "visual vs. semantic." Not sure if it applies as well here. -- francis

How about 

  Flow-based: hierarchical nesting without absolute coordinates
  Coordinate-based: uses absolute coordinates
  Mixed: Uses some nesting and some absolute coordinates

It seems that there are several distinct "axes" being considered here:

Most real-world GUI systems provide some level of support for each extreme on each axis. A developer can usually make any system work any place along any of the axes, so this is not an "either-or" situation, but a "how easy is it to do what I want" situation.

While certain combinations are more useful than others, I don't think "coordinate" vs "nested" makes it very clear exactly what we are talking about. Neither does "flow" or "layout". Maybe this page needs to be split up, or maybe somebody needs to clarify what the topic is.

-- KrisJohnson

Associative layouts (most widgets layouts are determined by a relationship to a different widget), as opposed to independent layouts (where most widgets layouts are determined by a relationship to a top-level container)

I think that is the same as "absolute positioning vs. relative positioning" in the bullet list above.

What are examples of "non-numeric" and "logical coordinates"?

"Non-numeric position specifications" would be something like "to the left of object X", or "between objects X and Y", or "at the top of the window" or "half the width of the screen" (you might claim that "half" is numeric). A "logical coordinate system" is one that is not directly tied to hardware pixels; you might use percentages of window size, for example.

What about auto-generation of GUIs, such as a rule based system that generates GUIs for corresponding models? Coordinate systems can't handle that. It would then be more of Esthetic vs Model Based. Esthetic will imply the layout was based on visual appearance (a VB application where coordinates are hardcoded) and Model Based would imply that the GUI is generated from a model and comes out of the model. If your application does not auto-generate GUIs, then Flow based layout does not offer much other than resizability.

Auto-generation is usually used for preliminary arrangement in my experience. One then makes custom adjustments.

I do not mean auto-generation of code. I meant generation of GUI at run-time. -- AnonymousDonor

Users are Picky Down to the Pixel Level

I am suggesting that auto-generated GUI's are fine for prototypes, but users or customers often want to tweak stuff in ways that flow-based cannot easily handle. There are certain esthetic "rules" that a flow engine just has no clue about; perhaps because it is a subjective thing. But TheCustomerIsAlwaysRight? even if they want stupid things. In other words, coordinate-based allows you to do stupid or illogical things easier with the layout.

For example, some things might tend to almost line up out of pure coincidence. The customer looks at it and says, "could you line these up better, please?" not knowing or caring that it is just coincidence that they are almost lined up. The flow engine has no idea that a bunch of things happen to coincide in length or position. With coordinate-based, you simply shuffle things around a bit in a WYSIWYG tool to make them line up all the way. No fuss, no hassle, no NBSP-like filler things. Suppose we have some input fields with labels right-justified against them: 

  ...Sdf asdf sflksjdf: [____]
  ....Eosjslk blkjasdl: [____]
  ............Grog sdj: [____]
  ..........Asdsdf sdf: [____]
  ............Sld bsok: [____]
  ...Ybwslkj blso apon: [____]
  ...Ublkjs mogk robno: [____]
The user might look at the middle three fields as a visual group and say, "Those are almost aligned on the left side. Can you make them fully aligned?" Our framework only knows left, middle, and right aligned. It is blind to this coincidental alignment of the left-most characters in this case. (I would personally disagree with such a layout, but TheCustomerIsAlwaysRight?. They don't appreciate lectures on "proper" layouts, they just want it as they envision it without "flak".) In a coordinate-based system you simply shuffle the text around to make it fit how the customer wants it to be: 

  ...Sdf asdf sflksjdf: [____]
  ....Eosjslk blkjasdl: [____]
  ..........Grog sdj..: [____]
  ..........Asdsdf sdf: [____]
  ..........Sld bsok..: [____]
  ...Ybwslkj blso apon: [____]
  ...Ublkjs mogk robno: [____]
(Dots used to avoid TabMunging. Unfortunately, the dots make it hard to see the alignment issue.)

I realize that we can make a split sub-container in a nested model to left-justify the middle three, but it is a lot more work and it is hard to tell from the code what it is going on until it is actually rendered. I would rather just click-and-drag than introduce more UI fiddle faddle into the software code. The less we have to go back and nit with the code for esthetic purposes, the better. Adding yet more nestedness to "solve" things like this reminds me of AddingEpicycles. -- top

You can do that in a flow layout system if it supports grids (like HTML tables). Having seen that the things almost line up, nail them to a grid.

Why have the middle-man? Just use coordinates. Besides, grids don't handle the "almost" problem described above unless each cell is pixel-sized, in which case you have a coordinate system anyhow. I suggest you try the above exercise using HTML tables and record your changes. Note that at least you are going to have to split one column into two and give "colspan=2" tags on all the non-participant cells. Then you have to worry about the middle-most row lining up properly on the right because it will be left justified if we want it to match its two neighbors on the new left edge. Our first try will probably look like this: 

  ...Sdf asdf sflksjdf: [____]
  ....Eosjslk blkjasdl: [____]
  ........Grog sdj....: [____]
  ........Asdsdf sdf..: [____]
  ........Sld bsok....: [____]
  ...Ybwslkj blso apon: [____]
  ...Ublkjs mogk robno: [____]
There is no simple HTML command to tell it to line up both on the right side and match its two neighbors as the same time. That is an abstraction that HTML, nor any other known tool, was built to natively handle in a strait-forward way. In HTML it would likely require fiddling around with absolute cell widths or NBSP's. Something that would be 1 minute drag-and-move exercise under coordinates is now a 45-minute exercise in type-text-and-re-render, or as I like to call it: "nudge-N-fudge". Plus, it still might not render the same on another browser even after all that. Further, MS-IE has known layout bugs that they don't seem to be a in a hurry to fix.

Note that this issue applies to the nested approach also, not just auto-generated GUI's.

No it doesn't. Relative coordinates can be specified at any precision required.

Relative coordinates? That is kind of a hybrid between the choices considered.

No it isn't. What you refer to as "nested GUIs" are just GUIs that use relative coordinates. Swing and HTML both support relative and absolute positioning of components, and those positions can be expressed in pixels.

I think we have some serious definition issues to work out.

OK, let's start with the top of the page:

"Examples of coordinate-based GUI: VB, VC++"

These use absolute positions for components.

"Examples of nested GUI: Java AWT and Swing using LayoutManagers, HTML tables with no height or width attribute, Tk."

These support relative positions for components. Swing and AWT have a "null" layout manager that allows absolute positioning. HTML's divs can be relative or absolute.

What other issues are there?

I would not call HTML and Tk style "relative". Relative is "5 pixels from the corner of containing table cell". Here is a working taxonomy:

(BTW, Tk has an optional coordinate-based geometry manager.)

I've never used Tk, but HTML/CSS definitely supports relative positioning. (How else would you describe "<div style='position:relative; left:0px; display:inline; width:25px'>0</div>"?) Flow-based" is just relative positioning where the coordinates are expressed as components instead of pixels.

"Components"? I admit I don't yet have a satisfactory definition of "flow based" to offer as an alternative, but I don't like "relative" because there is relative positioning like your example above.

That CSS clause is an example of relative coordinates, but not flow-based. Working together, perhaps we can come up with sounder definitions. The best I can say at this point is that "flow based" gives positions relative to other components using non-distance references. Relative coordinates use numeric distances, as do absolute positions. In practice, flow-based may specify borders/buffers/margins (visible or invisible) using distances, which is a slight violation of the rule, but perhaps forgivable.

Different reference techniques:

Flow-based generally doesn't use the first two although it is possible to use hybrids, which I have done before to fine-tune (tweak) layouts that the flow-based approach could not by itself get quite right.

[1] HTML, for example, does this by context, not by explicit reference. If one wanted to use an explicit reference for web stuff, they could use a DOM tree path.

-- top

Another force is the need to generate the GUI on runtime (i.e. the number/type of controls cannot be known at compile time). You have to be more careful when generating the GUI in coordinate based system.

It seems to me this would probably greatly depend on the GUI API/framework and perhaps to a lesser extent the language.

We are looking for an abstract way to describe the layout of the components. (A coordinate system is not comfortable enough anyway. For an example the JavaSwing LayoutManagers are very good.) The underlying implementation should be hidden. We came up with this: For arranging components we only need the information if they should be set vertically or horizontally and optional we must know which component should be set in the center. To get the complex layout, these components will be grouped and the groups themselves will be layouted.

I disagree. Abstraction does not work with GUI's because the customer wants it to fit their own mental vision (see above), not idealistic notions of grouping and placement. Abstraction works best for things hidden from the user.

Please see also the discussion with the topic Swing: Handling Complex Layouts http://jinx.swiki.net/236 on the JinxWiki on the SwikiFarm

I don't see any visual examples there. Anyhow, nobody is arguing that it cannot be done with enough nesting of different kinds of layout managers and iterative futzing around, but rather that it can get awkward and non-visual. It also risks DiscontinuitySpikes if you pick the wrong one. Whenever people have to ponder a long time which approach they take, it is probably a symptom of a non-flexible approach.

Coordinates can handle any screen arrangement you have in mind, unlike pure flow layouts. But flow-based layouts can be a kind of shell around coordinate-based layouts since everything must eventually be translated to coordinates anyhow. Thus, it seems logical to me to have a base protocol based on coordinates, and then put a nested (flow) layout engine on top of that if desired. You cannot do it the other way around.

With an appropriate nesting layout engine, you could go either way. The points of a flow layout are all that need be nested, not the entire components themselves. You can therefore define a grid of points by successive division, and name those points (1,1)(1,2)(1,3)...(2,1)(2,2)...(10,9)(10,10) and so forth. They are equivalent, and so the choice between them should be decided by whichever works best for the platform in mind. -- WilliamUnderwood

If I understand you correctly, that leads to the AddingEpicycles complaint given above.

That complaint is ill-founded: epicycles are bad because they add complexity to a model in order to make it match a reality for which it is ill-suited. Adding a new definition of a point to a UI model actually models the UI exactly, because the model _is_ the reality.

In other words, changing the coordinates by hand is the coincidental method of aligning components. It is like making columns line up in a word processor by using a bunch of spaces as opposed to setting a couple tab stops. It is like (nay, it is exactly) making eyeflow in a layout by nudging objects till they look right as opposed to setting a couple guides and having the objects snap to _exactly_ the right spot. (This is well known in publishing circles)

-- WilliamUnderwood (who has spent more than his fair share of time doing print layout design in a previous life)

Perhaps 90% of the time, but about 10% it does not have fine enough control. Human minds don't always process images or esthetics with the same rules that the computer uses.

[I disagree with this - I've never seen a layout I couldn't implement in my layout manager of choice.]

Nobody is suggesting it is a can-or-can't situation, but rather an issue of convenience and productivity. Just like AddingEpicycles, with enough layers anything can probably eventually be achieved that way, but there is often a point where it would just be easier to click-and-point and be done with it. You pull out yer gun and just shoot du rabbit rather than build elaborate rabbit traps.

I was forced to make a website that had to make use of extensive absolute CSS positioning. The pain. There seems to be an overall forgetfulness of separating what the GUI creator needs from what the user wants. Which, as was already stated, tends to be illogical - I cherish every possibility of achieving this or that requested cheesy flashy pointless eyecandy without sacrificing all too much design logic. I have wet dreams of being able to create application GUIs with something as elegant and structured as lessay HTML/CSS, without having to wade through pixelwise mess and jungles of identifiers for widgets that only contain other, more semantically important ones.

What the user might want to do with what comes out of my design should not be my concern in the GUI code, but rather the concern of whatever system renders the GUI. A GUI defined with a flow layout is much easier to maintain in case someone has to hack at it and doesn't have your layout drawings, and I seriously doubt allowing the user to change widget position offsets is a horror to implement. As a matter of fact, it is very well implemented on most platforms, though I concede embedded and proprietary systems might pose a problem - but then again, these usually have a limited group of users that know better than to complain about what unneat pointless details their worktool looks to their employer. Serialize said offsets in a configuration file, and presto.

With a coordinate based system, you're actually robbing yourself of the opportunity of easier change at runtime, with having elements divided into small collections independent of each other (should you really feel such workspace chaos is a benefit) whose actual coordinates at temporal index foo need not interest anyone, much less the already overstrained coder. As far as set-based grouping goes for the more esoteric of GUI organizations, no-one's restraining you from defining your own containers and stuff in references to the elements you want, except hardware, but I'm not digressing that far. But not having to do so for the simpler GUIs since you already have a structure you can manipulate present will win out in the case statistics.

To conclude with a small thought-provoker as to whether the user really wants that much control over the GUI: How many of you that use Windows have done something as trivial as relocated the taskbar from the bottom where it sits since the install?

Honestly, I have trouble seeing how this is even an argument - the claim seems to be that since you it's easier for you to drag stuff around in a form designer, coordinate based layout is somehow superior. Note that HTML isn't the only model here. Positioning in HTML is primitive at best, in a "real" ui there's a lot more control and you have a lot more options.]

Some people relish the ability to futz around with their environment. Some don't care. People vary widely.

Also, there is a reason why OOP won out over structural programming.

Better hype.

Said futzing around is implementable and implemented without having to be present in the GUI logic. And no way I'm taking the better hype argument. True, anything you can do with OOP can be emulated procedurally with strict nomenclature, but I see no point in emulation when i can use a more natural way of expressing. Well, that should prolly go into another page, so I'll stop here.

"Natural" is probably very personal and subjective, based on past long arguments. Anyhow, I lean toward declarative GUI approaches, not so much procedural. Note that coordinate-based approaches do not rule out moving stuff as a group. Some tools make it easier than others. Perhaps that area can be improved by being able to have named sets (not hierarchies) such that one can simply type the name of the group/set and then move them all at the same time. "Snap-to" grids are also nice for such (as long as you can override them on a widget-by-widget basis.) Also, I agree that both styles have their place. It would be nice to be able to convert an existing nested-based layout to a coordinate one when you eventually need finer control. That way you can start out with the cleaner ideal approach, but tweak it at the pixel level if the customer is picky and does not want excuses. I am not sure this is an OOP-versus-non-OOP issue anyhow. Does OOP naturally lead to flow-based layouts? How do you recon that? -- top

[I'd say this has zero to do with OOP. GUI layout isn't programming anyway, any more than writing HTML is. I don't see your need for "finer control", either - if you don't have the control you need with a nested layout manager, then your tools are broken. SharpenTheSaw. -- ChrisMellon?]

They are often interrelated. What's possible/practical with programming may greatly affect the GUI design choices. Ideally they'd be separate interests, but in practice they are often intertwined for non-trivial apps. And auto-layout is often just "dumb", as illustrated nearby. It does not understand human aesthetics and psychology, and putting that knowledge into the tool, if technically possible, would make it bloated and unpredictable (just like the users :-)

From what I have seen, people like GUI builders. They appear to like clicking and clicking and dropping and dropping, and clicking and clicking and dropping and dropping. I am buggered if I know why they enjoy it. From experience using auto generation of screens over twenty years in one environment, I am able to assess the usefulness of the generation process as opposed to the screen painting process. And my conclusion is absolutely in the generation camp.

There is that question of user finickitiness. Very difficult to overcome. But after overcoming that, the user is in the long term happier because the generation process causes some consistency within the system. --PeterLynch

Generally I agree, but the social/political environment often doesn't reward a longer-term view. Sometimes we just have to cater to silly whims if we want the rewards the game offers. Related: ChoosingSatisfactionOverMoney. You can say, "I will risk my career to make the GUI right instead of please fools." But that decision will not scale to all readers or workers.

I think a lot of things on this page could be summed up as "HTML positioning sucks", which I have no argument whatsoever with, and "Nested layout is too complicated", which is very different from being inferior to coordinate.

Nested layouts provide a strict superset of capability, at the expense of complexity. Obviously, the need is to reduce complexity, which you can achieve by using form designers that support layout magnets. QtDesigner has a nice feature which lets you drag and drop your controls, which is nice for prototyping and brainstorming, and then to add those controls to layout managers. -- ChrisMellon?

Relative position GUIs are much easier to internationalize. Fixed position GUIs don't automatically adjust to different character set sizes, and when you invert the text direction for Arabic or Hebrew the coordinates become meaningless.

To end this useless thesis-antithesis brawl, I will try to show, that the synthesis of both is already widely in place. Examples:

I guess there are many more examples. The remaining question is not, which is better, but WhenToApplyWhich? or FindingTheMiddleWays?.

-- GunnarZarncke

Coordinates with Stretch-Zones

I thought of a possible way to allow coordinate-based screens to expand without having to abandon coordinates. Have a vertical and horizontal "stretch bar". In design mode the stretch bar would just be two lines, a cross in the middle whose end-points reach to the edge of the form. When the window is expanded, the line(s) forms a gap and widget points (corners) will stay on each side of the panels. Imagine the cartoons where somebody is on top of and between two train cars with one foot on each train. When the trains separate, the character's legs stretch. The location of the stretch bar would be designer-determined. It probably would not cover 100% of all situations, but may cover most. Also, in some cases some widgets may want a designation of "non-stretch" such that they keep the same proportion, stuck to one side or the other (or top and bottom) as the primary reference.

Are you thinking of SpringsAndStruts?

No, but if somebody else already tried the idea, that is great. It looks a bit more complicated than what I have in mind, though.

To set how stretching happens across the zones, each edge of the bounding rectangle of the widget needs to be assigned to one of the 2 possible stretch directions. 

 widget.topStretch   = "top";   // or "bottom"
 widget.rightStretch = "right";  // or "left"
 widget.leftStretch = "left";     // or "right"
 widget.bottomStretch = "bottom";  // or "top"
(Perhaps there should also be a "middle".)

These would be the defaults, so normally we wouldn't need to specify these specific ones. Note that buttons do not normally stretch, so bunches of buttons in a group may be best riding on a panel that you create for them, which itself uses the stretch settings.

Another feature would be scaling of widgets such that the user could magnify or shrink the screen, but the relative sizes of everything would stay the same. This would require vector-based fonts, however, which sometimes don't map well to raster-based conventions (at least until pixel sizes get sufficiently small via the technology curve).

This is a "real world" experience that reminds me of the limitations of auto-placement as described above (which I am not outright against if it's optional). I was hanging a picture on the wall the other day and was careful to center it properly between the available wall borders. It was a fairly narrow area. When done, I stood back and was dismayed about how off-center it looked. I checked the centering again, and technically it was correct, but it still looked off-center. It's just the "lay of the land" in that spot that tricks the eye. I'm still kicking around the idea of fudging it to make it look centered, but am too lazy to futz with it further. Many managers and users do complain, or at least notice such things on screen, and it thus affects a developer's score. -t

See also: GuiCoordinateNotationDiscussion

CategoryUserInterface, CategoryWebDesign, CategoryInteractionDesign

MayZeroNine

EditText of this page (last edited August 28, 2014) or FindPage with title or text search