Hacker News new | past | comments | ask | show | jobs | submit login
Windows 11: a survey of text boxes (sjmulder.nl)
125 points by sjmulder on Sept 3, 2021 | hide | past | favorite | 144 comments



Windows Terminal colour dialog

My response upon seeing that was "WTF! That looks ridiculously amateurish!" It almost feels like it's trolling me. Even the labels somehow manage to have a different size of font than the rest of the dialog, something a noob in the 90s using Visual Basic drag-and-drop to create dialogs would not produce without expending (considerable) additional effort.

Ironically, Win32 has had a much more full-featured and standard dialog for choosing colours since Windows 3.x:

https://docs.microsoft.com/en-us/windows/win32/dlgbox/color-...


Wow I’d at least hope for a preview of the color I’m “choosing”.


In Windows Terminal? You do get that. https://i.imgur.com/nSJlAy0.png

Personally, I like this better simply because it has the RGB representation in hex which is so much easier to copy and paste than dealing with 3 individual textboxes.


Ah ok, I admittedly haven’t used Windows terminal much as of yet, I thought the screenshot shown in the article was majority of the dialog.


I don't understand why microsoft doesn't have a small team dedicated to look and feel and just bringing it all up to date - all those control panel applets, have they finally been upgraded?


all those control panel applets, have they finally been upgraded

I hope not --- frankly speaking, this new stuff is horrible.

Compare how long the original Control Panel takes to open with the new "Settings App". Then compare their visual complexity. The latter takes multiple seconds to open, even has a loading screen, and yet all the controls in it are incredibly bland and featureless and conceptually simpler to render than in the old one. This is none other than a huge regression.


80% of the time if I want to change something in the Windows 10 settings all my time is spent trying to find out which magic words I need to recite and which buttons I need to click to get to the old Windows 7 / XP style configuration dialogs.

E.g. you have to navigate through this garbage: https://i.imgur.com/W1txUAK.png to find the one link (named "Sound Control Panel", hidden somewhere down the page) that opens the actual useful config panel: https://i.imgur.com/zDnnMPE.png


I wish they would just improve the old interface. It is mostly fine, but suffers from claustrophobic fixed size windows and listboxes that needed to fit on 640x480 screens. They also should make MMC toolkit DPI-aware.


That's how this mess started, trying to re-implement the settings screens in a more "modern" design.

If they just made the original control panels work with HiDPI screens, there would be complaints that they've done nothing.


There's a bunch of legacy apps that still have hardcoded pixels in the layout. It's a lost cause to try to make it work.


Quick tip you can just right click your speaker/volume icon in the systray and click "Sounds" to open it, although on the wrong tab.


The best control panel was the Windows 95 version : only a grid of icons.


Amusingly enough, some shuffling of icons aside, macOS has had pretty much exactly this for its entire tenure. It’s not perfect, but surprisingly consistent across two decades of releases.


And even that comes from Windows 3.0


> even has a loading screen

Slightly unrelated, but this is one of this things that annoys me the most about using gmail. Inbox by Gmail used to load instantly, there's really no good reason at all for it to have a loading screen.


Setting uses UWP underneath.

It's a dead platform.


I have no idea why they don't sort this out. Perhaps they feel like it is an issue. Windows 11 has UI elements from every OS back to Windows 3.1. I guess they like the absurdity of stacking various settings behind 2-3 control panels, some of which aren't even linked from one panel to the other.


Instead they have a bunch of small teams dedicated to their own little siloed feature set and then they cobble it all together, that’s my two second analysis of the inconsistencies seen here.


Costs versus benefits.


As it looks, it does not cost more than a couple dollars.


No, not really.

You get some updated Win32 window classes, theme engine updated for the UWP based stuff (or WinUI if on desktop side) and that's it.


they do have, the problem they have never use windows 11


As a longtime iOS engineer trying to prototype something on Windows, I did not realize how good I've had it while working with UIKit.

I just want Microsoft to give me the one true Blessed Way to write Windows apps. Instead it seems like there are 5 true Blessed Ways, and if I want something performant I need to use 20 year old APIs?

I was going to dig in to GDI+ for fast text styling performance but saw an offhand comment in some forum today that you can use DirectX for performant text rendering. How do people discover this information under normal circumstances?


Meanwhile on macOS, Carbon, Cocoa, Catalyst and SwiftUI, each with its own set of issues.

We discover this information like everyone else, conference talks, blog posts, books and developer documentation.


AppKit works perfectly, though. There's no UI control or esoteric tool that becomes inaccessible to you if you choose AppKit. You're not giving anything up by using AppKit unless you love declarative UI.

