What I find must puzzling is that everyone seems to just be violating basic rules that had been in place for ages.
Things like:
- If you can't respond to a UI event wait until you can
- Menus should be tree structures
- Pressing alt should underline the hotkeys you need to access anything clickable
As well as just basic responsiveness or predictability. A 2000 era windows application may not have been pretty, and may well have several different styles all imitated from office, but at least I knew what everything did and when it was slow at least it did what I expected.
This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen. Nowadays that has no chance of working because even to log in I need to press enter or click some button (which one depends on how I logged in previously, maybe) before I can even start typing and doing so eats a random amount of keystrokes while the damn log in screen loads to do its one damn job.
It's because we went from the Desktop environment, where rules were well-documented and standardized, to the Web/Mobile environment, where rules had to be reinvented and, for the most part, were not.
Over the past year I've started thinking a lot more about design and UI work, and I think it's basically impossible to design things, or create design systems, that appeal broadly to different types of users in a cross-platform way.
I personally love dense UIs and have no expectation of doing certain kinds of work on a phone or low-powered device like a chromebook, phone, or bottom-barrel laptop. But if you're a company trying to sell products to a broad user base, you want to try to design in a way that works for those kinds of users because they still might be end-users of your product. And there's a good chance that those platforms may be where someone first evaluates your product (eg from a link shared and accessed on a mobile device) even for the users who do plan on using more powerful desktop devices to do their work.
So instead we get these information poor, incoherent (because it turns out proper cross-platform, cross-user design is much more difficult than just getting something that works cross-platform for all users on its surface) interfaces. I guess I'm writing this just to add, web/mobile have complicated things partially because more than just requiring their own distinct patterns, they each represent a distinct medium that products try to target with the same kind of design. But because they're different mediums, it's like trying to square a circle.
It is absurd that there is no standardized UI toolkit, or rather that the web browser _is_ the standard with is characteristic _lack_ of user interaction idioms.
The fact that there are multiple platforms for UIs* is a huge failure of the industry as a whole. Apple, Microsoft and Google could have had a sit down together at any point in the last 20+ years to push some kind of standard, but they decided not to in order to protect their gardens.
*: a standardized UI platform doesn't necessarily mean a standardized platform. Just standardization of UI-related APIs and drawing.
My guess 10 or so years ago was that Google would be the first to bake Material UI into browser with web components, and then any browser would essentially reuse that to extend out whatever style they wanted. It really seemed like the way the web (and Google was heading). Instead we got bad Material UI knock-offs in about 45 different UI frameworks.
I'm not convinced that it's possible to create a UI toolkit that works on both desktop and mobile without one compromising the other. It's a bit like trying to design a vehicle that can serve both as a 2-ton pickup truck and as a golf cart; the needs of the two are just too different.
Another reason is that in 2000 if you wanted pointless UI wank you had to implement it yourself from scratch. Today with bloated frameworks where the developers ran out of ideas 15-20 years ago and have filled the intervening time adding wank that no-one asked for and no-one needs, everything you build with it gets to include every brain fart someone had at 4am back in 2017 that they thought looked cool at the time.
> basic rules that had been in place for ages. Things like: [...]
I am going to add my favorite here, just to rant into the void. A dialog box's options must never be Ok/Cancel. These are not the same sorts of things. "Cancel" is a verb, "Ok" is a noun (in this context). Even if "Ok" is taken to mean the verb "acknowledge", it is still not an alternative to cancelling.
99% of these dialogs should be "[Verb]/Cancel": Change "Ok" to a verb or short phrase indicating the action that will be taken if you press it. Don't do the action if the user hits "cancel". The verb should be something specific like "Delete file" or "Terminate process" and not something useless like "proceed".
IMO the ubiquitous Yes/No/Cancel is even worse. No and Cancel are too conceptually close. Doesn't help that these usually show up when you're about to lose all your unsaved changes.
We've got big screens now! use more words! Save changes/Discard changes/Don't quit.
I understand those prompts perfectly fine, but they are panic inducing for e.g. my mom who has about a 50% chance of clicking the wrong button and losing work.
We've ended up in a world where power users have been forgotten. Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
I would argue that desktop is the platform for power users, and its future depends on them. The keyboard shortcuts, the micro-interactions, the window management -- this stuff is all important when you're using a system for 8+ hours per day.
Yet we risk desktop experiences becoming less useful due to the UI becoming "dumber" as we keep shoehorning websites onto the desktop. Website UI is dumb. It's mouse driven, keyboard is an afterthought. There's no consistency, and you have to re-invent the wheel every time to get the details right (almost never happens).
>We've ended up in a world where power users have been forgotten.
I think its more like the OS vendors have stopped being operating system vendors, and are now - instead - vendors of eyeballs to advertisers.
The less the user is GUI'ing, the more they are just watching, placid, whatever else is on their screen.
For native apps to survive, they need to not be platform-specific - i.e. web apps, which require a browser and all its responsibilities - but rather cross-platform, reliable, predictable on all platforms - i.e. dissuaded from using native, but rather bespoke, UI frameworks.
This is attainable and there are many great examples of apps which are in fact, old wheels not re-invented, which still work for their particular user market.
I have the most respect for apps I can use on MacOS, Windows, and Linux - with the same hotkey/user experience on all platforms, equitably - and the least respect for apps which 'only run on one of them', since that is of course nonsense in this day and age.
The cognitive load of doing a web app that can do all the things a native app can do, is equivalent to the load required to build a cross-platform app using native frameworks, so ..
> I have the most respect for apps I can use on MacOS, Windows, and Linux - with the same hotkey/user experience on all platforms, equitably - and the least respect for apps which 'only run on one of them', since that is of course nonsense in this day and age.
No. I want things like keyboard shortcuts to reflect the platform norms of where the app is running (macOS in my case). A shared core is fine, but the UI framework must be native to be acceptable. Ghostty is a "gold standard" there.
This is why most web apps are lowest-common-denominator annoyances that I will not use.
Indeed, if the framework is sensible, keyboard shortcuts reflecting platform norms is entirely attainable in a manner that developers don't have to bother with it, much, if they don't want to.
There are plenty of examples of cross-platform UI's surviving the hotkey dance and attaining user satisfaction. There are of course poor examples too, but that's a reflection of care, not effort.
>i.e. dissuaded from using native, but rather bespoke, UI frameworks.
Based on my experience, I would be quite reluctant to rely on any non-native cross-platform desktop UI framework that is not web-based. These tend to be either less performant, look outdated or are bug-ridden.
Qt apps don't feel great on macOS, though it's by far the best for mac-ish UI. Dropbox was Qt for a long time and I'd argue it worked well for them. Its easy to fall into "uncanny valley".
On Linux, Qt apps feel a bit off in GNOME, though you can never satisfy everyone as its the wild west.
I think Qt also suffers from not really being anyone's favourite.
On the one hand, you have web developers who tend to not really appreciate the nuance of the desktop as a platform. They're not going to advocate for Qt, it's not CSS/HTML/JS.
On the other hand, you have native Mac developers who love Apple's toolkits (AppKit, maybe SwiftUI). They're not going to advocate for Qt either.
Lastly, you have native Windows developers who have been burned so many times they don't advocate for anything in life anymore.
QML is an entirely separate widget toolkit that really isn't a great fit for desktop programs - it's not much different from using a web-based toolkit.
QML doesn't have a way to define interfaces with JSX and doesn't integrate with the wider JS tooling. From my very limited experience, it still feels too close to the C++ world.
That's your prerogative, but web-based UI's have their hard limits, and native cross-platform desktop UI's are no more/less problematic than the browser.
Mozilla removed a lot of power-user features and customization from Firefox claiming that their telemetry showed that few users used them. That's the reality now, nobody wants to develop and maintain things for the 1%.
> We've ended up in a world where power users have been forgotten. Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
Power users are less susceptible to suggestion and therefore less profitable. They have largely moved to OSes that do not interfere with their wishes, allowing them to make their own choices about what they can or can't do/run (Eg. Linux).
> We've ended up in a world where power users have been forgotten.
I think the world changed. "Power users" in the traditional sense use Linux and BSD now. Microsoft and Apple dropped them when they realized how lucrative it would be to dumb things down and make computers more like cable TV.
If you become a power user you realize that nothing matches the power of the command line. And at that point you also realize that are better OSes that allow you to fully explode the true computing power that is terribly limited and constrained by a GUI.
I know this isn't really your main point but I don't think they've been trying to reduce complexity but rather increasing ease-of-use for the end-user*. Those things are often completely at odds with each other in software as I'm sure you know.
*well, that seems to have been their goal in the past; nowadays it just seems like they've been trying to funnel windows users to their other products and forcing copilot into everything.
Well, Alt+Tab in Windows is supposed to switch windows. That's unless you're in Microsoft Edge where obviously, it switches tabs. Inconsistent and annoying.
> This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen.
I mean... well... responsiveness matters to me too, and I am impressed by such inspired productivity, but... I'm also confused. Why not turn on the screen - the monitor, right?
Now thinking about how gui lag might impact the sight-impaired, tangential as that is...
As someone who saw what impact WPF had on average users running average hardware in the late 2000s to early 2010s, I disagree.
In 2011, my brother was in seminary, using an average Windows Vista-era laptop that he had been given in 2008. When he was home for Christmas in 2011, we were talking about his laptop, and he told me that the Logos Bible software ran sluggishly on that laptop. He said something about how, for reasons unknown to him, the current version of Logos required advanced graphics capabilities (I forget exactly how he phrased it, but he had learned that the slowness had something to do with graphics). Bear in mind, this is software that basically just displays text, presumably with some editing for adding notes and such. At the time, I just bought him another laptop.
A few years later, I happened to read that Logos version 4 was built on WPF. Then, remembering my brother, I found this Logos forum thread:
This shows that Logos users were discussing the performance of Logos on machines with different graphics hardware. For a program that was all about displaying and editing text, it shouldn't have mattered. WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. And that's just the one example I know about.
I remember when ChatGPT exploded and Bing had it integrated, the idea was brilliant because unlike ChatGPT it didn't have information cut-off since it can access the web. I was very excited to ditch Google for AI chat with web access.
How did MS actually implemented it though? After a few messages the chat is blocked because MS did not choose to walk the extra mile and maybe compact the context so that their product can be actually usable.
Of course OpenAI, Perplexity and others later implemented that properly and its integral part of modern AI chat and I actually ditched Google for the most part. Had Microsoft done it, they might have had a shot in replacing Google and maybe becoming the AI Chat provider. But no, Microsoft can't have a well thought UI to provide a delightful UX.
IMHO it's a culture thing. Lack of cohesion is a result of it, I used to be annoyed by Apple that doesn't allow to ship its own UI libraries together with the app so to support old versions etc. but Apple had it right, thanks to the limitations UI is coherent.
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.
2 things Microsoft failed to do in the last 15 years are:
1) They abandoned their mobile phone, tablet, and wearable strategy. So, today if you develop a native Windows application, it will only work on desktops and laptops. That is it. It is not attractive for a developer to learn a whole new UI framework just to target a single form factor. And I don't know if there is any solution for this at this point, they shouldn't have completely abandoned those markets.
2) They did not back 1 UI framework for a long time (I mean 10 years+), instead they did significant changes to their UI framework strategy every 3-4 years. It takes a huge time for developers to trust, learn and develop complex and polished apps in a UI framework. Also it takes a long time for a UI framework to become mature. If you change your UI strategy every few years, you will never have complex and polished apps written with it.
To be honest I am not sure if Windows will ever be able to recover in the long term and keep its market share. The only reason it seems to be alive is because enterprise runs on Windows and it is hard to change that.
I feel like an Apple + Google dominance will be more likely in the long term for desktop operating systems. I am not sure if Google will be able to avoid the first mistake I wrote above but they are working on bringing Android to desktop. It is a good idea but it requires at least 10 years of supporting and polishing it despite not getting much traction. But if Google persists, we might be all using MacOS and Android on desktop 20 years from now.
The churn would have been much worse if Microsoft was rolling out successful GUI framework after GUI framework. As it is you can still write a Win32 app if that pleases you, or still write .NET (and damn that runtime download!)
Microsoft has bought into ‘make a web app’ since 1988, they introduced AJAX, they got flexbox and grid into CSS and numerous HTML 5 features to support application UIs. They ‘frikin bought npm!. I use Windows every day but I almost exclusively develop cross-platform systems based on the WWW, Java, Python, etc. Whenever I have developed with .NET it has been for a cross-platform front-end like Silverlight or Unity/itch.io.
I can’t say I have a desire to make a native Windows GUI app when I could make a web app: like if it worth doing from my computer isn’t it worth doing it on my iPad from anywhere with Tailscale? For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX and you certainly don’t need to ship an Electron runtime for many applications.
The problem is that they just could not commit to anything for more than 2 years after Win32.
They had something reasonably good in WinRT. They should have stuck to that. But Nadella came in, said Azure Cloud is the future and abandoned the Windows platform.
Having spent some time kicking around the Delphi space I got quite into WPF in 2007ish. By 2010 I had not just sworn off it, I'd sworn off Windows entirely. The constant stream of rug-pulls as one bit of MS managed to pull off a political heist over another and - oh no - yet another "latest and greatest" technology was effectively deprecated within 18 months of launch, invalidating all the effort you put in to staying up to date just became a pointless treadmill.
Fortunately Rails was taking off at that point so it was fairly easy to change horses and just ignore it.
Java wanted to run your code everywhere so they basically wrote a byte code compiler and then wrote one vm per OS/architecture
I never understood.NET's purpose. What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not.
Sidenote - MFC is the ugliest thing you'll see. Yet they didn't mention another piece of work called ATL. Active Template Library.
WinForms were really decent and that was enough. Keep Win32 API and a managed wrapper around it as WinForms and that would have been more than enough.
When a platform can’t answer “how should I build a UI?” in under ten seconds, it has failed its developers. Full stop.
That's fine, except no platform answers this.
Obviously Linux doesn't, but the Mac doesn't either. Apple of course has it's recommendation, but most developers do not take Apple's recommended path because of course, it's Apple-only, most developers make cross-platform apps these days.
Even if Microsoft decreed the one-and-one Windows development path, most developers are not taking that path.
It used to be the case that Mac developers used Apple tools, Windows developers used Microsoft tools, but those days are gone. Developers want to use Electron, or Qt, or some other system to support multiple platforms in one codebase.
Microsoft has less to do with this than the article makes out. I'm a desktop developer. I don't care what Microsoft recommends, or what Apple recommends, because neither work in the real world where supporting only their platform just isn't realistic.
Wow, totally ignores the one framework Microsoft developed that was actually a pleasure to use (WinForms). Avalon sucked IMO; it was just a continuation of the fever dream at the time of making everything XML (or XAML in that case). MFC sucked because it was C++. WinForms was that brief Window of “modern programming language with simple, elegant GUI framework”.
I know it’s not a popular opinion, and I am sure there were reasons Microsoft abandoned it, but that was a brief few years when I actually enjoyed building GUIs on Windows.
> WPF shipped in late 2006. It was remarkable – XAML, hardware-accelerated rendering, real data binding. If Microsoft had made it the definitive answer and invested relentlessly, the story might have ended differently.
Er… The author perhaps never used it? WPF was the worst framework I ever used. It was unbearably verbose, brutally unforgiving, used 2-way bindings that created updating nightmares, ans not the least it was incredibly slow.
WinForms was not the best for sure, but at least you can get stuff done. It was for a long time the right answer to the question the author asked. .Net + WinForms worked well.
I remember I was trying to learn GUI programming in late 2000s. I took an attempt at MFC but no matter how hard I tried, it just didn't make any sense. Then I found out about Qt 4 and it felt like magic immediately. I ended up working as a professional Qt software developer for 3 years.
Fast forward to now, and KDE Plasma is state of the art Linux desktop that I've been daily driving for years. It's also built on Qt.
I used to be a software test engineer at Microsoft in the late 90's and early 2000's. What I learned is that 60% of their business was International because of their language support. Also most of their customers are business customers locked in to using their Windows Server Domain system for corporations. These corporations also run office and Sharepoint and build custom apps using office. This is why they have so many different ways to build apps on Windows. We are not the users they are targeting, they target the enterprise.
It is a fantastic book, I learned everything I know on Win32 from it. Wrote real time scientific software in windows for ~10y! We did it all, external hardware control, custom UIs, etc. Thanks Ryan Geiss for your timing info.
Right about VC6 was the sweet spot imo, C/C++ with lightning fast UI for docs and more. Tools got out of the way. Once other languages got involved (C#?) the docs got out of control and harder to use, and the UI started to get a little overloaded.
The snappiness of those old windows systems was pretty great.
At Redmond, there was also the Patterns & Practices group (P&P) that tried to make sense of the dev products, and built extra libraries “to show customers how to use them”. They followed the bouncing ball of the frameworks releases from the main development teams. It suggests that it wasn’t clear exactly how you’d use the main products: so P&P said, ‘try it like this.’
I also think the article didn’t say much about MS in the web era. The company survived webdev IMO, but it definitely wasn’t the leader
Xaml and styling and all sorts to try and compete.
Trouble is, it made desktop development harder, and it didn't win against the web. It left the simple and safe formula of standard and common controls for a designer's playground, but the designers preferred the web. And if you make something for the web, you can package it in Electron and get cross platform cheaply.
A decade or so ago, I had a clear idea of what a "native ui" should look and feel like, even if there were multiple routes to get there. I don't know any more.
There’s a poster on here who keeps posting and re-posting about their dinner with a Microsoft executive and how they were told Microsoft is all-in on enterprise. Waiting for that copy-paste to make its way over here.
Microsoft keeps footgunning things so hard I think even enterprise might be reluctant to go with them moving forward [0]. I don’t have Netcraft numbers in front of me but I doubt things have notably improved even if they do have a strategy shift to enterprise which includes crapping all over Windows for no good reason.
I’m personally glad FOSS is going strong but that’s a complete aside.
[0] We got burned by Azure as I’m sure many other enterprises have, and they did exactly nothing to remedy/compensate the situation, SLAs be damned. At this point our strategy is to move off of reliance on any Microsoft/windows tech. We moved off of ActiveDirectory not too long ago. Bing/Edge/etc honestly who cares.
The biggest issue in my opinion is that Microsoft is chasing web devs. XAML is pita, just like css and html markup. They need to pick a lane and just use it. Allow other frameworks access to the default low level api such as Win32, but document it to the same level as Google does on Android and Apple with SwiftUI
I very much dislike WPF. If I have to do a windows UI (and usually when I do it's a simulator for some piece of hardware), I honestly just grab WinForms. It's stupid simple.
I've worked inside the Microsoft 365/SharePoint ecosystem for over 20 years, and the incoherence runs deeper than the GUI layer.
Microsoft has been developer first, then cloud first, now AI first. It has never been design first. And when something does work, the pattern is always the same: force it everywhere. Metro was genuinely good on mobile, then they pushed it onto desktop where it didn't fit. Now Fluent UI is repeating the cycle.
Fluent UI is on its third major rewrite (Fabric, then Fluent UI React v8, then v9). Each one brought breaking changes. v9 appeared around the same time Microsoft released their new Teams client, and it shipped with performance and accessibility issues that are still being worked through. Signs already point to the next throwaway Fluent UI version. In practice, Fluent seems to be first-party only. It's 'open source' in the sense that you can look but don't touch. In SharePoint alone, the same UI elements look different across pages, lists, document libraries, and settings panels.
The irony is that the web platform itself has caught up. You can build a fully themed, accessible component library in plain HTML and CSS today. No framework dependency, no version lock-in. I did exactly that with hTWOo (https://htwoo.io/), an open-source alternative that matches the Fluent design language without any of the React coupling.
The real problem isn't that Microsoft can't pick a GUI strategy. It's that they keep rebuilding from scratch instead of creating a design system flexible enough to sustain across platforms and product generations. The web platform already provides the primitives. You just have to commit to them.
Microsoft's biggest mistake was .Net being a Java competitor when it should have just been like golang producing native binaries. Especially since .Net was realistically only going to succeed on x86/64 at that point (late 90s and 2000s). This shut the door on C# for consumer UIs, and people stuck to Visual Basic and MFC.
It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.
As an outsider, it always felt that 'internal team politics' were the root cause of Microsoft's technological downfall. This went far beyond the GUI. In 'flagship' offerings like SharePoint or Skype/Lync/Teams you could see the unmixable partial code-bases brutally forced together under a single product name an foisted upon a user-base baffled by how this could have gone so wrong.
Fun and sad. Garbage collected languages like .NET, Java, and Go are slow compared DIY languages like C, Rust, and Swift. So, no wonder the Windows team dislike them. However, it seems the Windows team had to live with a React start menu for quite some time. How does that fit into the over all battle between the teams and UI frameworks?
Winforms is still compelling to me. Now that we have WebView2, building complex hybrid apps is trivial. I know I could easily go pure web, but something about having proper native chrome feels better as a user. All of my clients/users are on windows so I stopped fighting this battle years ago. I've recently been using .NET10 + Winforms + WebView2 to build custom ai assistants for others. I cannot imagine how much it would suck to iterate the presentation of a conversation history in pure win forms. The hybrid stuff is crazy productive.
The roadmaps look messy if you look at them as coming from one company. But if you remember that windows and .net (or DevDiv) are more like competing companies then it makes more sense. Then for one side it’s Win32, MFC, WinSDk and for the other it’s Win32 (WinForms), WPF, MAUI
If Microsoft hadn’t been preoccupied with a failed mobile bet then this wouldn’t have happened. It’s a lost decade followed by a (much more successful) cloud pivot. The reason desktop is ignored is because it can be. No one is eating their lunch on desktop.
IDK, it kind of sounds like from the article's own prose that Project Reunion / WinUI 3 is an overall good thing and that Microsoft actually does have a pretty good vision for the past 5 years at least.
From a user's perspective, I don't really see where the problem is. All my apps look like Windows apps to me, and I also think that includes apps that do their own thing and look their own way. For as long as Windows has been around we've had apps that just don't follow the rules, from RealPlayer to WinZip to iTunes to Spotify.
This idea that all applications must be consistent with each other on one platform is generally a good idea but the downside of not having it that way is not very tangible to most users.
E.g., Steam looks different than every other Windows app. Same with Spotify and Slack and Discord. How does that negatively impact users? Well, not really at all. The consistency is within those apps themselves. I'm comfortable with Steam because I've been using it for 20 years and it's evolved on its own terms.
I could see it being an accessibility problem, but can't figure out any other potential downside.
I also don't think any other platforms have this figured out. See the window corners in macOS Tahoe. Remember how Mac Catalyst apps first looked when that came out? They didn't follow OS conventions at all. Remember when Final Cut Pro 6 didn't look anything like a Mac app? Or GarageBand etc. and their skeuomorphic looks? Linux is no better with a mix of desktop environments, Wayland versus Xorg, etc. Then we look at mobile apps and it's one of the least consistent environments imaginable: you've got a mix of native and frameworks like React Native and Flutter and the rest.
580 comments
Things like:
- If you can't respond to a UI event wait until you can
- Menus should be tree structures
- Pressing alt should underline the hotkeys you need to access anything clickable
As well as just basic responsiveness or predictability. A 2000 era windows application may not have been pretty, and may well have several different styles all imitated from office, but at least I knew what everything did and when it was slow at least it did what I expected.
This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen. Nowadays that has no chance of working because even to log in I need to press enter or click some button (which one depends on how I logged in previously, maybe) before I can even start typing and doing so eats a random amount of keystrokes while the damn log in screen loads to do its one damn job.
We've lost design idioms, which is a huge tax on users everywhere. I've been mad about this for years: https://essays.johnloeber.com/p/4-bring-back-idiomatic-desig...
I personally love dense UIs and have no expectation of doing certain kinds of work on a phone or low-powered device like a chromebook, phone, or bottom-barrel laptop. But if you're a company trying to sell products to a broad user base, you want to try to design in a way that works for those kinds of users because they still might be end-users of your product. And there's a good chance that those platforms may be where someone first evaluates your product (eg from a link shared and accessed on a mobile device) even for the users who do plan on using more powerful desktop devices to do their work.
So instead we get these information poor, incoherent (because it turns out proper cross-platform, cross-user design is much more difficult than just getting something that works cross-platform for all users on its surface) interfaces. I guess I'm writing this just to add, web/mobile have complicated things partially because more than just requiring their own distinct patterns, they each represent a distinct medium that products try to target with the same kind of design. But because they're different mediums, it's like trying to square a circle.
The fact that there are multiple platforms for UIs* is a huge failure of the industry as a whole. Apple, Microsoft and Google could have had a sit down together at any point in the last 20+ years to push some kind of standard, but they decided not to in order to protect their gardens.
*: a standardized UI platform doesn't necessarily mean a standardized platform. Just standardization of UI-related APIs and drawing.
Any system that needs a straightforward UI for kicking things off, stopping them, logging them, and dragging data files into them..... WinForms.
Bugfree, hardened by the test of time, works on Windows X, Y and Z.
Everything else is just consumer silver sprinkles, and involves faffing around with multiple config files and obscure layout issues.
> basic rules that had been in place for ages. Things like: [...]
I am going to add my favorite here, just to rant into the void. A dialog box's options must never be Ok/Cancel. These are not the same sorts of things. "Cancel" is a verb, "Ok" is a noun (in this context). Even if "Ok" is taken to mean the verb "acknowledge", it is still not an alternative to cancelling.
99% of these dialogs should be "[Verb]/Cancel": Change "Ok" to a verb or short phrase indicating the action that will be taken if you press it. Don't do the action if the user hits "cancel". The verb should be something specific like "Delete file" or "Terminate process" and not something useless like "proceed".
We've got big screens now! use more words! Save changes/Discard changes/Don't quit.
This is one that I hold my devs accountable for. No, I shouldn't have "put it in the spec", because it is the fucking spec.
I would argue that desktop is the platform for power users, and its future depends on them. The keyboard shortcuts, the micro-interactions, the window management -- this stuff is all important when you're using a system for 8+ hours per day.
Yet we risk desktop experiences becoming less useful due to the UI becoming "dumber" as we keep shoehorning websites onto the desktop. Website UI is dumb. It's mouse driven, keyboard is an afterthought. There's no consistency, and you have to re-invent the wheel every time to get the details right (almost never happens).
>We've ended up in a world where power users have been forgotten.
I think its more like the OS vendors have stopped being operating system vendors, and are now - instead - vendors of eyeballs to advertisers.
The less the user is GUI'ing, the more they are just watching, placid, whatever else is on their screen.
For native apps to survive, they need to not be platform-specific - i.e. web apps, which require a browser and all its responsibilities - but rather cross-platform, reliable, predictable on all platforms - i.e. dissuaded from using native, but rather bespoke, UI frameworks.
This is attainable and there are many great examples of apps which are in fact, old wheels not re-invented, which still work for their particular user market.
I have the most respect for apps I can use on MacOS, Windows, and Linux - with the same hotkey/user experience on all platforms, equitably - and the least respect for apps which 'only run on one of them', since that is of course nonsense in this day and age.
The cognitive load of doing a web app that can do all the things a native app can do, is equivalent to the load required to build a cross-platform app using native frameworks, so ..
> I have the most respect for apps I can use on MacOS, Windows, and Linux - with the same hotkey/user experience on all platforms, equitably - and the least respect for apps which 'only run on one of them', since that is of course nonsense in this day and age.
No. I want things like keyboard shortcuts to reflect the platform norms of where the app is running (macOS in my case). A shared core is fine, but the UI framework must be native to be acceptable. Ghostty is a "gold standard" there.
This is why most web apps are lowest-common-denominator annoyances that I will not use.
There are plenty of examples of cross-platform UI's surviving the hotkey dance and attaining user satisfaction. There are of course poor examples too, but that's a reflection of care, not effort.
>i.e. dissuaded from using native, but rather bespoke, UI frameworks.
Based on my experience, I would be quite reluctant to rely on any non-native cross-platform desktop UI framework that is not web-based. These tend to be either less performant, look outdated or are bug-ridden.
It is (1) performant (C++-based), (2) does not look outdated, and (3) not bug-ridden.
On Linux, Qt apps feel a bit off in GNOME, though you can never satisfy everyone as its the wild west.
I think Qt also suffers from not really being anyone's favourite.
On the one hand, you have web developers who tend to not really appreciate the nuance of the desktop as a platform. They're not going to advocate for Qt, it's not CSS/HTML/JS.
On the other hand, you have native Mac developers who love Apple's toolkits (AppKit, maybe SwiftUI). They're not going to advocate for Qt either.
Lastly, you have native Windows developers who have been burned so many times they don't advocate for anything in life anymore.
DotNet WinForms has been rock solid for 15 years. And there are so many good 3rd party widgets if you need them.
If you prefer C++, then Windows Template Library (WTL) is also rock solid and released more than 20 years ago.
> On Linux, Qt apps feel a bit off in GNOME, though you can never satisfy everyone as its the wild west.
It's much better than how GTK apps feel under Qt-based DEs - at least Qt tries to adapt to the DE style.
Developing UIs without hot reloading is too painful.
- Qt Widgets worked fine, but looked like a piece of software made in 2013;
- QML looks stylish and is a very nice language, but had a lot of weird bugs.
Neither of these are issues I'd run with if I were to make a web app.
Power users are less susceptible to suggestion and therefore less profitable. They have largely moved to OSes that do not interfere with their wishes, allowing them to make their own choices about what they can or can't do/run (Eg. Linux).
> We've ended up in a world where power users have been forgotten.
I think the world changed. "Power users" in the traditional sense use Linux and BSD now. Microsoft and Apple dropped them when they realized how lucrative it would be to dumb things down and make computers more like cable TV.
*well, that seems to have been their goal in the past; nowadays it just seems like they've been trying to funnel windows users to their other products and forcing copilot into everything.
> Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
The web is not consistent itself. Lots of sites, and most web apps, invent their own UI.
Hopefully /s
> This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen.
I mean... well... responsiveness matters to me too, and I am impressed by such inspired productivity, but... I'm also confused. Why not turn on the screen - the monitor, right?
Now thinking about how gui lag might impact the sight-impaired, tangential as that is...
> WPF was good
As someone who saw what impact WPF had on average users running average hardware in the late 2000s to early 2010s, I disagree.
In 2011, my brother was in seminary, using an average Windows Vista-era laptop that he had been given in 2008. When he was home for Christmas in 2011, we were talking about his laptop, and he told me that the Logos Bible software ran sluggishly on that laptop. He said something about how, for reasons unknown to him, the current version of Logos required advanced graphics capabilities (I forget exactly how he phrased it, but he had learned that the slowness had something to do with graphics). Bear in mind, this is software that basically just displays text, presumably with some editing for adding notes and such. At the time, I just bought him another laptop.
A few years later, I happened to read that Logos version 4 was built on WPF. Then, remembering my brother, I found this Logos forum thread:
https://community.logos.com/discussion/6200
This shows that Logos users were discussing the performance of Logos on machines with different graphics hardware. For a program that was all about displaying and editing text, it shouldn't have mattered. WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. And that's just the one example I know about.
How did MS actually implemented it though? After a few messages the chat is blocked because MS did not choose to walk the extra mile and maybe compact the context so that their product can be actually usable.
Of course OpenAI, Perplexity and others later implemented that properly and its integral part of modern AI chat and I actually ditched Google for the most part. Had Microsoft done it, they might have had a shot in replacing Google and maybe becoming the AI Chat provider. But no, Microsoft can't have a well thought UI to provide a delightful UX.
IMHO it's a culture thing. Lack of cohesion is a result of it, I used to be annoyed by Apple that doesn't allow to ship its own UI libraries together with the app so to support old versions etc. but Apple had it right, thanks to the limitations UI is coherent.
Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.
1) They abandoned their mobile phone, tablet, and wearable strategy. So, today if you develop a native Windows application, it will only work on desktops and laptops. That is it. It is not attractive for a developer to learn a whole new UI framework just to target a single form factor. And I don't know if there is any solution for this at this point, they shouldn't have completely abandoned those markets.
2) They did not back 1 UI framework for a long time (I mean 10 years+), instead they did significant changes to their UI framework strategy every 3-4 years. It takes a huge time for developers to trust, learn and develop complex and polished apps in a UI framework. Also it takes a long time for a UI framework to become mature. If you change your UI strategy every few years, you will never have complex and polished apps written with it.
To be honest I am not sure if Windows will ever be able to recover in the long term and keep its market share. The only reason it seems to be alive is because enterprise runs on Windows and it is hard to change that.
I feel like an Apple + Google dominance will be more likely in the long term for desktop operating systems. I am not sure if Google will be able to avoid the first mistake I wrote above but they are working on bringing Android to desktop. It is a good idea but it requires at least 10 years of supporting and polishing it despite not getting much traction. But if Google persists, we might be all using MacOS and Android on desktop 20 years from now.
Microsoft has bought into ‘make a web app’ since 1988, they introduced AJAX, they got flexbox and grid into CSS and numerous HTML 5 features to support application UIs. They ‘frikin bought npm!. I use Windows every day but I almost exclusively develop cross-platform systems based on the WWW, Java, Python, etc. Whenever I have developed with .NET it has been for a cross-platform front-end like Silverlight or Unity/itch.io.
I can’t say I have a desire to make a native Windows GUI app when I could make a web app: like if it worth doing from my computer isn’t it worth doing it on my iPad from anywhere with Tailscale? For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX and you certainly don’t need to ship an Electron runtime for many applications.
They had something reasonably good in WinRT. They should have stuck to that. But Nadella came in, said Azure Cloud is the future and abandoned the Windows platform.
It's 2026. We're running 8+ cores and 32gb ram as standard. We can run super realistic video games at high frame-rates.
Yet on the same machine, resizing a window with rectangles in it is laggy on every platform except macOS (where there's a chance it's not laggy).
https://x.com/stevesi/status/2036921223150440542
Fortunately Rails was taking off at that point so it was fairly easy to change horses and just ignore it.
I never understood.NET's purpose. What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not.
Sidenote - MFC is the ugliest thing you'll see. Yet they didn't mention another piece of work called ATL. Active Template Library.
WinForms were really decent and that was enough. Keep Win32 API and a managed wrapper around it as WinForms and that would have been more than enough.
.
(This isn't even a joke. Assuming you're not going Electron.)
Part of the reason here is that it's their main business. They can't afford letting it languish and/or changing direction every 6 months.
That's fine, except no platform answers this.
Obviously Linux doesn't, but the Mac doesn't either. Apple of course has it's recommendation, but most developers do not take Apple's recommended path because of course, it's Apple-only, most developers make cross-platform apps these days.
Even if Microsoft decreed the one-and-one Windows development path, most developers are not taking that path.
It used to be the case that Mac developers used Apple tools, Windows developers used Microsoft tools, but those days are gone. Developers want to use Electron, or Qt, or some other system to support multiple platforms in one codebase.
Microsoft has less to do with this than the article makes out. I'm a desktop developer. I don't care what Microsoft recommends, or what Apple recommends, because neither work in the real world where supporting only their platform just isn't realistic.
- windows forms in .net
- flutter
All the rest always presents itself with a sheer aura of "It was a great idea but we couldn't finish it".
Without ever discussing with anyone from MS about it, I think they stopped improving/working on this because of electron.
Any web developer can build a good enough website and a good enough desktop app with electron.
Invested in it, shipped it, seen it solve the cross-platform problem beautifully.
Can just write C++, and see it running everywhere.
The JUCE GUI capabilities are more than adequate for many, many things.
There are other platform-scaffolded cross-platform frameworks. JUCE is cromulantly FNORD.
A few years ago, I wanted to prototype something quick and I wrote it in Windows Forms over C# (all code, no visual editor).
I know it’s not a popular opinion, and I am sure there were reasons Microsoft abandoned it, but that was a brief few years when I actually enjoyed building GUIs on Windows.
> From their perspective, gambling on a new managed-code framework had produced the most embarrassing failure in the company’s history
Most embarrassing failure in the company’s history that far.
> WPF shipped in late 2006. It was remarkable – XAML, hardware-accelerated rendering, real data binding. If Microsoft had made it the definitive answer and invested relentlessly, the story might have ended differently.
Er… The author perhaps never used it? WPF was the worst framework I ever used. It was unbearably verbose, brutally unforgiving, used 2-way bindings that created updating nightmares, ans not the least it was incredibly slow.
WinForms was not the best for sure, but at least you can get stuff done. It was for a long time the right answer to the question the author asked. .Net + WinForms worked well.
When WPF shipped was when the shit hit the fan.
Fast forward to now, and KDE Plasma is state of the art Linux desktop that I've been daily driving for years. It's also built on Qt.
It is a fantastic book, I learned everything I know on Win32 from it. Wrote real time scientific software in windows for ~10y! We did it all, external hardware control, custom UIs, etc. Thanks Ryan Geiss for your timing info.
Right about VC6 was the sweet spot imo, C/C++ with lightning fast UI for docs and more. Tools got out of the way. Once other languages got involved (C#?) the docs got out of control and harder to use, and the UI started to get a little overloaded.
The snappiness of those old windows systems was pretty great.
Thankfully I have been mostly insulated from it by sticking to Qt and C++ for the last 25 years.
Xaml and styling and all sorts to try and compete.
Trouble is, it made desktop development harder, and it didn't win against the web. It left the simple and safe formula of standard and common controls for a designer's playground, but the designers preferred the web. And if you make something for the web, you can package it in Electron and get cross platform cheaply.
Microsoft keeps footgunning things so hard I think even enterprise might be reluctant to go with them moving forward [0]. I don’t have Netcraft numbers in front of me but I doubt things have notably improved even if they do have a strategy shift to enterprise which includes crapping all over Windows for no good reason.
I’m personally glad FOSS is going strong but that’s a complete aside.
[0] We got burned by Azure as I’m sure many other enterprises have, and they did exactly nothing to remedy/compensate the situation, SLAs be damned. At this point our strategy is to move off of reliance on any Microsoft/windows tech. We moved off of ActiveDirectory not too long ago. Bing/Edge/etc honestly who cares.
Microsoft has been developer first, then cloud first, now AI first. It has never been design first. And when something does work, the pattern is always the same: force it everywhere. Metro was genuinely good on mobile, then they pushed it onto desktop where it didn't fit. Now Fluent UI is repeating the cycle.
Fluent UI is on its third major rewrite (Fabric, then Fluent UI React v8, then v9). Each one brought breaking changes. v9 appeared around the same time Microsoft released their new Teams client, and it shipped with performance and accessibility issues that are still being worked through. Signs already point to the next throwaway Fluent UI version. In practice, Fluent seems to be first-party only. It's 'open source' in the sense that you can look but don't touch. In SharePoint alone, the same UI elements look different across pages, lists, document libraries, and settings panels.
The irony is that the web platform itself has caught up. You can build a fully themed, accessible component library in plain HTML and CSS today. No framework dependency, no version lock-in. I did exactly that with hTWOo (https://htwoo.io/), an open-source alternative that matches the Fluent design language without any of the React coupling.
The real problem isn't that Microsoft can't pick a GUI strategy. It's that they keep rebuilding from scratch instead of creating a design system flexible enough to sustain across platforms and product generations. The web platform already provides the primitives. You just have to commit to them.
It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Windows Native App Development Is a Mess
https://news.ycombinator.com/item?id=47475938
Microsoft developed VS Code and Teams in Electron. That says a lot about how they see the future.
If Microsoft hadn’t been preoccupied with a failed mobile bet then this wouldn’t have happened. It’s a lost decade followed by a (much more successful) cloud pivot. The reason desktop is ignored is because it can be. No one is eating their lunch on desktop.
https://blog.hiler.eu/win32-the-only-stable-abi/
From a user's perspective, I don't really see where the problem is. All my apps look like Windows apps to me, and I also think that includes apps that do their own thing and look their own way. For as long as Windows has been around we've had apps that just don't follow the rules, from RealPlayer to WinZip to iTunes to Spotify.
This idea that all applications must be consistent with each other on one platform is generally a good idea but the downside of not having it that way is not very tangible to most users.
E.g., Steam looks different than every other Windows app. Same with Spotify and Slack and Discord. How does that negatively impact users? Well, not really at all. The consistency is within those apps themselves. I'm comfortable with Steam because I've been using it for 20 years and it's evolved on its own terms.
I could see it being an accessibility problem, but can't figure out any other potential downside.
I also don't think any other platforms have this figured out. See the window corners in macOS Tahoe. Remember how Mac Catalyst apps first looked when that came out? They didn't follow OS conventions at all. Remember when Final Cut Pro 6 didn't look anything like a Mac app? Or GarageBand etc. and their skeuomorphic looks? Linux is no better with a mix of desktop environments, Wayland versus Xorg, etc. Then we look at mobile apps and it's one of the least consistent environments imaginable: you've got a mix of native and frameworks like React Native and Flutter and the rest.