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
The main thing that's hard going down this route is dark mode support. The Win32 USER and common controls just don't not support dark mode, but are actively hostile to it due to the amount of hardcoded light colors and backgrounds in the system. All of the system colors are light regardless of the dark/light system setting, highlights are hardcoded to light blue, disabled controls use a hardcoded color, half of the window messages for changing control colors are silently ignored with theming is enabled. Menus are among the more difficult to deal with as they require extensive owner draw.
On top of this, there are a small handful of system UIs that do support dark mode and make your program look inconsistent with dark mode regardless. Message boxes will switch to dark mode, and so will file dialogs -- which is a problem if you've used the Vista-style customization, as any syslinks will appear in a color of blue that's hard to read against the dark mode background.
First, dark mode is for people who set their screen brightness too high.
Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed because parts of the platform are so disconnected from other parts.
Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not.
Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in Windows XP. Beyond that, there were always a few hardcoded colors like disabled gray text going back to Windows 95.
Dark mode ignoring Win32 system colors is not incompetence. It was _intentional_. Dark mode was introduced by the UWP side, which intentionally did not extend it to Win32. To this day, there is not even a Win32 API for desktop apps to query whether dark mode is even enabled. The official recommendation is to compute the luminance of the UWP foreground color setting:
But they had dark themes for the XP theming engine, e.g. the Zune theme, didn't they? They could make the dark mode switch to a dark theme for XP-style themed controls and configure dark colors for the Win32 system colors.
Yes, and this is also how Windows 10/11 explorer turns some parts of its UI dark like scrollbars. But notably, Microsoft refuses to officially support Explorer's dark control themes or ship a complete dark theme, and because the theming engine only loads themes signed by Microsoft, no one else can ship one either without patching the OS.
Only a very small minority of users actually care about dark mode. It is not a general expectation for software, as loud as those users may be on forums like this one.
Mobile is different from desktop. Dark mode became popular with OLED panels because on those it saves battery, and blacks actually look nice, compared to the average LCD. I use dark mode on mobile but light mode on desktop.
I'm not sure how much Android use generalizes - I prefer light mode, but I'll use dark mode for the battery savings on portable devices with OLED screens.
> First, dark mode is for people who set their screen brightness too high.
Not at all. It became popular mainly because as part of the spread of the flat UI epidemic, the previously non-optional “light mode” OS UI themes all shifted away from midtone colors to blinding stark whites. This meant that monitor brightness settings that had previously been comfortable suddenly weren’t.
On top of this, modern flat UI light mode themes consistently have poorer contrast and delineation than their dark mode counterparts, because higher contrast with darker grays makes flat white UI themes appear “dirty”. So even if the brightness isn’t an issue, your eyes have fewer visual cues to guide them.
Aside from that, on IPS panel monitors lowering brightness past a certain point also greatly lowers color vividness which looks bad, which is why some of us like to keep it maybe not maxed but a bit higher than is comfortable with light mode.
It is not. I have some issues with my eyesight and dark mode makes it easier to use a computer in some lighting conditions. So for me dark mode is an accessibility feature. And yes you could use the ugly recolor feature windows has but dark mode does the same thing and looks better most of the time cause a UI designer actually looked at it.
> dark mode is for people who set their screen brightness too high
There can be other valid perspectives than your own.
I don't think your brightness sentiment is universally shared by most people, hence the downvotes. I think this comes from one particular study that people just end up parroting, possibly via third-hand gossip.
While a sufficiently low-brightness screen might have some specific advantages to dark mode, I think the issue is more nuanced than that.
First, not everyone can set their brightness to an appropriate level.
If the user is prone to migraines or light sensitivity, light mode even at a low setting could trigger headaches.
Light mode also produces significantly more blue light, which can have health side-effects as well.
If you keep a white screen on at appropriately low brightness in a dark room, the relative difference between the screen and the surroundings is still massive. This creates pupil strain as the eye constantly adjusts. Dark mode aligns the screen's luminance closer to the room's, reducing this strain.
Dark backgrounds make colors pop more vibrantly and prevent the "washed-out" look that can happen when bright images sit on a white background. It can also reduce halos visible around bright objects in photography apps and make the UI less distracting.
For battery-powered/mobile devices, dark mode uses much less battery power on OLED screens.
Maybe I grew up with Windows so the older uis don’t phase me, but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland. The average Windows user might stumble on an aero dialog, which is arguably less jarring in win11 than og metro.
> but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland
I've been around long enough to remember MS and their fans banging on about how bad other OSs were for their inconsistent interfaces, so I feel justified in getting a little riled at the hypocrisy of how much of a mess UIs are in Windows these days.
And I don't see it getting any better - they'd rather spend the time finding new places to slip in adverts. And this is far from the fault of app developers, while they often do have something to answer for wrt consistency, because the worst culprit is MS themselves both in their apps and the OS.
I shouldn't have to click to make sure the right thing has focus for instance, particularly after switching from another virtual desktop, I should be able to see this information easily but there is no consistency in titlebars and other window chrome any more.
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.
The last time I built a native Windows app years ago, I used WTL 3.0. It’s a light weight wrapper on the native Win32 API, lighter than MFC. It took out the unpleasantness of working directly on Win32 API and wrapped it in a simple OO framework. It had access to all features of Win32. It could produce runtime binary in dozens of K, instead of MB or GB.
Microsoft released it open source later on. Looking at the repository, looks like it has been kept up and maintained, up to version 10 now.
WTL delivers very small and efficient code, very close in size and speed to SDK programs, while presenting a more logical, object oriented model to a programmer.
I don’t want to be that person, but if you can think of a decent API for your MFC-style wrapper, an AI should be able to write a decent implementation for you.
Agreed. In fact this supports the GPs point about using the rawest form of GUI manipulation.
For years we loaded up libraries and abstractions to minimize boilerplate. These hid the actual underlying mechanisms and often made specific customisations harder to do since you were taken away from the raw functionality.
These days AI is extremely good at writing boilerplate and in my opinion explicitly typed out boilerplate code is much easier to reason about than a library that abstracts things away to a one line annotation or similar.
A good example is that i've recently been leaning back to the raw Android apis for things like recyclerviews etc. It used to be 10+ files to changed to create an efficient scrolling view on Android with various resources and adapters required. So a whole bunch of libraries came out to try to abstract the complexity away. You know what though? I don't care about that anymore. I'm going back to the raw GUI APIs where possible because it's so explicit and clear even if it's 10x more code.
Do you know if a remote backup service was written?
I am going through SimpleBackup code, (and if not exists) I would like to contribute remote agent for backup. Any pointers for that implementation would be appreciated.
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.
So I went and checked my suggestion on colors. You pulled it, but then never actually implemented it (unless I don't know how to toggle it). Are you going to add colors to the current version or should I go back and retro merge the color code I have?
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.
UI elements jumping and moving around like that are absolute hell for usability. It denies muscle memory, demands eye tracking (and good eyesight and situational awareness in general), and keeps users on edge because things keep changing.
I'm failing to see the point of that dropdown (well, dropup) menu. The space is there from the beginning, but as unused and wasted whitespace. Why the unnecessary button and associated UI movements?
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.
The "once a year" point goes both ways. If it's only going to be used once a year, then "juicing" (in the sense that the original article meant) is only going to give very negligible added value whichever way you look at it. The original example (mushrooms in Mario) is effective because of the frequency of the event which triggers it. If the player only heard the sound once per year, it would be irrelevant.
On the other hand, if we're talking about parts of the UI which will see regular use then I agree with the other comments about usability reduction, while also acknowledging that there are other opinions out there. The best approach with these sorts of controversial features (i.e. those which some users love and others hate) is to offer a toggle in the options with a default aimed at the non-power user.
> If it's only going to be used once a year, then "juicing" (in the sense that the original article meant) is only going to give very negligible added value whichever way you look at it.
Meh. The animations juice, maybe. The slightly non-standard UI, though, is probably worth it if it avoids the nested-modal-dialog hell the stock Windows UI is prone to having. Installed mouse and audio drivers on NT 4 recently and, well, I’m glad I forgot how bad it was. Making settings non-awful is important even if you only visit them once.
What’s the upside for the user of a nested sequence of modal dialogs anyway? Though I understand the technical convenience given how limited the bare Win32 toolkit is. And there definitely is a downside for the user: I can’t say how many times I’ve seen relatively sophisticated users fruitlessly smash the OK button on the wrong (not top-level) dialog, because they all look the same. (This is perhaps salvageable by more prominently shading disabled windows—something Win95 admittedly could not afford on contemporary hardware—instead of blinking the title bar, but is it worth it?)
What you've basically said is "I don't agree with your opinion, therefore you are wrong". While you may have provided justifications for your beliefs, your delivery was unnecessarily aggressive and only served to further alienate yourself from the discussion. I would encourage you to try and engage in more constructive conversation in the future.
For what it's worth, I also despise this sort of needless UI fluff for essentially the same reason they do; it reduces usability.
> UI elements that move around are bad for usability
Bit of a broad brush here. When the "next ->" button moves around of its own accord (in response to changing text content, say) and you need to click it to page through 10 screens of text, that's for sure bad. When elements move in response to a toggle the user clicked when they are nowhere close to the elements that move that's really not a big deal in my opinion. This is especially not-bad when the toggle will move everything back without the user moving their cursor.
Consider the "Backup verification" window[1]: The whole window is overwritten with a readme upon clicking "More on this...". This is bad, I've seen more than enough people X out of such windows (because they think it's not the window they were working with) and then wonder where the window they were working on went.
Why couldn't the readme open in a separate window? It's completely different contextual information to the window they were working in, and in fact most software do produce a new window when opening help documentation so users aren't confused. Different windows for different contexts, this has been standard design for windowed environments since forever.
Now consider the "Backup settings" window[2][3]: Why are the various dropdowns a button you click on which proceeds to resize and move the entire window?
Standard design for dropdowns have always been dropdown menus. Almost everyone knows how to use dropdown menus, both Windows and other programs use them. This is inconsistent design language for the environment the software operates in, and this is confusing for users.
What's more, there is no scroll bar to indicate there is information overflow in the window[2]. Can you tell there is more information above the "More options..." section in window[3]? I know I can't.
We need to take a page from Apple's playbook on this: Consistent design language is good design language. In this case, follow the design language of Win32 and Windows in general. Yes, this isn't as easy as it sounds since Microsoft themselves violate the rule of a consistent design language, but that's not an excuse for others to also violate it.
Not presenting a scroll bar to indicate information overflow is also inexcusable. A user interface exists to inform and guide a user, hiding or even lying to the user defeats the very purpose of a user interface. On that note, the window is being resized, why then isn't it being resized to show all of its contents? At least the resizing would then have a legitimate reason.
Now consider the "Preferences" window[4]: Why are the help texts for this window hidden behind "?" when the other windows either don't have them [1] or show the help text outright[2]?
Why is the "More..." text a hyperlink and the "Less..." button a button when they are the same interface element? This criticism also applies to the "Backup verification" window which exhibits the same problem.
This is all inconsistent design language within the software itself, let alone when compared with its operating environment. This is bad, again: Consistent design language is good design language.
>Needing to pay attention to the contents of the screen? What an unrealistic burden.
I know far too many people (read: common users) who quickly lose track of what's going on if their program keeps changing things. Hell, I find most people still can't keep track of tabs in a web browser (because each tab overwrites most of the window), let alone your stuff.
>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.
A singular, global button or toggle somewhere that permanently keeps the UI in either Simple or Advanced modes? Almost nobody needs to flick between the two back and forth. Common users only care for what will get their work done, power users always want (and can deal with) all the details.
>The point of all that "hell" is the layering and progressive refinement of the UI.
What you call "layering and progressive refinement" I call an unnecessary click and movement of UI elements that don't have to exist. The former is a waste of time, and the latter is a waste of screen real estate.
For the first link I think it’s pretty bad as-is, but would be much better if you distinguished the new “more” items in some way. Eg different colored text (and make the “more” button match that formatting). That way you don’t need to re-scan every single option to find what’s changed, and keeps the visual shape of the sections of existing text there. I am also baffled by the menu hiding. But I think the other two examples are pretty nice.
My 89 year old mother-in-law doesn't have great vision but also poor situational awareness around web sites for government and financial services. For someone that is used to paper forms, it is extremely difficult to navigate your way around these places. Not intuitively knowing that a "profile" section will be somewhere to adjust account information, or when autocomplete and drop down menus make things jump around makes many of these experiences exhausting and frustrating (and even dangerous)
These sort of over the top animations can also help folks like that, like how you see minimized windows shrink into the dock on a Mac, as opposed to just disappearing on Windows.
The pi permits access to a commonly used computer security system called "Gatekeeper" sold by Gregg Microsystems, a software company led by CEO Jeff Gregg.
Gregg is connected to with the "Praetorians", a notorious group of cyberterrorists linked to recent computer failures around the country.
Once the Praetorians sabotage an organization's computer system, Gregg sells Gatekeeper to it and gains unlimited access through the backdoor.
This one does confuse me though. Why not have the sidebar display permanently instead of hiding it within a drop-down? There already appears to be white space and a column header ("More options...") dedicated to it already. Also, why is the button label pi? It's all just really confusing and feels unintuitive. I imagine some thought went into it though, so I'm curious as to the reasoning behind it.
Other than that one particular case, I like what you've done with the rest.
These are nice! I’d recommend making the animations even faster. You only need a couple frames of animation to give the feeling of moment, otherwise the UI starts to feel sluggish.
This seems pointless to me. The "More…" button adds three options and some help buttons. Wouldn’t it be less confusing to just have the options on the screen at all times?
These are great! how tricky is it to add these effects?
I’m mostly stuck in the html/css/js world and implementing anything like you have here would be a pain
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.
Really tasteful animations. They allow me to see what changes when I do something, infinitely better than just popping things in and out of existence. Thanks for sharing examples.
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.
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
reply