On Windows it seems like there are so many tradeoffs depending on which framework you pick. AppKit is still 'the' solution on macOS unless you're trying to port your iOS app with the minimal amount of effort.


Win32 is Windows AppKit.


Carbon and Catalyst didn't really overlap. And Catalyst is just for porting iPad apps.


Many educated iOS devs see Catalyst as entry in macOS development instead of learning new frameworks, no porting required.


They complained about lack of guidance from Microsoft. Guidance from Apple is Catalyst is for porting.


Where is this guidance document available?

While you are in the process of pasting it, the guys at ATP Podcast might also appreciate it.

> Native Mac apps built with Mac Catalyst can share code with your iPad apps

https://developer.apple.com/mac-catalyst/


The rest of the sentence is "and you can add more features just for Mac". It implies you have an iPad app already. Even the part you quoted is about sharing code with an iPad app. And the rest of the page is all about porting.

"There’s never been a better time to turn your iPad app into a powerful Mac app."

"Bring your iPad app to Mac"

"Your iPad app can be made into an excellent Mac app. Bring your iPad app to life on Mac using the latest version of Xcode. Begin by selecting the “Mac” checkbox in the project settings of your existing iPad app to create a native Mac app that you can enhance further."

"Learn how to build a native Mac app from the same codebase as your iPad app."


They might be the fanciest or laden with trendy buzzwords, but when it comes to building functional, pleasant to use apps, UIKit and AppKit are still hard to beat. If they became deployable on other platforms (Android and Windows/Linux, respectively) I don’t think I’d ever use anything else.


As someone who hasn't had to use Windows since XP, is anyone able to explain the technicals of how this even happens? I mean, at a complete OS layman's level, one would assume that someone somewhere comes up with the design for how a text input should look across the OS, someone else probably writes the UI code for that, someone else maybe writes the plumbing for it, then _everyone_ uses it whenever they need a text input. What is it about Windows that means this is impossible? Their UIs are like the jumble sale aisle down the middle of Lidl.


I think the core problem is that they all use different toolkits. The design teams come up with these great widget designs and then they all have to be implemented on a per-toolkit or even per-app basis.

Just looking at Explorer:

- The window itself is a regular Win32 window

- It hosts a WinUI island or such for the top toolbar

- The navigation bar is a ReBar with all custom Win32 widgets

- The content view is a DirectUI widget

You'd think that if they'd standardise on a single toolkit (like macOS with Cocoa) they'd be able to get better results with much less work. Perhaps this is an organisational issue?


MacOS breaks compatibility regularly.

If Windows would change the Win32/Winforms spacing and such I wouldn't want to be the developer that gets to keep all the pieces broken off.

Read some Windows Terminal blog entries, they're very enlightening. They're basically working around a huge minefield of compatibility and trying to get things moving again. It's quite a feat of real software engineering, what they're doing over there.


Really wish they'd just completely rewrite Explorer from the ground up.

It's woefully antiquated feeling next to Finder. Seeing it struggle to scroll folders with 10,000+ items it can't even load them all in at once you have to scroll bit by bit, seeing it choke reading MP3 file folders because it's trying to do some dumb WinXP era metadata reading on an ancient code path. Seeing it unable to search for files on a sensible timescale or even accurately.

It's infuriating.


> Really wish they'd just completely rewrite Explorer from the ground up.

Oh god no. They’d nuke all the keyboard shortcuts, make everything take 20x more space, remove any advanced features such as keying by non-primary column, sorting by weird file-specific metadata, etc, add loading screens everywhere, make even the most basic operations require an async dispatch to a runtime host, break credentials authentication with the OS keystore, remove IME and input accelerators, nuke integrations with 3rd party apps for menus, overlays, and previews, hide file extensions, run always in fullscreen, break ClearType text rendering, block access to any system files, break the elevated operations workflow, remove access to non-local files, use 20x as much memory, crash at startup, break when an update ships out-of-band on an older patch release, and then be rewritten in four years.


If the company making the one true OS for everyone (except those Mac weirdos and the Linux perverts) cannot be trusted with making a modern file explorer, then they're not improving an ecosystem, they're just shovelling coal into the furnace of an heritage building. They're in maintenance mode.


at some point you could use KDE's Dolphin on windows, that was awesome


macOS now has 4 toolkits to choose from.



Yes really, nothing forbids random developer Joe not to follow your point of view.


Carbon was 32 bit only. macOS is 64 bit only now. It isn't a point of view.


Not everyone is running on the latest macOS version, and even so we are still down to 3 frameworks, yes it is a point of view.


