I think this peaked some time around 2015. Back then, I remember many developers getting up in arms about following Apple's guidelines to a T, or insisting that Android apps look like a hyperactive stack of colorful paper cutouts under a direct light.

Since then, I think many of us have gotten tired of looking at overdesigned sameness that by now we all know will age quickly. Programmers no longer see the sense in chasing a perpetually changing visual standard for no reason other than "BigCo said so". Most importantly though, BigCos in question have fallen out of our good graces, and the "Design Systems" they keep pushing are now regarded as nothing but cynical branding exercises that come at the cost of UX.

You are right but at the same time I am willing to bet you 5 years later someone else will make the opposite argument and be upvoted the same.

It's a pendulum.

Maybe in 5 years one or two of those BigCos will be humbled by an upstart, or the state, or the market, or a previously humbled BigCo (cough Microsoft). Then, by necessity, their design systems will become once again driven by the needs of actual users and developers. That's the underlying pendulum.

I'd bet on the next UI standard being a cross-platform library. Electron-like, but with much more efficient stack, and with binding to multiple languages.

I'd bet on "if you can't beat em', join em". Reactive component-based architectures a la React/Vue have won. The DOM has won for the view layer too. And with wasm, you get your bindings to multiple languages. See: Blazor (it's just the first, more are coming). As for desktop apps that could benefit from proper concurrency, lack of a browser sandbox, full system access, etc. - server side Blazor is quietly pioneering a weird new paradigm - essentially running a headless browser in a regular process with full privileges, and then only doing vdom diffing inside the browser.

> The DOM has won for the view layer too

As a front-end dev, I'm not entirely sure I agree with that. The DOM has some annoying performance limitations, and I'd love to be able to use something better for rendering. I think what the DOM has shown, is that cross-platform and the ability to easily do custom look and feel are crucial.

the push isn't (just) about homogeny of look, it is about consistency for users. When your UI design is backwards (or even inconsistently backwards, such as when a user is in he-IL locale) or you label your Delete button OK on platforms where the user doesn't expect that, it makes using the app frustrating, inefficient, and error-prone

>cynical branding exercises that come at the cost of UX

Well put!

Personally I'm fine with application specific UI schemes. It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation.

The original point - that people would get confused from non-platform UI schemes - has been proven kind of moot since most games have their own domain specific UI schemes and people love them anyway.

> It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation.

They really don’t. Have you taken a look at the thriving ecosystem of native, powerful macOS apps that follow platform conventions?

Most apps that I know people use in MacOS are really not native-controls based - Ableton Live, Max/MSP, VDMX, Resolume, Mathematica, JetBrains IDEs, VSCode, Sublime Text...

I'm pretty sure the parent was talking about macOS exclusive apps. The ones I recognize there are all multi-platform, which have always had the problem of keeping their own conventions between platform or adopting the platforms--most chose to keep their app consistent platform-to-platform.

I also think "professional" apps are a special case (which is a totally subjective classification). Even Apple and Microsoft have done their own thing for professional apps since forever. If I'm going to use that app for 8hrs every day, I'm more accepting of learning something new. I'm still more likely going to pick up an app if it follows existing conventions...I already chose my OS because I've learned and like those conventions.

There are a couple that are cross platform and still native, such as Microsoft Office and the Affinity suite.

Microsoft Office has gotten way better over the years. They used to design the UX around the idea of "Office Users", not "Mac Users"

This is very frustrating when supporting a mixed team of Mac and PC users on office. I would prefer it to be the same everywhere.

And that's the problem. I imagine those Mac users chose it because they like the OS' conventions. Photoshop seems to have gone the other way from using OS conventions to doing their own thing the same on each platform. iTunes, which didn't always follow macOS conventions, did port everything to Windows.

You might have a point there, if at any time in their sordid history Apple actually followed any of their own UX/UI conventions in their flagship apps.

http://hallofshame.gp.co.at/qtime.htm

That example was 20 years ago, and Apple specifically discarded the skeuomorphic focus which that resulted from around six years ago (partly in concert with retina displays).

Do you have a more modern example?

My mac's primary purpose is to run bash, firefox, intellij, and docker. they've all got their own UI, and I don't feel wanting for power.

That’s not the assertion I was refuting, which claimed that Apple’s platform conventions restricted the power of apps.

> has been proven kind of moot since most games have their own domain specific UI schemes and people love them anyway.

