News for hackers. Stuff that matters.
Re:IDEs we had 30 years ago by csomar on Thursday December 28, 2023 @11:20PM (#38801726)
VB6 worked because the environment was simple. GUIs are simple when you don't need to do any styling, do not require any special modifications and most importantly you don't need responsiveness. All of that, and you need a special environment and operating system to run the GUI. Web front-end are a completely different game in that regard.
Re:IDEs we had 30 years ago by josephg on Thursday December 28, 2023 @11:51PM (#38801844)
Yeah. Back in the day, every application was expected to use the same common set of controls - which were well written by the OS vendor, well tested, well documented and well understood by users. Every button on windows 95 looks and behaves the same way. Every application had application menus that worked the same way, in the same font, and they all responded to the same keyboard shortcuts.

These days every application reinvents its own controls for everything. For example, in a web browser the tab bar and address bars are totally custom controls. Electron apps like vscode take this to the extreme - I don't think vscode or spotify use any native controls in the entire UI.

I blame the web in part. It was never designed as a system to build application UIs, and as such the provided UI primitives are primitive and rubbish. Developers got used to building our own custom elements for everything - which we build fresh for every client and style in alignment with the brand. UIs built on the web are inconsistent - so our users never get a chance to learn a common set of primitives.

And for some reason, OS vendors have totally dropped the ball on this stuff. Windows has several competing "official" UI libraries. Every library has a different look and feel, and all are in various stages of decomposition. Microsoft's own software teams seem as lost as everyone else when it comes to navigating the morass of options - if windows 11 and MS Teams are anything to go by. Macos isn't quite as bad, but its still a bit of a mess. Every year I expect the people building xcode to know how to build and debug software on macos. And then xcode crashes for the 3rd time in a week. Xcode achieves the impossible of making the javascript ecosystem seem sane and attractive.

I'd love a return to the halcyon days of vb6, where UIs were simple and consistent. Where there was a human interface guidelines document that UI developers were expected to read. I want users and developers alike to know how the platform works and what the rules and conventions are. F it. How hard can that really be to build?

Re:IDEs we had 30 years ago by pvg on Friday December 29, 2023 @01:06AM (#38802192)
I think you're forgetting how much more dense and complex even a basic web ui is in controls. Every HN comment in the default story view has something like up to 10 clickable controls - a pair of vote buttons, username, timestamp, a bunch of nav links, a hide control, a reply button. HN, the famously minimalist, oldskool website. The web made new ui and even the back-in-the-day version of that ui is way more complicated than the back-in-the-day desktop app UI you're thinking of.
Re:IDEs we had 30 years ago by josephg on Friday December 29, 2023 @02:38AM (#38802561)
Hm. I don't think it would be that hard it would be to remake HN's UI using an old school UI component library. The up/down arrows could use the up/down buttons on this screenshot from macos's old color picker:

https://guidebookgallery.org/pics/gui/interface/dialogs/colo...

... But limited to only allow you up/downvote between -1 and 1.

Everything else could be done with buttons and a TextField / Label for comments and replying.

The web is a bit weird in that it taught us to build every UI as a giant scrolling document. And HN is no different. A more "classic" UI approach would be something like Thunderbird mail - with 2 panes: a "comments" tree on top and a "message body" down the bottom. That would be harder to read (since you'd need to click on the next message to jump to it). But it might encourage longer, more thoughtful replies.

Thunderbird: https://lwn.net/Articles/91536/

Or you could reimplement HN with classic controls and something like TB 114's UI:

https://www.ghacks.net/wp-content/uploads/2022/08/account_ma...

Probably still worse that what HN is now though.

Re:IDEs we had 30 years ago by tomatocracy on Friday December 29, 2023 @03:45AM (#38802915)
A "traditional" UI for HN would surely look a lot like Usenet newsgroup readers. I think Thunderbird might even still support NNTP.

Usenet had a much better model for discussion groups/forums like HN in my view, though crucially for the modern world it is missing some kind of "comment voting"/user-driven moderation. I wonder if there's an HN<->NNTP gateway around somewhere?

Re:IDEs we had 30 years ago by rbanffy on Friday December 29, 2023 @01:18PM (#38808288)
Voting could be handled with comments with specific content - wouldn’t even need to have a body, as everything could be in the headers. Totals could be computed at the server, unless we wanted real NNTP-style distributed discussions.
Re:IDEs we had 30 years ago by davidwritesbugs on Saturday December 30, 2023 @05:18PM (#38819833)
You'd probably just need create your own X-header extension
Re:IDEs we had 30 years ago by troupo on Friday December 29, 2023 @03:09AM (#38802716)
> I think you're forgetting how much more dense and complex even a basic web ui is in controls.

It really isn't. Web is anemic in controls and layouts compared to what's actually possible with proper controls and control over those controls.

Re:IDEs we had 30 years ago by josephg on Friday December 29, 2023 @08:21AM (#38804574)
Yeah; especially given the number of pixels we have at our disposal. Old UI screenshots look simple but they had to work at tiny resolutions compared to modern user interfaces. I remember when 800x600 was considered luxurious.

Web apps also can't use a lot of native shortcut keys to build keyboard-friendly UIs. Its rude to override the browser's right click menu. Alt-anything might bring up browser native controls. Ctrl/Cmd+S is owned by the browser. And so on. Some of this stuff you can override, but even if you do, users never experiment because those shortcut keys basically never do what you expect.

Re:IDEs we had 30 years ago by HeavyStorm on Friday December 29, 2023 @05:49AM (#38803687)
I don't see anything special in having tens actions on a UI item. Toggles, action links and vanilla buttons would take care of it.
Re:IDEs we had 30 years ago by magicalhippo on Friday December 29, 2023 @05:59AM (#38803735)
Dense?! I've never seen a web UI remotely close to what I'd call dense.

The HN UI would be very easy to recreate in something like Delphi, I'd call it trivial.

We use Delphi at work. Our main application is a regular Windows desktop application. I recently had to add a new module to our application at work, it required three new input windows/screens, each with 100-150 input fields, few dozen buttons, and several grids.

I made the UI parts in a day. A few more hours the day after and all the UI logic and database loading/saving was done, and I had a functional UI for all three windows/screens.

Many of our customers have HTML-based ERP or CRM systems that we integrate with. I've never seen any of them that are close to dense UIs, and most of the time I see the user having to click through multiple sub-screens just to do a relatively simple task like looking up a couple of values. With a denser UI that could all have been on a single screen and saved the user a ton of time.

But I'd love to be proven wrong. Any examples out there of actually dense, in the good sense, web UIs?

Re:IDEs we had 30 years ago by troupo on Friday December 29, 2023 @07:04AM (#38804093)
> I think you're forgetting how much more dense and complex even a basic web ui is in controls.

I realised I should've added: Have you actually seen a proper dense UI? Look at any professional software. You will die of old age before you can implement just the layout for it using web technologies.

Here's Cubase with TAL-U-No-LX synth emulator in front of it: https://pbs.twimg.com/media/E8M6-QOWEAQMgGl?format=jpg&name=...

Re:IDEs we had 30 years ago by Shorel on Friday December 29, 2023 @08:07AM (#38804438)
Can MIXXX be considered professional software?

The skins are made using XML and QSS (Qt CSS).

It's not web per se, but it is not too far from it either. I would say it's a combination of both, Web and Desktop technologies, into one.

https://i0.wp.com/djtechtools.com/wp-content/uploads/2021/07...

Re:IDEs we had 30 years ago by troupo on Friday December 29, 2023 @08:11AM (#38804483)
It's not web technology by any stretch of imagination
Re:IDEs we had 30 years ago by geysersam on Saturday December 30, 2023 @07:34AM (#38814808)
What about a dense ui is intrinsically more difficult to implement on the web? Doesn't dense just mean lots of buttons/fields and small margins between them? Your example looks very challenging indeed, but it was probably not trivial to implement either way.
Re:IDEs we had 30 years ago by troupo on Saturday December 30, 2023 @05:16PM (#38819819)
> What about a dense ui is intrinsically more difficult to implement on the web?

You have no control over layout or control over rendering. In native apps (especially desktop apps) you can always go down or up any level you want. In the browser you're always fighting the quite rigid and high-level layout and rendering engine.

It's somewhat better now with grid and felxbox, but the browser will always have its own ideas on how the children can be laid out, and there are no good ways for children to depend on the parent, or for the parent to depend on the children etc.

There are very, very few dense layouts on the web. And while late-90s/early-2000s sofware was often ridiculed, you could create dense control-rich interfaces in minutes. Because they are usually not ad-hoc hacks added to the platfrom as an afterthought, like everything on the web.

Re:IDEs we had 30 years ago by ReleaseCandidat on Friday December 29, 2023 @06:54AM (#38804024)
> Every application had application menus that worked the same way, in the same font, and they all responded to the same keyboard shortcuts.

My experience had been that most (almost all) of them _only_ worked with a single font in a single font size and a specific window size. If you did change any of these, it got unusable.

About consistency: except for those that didn't, not even MS themselves were consistent. http://hallofshame.gp.co.at/shame.html

The 90s had been also the time of programs like Kai's Power Tools https://mprove.de/script/99/kai/ and Winamp.

I'm sorry, but "interface consistency" is not something that comes to my mind when I think of 90s and early 2000s Windows programs (neither was Linux). Irix with 4DWM had been quite consistent at that time.

Re:IDEs we had 30 years ago by josephg on Friday December 29, 2023 @08:05AM (#38804430)
In the "hall of shame" you linked, they list applications which misuse radio buttons. Uh oh, call the police. Sure, there were a few inconsistencies. But honestly, up until the ribbon in Office, it was incredibly homogeneous compared to today.

In comparison, modern windows doesn't even hide its inconsistencies. Try right clicking on the desktop in windows 11. You get a dropdown with large item spacing and rounded corners. But then if you click "Show more options", the dropdown is replaced with a different dropdown with subtly different menu items, small spacing and sharp corners.

They aren't even pretending any more.

This isn't Kai's photo goo we're talking about here. This is core windows.

Unless you opted out, basically every application in the 90s and early 2000s was built using the core platform's UI library. There were a few exceptions, but the 90s were a golden age for platform consistency compared to today.

Now its hard to find any 2 applications on windows which use the same UI style. Firefox and explorer? Nope - the maximise and close buttons have a different style. Spotify? Nah thats some custom webview. Visual studio? Nope, thats using an old windows library. Whatsapp desktop? Qt. Intellij? Some java thing. And so it goes. Its an absolute zoo.

Re:IDEs we had 30 years ago by tracker1 on Saturday December 30, 2023 @02:03AM (#38813335)
You can always make web form based applications without style sheets.

They're pretty fast to create, relatively consistent, simple and fast/easy to create.

That's not what people want, they want all the flexibility and features of say Gmail or maps. B along with some communication and flexibility. Not to mention running on every OS under the sun, and being able to use accessibility and screen reader tools on all those platforms.

Re:IDEs we had 30 years ago by josephg on Saturday December 30, 2023 @07:00PM (#38820493)
> You can always make web form based applications without style sheets.

Uh, no you can't. Web forms aren't rich enough to build most desktop applications. You can't make vscode, gmail, slack or spotify using web forms. They're just a bad set of primitives for applications. (In the web's defense, it was never designed as an application platform).

Yet - we had some version of all of those applications in the 90s, on every OS at the time. And (mostly) using the platform's built in UI libraries so the look and feel was consistent and delightful.

Re:IDEs we had 30 years ago by tracker1 on Tuesday January 02, 2024 @06:50AM (#38840666)
Web forms are absolutely enough to roughly match the typical VB6 application. Especially the "easy" path mentioned. Not every app, but definitely most.
Re:IDEs we had 30 years ago by Amezarak on Friday December 29, 2023 @07:40AM (#38804283)
I used Windows 98SE for eight years. I never saw any issue changing window sizes.

I can't speak to font sizes since IIRC that was an option but I left it default.

Re:IDEs we had 30 years ago by rbanffy on Friday December 29, 2023 @01:13PM (#38808219)
For all my apps that had controls pinned to a specific coordinate, I made sure to make the windows fixed-size.

I taught courses on VB from versions 3 to 6 and this was always something we went over.

Re:IDEs we had 30 years ago by badsectoracula on Friday December 29, 2023 @11:24AM (#38806668)
Interfaces were WAY more consistent than they are nowadays even when taking into account some applications slightly altering their themes. One application using a listbox instead of a tree (like one of the Microsoft examples in the site you linked) does not make a UI inconsistent (even as the wrong control, the listbox still looks and works exactly like the other listboxes in the system), it only makes it an odd/bad choice. And from a quick browse, most of the issues mentioned there are things like that (including, amusingly, a ribbon-like interface in Windows 3.1 in the tabs section[0] :-P).

IMO the fact that someone cared enough to make a site about what is largely nitpicks like this shows exactly how these stood out in the otherwise consistent landscape of UIs in the 90s.

Nowadays such a site would have 99% of every application released. It could even be automated, just somehow track all new .exe files in GitHub, MajorGeeks, Softpedia, etc and add them automatically to a hall of shame list, chances are even without human supervision the overwhelming majority will be correct :-P.

[0] http://hallofshame.gp.co.at/tabs.html

Re:IDEs we had 30 years ago by wildrhythms on Friday December 29, 2023 @09:19AM (#38805118)
I think about this every time I'm asked to build a custom dropdown menu. Can we just use a <select>? No- it must be 'branded'!
Re:IDEs we had 30 years ago by wharvle on Friday December 29, 2023 @09:57AM (#38805609)
If you’re in a rare team doing agile halfway right, see if you can start providing separate level-of-effort for a feature with good UI that’s also quick, and the worse-for-the-user “on-brand” one.

Part of what causes this crap is that the costs aren’t visible. If you can get it through stakeholders’ heads that they’re cutting the feature development rate in half (and making UX worse, and paying in maintenance time and a higher defect rate, but those are harder to make them understand) with their twee UI, some can be steered away from it, or at least convinced to tone down the most-harmful parts.

Re:IDEs we had 30 years ago by rbanffy on Friday December 29, 2023 @01:22PM (#38808339)
> Part of what causes this crap is that the costs aren’t visible.

A billion times this. And this is when the next version of the design system isn’t incompatible with the previous one.

Re:IDEs we had 30 years ago by rbanffy on Friday December 29, 2023 @01:10PM (#38808182)
> Windows has several competing "official" UI libraries. Every library has a different look and feel, and all are in various stages of decomposition

I can’t fathom why they made the decision to push every style to a different rendering engine. Working on Windows gets you to see every look and feel and the deeper you go, the closer you get to Windows 2000.

Re:IDEs we had 30 years ago by lmpdev on Saturday December 30, 2023 @06:30AM (#38814421)
They dropped the ball because no major part of their current business model involves creating a better operating system for the sake of attracting new users

They seem to aim at minimising users leaving and maximising the extraction of data obtained per user

Re:IDEs we had 30 years ago by norswap on Monday January 01, 2024 @05:09PM (#38835786)
Hasn't there been a set of web components that tries to reproduce this?
Re:IDEs we had 30 years ago by indigochill on Friday December 29, 2023 @01:12AM (#38802224)
>and most importantly you don't need responsiveness

I'm gonna ask a dumb question out of ignorance because I know responsiveness is all the rage, but... what do we gain from it? Would it not be more straightforward to build UIs from the ground up for desktop and mobile targets than make one UI to morph to fit both?

Re:IDEs we had 30 years ago by alpaca128 on Friday December 29, 2023 @03:53AM (#38802957)
"Desktop" encompasses everything from ultrawide 8k monitors to 768p laptop screens where the user may have scaled down the browser window - and that's on brand new hardware, I know people who are still using 15+ years old laptops!

This alone means you either handle any window size and size ratio or your UI will break for some users.

Re:IDEs we had 30 years ago by rbanffy on Friday December 29, 2023 @01:25PM (#38808382)
> This alone means you either handle any window size and size ratio or your UI will break for some users.

You should spec your UI in device-independent units and let the GUI handle things like different pixel densities (or aspect ratios) and font sizes.

Re:IDEs we had 30 years ago by Osiris on Friday December 29, 2023 @02:20AM (#38802490)
There are many different screen resolutions. Being able to adjust the application based on available space makes the application usable to more people.
Re:IDEs we had 30 years ago by funcDropShadow on Friday December 29, 2023 @06:16AM (#38803824)
And it introduces new failure modes. I often experience responsive web applications hiding UI elements in my Firefox windows. Those windows usually use either the left or right have of a 28" 4k display. Why the heck do the hide the sidebar to save space? It is fucking annoying.
Re:IDEs we had 30 years ago by badsectoracula on Friday December 29, 2023 @11:42AM (#38806953)
In theory that sounds nice but in practice i haven't seen a single desktop application that can actually handle resolutions lower than whatever resolution the developer/designer used. I used a 1366x768 monitor for a long while ~3 years ago and everything looked both gigantic and had padding everywhere.

As for the web, responsive design was so great that in almost every site i had to zoom out to make it think i had a monitor with a bigger resolution than i really did.

These days and since i do not maximize the browser (because my monitor is huge - like all modern monitors that do not have awful image quality tend to be), i often have to resize the window because sites tend to think i'm using a mobile phone and instead of scaling down / hiding less important stuff (that would at least be appropriate for a narrower viewport) they make thing ultraginormous (because touch screens), overly padded out (because touch screens) and they hide all options behind a hamburger menu (because mobile screens are physically too small).

I'm certain there are theoretically ways to do it "right" (a friend web developer told me how but i forgot) but absolutely zero sites (that i visit) do that.

Re:IDEs we had 30 years ago by TeMPOraL on Friday December 29, 2023 @05:37AM (#38803615)
Responsiveness lets you target two platforms with shit UIs for the price of one good one*, which is what businesses want[0], per the good ol' "worse is better".

* - two for one up front, ongoing development and maintenance costs of modern responsive UIs is going to be much greater than doing things right 2 or 3 times, but those costs are beyond the next sprint, and pay the good chunk of salaries in this industry, so...

--

[0] - And, unfortunately, this thinking became the zeitgeist of software development, so OSS projects do the same.

Re:IDEs we had 30 years ago by HeavyStorm on Friday December 29, 2023 @05:43AM (#38803651)
That and the fact that web is built over a language for text, not UI. HTML is a terrible foundation for UI.
Re:IDEs we had 30 years ago by zeroc8 on Friday December 29, 2023 @05:57AM (#38803725)
That's why I'm still hoping on Flutter or something similar for actual web applications. But it's been a long time in the making, I'm not quite convinced it will ever be able to replace the more traditional stuff.
Re:IDEs we had 30 years ago by rbanffy on Friday December 29, 2023 @01:23PM (#38808357)
I have to disagree on that.

Most of the controls you have on the average GUI app are present in HTML. The big difference is that HTML describes active documents, not dialog boxes.

Re:IDEs we had 30 years ago by lou1306 on Friday December 29, 2023 @06:53AM (#38804020)
Uhhh, aren't native GUI toolkits "responsive" by definition? I remember in VB6 you could have elements take up a given % of its container, and I am pretty sure you could even make them appear/disappear programmatically (e.g., depending on container width). Sure you didn't have to make it work across a huge set of resolutions, but it was quite flexible still.
Re:IDEs we had 30 years ago by Shorel on Friday December 29, 2023 @08:07AM (#38804444)
wxWidgets sizers raise their hands!
Re:IDEs we had 30 years ago by jules22 on Friday December 29, 2023 @10:59PM (#38812721)
I liked Delphi's anchors. They were extremely simple, visually defined, and met all of my layout needs.
Re:IDEs we had 30 years ago by capr on Saturday December 30, 2023 @01:59PM (#38817838)
Those were nice because you would start with floating elements that you'd move around with the mouse until you'd figure out a good layout and then add the anchors at the end and make it all flexible. Delphi was all about having a smooth progression from mockup to prototype to production. Compared to it, current web workflows are outright retarded.
Re:IDEs we had 30 years ago by rbanffy on Friday December 29, 2023 @01:05PM (#38808116)
> GUIs are simple when you don't need to do any styling

Styling should be provided by the host, not the app. The app should give, at most, hints to the system - that this button is the default, what the tab key navigation order is, etc.

> Web front-end are a completely different game in that regard

They shouldn’t be. The API is different, because the presentation layer leaks all over the place into the app logic. With runtimes such as VB’s the UI elements see and react to events, while the runtime takes care of pushing those events either to the host software or to the event handlers that are part of the app.