Apple removed Carbon and made Catalyst generally available in the same version. So they weren't ever viable at the same time. And can you point to even 1 developer considering a brand new app that doesn't support the last 2 OS versions?

Why stop at Carbon if you count removed frameworks? They had Classic and X11 too! And HyperCard!

Catalyst is expressly for porting iPad apps. So it's just SwiftUI and Cocoa if you compare macOS to Windows.


Many generations of code and UX standards, all still supported.

This just reveals Microsoft’s prioritization of UX consistency. Whatever the priority is, it’s not enough to overcome the perceived cost of creating consistency.

It also shows why Windows can be a strength: still runs almost everything anyone ever made for it.


I understand that Microsoft cares a lot about backwards compatibility. I think this is great and they should keep doing it.

Now, I completely understand if some third-party program developed twenty years ago looks inconsistently. I even understand if some recent third party tool also looks inconsistently. But here we're talking about the software that is shipped with Windows and it's created by Microsoft directly. These are examples from Edge, Explorer, Settings, etc. This is more than having a low priority for consistency, this is Microsoft not even considering the possibility of consistency.

I have not tried Windows 11. But I'm baffled to find that in Windows 10, Microsoft still ships parts of its own UI that are not high-dpi ready. They seem to have zero problem showing dialogs with scaled pixelated text.


Some of these stuff expose plugin apis or hooks which make this complicated. Control panel is a good example of this. The only alternative is to effective create a new and make that default unless configured otherwise.


The fact I can open most exe files from 1993 today on my window 10 laptop and have it work nearly perfect is an incredible feat.

MacOS couldn't be more opposite in this regard. Linux I also dislike for this reason.

It's expect you compile your own programs, but more often than not it'll fail if the project is abandoned for 5 years (purely anecdotal).


While I agree this is great, it is not really related to and no excuse for the inconsistent mess that Windows' UI has been ever since the Windows 8 Metro disaster. Win32 UI (think Windows 2000) was perfectly line.


If I want to run an old program I'd rather do it in a VM and have a nice, lean, consistent, sensible OS.


You're a technical person. Grandpa would go: "VM? What's that???".


The answer to this is simpler than it seems: instead of dedicating your compatibility efforts toward a monolithic OS that runs everything, dedicate them toward make the VM/shim layer so transparent “Grandpa” doesn’t have to know it’s an implementation detail.

In contrast with the earlier comment about how poorly Apple fares on backcompat: they have twice (thrice, actually, counting 68k->PPC) successfully made breaking platform changes where old software kept working with no required intervention by users or even knowledge it was happening.

Not everyone has been happy with Apple’s deprecation strategy, but there’s no technical reason MS couldn’t use their subsystem prowess to gradually move old technologies out of the core OS into sandboxed environments.

The reason they don’t is partly cultural—the compatibility at all costs trope is real—but I think it’s mostly a combination of lack of motivation and a recognition that the ecosystem produces a lot of abandonware that would quickly show seams.


This is what I had in mind. Something along the lines of VMware Unity.

Shipping an OS where some bits of UI date back to Windows 3.1 is never going to lead to a seamless experience.


Tell that to a bookeeper who runs aincent software the company has licensed decade ago or to the factory worker who must use a CAD software for a particular CNC machine to prepare the work files.


So yeah, legit but niche use case. Thankfully I don't need to worry about it so don't give it a second thought.


windows's long tail is niche use cases


A lot of old windows games do not run anymore on win 7 let alone 10.


Easy, they need to make sure Win32, MFC, Windows Forms, WPF, UWP and WinUI (basically UWP on Win32 without going into details) underlying rendering infrastructure gets aligned with the OS design language.

Guess what, I am 100% sure they do the basic for Win32, make some efforts for WinUI 2.0 (UWP) and WinUI 3.0 (the Win32 one) and that's it.


> Guess what, I am 100% sure they do the basic for Win32

The Win32 widgets have been updated but apparently they don't want to mess with the metrics, hence those controls are much more compact, don't use rounded corners, etc.

Is there any public UI toolkit in Windows now that offers the canonical widgets?


Kind of, only for WinUI 2.6, the UWP version.

The WinUI 3.0 (which is UWP decoupled from OS + UI) is still catching up.

https://docs.microsoft.com/en-us/windows/apps/winui/winui2/r...

Thing is, for Win32 anyone using bare bones Win32 has to do the work themselves for anything that ins't on the OS anyway.

So MFC and Forms get a partiall update via those Win32 changes, while WPF gets nothing due to its own DX rendering stack.

