Yet the Winamp UI gets more love than almost any software in history.

It is my recollection as well. Most applications used VB, Delphi, MFC etc. that all had the "native" OS look and feel. There were some exceptions like WinAmp and others, but from what I can remember most applications were more consistent than today.

Early 90's, especially on Amiga -- where a proper windowing desktop env ("workbench") coexisted with the wildest custom UIs. Maybe it was the roots of the machine, heavily used as a games console and a demoscene workhorse? It seems like at that time there was so much creative design effort put into UX -- and it didn't seem to get in the way, maybe because each genre of software was kind of on the cutting edge back then, establishing what would eventually evolve into conventions. Mod trackers, image editing, disk copying, etc. Maybe it's a bit of nostalgia, but it felt really immersive to pull up a piece of software you were familiar with; each UI was so distinct and purpose-built, but it also had.. flourish? style? soul? Not so much now.

Nah, the Windows ecosystem never even got close to being consistent.

MS Office had its own UI toolkit and routinely invented new UI paradigms that weren't exposed in any Windows API, leaving people who wanted to look native scrambling to reimplement. This was particularly the case for toolbars. MS Office first invented the so-called "coolbar" and then the ribbon. Internet Explorer also rolled its own toolbar styles in ways not supported in the base Windows API e.g. toolbars with large icons and sliding sub-sections. Inventing custom toolbars was practically a sport on Windows; Netscape also did it.

At the time the most popular media players were WinAmp (totally custom and themeable to boot), RealPlayer (custom UI https://andrewnile.co.uk/blog/remembering-realplayer/), Quicktime (custom UI) and Windows Media Player (mostly but not entirely native).

Even the base utilities that came with Windows weren't consistent with each other. It wasn't uncommon in the Win 9x era to find programs still using Win3.1 style file dialogs ... a few are still buried in Windows today!

The problem got worse when you examined the artwork. The stock icon library in Windows was anemic, so dev platforms frequently had to expand the core library with their own. Delphi apps could be easily identified by the distinctive icons in their buttons (https://zarko-gajic.iz.hr/wp/wp-content/uploads/2017/02/delp...).

Restyling window decorations was also very common. Microsoft themselves did it routinely, for example their flagship Encarta encyclopedia app had totally custom widgets and window styling: https://winworldpc.com/product/encarta/1999

To get online most users were running something like CompuServe (custom web-style main UI https://thedayintech.wordpress.com/wp-content/uploads/2013/0...), or AOL (custom UI https://www.reddit.com/r/nostalgia/comments/ehxb1g/the_aol_h...), or MSN (custom UI https://cdn.prod.website-files.com/6179a66d5f9cc70024c61878/...)

Windows apps of this era were much like web apps are today: they shared some common code for things like rendering menus, buttons or widgets in their settings screens, but the main UI users interacted with were almost always custom widgets that were extremely varied between apps. Win32 was nearly impossible to style compared to HTML so this represented a large investment of developer time, but a custom branded UI was believed to be worth nearly any cost. This is something fundamental to how humans work and is pointless to fight, a lesson the web platform fully embraced giving it an advantage over other UI toolkits of the era.

The mental overhead from having slightly different drop shadows and button sizes is minimal, and I think pretty overblown by people who prefer identical UIs for everything regardless of form factor (which is of course a valid take).

But someone could just as easily respond to today's UIs with "Yes, it's wonderful that every single app looks identical, as if it was all designed by one pretty boring artist with no creativity whatsoever" and that would also be a perfectly valid take.

Do you have a solution in mind? While a platform (OS) can provide a UI toolkit and provide a HIG, one cannot stop language and programming tools vendors or programmers from doing whatever they like.

Maybe using computers is not for you.

I'll take hiding the scroll bar over not even handling mouse scroll events any day of the week

No-one would claim building a web browser is easier than putting some widgets together in Win32/Cocoa/GTK+/whatever, yet here we are with Electron.

But you're describing pretty much every UI toolkit!

File Pilot has got to be the biggest fuck-you to modern app development practices I've seen in a long time.

The GNOME project seems like it has a strong desire to converge all on-screen UI onto mobile-like patterns. There are some mobile conventions that can be brought over to desktop without impairing usage too much but I think that perhaps it’s starting to cross too far over to the mobile side of the line.

It’s unfortunate because in other ways I find GNOME/GTK more agreeable than KDE/Qt (layout of controls within windows is consistently better in GTK environments/apps for example, Qt apps have a tendency to feel slapdash/haphazard/“engineery”) but I don’t like the increasingly strong mobile influence.

This is where it’s useful for the menu bar to be system-owned rather than the responsibility of individual programs (whether that be a global bar as in macOS or attached to window decorations). That would make it easy to implement a toggle that hides menubars either globally or on a per-app basis and enable a Unity-type shortkey-summoned HUD to be used instead.

Even on mobile, in most situations there are better UX choices than hamburger menus. Nearly every app using them I’ve encountered has put as little thought into navigation and UI hierarchy as possible and are awkward to get around in. They’re the ones where one has to go down a winding ever-changing maze to access the desired functionality.

Most would be better served by surfacing the most commonly used screens as tabs and most commonly used functions within those tabs. Ideally 2-4 taps is all it should take to get anywhere, and there should only ever be a tiny handful of niche things that take 5+ taps to access.

For most emails, yes. Some other emails, no. I don't know what determines when it works and when it doesn't.

It provides a quick feedback loop when you're trying to poke at stuff on-screen with your fingers. Which is nice since it lets you know quite seamlessly (1) how good your aim is, which gets kind of critical when using fingers on a touchscreen compared to a mouse. and (2) whether a tap has even registered in the first place, which is often problematic for many users who may be wearing gloves, have drier skin that doesn't register as easily, etc. etc.