Comment by trevyn
4 years ago
It's tricky to do GUI editing when your design is expected to be responsive to different aspect ratios, input methods, and screen sizes. :(
4 years ago
It's tricky to do GUI editing when your design is expected to be responsive to different aspect ratios, input methods, and screen sizes. :(
The myth of "omg only html has different screen sizes" is so pervasive, it's mind boggling.
Desktop apps have had "different screen sizes" forever. This is called "resize your window in any way you want".
I have a rant/thread on this: https://twitter.com/dmitriid/status/1424052193951354881?s=20...
Sure, but I don't recall many programs / games / thick clients that would reorganize the layout of the application (adding or removing elements, reorganizing rows as communs, etc...) At least not 90s era windows programs, and certainly not dos.
Résolution was taken into account in games, to compute a scaling factor, maybe add some screen bars, and that was nearly all - fundamentally, because hardly any program was going to be used in a small, top to bottom screen at all.
So html was just the first one to have to do it pervasively because of desktop + mobile web browsing of the same source - but it could have happened before.
> Résolution was taken into account in games, to compute a scaling factor, maybe add some screen bars, and that was nearly all - fundamentally, because hardly any program was going to be used in a small, top to bottom screen at all.
Are you comparing applications or games? Because games don't have a fluid layout anyway[1], whether HTML5 or native application.
> So html was just the first one to have to do it pervasively because of desktop + mobile web browsing of the same source - but it could have happened before.
No. All the GUI toolkits I have used to produce native GUI applications since at least 1998 had support for ensuring that elements were still accessible after resizing[2]. Even in 1998, Delphi's "anchor" worked better than anything in HTML today.
HTML was the last GUI development system to get this sort of thing.
[1] You can choose one of a dozen preset WIDTHxHEIGHT resolutions. You couldn't narrow the window and still expect to see all the game elements.
[2] I don't remember many native GUI applications that were broken when you halved the width, or halved the height.
3 replies →
Boy do I have a story for you :-)
WriteNow https://en.wikipedia.org/wiki/WriteNow was a word processor available for the Macintosh from 1985. Its windows could be resized from full screen (512x342!) down to so small that only part of one character was visible. There was zero reason to support windows so small other than programmer amusement. The interesting thing was that the scrollbars were perfectly usable at any window size, and changed not just their size but their layout to do so. From memory: at a normal size window, the vertical scrollbar looked normal: something like this:
^
|
|
v
At a smaller window size, the scrollbar got narrower, with smaller arrows. This made some sense.
At a still smaller size, the scrollbar shrank again, and the arrows changed shape to be smaller. At this point the window might be displaying two lines of text and the scrollbar was only 20 pixels tall. This was a pointless window size.
At a still smaller size, the scrolling area itself would disappear because the arrows began to overlap. This was a ludicrous window size.
At a still smaller size, the vertical scrollbar changed to horizontal, with two tiny arrows only a few pixels tall, and a teeny scrollbar between them. This was completely pointless.
All of the scrollbar designs were functional.
It did happen before, X Windows Athena and Motif used layouts, because no two X Windows Thin Clients were alike.
Same applies to Tcl/Tk and Java Swing that build on the same principles.
On Windows side, Windows Forms introduced layout manager, Delphi and C++ builder did the same with VCL.
Qt and wxWindows also have layout managers since the early days.
What happens is that people cargo cult how native programming used to be like, and youger generations only care about Web and mobile.
In the 90s we went from 640x480 to 800x600 to 1024x768 in fairly rapid succession, and Windows could be running in any of those modes depending on the user's hardware. Many apps were able to run in any of those responsively, though some would refuse to run without a minimum level.
> (adding or removing elements, reorganizing rows as communs, etc...)
The main reason you don't recall apps doing that is that it is a pretty horrible idea in virtually all cases.
5 replies →
No.
NeXTStep had resizable windows.
NeXTStep had Interface Builder.
Worked like a charm.
It's still there in MacOS's XCode
When I've looked in the past, Interface Builder was (as far as I could tell) a first-step-and-don't-return thing. Meaning you could lay out an interface visually, but when you want to start coding it becomes a code definition of that interface, and once you start updating that, you can't (easily) return to the visual interface-definition interface. Has that changed, or was I wrong?
1 reply →
I think "it's tricky" and "it exists" are compatible sentiments.
Ok, how about "scrollable page" as the underlying mental model?
Drag and drop a scroll bar: now you have a scrollable page.
Do whatever you want to it.
1 reply →
Not tricky if you spend the time. I'm always speechless when people claim that lack of responsive screen adjustment was the death knell of Flash/AS3. Any language or stack is going to suck on some screens unless you test it on those screens and write code accordingly. Nothing had better performance in this than Flash, up until Google decided to stop letting Chrome fire off new window boundaries on resize until the click/drag was let up. I wrote practically a whole operating system with window managers and apps in a resizable browser window in 2008 using that tool in under 300k. And large portions of the graphical elements were done through the GUI. Do you realize how much more boring and time consuming it is to write every media size CSS subclass and have to test it compared with just drawing multiple sizes of things and changing their positions and filters?
>and write code accordingly
That is exactly the point — now you have to write code, not use a graphical editor.
No, but the sprite/graphic implementation was much less tedious when you could use a good GUI to set up all the small bits instead of relying on a mental map of flex/grid/css to resolve every little padding or margin.
I often write 99% of an app now and spend days dealing with single-pixel discrepancies on screens whereas before, the layouts would likely be implemented before the code to swap between them even started being written.
You always also had to write code.