The end of the nice GTK button

    Taskbar: explorer.exe
    Start menu: StartMenuExperienceHost.exe
    Searching: SearchApp.exe

Perhaps keystrokes are lost during the switch.

This is exactly what I was “hinting” at when I said coming up with a universal function that would work for anything. You can’t just snap some/all things to a pixel grid; it would look absolutely terrible because it would make lines and whitespace uneven. Even font autohinting, which does exist, is more sophisticated than just aligning key control points to a pixel grid.

> Much of the complexity you point out only arises because we now insist on having physically sized rendering for "mixed-DPI" graphics, like a single window spanning both a low- and a high-resolution display. That's not necessarily a very sensible goal, and it's not something that would've been insisted on back when achieving "pixel perfect" rendering was in fact a major concern, regardless of display resolution.

It’s not. Even under Wayland, which can achieve this, the application would only render one surface at a specific resolution at any given time. Nothing I’ve been talking about is related to being able to split a window across different DPI screens.

> A similar concern is the demand for arbitrary subpixel positioning of screen content, that basically only matters in the context of on-screen animations. Nobody really cares if an animation looks blurry, but it's somewhat more important for static content to look right. Trying to have one's cake and eat it too will always be harder than just focusing on what's actually important for good UX.

If you scale a UI that was designed for 96 DPI pixels to a screen that is around 160 DPI, you already have subpixels. If you then attempt to snap to a pixel grid instead of rendering elements at subpixel positions, then you have uneven, ugly looking UI elements.

This unevenness is arguably more tolerable for text than it is for UI elements, but Microsoft actually took the approach of not having it for text regardless; to make text look cleaner, text uses more aggressive gridfitting in Microsoft UIs, resulting in each glyph being gridfit. This is exactly why old Windows UI scaling lead to cut off text and other text oddities; it’s because the grid fitting lead to text that had different logical widths when rendered at different resolutions!

You can’t just wish away subpixels. Numbers that just happen to be whole numbers are the real edge cases in a world with arbitrary scale factors.

Today, every application seems to just do its own thing, and continually churns its own UI, chasing trends.

There was a time when an elderly relative would say “computers are too hard to use”, and I could recommend a book or manual that would help make it clearer.

Nowadays I tend to just agree with them.

> If it's not obvious, it's probably not a critical feature, just a nicety for those who discover it.

There is a huge difference between discoverability and hierarchy. If the user can't distinguish between an interactive element and a static label, the UI has failed. But there is definitely nuance in the degrees of hierarchy and importance. If every button looks the same with every affordance necessary for a user to recognise it as such, it might be great in terms of discoverability, but in most cases it would still be bad design because as a user I can't easily distinguish between primary, secondary or tertiary actions.

This is of course also highly dependent on the business goals and overall context of the design. If you have a marketing page you might want to clearly distinguish actions that lead to the sign up or download of your product (this – in most cases – is what you would like your users to do and also what your users eventually want to do themselves). If you have enterprise software that is highly customizable and completely different for each and every individual, you might want to shy away from opinionated hierarchy of importance. In this case, it would be very much dependent on the user and therefor their choice.

Typically the context is – at scale – more on the former side than the latter. If I have, for example, a notes app I would say the hierarchy favors the creation of new notes rather than going into settings to change the appearance of my notes. That doesn't mean it shouldn't be discoverable, only that the design should clearly dictate what's more important (especially on a temporal dimension: I'll add notes more often than I would edit the style) and therefor influence the appearance of both actions.

Let me know what you think.