https://docs.microsoft.com/en-us/windows/apps/get-started/ma...


Looks like WinUI 2.6 is the way to go then. But I'm surprised that there doesn't appear to be any sort of official built in canonical thing with standard widgets (like what Win32 used to be). All these separate frameworks are implementing everything for themselves.


WPF is nuts. It appeared to have native controls but in reality they reimplemented everything, with a unique style definition for every control on every supported version of Windows. It would have been a huge amount of work. It seems like they haven't bothered to keep up with it as control styles have evolved though.


If you check the github issues and community talks on YouTube, it is quite clear that when Microsoft went full steam with WinRT, most likely the remaining UI teams got ramped down.

As they pivoted back into Reunion and merging Win32 and UWP worlds, new teams were created, so....


That train departed long ago.

In fact already during the Win16 days, many of us were already jumping into C++, Delphi and VB frameworks, instead of suffering through plain C programming.

Borland common controls used to be quite easy to spot with their green check mark.

Win32 has very few built-in controls, and Windows always enjoyed a good ecosystem from commercial vendors selling custom controls, like Telerik and ComponentOne to refer to two well known ones.

As historical info, modern COM traces back to Visual Basic VBX components.

https://en.wikipedia.org/wiki/Visual_Basic_Extension


Probably third party toolkits such as wxwidgets or Java AWT (the Swing predecessor)?


I get why they'd need to support all that for 3rd party app backwards compatibility, but surely for their own OS they can just use the current toolkit for everything? They own it after all.


What is the current toolkit?

Win32 is quite basic in the set of controls available, almost everything in traditional Win32 applications is custom drawn, beyond what you also find the HTML forms as components.

Then there are all commercial components that are so common in Windows applications.

However if you will, the future is WinUI/UWP, and that is the only one getting full Mica support.


Yeah that’s easy. Rather than fix the last thing it’s easier to write a new turd from the ground up with the promise that it’ll solve all the last problems.

Windows happens to have such legacy support and lack of product direction that’s it’s now layers and layers or turds.


Windows UI has always been a shambles. Each version of Windows, Office and VisualSomething has at least one new toolkit. It might even look the same as the other ones that came before it, but internally is a different library with different incompatible APIs, bitmaps, workings, etc. Third-Party tools usually also provide their own toolkits that are sometimes made to look Windowsy, sometimes not.

In some cases, APIs wouldn't be too much of a hindrance, and one could replace one toolkit by a later version with updated designs. But the designs themselves also do have a lot of compatibility problems: It is uncommon in the Windows GUI world to use layout managers (similar to CSS flexboxes and the like) that automatically adapt to different window and UI element sizes. Instead, most widgets are positioned pixel-wise. That is also why most dialogs are non-resizeable and things break e.g. when translated strings have different lengths. So a new design which changes sizes breaks all the pixelwise layouts everywhere.

tl;dr: Windows GUIs and toolkits are usually not designed with compatibility and resizeability in mind and break if you change the looks of anything (beyond just changing colors).


They could add an opt-in flag for this per process. So developers could just turn on some "moderngui" flag in their win32 apps and with some little adjustements most of the apps could be modernized.


Those exist. The Win32 Common Controls libraries are versioned and applications can opt in to them with rebuilds. There are also "application manifests" where in some cases an EXE can claim that "I know I was built with an earlier version of Common Controls, but I do the right things with them and was built with forward compatibility in mind so please display them the newer way".

The problem with opt-in flags is that it still requires active application developer work (keeping up to date on dependencies; sometimes worse, keeping up to date on future dependencies and learning their restrictions needs) and still can't solve the inconsistency issues from applications developed by people that don't exist anymore or don't have a maintenance budget or the source code was lost or…


Including Microsoft own teams.

Manifests are a thing since Windows 2000, as they were also introduced to sort out registry issues, and go back into xcopy deployments.

Yet even Microsoft's own teams keep putting into the registry what should be in manifest files.


> Windows GUIs and toolkits are usually not designed with compatibility and resizeability in mind and break if you change the looks of anything

More often than not they don’t even look designed.


Initially, that was more or less how it worked. The older and closer to Win32 you are, the less customisable the look is.

But more modern toolkits like WPF are much closer to html in their function. A text box is a white rectangle with a cursor. If you want to add autocomplete, placeholders, a magnifying glass icon in the edge - you put it there yourself.

So basically, making a text search field in Windows now is the same as making it for a webpage. The toolkit doesn't have options for adding autocomplete, placeholder text or icons. I think this is the correct API design, because controls that could do everything would be very difficult to work with.

