5 ms·

> Yes. We had drag and drop UIs decades ago. We had _simple_ drag and drop UIs decades ago. Computers operated within a lot more limited constructs back then.

> Yes. We had drag and drop UIs decades ago. We had _simple_ drag and drop UIs decades ago. Computers operated within a lot more limited constructs back then. UI windows didn't resize, or it was reasonable to expect that they're fixed. How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide?

bonaldi 8y ago
Interface Builder has been building complicated and resizable UIs for literally decades.
vthriller 8y ago
> How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide? For simpler forms you'd just set anchoring properties of the widgets in question (akRight/akBottom in Borland's VCL or whatever its counterpart is called in WinForms or what was its predecessor). Nowadays it's even easier with things like, say, GTK's HBox/VBox. > Computers operated within a lot more limited constructs back then. Resource limits didn't stop web browsers of the era from rendering complicated tables in a variety of sizes.
- qwerty456127 8y ago
  > 400pt wide to 2560pt wide There are 2 major strategies for responding to such a difference: 1. Vector scaling. It will make the difference irrelevant and the resulting UI will look approximately the same on whatever a resolution. 2. Capacity scaling. I.e. keep the same font letting more information to fit in the control without scrolling. It may be a little bit hard to formalize but these two can be combined intelligently. It is also important to know which one the user prefers (e.g. I mostly prefer the second while many prefer the first).
  - madeofpalk 8y ago
    Note I mentioned display _points_ rather than display _pixels_ - how do you create a UI that scales from a phone to a 27" monitor. This is more than just scaling up assets and turning on word wrap.
    - qwerty456127 8y ago
      > This is more than just scaling up assets and turning on word wrap. Why? What else is there? I'm actually curious. I personally have never dealt with displays bigger than 1280x1024.
- int_19h 8y ago
  In WinForms, it's still called Anchor (it really did take a lot from VCL), but since enums are scoped in .NET, you have Anchor.Left, Anchor.Top etc. WinForms also had Dock (Left, Right, Top, Bottom, or Fill) which basically forced the control against that edge of its parent, taking up full length and/or height accordingly in one dimension, and using the explicitly specified size in the other. With multiple controls with Dock, they'd gradually fill the available space in Z-index order, stacking up against each other; then whatever control had Dock=Fill, would fill the remaining space. So yeah, resizable windows were common, and easy to deal with. The real problem is dynamically sized controls themselves, e.g due to DPI changes, or because the control contains dynamic content of unknown size. With those, anchors no longer work well, and you need some kind of box and grid layouts. Which are available - but it's kinda hard to edit them visually in a way that's more convenient than just writing the corresponding code or markup. The closest I've seen to visually editing UI that can accommodate dynamically sized controls was actually in NetBeans, which had its own layout manager for Swing. That thing allowed you to anchor controls relative to other controls, not just to the parent container. Thus, as controls resized according to their context, other controls would get moved as needed: https://netbeans.org/kb/docs/java/quickstart-gui.html https://netbeans.org/kb/docs/java/quickstart-gui.html https://youtu.be/_ZW4ktG1DEE?t=129 https://youtu.be/_ZW4ktG1DEE?t=129 Still, you needed to be very careful in the UI form editor, to make sure that controls are anchored against other controls in ways that make sense. Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc.
  - pjmlp 8y ago
    > Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc. WPF and UWP can deal with it perfectly fine.
    - 8y ago
robotresearcher 8y ago
> UI windows didn't resize, or it was reasonable to expect that they're fixed. This isn't true at all. The original Mac in 1984 had resizable windows for most apps. Most other WIMP GUIs followed suit.
Mikhail_Edoshin 8y ago
An early desktop publishing program, Ventura Publisher (v3 of 1990) could easily reflow complex document layouts and allowed alternate stylesheets to be applied to the same text. This is not exactly UI, but the layout was more sophisticated than what HTML can do. The idea of same content and different rendering is certainly not new.

bonaldi 8y ago

Interface Builder has been building complicated and resizable UIs for literally decades.

vthriller 8y ago

> How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide? For simpler forms you'd just set anchoring properties of the widgets in question (akRight/akBottom in Borland's VCL or whatever its counterpart is called in WinForms or what was its predecessor). Nowadays it's even easier with things like, say, GTK's HBox/VBox. > Computers operated within a lot more limited constructs back then. Resource limits didn't stop web browsers of the era from rendering complicated tables in a variety of sizes.

qwerty456127 8y ago
> 400pt wide to 2560pt wide There are 2 major strategies for responding to such a difference: 1. Vector scaling. It will make the difference irrelevant and the resulting UI will look approximately the same on whatever a resolution. 2. Capacity scaling. I.e. keep the same font letting more information to fit in the control without scrolling. It may be a little bit hard to formalize but these two can be combined intelligently. It is also important to know which one the user prefers (e.g. I mostly prefer the second while many prefer the first).
- madeofpalk 8y ago
  Note I mentioned display _points_ rather than display _pixels_ - how do you create a UI that scales from a phone to a 27" monitor. This is more than just scaling up assets and turning on word wrap.
  - qwerty456127 8y ago
    > This is more than just scaling up assets and turning on word wrap. Why? What else is there? I'm actually curious. I personally have never dealt with displays bigger than 1280x1024.
int_19h 8y ago
In WinForms, it's still called Anchor (it really did take a lot from VCL), but since enums are scoped in .NET, you have Anchor.Left, Anchor.Top etc. WinForms also had Dock (Left, Right, Top, Bottom, or Fill) which basically forced the control against that edge of its parent, taking up full length and/or height accordingly in one dimension, and using the explicitly specified size in the other. With multiple controls with Dock, they'd gradually fill the available space in Z-index order, stacking up against each other; then whatever control had Dock=Fill, would fill the remaining space. So yeah, resizable windows were common, and easy to deal with. The real problem is dynamically sized controls themselves, e.g due to DPI changes, or because the control contains dynamic content of unknown size. With those, anchors no longer work well, and you need some kind of box and grid layouts. Which are available - but it's kinda hard to edit them visually in a way that's more convenient than just writing the corresponding code or markup. The closest I've seen to visually editing UI that can accommodate dynamically sized controls was actually in NetBeans, which had its own layout manager for Swing. That thing allowed you to anchor controls relative to other controls, not just to the parent container. Thus, as controls resized according to their context, other controls would get moved as needed: https://netbeans.org/kb/docs/java/quickstart-gui.html https://netbeans.org/kb/docs/java/quickstart-gui.html https://youtu.be/_ZW4ktG1DEE?t=129 https://youtu.be/_ZW4ktG1DEE?t=129 Still, you needed to be very careful in the UI form editor, to make sure that controls are anchored against other controls in ways that make sense. Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc.
- pjmlp 8y ago
  > Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc. WPF and UWP can deal with it perfectly fine.
  - 8y ago

robotresearcher 8y ago

> UI windows didn't resize, or it was reasonable to expect that they're fixed. This isn't true at all. The original Mac in 1984 had resizable windows for most apps. Most other WIMP GUIs followed suit.

Mikhail_Edoshin 8y ago

An early desktop publishing program, Ventura Publisher (v3 of 1990) could easily reflow complex document layouts and allowed alternate stylesheets to be applied to the same text. This is not exactly UI, but the layout was more sophisticated than what HTML can do. The idea of same content and different rendering is certainly not new.