I emphatically disagree. There are still jokes (from legitimate annoyance) that the main consoles have different conventions for buttons and button names. It's awkward to navigate menu system with a simple up, down, left, right, accept, cancel when accept/cancel move around system to system. At least on desktop computers Spacebar/Enter and Escape are mostly consistent.

As for in-game control schemes, it's generally coalesced around wasd + mouse and USE. Even with that there are jokes (stemming from legitimate annoyances) about putting down a game for a week because you're older, are a parent, and have other responsibilities, then having trouble picking it back up.

This is a major reason I'm incredibly selective about the games I play and one reason I avoid online play. Sure, I'm one data point, and it may not apply to a majority of the cashflow for gaming, but I see it expressed online quite often.

I hear you. I forget the control schemes as well, whether they are keyboard or controller.

But the thing about those is that they are 'hidden' and require memoization. There is no on-game HUD that would show legend of all the available actions all the time. If you could have that, then people would be much more comfortable about even the hidden schemes.

There are game UI:s that are mostly mouse operated, and expose the user interaction grammar using the game specific, visual UI narrative. My kids seem fine navigating between those. A great example is Roblox, which has lot of "controller heavy" games where there are custom UI:s for building and configuring lots of things.

There are no guidelines that the authors defer to, but, they organically try to make the UI:s as understandable as possible. Most of the time they copy established conventions anyway, and when they don't either the UI is still understandable or no-one will play the game.

I agree with this. Unfortunately that’s a designer bottleneck rather than anything else. Think of it this way, if somebody ends up with a mess of an Electron app, he or she probably wouldn’t have fared any better in usability with a native app even if the UI would look superficially ‘in-spec’.

Edit: Also as an example, Aether comes with plenty of shortcuts, or even has proper tabbing and tab highlighting for low-vision users. Electron prevents none of these, in fact the platform it’s based on, the DOM, is one of the most accessible platforms ever made in terms of support. Whether people actually make use of it it is another matter.

I wouldn't necessarily say it's just the way it looks, it's also how things work that you get for "free" when you use the native UI toolkit.

Examples would be shortcuts, tabbing through form fields, how a file explorer works and other small things. The file explorer in VSCode for example doesn't really behave like a native one, you have to manually refresh, you can't easily drag and drop and everything just feels a bit off.

Just last week I added shortcuts to our MacOS and Windows Electron app in about 15 minutes. I didn't read any documentation and I'm not even a developer, just a designer. I can barely make a proper if loop in js and I can't tell the difference between a method and a function either.

Electron is sooo simple. I mean, we've run into some pretty interesting issues like with hardware acceleration and difference in color and font rendering between platforms, but if a guy like me can code, sign and ship a fully functional application, anyone can.

Also, I can really recommend Vue and Quasar for anyone looking at building electron and mobile apps. Really fun!

There’s a lot more to getting an app to feel native than just shortcuts, unfortunately. A native platform toolkit will do the right thing for your platform, sometimes even if you don’t know what the right thing is or that it exists.

I completely agree with this. As a blind screen reader user, Electron apps are 90% inaccessible to me and other screen reader users. Screen readers (on any platform) interact with the underlying libraries/ frameworks. Every operating system supports its own native toolkit. It's a shame that Java's SWT framework fell out of favor for cross-platform software. That is quite accessible. Unfortunately, blind screen reader users are overlooked when it comes to these types of underlying frameworks.

That would have been me 18 months ago. But since dropping macOS I've become indifferent to platform conventions. I will never become hostage to a single platform again. Which (admittedly by a very different route) puts me more in touch with ordinary users, who for the most part don't care or notice.

Really, that's not an issue with Electron, I think. You can perfectly well make use of a common platform toolkit and still make a completely counter-intuitive UI - and people did that, a lot. In the end, the important things are things like that the cancel button is on the left and the button to confirm is on the right (depending on your platform), not whether it's grey or blue.

And I'd even argue that, with the freedom Electron gives you, app developers have started to actually pay attention to their design, rather than just using the standard toolkit and considering it done - so Electron apps often have better UI. I'd take VSCode's UI over Geany's any time, for example.

To be honest, native MacOS UI doesn't even look good compared to the great styling you can get with HTML/CSS.

Native UI toolkits are not necessarily about looking beautiful for every app, they are about consistency, accessibility and letting the user expect how certain things work and can be found at. They have to fit to a lot of constrains that a single app doesn't have to.

Yes grey text on a white background can look great on a retina screen, but does it look good across the product range from the last 7 years and all devices, lighting conditions and for people with various disabilities?

I'm intrigued by this. How do you cope with the www?

I use web apps so often that Electron looks natural