Screenshots are made on Windows 8.1 box, the windows chrome comes from there.
Plus the whole thing is meant to work on ancient Windows versions (like, Vista and WS2008 ancient), so that ultimately defines the minimal common UI denominator.
Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper.
Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuances of the UI, yours to extend and mend as you wish.
If there's one thing that Microsoft is really good at, it's ensuring deep backward compatibility. So anything that's based on Win32 API is going to be stable. If it works now, it will work later.
I have some examples from 10+ years of development updates accumulated here - https://bvckup2.com/wip
Yes, I wrote one [1] and others did too, e.g. [2] and [3].
The gist of it, as mentioned in [4], is that you need to have a web server that implements checkStatus and saveConfig PUTs, and PUT and DELETE for saveBoard.
Most transitions are trivial to implement - you have a state A of your dialog that looks like this and a start B with your target look/layout - so the framework figures out what needs to move where, what needs to be hidden/shown and then animates that in a quick loop.
The complicated part is the fading of controls. There's no fine-grained control over when Windows repaints controls exactly, so unpainted parts of the background showing through is a nasty issue. Requires basically per-Windows version voodoo, because what works for W8, doesn't work for W10 and vice versa.
Yes, hell, hell, I'll tell 'ya! Especially horrible the muscle memory aspect for the UI parts that are accessed once a year, if ever. And don't get me started on the situational awareness. Needing to pay attention to the contents of the screen? What an unrealistic burden.
Seriously though, feel free to offer your version of the same that would cleanly separate secondary options and sub-options so not to overwhelm the user with a laundry list of settings.
> I'm failing to see the point of that dropdown (well, dropup) menu.
The point of all that "hell" is the layering and progressive refinement of the UI.
I make a boring Windows software that uses this sort of juicing in its UI.
Had some doubts if it would go well with, you know, your good old sysadmin types, but it did! A bit of embellishment that doesn't deviate too far from the native look and feel goes a long way. As per some guy here on HN - "delight your users" and all that.
Few years ago started using asserts as an ad-hoc documentation mechanism for invariants and then also started shipping them in production builds. When triggered, asserts grab the stack trace, write it into the application log and give an option of sending a bug report. And then they shut down the program.
Was scary at first, but the initial pain is absolutely worth it.
This flushed hundreds of absolutely crazy edge cases, improved code quality and stability tremendously. It also forced writing cleaner code to begin with and sped up debugging while in development. Now have about 3K asserts in 250 KLoC code base. Can't recommend this practice strong enough.
Did an AB test a while back and mere presence of the PayPal option boosts sales through all other options plus generates extra sales through PayPal itself. Not something that I was expecting at all, but the confidence level was over 99%.
Plus the whole thing is meant to work on ancient Windows versions (like, Vista and WS2008 ancient), so that ultimately defines the minimal common UI denominator.