6 ms·

The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer instead of the design system layer. WinForms, WPF, UWP, WinUI

The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer instead of the design system layer. WinForms, WPF, UWP, WinUI -- each one a new framework, each one eventually abandoned. Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.

gunsle 6mo ago
Insightful comment
GaProgMan 6mo ago
I agree. Except that WinForms has not been abandoned. In fact, it's one of the supported paths in the modern .NET stack.
- Dwedit 6mo ago
  WinForms is a layer built on top of raw Win32. So it's not portable. Even though Wine exists, Win32 calls can only be made from Win32 programs, not native Linux programs. So a WinForms app using the latest dotnet would need to run the Windows version of dotnet under Wine, and not use the Linux version of dotnet.
  - DeathArrow 6mo ago
    >WinForms is a layer built on top of raw Win32. So it's not portable. Neither are SwiftUI and AppKity.
  - pjc50 6mo ago
    True, but: Microsoft haven't made a better UI framework that's portable to Windows yet. Everything after WPF has near zero adoption, including (critically important!) by Microsoft itself.
  - anthk 6mo ago
    Mono used to have libwine embedded. You know, libwine exists as a library running and compiling Win32 natively under Unix. Instead of PE binaries you would run ELF Linux ones, but with nearly the same outcome.
    - Dwedit 6mo ago
      Every time I tried following alone with the winelib/winemaker documentation, I always ended up with an ELF that had to be invoked using "wine" to run. Nothing that could self-load any of the wine dependencies.
      - anthk 6mo ago
        Mono supported WinForms. But IDK how did they integrate it with the CIL. But for sure they used WineLib.
- zerr 6mo ago
  It lacks hardware acceleration.
  - RedShift1 6mo ago
    Does it need it?
    - zerr 6mo ago
      Good point. Akin to Qt Widgets - it doesn't really need it on desktop. HW acceleration is crucial on mobile, but WinForms doesn't have a story there.
TiredOfLife 6mo ago
> Apple solved this This comment written before Tahoe
- dagmx 6mo ago
  Snide and subjective comments aside, you’ve clearly missed their point. Even if you take away subjective opinions on Liquid Glass, the point is that the core system updates things across the board. Unless apps have implemented custom drawing, you get a consistent-ish UI (for better or worse) across the system, whereas with windows you are beholden to whatever hodge podge of UI frameworks were chosen at the given time.
  - direwolf20 6mo ago
    That's a bad thing. It breaks apps. Apple has decided to stop supporting apps that aren't continually updated. Microsoft hasn't.
    - audunw 6mo ago
      I don’t think Microsoft’s approach to perpetually support old apps is unequivocally a good thing. It seems to be getting them into a deeper and deeper mess over time. As a consumer I prefer Apples approach. If I were an industrial customer relying on old software to operate my machines i would prefer Microsoft’s approach.
  - TiredOfLife 6mo ago
    The size and losition of the traffic lights control is not dependent of the os the app runs on but on the os the app was compiled on. So things are not updated across the board
    - dsego 6mo ago
      I found this out when I tried running an old app I compiled on MacOS several years ago, it still has the old title bar gradient and traffic light.
    - 6mo ago
pjmlp 6mo ago
Being a 70's child, in computing since the mid 80s you made me almost spill my Monday coffee. What a laugh, do you want the examples on Apple's side?
- Iulioh 6mo ago
  The evergreen question of "how do you go back and/or close an app on IOS?"
  - bayindirh 6mo ago
    It's still easier than Windows CE though.
  - mckn1ght 6mo ago
    Maybe just the circles I run in but these are not evergreen questions in my experience. I don't even know what "go back" is supposed to mean here, or for that matter what it would mean in a Windows application. Is there a system level "go back" in WinAmp/Excel/SimCity/Photoshop I've never seen before?
    - Iulioh 6mo ago
      I was referring to IOS, not MACOS Androids do have universal back button at the bottom on the phone or the same swipe gesture if you want but iphones do not. Sometimes swipe (the direction and position is a guessing game), sometimes and x (right or left ) and the behavior is inconsistent too (back or close) There are some guidelines but more often than not seems like every app has it's own method and you need to get used to it
      - bayindirh 6mo ago
        In iOS, task manager and closure can't be overridden. You swipe right to return to previous application. You can swipe left for a couple of seconds if you didn't intend to do that. You swipe up and remove the application from the stack, all processes of the application is killed. Background processing has strict limits, and you need permissions to run longer than that, and for some use cases, there are no recourse. OS swaps you out or freezes the app. If you want an app to work in the background, don't kill it, period. Push notifications are handled by the OS and is not hindered by this.
Kwpolska 6mo ago
You can't just take 40 years of Win32 apps and add the Metro design language, touchscreen compatibility, or dark mode system-wide. WPF nowadays has a skin that imitates WinUI, so at least Microsoft is trying.
- gf000 6mo ago
  Sure, but you could have had a uniform design language for the last 3 or so frameworks.
