MacOS apps feel pretty wrong to me.
Some don't remember which screen they should be on, and always go to that screen at a predetermined size and geometry (tkdiff).
Others expand incorrectly to full-screen (macvim) when moved to a different screen.
VSCode doesn't behave like the native apps.
The list goes on, I'm short on time.
> And I couldn't care less.
You caring or not doesn't make the problem go away - native widgets always feel less wrong than non-native widgets.
And if you are on macOS doing any kind of design work, this is your mode of working. People using Photoshop or any 2D/3D DCC etc. You use all the screen space real estate on any number of screens you have. But even if I write code I run VSCode in full screen. If I have a dual screen setup I usually have one screen with two code editors, mini map & folders + terminal on screen two. But that's it.
But even assuming you run apps side by side/stacked whatever so you could actually visually see how non-native/different they look. Is that the real issue on macOS today? Personally the main gripe I have is that -- and kindly pardon the tangent -- macOS native window management is shite. One of the first things people that come from a *nix desktop buy/install, when they switch to macOS, is a proper (possibly tiling) window manager.
But back to widgets/look: in DCC apps the main sort of dialog you interact with are attribute editors where you change properties of an object or node.
I like to refer to an issue on the egui crate which has some of the best out-of-the-box support for this kind of widget composition[1].
Apple Human Interface (AHI) guidelines do not have any handrails on how these attribute editors should look or be done. The best you can do is go with dialog AHI guidelines and these fall short for this sort of window. I can go into great detail here why but it's beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from.
Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps.
They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co.
IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'.
can you provide some examples on desktop? Touch maybe, but that is not used on desktop, afaik.
I mean stuff that is common enough to deserve a defintion and a best practice laid out in a human computer interface (HCI) guideline document for a platform/OS.
Off the top of my head:
Tab closing behaviour on Chrome/FF. Close a tab, other tabs shift but don't change size immediately so you the next tab's close button is directly under the mouse and can bel clicked to close another tab (and another, and ...).
Another one: the typical chat app with servers/groups/contacts on a list on the left and the chat on the right (and possibly threads on the far right).
There is no good standard for this, everyone cooks their own soup so stuff you learned for Slack doesn't apply in Discord etc. I.e. it's a pattern of some sort but there are no Windows/macOS/Qt/GTK interface guidelines covering this case and/or suggesting best practices. This includes e.g. platform standard keybindings to select stuff in such apps (at best Tab switching works).
Another one is use of (some) Markdown-inspired stuff in chat apps. I.e. `monospaced` ```monospaced multline``` or even ```<language for syntax highlighting> ...```.
In Slack ``` works but ```<lang> doesn not (but does in Discord, used to work in Slack in the past, I think).
I think there are many such patterns that are maybe not as groundbreaking than the invention of tabs (90's?), combo boxes/menus (also 90's? When there are too many choices for radio buttons) etc.
But beause they are used in some form (or another, unfortunately) by many apps now, the OS vendors should define a best practice for implementing their end-user facing functionality/behavior in their HCI guidelines.
Even if the platform itself doesn't provide a ready-made widget for each such case.
Hope that makes sense and explains what I meant.
