Decker, a platform that builds on the legacy of Hypercard and classic macOS
beyondloom.com
beyondloom.com
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...
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.
The main reason you don't recall apps doing that is that it is a pretty horrible idea in virtually all cases.
Having the interface add/remove elements for this dynamically is (a) obviously not necessary, as my desktop doesn't suddenly turn into a phone while I am browsing, and (b) not a good idea.
It seems like a neat generalisation, but it really isn't.
I've been designing web frameworks from the ground up since 1995. Two sizes is not how it works. You don't read the initial size of the browser window, or parse the device data to see if it's mobile, and decide from there which of two layouts to draw (mobile or desktop). You read it on the fly and redraw as necessary. All parts of the interface and the content working together.
Bootstrap, for instance, has xs, sm md lg xl classes and mixins. Often you don't hide interface elements but simply resize them. Font leading and size may change 20 times subtly as you resize a window.
If you don't believe me, load any major website in a desktop browser and play with resizing the window from narrow to wide.
I am just saying it is bad.
How do I know it is bad? I know it because I have to use this stuff.
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.
Was it also common to make sure your Qt app was working fine on the small portrait resolution of the mobile computers that were going to be invented any decade now ?
Flex is a layout system (a fairly good one, that I wish had existed on the web since the start. Rows, columns, wrap. Good.)
; responsive is a design considération (what do I as a human being decide should be visible when the screen is just too small to show everything.)
My claim is that "responsive" as a design issue is deeply linked to mobile computers, so it's not a surprise that it was not a big conxern before.
It was always technically possible to have a flexible layout, it just didn't become popular/"standard" until around when mobile started being a popular medium via which to view that content. The prevalence "best viewed at 1024x768 or higher" was just a symptom of inflexible design & implementation, not an actual technical limitation of HTML.
P.S. I will definitely agree that laying out content in HTML has always been awkward, tedious, and inconsistent across browsers, hahah :)
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.
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.
NeXTStep had resizable windows.
NeXTStep had Interface Builder.
Worked like a charm.
Do whatever you want to it.
Used to be a lot better.
That is exactly the point — now you have to write code, not use a graphical editor.
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.
This sabotage is subtle: A wide variety of technical decisions can be made at any time, with complex trade-offs, bounded by what the majority of developers is willing and able to handle. As we move our servers to the cloud to make our lives easier and get admins fired, the exact right level of complexity shows up in AWS and Azure to enable stable and well-paid cloud expert jobs. For that difficulty-goldilocks-zone, Visual Basic was too easy, and things like functional programming are too hard.
I suspect it's a subconscious process where we like to build a framework that appeals to us, where we get to be 'senior' and shape the world the way it is convenient for us. The antidote is a clear commitment to simplicity, to meditate over Picasso's Bull and apply that to our work.
Not all of us. I fervently wish that implementing the various platform-specific accessibility APIs, and the corresponding tricks for canvas-based GUIs in web applications, was easier, so more GUIs would be accessible. I wish I wasn't one of maybe a few hundred people in the world who had substantial experience with the UI Automation API on Windows, for instance. I'm working on an open-source project to try to package up that specialized knowledge in a reusable implementation. But it takes work to make inherently complicated things easier.
If you have a WordPress blog, you would be surprised how much you can edit in GUIs. .NET/Delphi/etc. are still around. Heck, you can GUI edit a Swing app right now if you want.
The trouble is that GUI editing is super limited, so it is worth learning to write the code yourself. And frankly, HTML with CSS3 is not that hard to make by hand; organize div and spans and other tags around what you need, then open the page in Chromes dev tools and adjust margins etc., until it looks like what you want, then save the CSS file it generates.
This is much better than fighting with a GUI tool.
I am a senior (30 years+) software engineer and html/css really doesn’t work for me. I can do it but I find it boring and annoying.
Or do you specifically mean an interactive HTML front-end, something I don't think you could make in DreamWaver either?
It's based on HyperCard, so the language isn't to everyone's taste. But it's updated to include color, unicode, more advanced coding techniques, database access, multi-platform and more. But the basic concept -- I want a button here, and a field there, and a slider there -- is still 100% there.
Director allowed quick development of Multimedia catalogs and even games. I wonder nowadays, what has taken its place? Let's say that I want to throw together some media assets, sincronize it's behavior, add some functional logic and package it all as a standalone binary to distribute, what should I use? An Engine like Unreal o other? Is there any authoring tools for that?
This are totally honest questions. I don't know the "state of the art" nowadays and if is even possible with an acceptable learning curve for someone to do that kind of things we use to do with Director
The second thing was that hypercard was a program html was a format.
Another case of worse is better? shrug.
Think about it this way, would you be happy if any random scammer could place links into your web page, well, with bidirectional links, now they can.
Your server would need to log and report on those entries. Of course, for privacy and other reasons, this is probably not dependable any more.
[0] https://en.wikipedia.org/wiki/Classic_Mac_OS#/media/File:App...
http://www.righto.com/2017/10/the-xerox-alto-smalltalk-and-r...
They are quite similar, but there's more pixel differences between current Linux/BSD pointers and the Macintosh pointer than there are between the Macintosh pointer than the Alto one (roughly 1 pixel difference).
IOW, Macintosh is closer to the Alto one than it is to the Linux/BSD ones.
I don't know where you lived but where I did internet adoption was slow, and most computers operated in isolation for years before everyone was connected. Floppy disks and CD-ROM reigned supreme for quite a while. Long enough for a new version of HyperCard to have come out with hyperlink support if that had been a priority.
An open and simple file specification. I don't know much about hypercard, was it's file format published?
An open and simple network transport system. html pages could trivially be loaded and linked from anywhere on the network.
The client came with source code and permission to modify it. Very quickly there were several competing implementations. for every operating system.