- solarkraft 6mo ago
  Right, but you can make basic adjustments to the theme to fit the rest of the system better, which took them all the way until Windows 11 to realize.
bartread 6mo ago
> The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer I really don't think that's the fundamental issue. TFA points out, and I agree, that the fundamental issue is political: competing teams across different divisions coming up with different solutions to solve the same problem that are then all released and pushed in a confusing mishmash of messages. I haven't written a line of code for a Windows desktop app or extension since early 2014, when the picture was already extremely confusing. I have no idea where I'd begin now. My choice seems to be either a third party option (like Electron, which is an abomination for a "native" Windows app), or something from Microsoft that feels like it's already deprecated (in rhetoric if not in actuality). It's a million miles from the in the box development experience of even the late zero years where the correct and current approach was still readily apparent and everything you needed to move forward with development was available from the moment you opened Visual Studio. There's just so much friction nowadays, starting with the mental load of figuring out the most acceptable/least annoying/most likely still to be supported in 5 - 10 years tech to use for solving the problem.
- sizeofdouble 6mo ago
  Honestly, things like Electron are quite literally the problem! All of people’s modern desktop woes begin and end at the browser. Here’s why: the late 2010’s push into the cloud made JavaScript all-the-rage. A language the creator made in pretty much a weekend coding session. There naturally is major business incentives powering this. SaaS made things MUCH easier for delivering software. Fast forward 15 years and MSFT is full in on TypeScript. It’s a disease that starts with MsOffice and percolates to the whole OS (same as what’s happening in copilot). .Net is actually elegant in many ways. You have PowerShell, VB .Net, C#, F# etc. languages of many paradigms all targeting the same bytecode (and supported by the OS). And this is being replace by a fun little JavaScript thingy.
  - cedilla 6mo ago
    That may be how JavaScript started, but unless your claim is that JavaScript hasn't changed at all in the thirty years or so since then, your argument is a complete non-sequitur.
atoav 6mo ago
The deeper problem is that all these layers are still in use somewhere within Windows. Try to give your Ethernetcard a fixed IP Address for example. On your way to the correct setting (which has visually looked that way when I was still going to school) you will move through maybe 3 or 4 layers of UI paradigms like a freaking media archeologist. Each of the newer layers dumbed things down and kept the old thing as a fallback. Meanwhile in MacOS they dumb things down without a fallback. The only people who appear to make serious attempts at improving the usability of computers are the likes of KDE and other Linux desktop environments. It used to be the way that Linux was the thing you used despite its shortcomings compared to commercial OSs..

gunsle 6mo ago

Insightful comment

GaProgMan 6mo ago

I agree. Except that WinForms has not been abandoned. In fact, it's one of the supported paths in the modern .NET stack.

Dwedit 6mo ago
WinForms is a layer built on top of raw Win32. So it's not portable. Even though Wine exists, Win32 calls can only be made from Win32 programs, not native Linux programs. So a WinForms app using the latest dotnet would need to run the Windows version of dotnet under Wine, and not use the Linux version of dotnet.
- DeathArrow 6mo ago
  >WinForms is a layer built on top of raw Win32. So it's not portable. Neither are SwiftUI and AppKity.
- pjc50 6mo ago
  True, but: Microsoft haven't made a better UI framework that's portable to Windows yet. Everything after WPF has near zero adoption, including (critically important!) by Microsoft itself.
- anthk 6mo ago
  Mono used to have libwine embedded. You know, libwine exists as a library running and compiling Win32 natively under Unix. Instead of PE binaries you would run ELF Linux ones, but with nearly the same outcome.
  - Dwedit 6mo ago
    Every time I tried following alone with the winelib/winemaker documentation, I always ended up with an ELF that had to be invoked using "wine" to run. Nothing that could self-load any of the wine dependencies.
    - anthk 6mo ago
      Mono supported WinForms. But IDK how did they integrate it with the CIL. But for sure they used WineLib.
zerr 6mo ago
It lacks hardware acceleration.
- RedShift1 6mo ago
  Does it need it?
  - zerr 6mo ago
    Good point. Akin to Qt Widgets - it doesn't really need it on desktop. HW acceleration is crucial on mobile, but WinForms doesn't have a story there.

TiredOfLife 6mo ago

> Apple solved this This comment written before Tahoe

dagmx 6mo ago
Snide and subjective comments aside, you’ve clearly missed their point. Even if you take away subjective opinions on Liquid Glass, the point is that the core system updates things across the board. Unless apps have implemented custom drawing, you get a consistent-ish UI (for better or worse) across the system, whereas with windows you are beholden to whatever hodge podge of UI frameworks were chosen at the given time.
- direwolf20 6mo ago
  That's a bad thing. It breaks apps. Apple has decided to stop supporting apps that aren't continually updated. Microsoft hasn't.
  - audunw 6mo ago
    I don’t think Microsoft’s approach to perpetually support old apps is unequivocally a good thing. It seems to be getting them into a deeper and deeper mess over time. As a consumer I prefer Apples approach. If I were an industrial customer relying on old software to operate my machines i would prefer Microsoft’s approach.