That said, there should have been some utility or standard library to make it easier to be consistent, such as creating a "system-standard search box" which would then simply do all the gluing that is required for adding the necessary bells and whistles.

I'm sure there is both documentation and utilitiies for doing exactly this - but the problem is that it's so hard to find because everything keeps moving. Ironically I think internal ms devs feel the same way.


...at least you know where to find the jumble in lidl. And, despite being occasinaly messy, they're often preferabke to shop than to work out wtf is going on in UI land.


The hyper consistent UI guidelines of the 80s and 90s were born in an era when we had to convince grown human beings to use these brand new (to them) systems without feeling too embarrassed about being awful at it.

Today, and perhaps for decades to come, by the time someone touches a PC, they've been screwing around on phones and tablets. They live their lives on the internet and apps, where "standard looking" often implies "cheap and knock-off", and long term consistency often implies "stale and old". They already know that nothing is consistent, and things aren't always what they seem.

Today the point on significantly diminishing returns on spending resources on UI consistency is lower than ever. It's fun to pick on the textboxes, but it doesn't matter. It won't stop anyone from being productive and happy using the software.


> Today the point on significantly diminishing returns on spending resources on UI consistency is lower than ever.

You'd think having one blessed toolkit and implementing things there, once, takes much fewer resources than doing it half-heartedly over and over again.


> They already know that nothing is consistent, and things aren't always what they seem.

Knowing that doesn't make it easier to use.


https://docs.microsoft.com/en-us/windows/apps/design/signatu...

Didn't worked well?

The UI on Windows is problematic since Windows XP. Microsoft doesn't maintain actually the libraries for the UI, they just add new libraries. And developers learned that on Windows you can do whatever you want.

* Win32 (C, requires experience but reliable?)

* Microsoft Foundation Classes (C++, Win32)

* WTL (C++, Win32)

* Windows Forms (.net)

* Windows Presentation Foundation (.net)

