Hacker News Reader

Comment by abainbridge | Hacker News Reader

There is no consistent native look/behaviour on Windows. Even a single program (Excel), written by MS themselves, has no consistent style. I think I see 7 different styles in these search results: https://www.google.com/search?q=excel+%22save+changes%22+dia...

Maybe some of those variations are due to running the same Excel on different versions of Windows, and it conforming to what it thinks native looks like on each. It's hard to tell.

If I redo the experiment on my own Windows 10 machine, I see 7 different kinds of save-changes dialogs, from these 7 programs: VS 2013, Notepad++, Paint.NET, Photoshop CS6, TextPad, UltraEdit and WordPad.

Again, this isn't a perfect test because many of those programs are using non-native GUI frameworks. But my point is that as a Windows user, I can't tell what native is, because approximately every program looks different.

View on HN

Consistent look is nice, but when talking about "native" UI, I really care about reliability and seamlessness.

Custom UIs tend to be crufty; slow-ish, sluggish, they don't quite integrate with OS conventions (right-clicks, C&P, tab, overflow behaviour, scaling, rendering quality, window resizing behaviour and so on). If a custom UI is none of those things, and not really ugly, I don't think I mind. For example, I never played a computer game and thought, nice game but why are the buttons so custom?

I think the "native look" requirement got further diluted in the last decade with the rise of so many new platforms. A while back, it was mostly Windows; Linux was less popular, and frequently TUI anyway, Mac was perhaps more niche. Java GUIs were a thing and not very well-received. But then at least these "platforms" came on with different, high-quality, "custom" UIs: Android, iOS, Electron (it has its own custom feel to it), generally web apps, and so on.

So I'm desensitised to native "look", but not native "behaviour".

Yes, Windows UI is a mess. The Office team has implemented their own UI library in the past... I don't know what they're doing now, but I think the very latest just gave up and it's an app wrapping web pages (Fluent UI + React?).

The greatest and latest in Windows land is WinUI 3 but none of your mentioned applications will probably ever use it because it's completely incompatible with their current user interface API.

OK, but as for "what is native" on Windows, I'd say it is still the Win32 controls because Win32 still underpins everything. Microsoft's problem is they painted themselves into a corner because Win32/GDI has inherently poor support for HiDPI and scaling.

So you shouldn't use the native controls.

It's illogical but partially explains why it's a mess.

There are APIs to enable HiDPI on Win32 and GDI+, and application manifests as well.

As for everything else, somehow the mess started with WinRT project, and nowadays it seems they got themselves into a mess via the business units that would gladly keep UWP running, those porting UWP features on top of Win32, and the remaning ones like Office and .NET that couldn't care less as now Azure runs the bank, alongside XBox which was never a fan of anything besides Win32 (as seen on the GDK release announcement towards the current state of WinRT support).

To make things even better now we have the Blazor team trying to put it everywhere, including web widgets.

It feels like there is a UI civil war going on, most likely caused by management KPIs.

> Maybe some of those variations are due to running the same Excel on different versions of Windows, and it conforming to what it thinks native looks like on each. It's hard to tell.

The Office apps have used their own controls for a long time. Check out Word 97 running on Windows NT 3.51 for example: http://toastytech.com/guis/nt351word.png / http://toastytech.com/guis/nt3513.html

Usually the office controls are integrated into Windows common controls in a later version.

In the past they would either land in Win32 classes or updated MFC.

The ribbon introduced by Office eventually became available as a COM UI library.

> Maybe some of those variations are due to running the same Excel on different versions of Windows, and it conforming to what it thinks native looks like on each. It's hard to tell.

This isn’t quite fair — as far as I can see, most of the dialogs use precisely the same GUI framework, running on different OS versions. It seems reasonable to expect the GUI style to have changed between one version and the next.

Of course, nothing is quite so simple: the exceptions to this are the very latest versions of Excel, which use some sort of weird hybrid UWP-esque dialog thingy. Is this ‘native’? It depends on how you use the word, but it definitely seems quite different to Win32 or WinForms-style dialogs.

But even so, I’d still argue that it’s wrong to call the word ‘native’ meaningless on Windows. There definitely exist some GUI libraries which are endorsed by Microsoft and have greater integration with the OS. As you note, it can be quite difficult for the user to tell by look alone which library is used for any particular application, but that doesn’t mean there are no benefits to using a native GUI — the integration with the OS is important. For instance, I use a custom keyboard layout; generally I find this works fine with native GUIs, but non-native ones don’t support it very well (with the notable exception of Qt). And that may be a somewhat niche example, but one can imagine many other preferences which non-native GUIs might not respect: accessibility, dark mode and border colours are three I can think of, and I’m sure there are more.

There is a consistent native look in Windows which is the standard at least until Windows 2000. but has fallen out of use.

Everyone wants to have a fancy, nonstandard UI with more freedom and options.

It is still there.

That's just not true. Even in Win2k/NT you had the Windows 3 dialogs in some system apps.

Some were still in Windows 10.

https://old.reddit.com/r/Windows10/comments/l85hsx/windows_3...

I'd say that's a Windows 3 era custom implementation of a file dialog, using fine grained controls that have nicely modernised. The buttons and the scroll bars certainly aren't contemporary with that cute folder control.

In a way I see it as a demonstration of how it should be: the UI intended at the time of writing is presented using current controls.

But even the text is broken. The text in the window title bar is way sharper than the blurry mess in the window. If the text isn't even the right resolution, it's not using "current controls".

Oh, didn't even notice the title bar sharpness. The scaled new buttons look even worse than the scaled old pixel font elsewhere. But that doesn't really change the way I read that example, it's an old UI, running on new controls (where they have remained in maintenance, e.g. the button). Scaling is done to the whole window, including still-current controls, because the old code is free to do framebuffer-level work.

They still use Win32 and COM shell utilities underneath, so there is plenty of stuff a NIH framework will have to implement, while those Excel versions share the same core features.

Reply on news.ycombinator.com