- TiredOfLife 6mo ago
  The size and losition of the traffic lights control is not dependent of the os the app runs on but on the os the app was compiled on. So things are not updated across the board
  - dsego 6mo ago
    I found this out when I tried running an old app I compiled on MacOS several years ago, it still has the old title bar gradient and traffic light.
  - 6mo ago

pjmlp 6mo ago

Being a 70's child, in computing since the mid 80s you made me almost spill my Monday coffee. What a laugh, do you want the examples on Apple's side?

Iulioh 6mo ago
The evergreen question of "how do you go back and/or close an app on IOS?"
- bayindirh 6mo ago
  It's still easier than Windows CE though.
- mckn1ght 6mo ago
  Maybe just the circles I run in but these are not evergreen questions in my experience. I don't even know what "go back" is supposed to mean here, or for that matter what it would mean in a Windows application. Is there a system level "go back" in WinAmp/Excel/SimCity/Photoshop I've never seen before?
  - Iulioh 6mo ago
    I was referring to IOS, not MACOS Androids do have universal back button at the bottom on the phone or the same swipe gesture if you want but iphones do not. Sometimes swipe (the direction and position is a guessing game), sometimes and x (right or left ) and the behavior is inconsistent too (back or close) There are some guidelines but more often than not seems like every app has it's own method and you need to get used to it
    - bayindirh 6mo ago
      In iOS, task manager and closure can't be overridden. You swipe right to return to previous application. You can swipe left for a couple of seconds if you didn't intend to do that. You swipe up and remove the application from the stack, all processes of the application is killed. Background processing has strict limits, and you need permissions to run longer than that, and for some use cases, there are no recourse. OS swaps you out or freezes the app. If you want an app to work in the background, don't kill it, period. Push notifications are handled by the OS and is not hindered by this.

Kwpolska 6mo ago

You can't just take 40 years of Win32 apps and add the Metro design language, touchscreen compatibility, or dark mode system-wide. WPF nowadays has a skin that imitates WinUI, so at least Microsoft is trying.

gf000 6mo ago
Sure, but you could have had a uniform design language for the last 3 or so frameworks.
solarkraft 6mo ago
Right, but you can make basic adjustments to the theme to fit the rest of the system better, which took them all the way until Windows 11 to realize.

bartread 6mo ago

> The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer I really don't think that's the fundamental issue. TFA points out, and I agree, that the fundamental issue is political: competing teams across different divisions coming up with different solutions to solve the same problem that are then all released and pushed in a confusing mishmash of messages. I haven't written a line of code for a Windows desktop app or extension since early 2014, when the picture was already extremely confusing. I have no idea where I'd begin now. My choice seems to be either a third party option (like Electron, which is an abomination for a "native" Windows app), or something from Microsoft that feels like it's already deprecated (in rhetoric if not in actuality). It's a million miles from the in the box development experience of even the late zero years where the correct and current approach was still readily apparent and everything you needed to move forward with development was available from the moment you opened Visual Studio. There's just so much friction nowadays, starting with the mental load of figuring out the most acceptable/least annoying/most likely still to be supported in 5 - 10 years tech to use for solving the problem.

sizeofdouble 6mo ago
Honestly, things like Electron are quite literally the problem! All of people’s modern desktop woes begin and end at the browser. Here’s why: the late 2010’s push into the cloud made JavaScript all-the-rage. A language the creator made in pretty much a weekend coding session. There naturally is major business incentives powering this. SaaS made things MUCH easier for delivering software. Fast forward 15 years and MSFT is full in on TypeScript. It’s a disease that starts with MsOffice and percolates to the whole OS (same as what’s happening in copilot). .Net is actually elegant in many ways. You have PowerShell, VB .Net, C#, F# etc. languages of many paradigms all targeting the same bytecode (and supported by the OS). And this is being replace by a fun little JavaScript thingy.
- cedilla 6mo ago
  That may be how JavaScript started, but unless your claim is that JavaScript hasn't changed at all in the thirty years or so since then, your argument is a complete non-sequitur.

atoav 6mo ago

The deeper problem is that all these layers are still in use somewhere within Windows. Try to give your Ethernetcard a fixed IP Address for example. On your way to the correct setting (which has visually looked that way when I was still going to school) you will move through maybe 3 or 4 layers of UI paradigms like a freaking media archeologist. Each of the newer layers dumbed things down and kept the old thing as a fallback. Meanwhile in MacOS they dumb things down without a fallback. The only people who appear to make serious attempts at improving the usability of computers are the likes of KDE and other Linux desktop environments. It used to be the way that Linux was the thing you used despite its shortcomings compared to commercial OSs..