* WinUI (C#, C++)

Please tell me if you forgot a UI library provided by Microsoft?

Gtk tries to make Gtk2, Gtk3 and Gtk4 look somewhat same and integrated applications of GNOME feel rather same. Similar for Qt and KDE and for Apple. Honestly, Firefox and LibreOffice doesn't fit perfectly. This is also the reason for Epiphany, which is using Gtk natively. https://developer.gnome.org/hig/

https://develop.kde.org/hig/

https://developer.apple.com/design/human-interface-guideline...

I miss a HIG for TUI (*curses). The behavior of CLI applications is partially defined by GNU (-l, --long, -L) but of rourse requires reading the manual: https://www.gnu.org/prep/standards/html_node/Command_002dLin...


You forgot ATL, and the WinRT evolution since Windows 8.

As for Gtk and Qt, don't throw rocks when the roof is made of thin glass.

All Gtk+ versions require major rewrites and now they even dropped Glade, with the replacement coming who knows when.

Qt, is now focusing on QML instead of C++ Widgets and also requires rewrites across versions.


Firefox has improved a lot in recent versions in regards to following the system theme on Linux. LibreOffice is still meh. I have a friend who uses Manjaro and a lot of buttons in LO are basically invisible with the default theme.


It is a shame that GNOME has no manpower to quickly update all of its apps whenever HIG changes. Nevertheless, consistency in GNOME apps has been much better than default windowls for a long time.


Maybe I’m just being pedantic, but when an OS uses 4+ different design languages across all the system software, While it has little to no effect on my ability to get work done, I simply prefer looking at a pretty, consistent UI.

To be fair, macOS isn’t perfect either, especially with some of the system apps that have become the iOS equivalent running on macOS in the past years. Although I do find macOS to have greater consistency overall than Windows.


Apple's UI design peaked several versions ago, and now it is a slow descent into random design changes for the sake of maintaining the salaries of their designers.


I disagree. I was skeptical about Big Sur. I loved the look of the Mountain Lion days, through Sierra, up to Catalina. Big Sur felt like a big difference that I wouldn't like. But, I switched over and have found that Big Sur is actually a nice upgrade visually from Catalina.

One thing I really love is the visual indicators in the menu bar. For example, I like the icons when I'm connecting to a Bluetooth device. I also find that Finder is pretty clean and nice to use, among other things.

Obviously it's all subjective but I think Big Sur is probably the nicest looking/feeling version of macOS yet. It seems like the "Mountain Lion was the best" way of thinking is mostly just nostalgia.


I would not call "Mountain Lion was the best" just nostalgia. The UI was more concise and polished in general. Consider the Big Sur sidebar, on some Apps it acts a shortcut list, on other as a tab bar and on others its used to host hierarchical views. It not only does not improve the UX in a functionality, it also breaks the reading flow as we need to look in the toolbar (left to right) and then on sidebar (top-bottom) as Apple is pushing developers to use it. It's not to say that skeuomorphic design was perfect too.

Using Mountain Lion in 2021 is going to feel less aesthetic than Big Sur just as using System 8 in 2011 felt. Overall consistency and sizing of Mountain Lion is superior to Big Sur if you consider a keyboard and mouse based OS just as Big Sur is superior if you're used to touch input and modern iOS UI.


Agree. A desktop OS has different needs than a mobile OS, and Apple is trying to foist iOS onto its desktop users under the guise of progress, but really nothing has fundamentally changed about using a keyboard and mouse to interact with the computer in decades. And that experience is very different, if you are skilled, than using fingers.

Of note, macOS has always been very good at having consistent keyboard shortcuts across apps, something Linux is still trying to learn.


We live in the world of web apps and electron now, UI consistency is dead and buried because they killed it. Windows's UI mess is just a reflection of them hiring modern developers.


That is true. I pine for the Macintosh Toolbox days when there was a simple and consistent UI ... essentially dictated by having a modest set of UI elements and a single framework for displaying them.

But I remind myself that in 1984, the idea of a visual interface was a little shocking to people: "What do I do? Where can I click?"

The Web kicked open the door and allowed all manner of UI designs. At the same time though, people were more comfortable navigating the breadth of UI by then.

I still prefer simplicity, consistency though.


"What do I do? Where can I click?"

...and now several decades later, I find myself asking the same question whenever I have to interact with a "modern" UI. Is it really that hard to make buttons look like actual buttons, and static text not look like buttons!?


Windows UI has been utterly inconsistent since Windows 8.

'Modern develpoers'? What're you talking about, first of all, HN has weird trend of speaking as if Devs are these all-powerful artisans at their org when actually there's a Product Manager and a whole design org that makes these calls, Devs at best can file a recommendation and maybe get it considered.

Secondly, Electron is a business choice to minimize time spent doing cross-platfom GUI development. Can someone give me the list of cross-platform apps from back in the day with well thought out platform-specific GUIs? Cause I swear most of the popular Windows apps I used in the early 2000s like Winamp, Foobar2000, Notepad++, Soulseek, µTorrent, were Windows-only. Everyone's not just gonna run out and learn Qt, so tired of this low-hanging fruit type comment about Electron/Web Developers ruining everything. Go talk to this thing called the market instead.


Apple has killed UI consistency too. New iOS and tvOS are just a mess of endless half-broken features in a pathetic attempt to satisfy every possible use case out there. Jobs would have used napalm on the whole UI/UX team.


Maybe. Jobs also introduced some rather outrageous UI (IMHO) when he returned to Apple.


I think a difference with Jobs at the helm though was yes, he let some really terrible UI's get into production, but he also had no problem axing them when he finally accepted they were awful.

The problem we're seeing now is nobody is willing to rollback bad ideas.


The UI consistency of most Linux distros is better out of the box.

2021 the year of the Linux desktop? /s


Ironically Linux's relative consistency is in part due to the long standing complaint about how inconsistent it was, which motivated developers to create ways to have unified theming across toolkits.

Meanwhile, the rest of the world went full derp and decided that UI consistency is for boring people who like to actually get things done with a computer.


To add to the irony too, because Linux was so inconsistent for so long more of the GUI toolkits also had to adapt better to fluctuating layouts and had fewer reasons to hard-code specific pixel sizes for controls (because one person's theme might use hugely different sizes than the next person).

Microsoft found out the hard way with Windows XP that Win32 controls generally can't be rethemed in ways that change the pixel counts because they were consistent for so long that apps did all sorts of (sometimes very dumb) pixel-specific logic. Microsoft's commitment to backwards compatibility makes any consistency in theming Win32 controls near impossible without application developer buy-in, and buy in of XAML and actually adaptive layouts has still been extremely slow overall even if you can discount how long pixel-perfect RAD tools with zero adaptive layout support dominated early Windows development (including and especially VB <= 6).


Consistency is not something windows users expect. In the "windows world" most software is downloaded from different sources, different vendors, different styles and each tries to stand out.

The result: every program is different in appearance and behaviour.


I did not use it much after W98SE. W98SE was very consistent imho.


Office 97 had a different style. Most commonly used programs had different sytles: winamp had its own UI, IE had it own theme, winfile had different icons...

Yes, system and default apps were somewhat consistent. But out of the box, a win9x installation was very poor with regard to installed software; you had to install more things if you wanted you computer to be useful. And the consistency went away.


>Windows's UI mess is just a reflection of them hiring modern developers

While I agree UI consistency is dead even on MacOS now, personally I believe the Windows issue stems from them being too scared to actually push out full redesigns.

Look how vocal and angry people were when they started redesigning Settings even though most of control panel was designed for sub 800x600 resolutions.

This is why we're stuck with such inconsistency because they can never make sweeping changes without people freaking out, this is why we're stuck with things like that terrible device manager that refreshes the whole view and flickers 3 times when you plug in a USB device.

Really Windows should be pushing out a complete redesign and update of at least 2 of these apps every version. People will scream and shout every time they do but it's the only chance Windows has to completely modernize itself and get it up to par with Mac system tools and standard apps.


What surprises me is how little functionality the new settings app has, and how often to get things done, I need to click through to an older settings screen.

Its not that they modernized the old settings / configuration screen. They made a new one that does about 1/3 of the job and still links to the old one for the last 2/3. It does not seem like Microsoft intend to slowly have the new settings setup subsume the old settings. Nor do they seem to want to improve the old settings. Instead we are left with a weird stack of settings screens.


This is largely because "modern" design has such poor information density, it requires 15 different screens for a single screen of a "legacy" UI.


They've made it pretty clear that to prioritize they've been following the 80/20 rule as best they can with the data they have. They try to prioritize the things people do most often in each iteration because they don't have the budget to do 100% of the things all at once. (And it probably is a waste of time to upgrade settings features that 0% of people use.)

The big real complication is that data they have available on what is used 80/90% of the time is telemetry. It's not a coincidence that the people that find that the settings they use the most that haven't been converted are in the set of people most complaining about telemetry and most actively disabling it.


9 years and counting.


As sibling mentions, the problem isn't that they made a new settings panel, it's that the new settings panel is both slower and less functional than the old ones!


When you refuse to hire junior developers for $50-60k and every new hire has to be a $200k rockstar, the rockstars have to provide value. They have to have something to show. So they have to rearrange something, replace something, do something.

This isn't unique to Windows. It's a general problem. When something like network configuration or screen resolution had been a pretty stagnant thing for 20 years, you could just leave it alone or... spruce it up. Sure, it's always possible that there are better ideas. But implementing a change because you have a better idea is one thing. Implementing a change to justify your salary is another thing.


I'm still pissed they haven't fixed Windows Explorer's "Open with..." popup since they Metro-ified it. It used to be you could type-to-select from the list of apps...now I have to use the mouse to scroll down.


Even font rendering is inconsistent: notice how Win32 widgets use subpixel antialiasing but the modern ones don't.


Sad truth is that nobody cares. Not the users, not the makers. It would take a minuscule fraction of Microsoft's resources to fix this, especially when they are anyway making a new OS. But other considerations take precedence, since nobody really cares if textboxes look alike.


>It would take a minuscule fraction of Microsoft's resources to fix this

This isn't true, almost each thing would require at least a UI rewrite to get them up to consistency or you'd just have a task of trying to hack the ten or so UI frameworks to look the same but they wouldn't act or feel the same.

I don't think it's impossible but you need a product focused exec who cares enough about it to basically demand a few of the apps or panels be rewritten each version and keep sending it back until it looks right.

Has to come from the top because a designer going around and trying to get them to rewrite say Device Manager to make it feel up to date and stop flickering isn't ever going to convince anyone.

Of course every step of the way reviewers and your own community are going to be shouting at you for changing 20 year old UIs. It'll be a thankless task until 10 years after it's done when they come to terms with the change and realize they finally have a consistent Windows.


Also Microsoft doesn't have anywhere near enough resources to rebuild three decades of Windows software and they have made it a strong point that they don't want to break compatibility with applications built 20/30 years ago. Even changing the sizes of controls by a single pixel to old controls can sometimes cause bugs and compatibility nightmares Microsoft can't test for nor easily fix.


For me, this is a blessing in disguise. Modern UI design is to pad everything out with reams of whitespace, hide elements that no longer fit behind a "...", then remove any affordances in the name of "cleanliness". At least some parts of windows reflect a more sane design language from an older era.


They don't care because they have no taste, it's sad that the dominant personal computing platform is utterly tasteless (from a design and technical perspective).


Check WinUI Github repository 2000 issues and mounting, do the same for other UI stacks, not sure where those resources would come from.

They even had to restaff Forms and WPF teams, because with UWP they were reallocated to something else.


Dear Microsoft: Just clone Zukitre giving consistency and a neutral gray-ish scheme to everything.

I am not an artist but media producers love the neutral gray and so does everyone else. Light themes are too bright.


Tell that to news sites. I wish more news sites used containers around their content and had grey backgrounds.

ESPN and NPR are two examples of news sites that use containers with grey backgrounds and I think they're both really nice to read. Not some blinding amount of pure white like most news sites.


Windows hasn't had a consistent look and feel since Windows 95; even Win95 OSR2 brought some Active Desktop widgets and browser integration into explorer, which broke the uniformity of the UI.


Windows 2000 was pretty consistent.


DOS was boss for consistency.


In what way? Every single program had to make its own interface. Even in text mode, there are tons of hacks to make interfaces look different, and not much has changed with more modern CLI programs.


Not true. CUA-compliant software was somewhat consistent, but they were rare. Many simply implemented a half assed toolkit each with a different behaviour and appearance


Is it hard to make all these elements consistent?


Windows does have a large visual surface, but so does OS X, and Apple mostly manages to have a consistent UI. I wonder if that's because Microsoft has introduced so many different UI frameworks over the years.


And most of them are now deprecated. In fact, on .NET 5, there is no good desktop UI framework at all. It seems to me that if you wrote a Windows Desktop app in the last 30 years, the only way it would still be supported today (i.e. possible to maintain using non-deprecated frameworks) is if it was based directly on the old Win32 API (or the MFC wrapper).


> if you wrote a Windows Desktop app in the last 30 years, the only way it would still be supported today ... is if it was based directly on the old Win32 API

I thought the same and did just that to see if it holds true: https://github.com/sjmulder/netwake

By default you get Windows 95 styling and Windows 3 fonts. You have to opt into 'visual styles' (introduced in XP) with a declaration in the app manifest and have to manually query and use the system font. DPI awareness is also opt in and puts all the work (sizing/positioning, scaling/reloading fonts) on you. But when you do that, it does look fine on Windows 10.

Not so much on Windows 11. Some of the widgets have been updated to mimic the new style but when you put it together it looks messy and old fashioned (e.g. fonts + you don't get the new context menus).

I'm curious to learn how one would create a 'proper' Windows app without having to reimplement the system's widget styling.


That shit makes me so happy to use Qt


.NET 5 saw renewed development in WPF, including some useful improvements over WPF in .NET 4.x. They've given the impression that WPF is fully "undeprecated" and current documentation points to WPF as the best way to utilize WinUI 3.0 controls (modern Windows controls) in .NET today.

(WinForms also saw a bunch of reinvestment in .NET 5 and also has a road to migrate to WinUI 3.0 controls if you really want, but I would argue that WinForms was never a "good desktop UI framework".)


Go to their github issues and have fun reading through them.

Basically Microsoft had to rampup Windows Forms and WPF teams (most likely ramped down to maintenance modus), as otherwise many companies would just ignore .NET Core.

The designers, which were redone to be out of process in .NET 5, still have lots of issues.

Basically, the future is UWP/WinUI, but just like with VB 6, there are plenty of big shot customers that want their apps to keep running and aren't open to rewrites.

And in what concerns WinUI, MAUI is being built on top of WinUI (with incompatible XAML) and then there is Blazor.

Plenty of political wars going on currently in Redmond UI teams.



This is mostly correct, I think. Just imagine all those SilverLight apps that are languishing.


Try to run Carbon, Cocoa, Catalyst and SwiftUI applications across similar workflows and you will find similar issues.

Last week's ATP podcast had a long rant about it.


Based on the last hundred years of Windows releases - apparently the answer is yes.


They are not going to lose users because of this, so why bother?


This is certainly why. There's not much value in making them consistent. Hell, I notice these things but don't really think or care much about them. It just doesn't affect my interactions. They all still look like places to enter text, which is the important part of their design.


Tbh some of these even look better in context. I’m not sure why it even matters that every text box is pixel perfect identical rather than suitable for the environment.


It’s a part of why they lost me.


I should've said they won't lose a a meaningful share of users.

Most people don't care. They probably don't even notice because they only use third party software on top of Windows.


It's not true that most people don't care. Most people absolutely hate it that they have to re-learn Word or Excel or Windows whenever a new version comes out. Just ask any mom or dad. But what can they do about it, really? Nothing.


My designer eye makes me really feel bad by looking at these all close together


Be honest: Do any of the Windows components in isolation make you feel good either?


And they say linux desktop environments UI is inconsistent...


paging for the next time someone complains about cross-platform solutions not following the OS design guidelines exactly




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: