Is there a use case for overriding/overpainting the OS-provided system menu?

Question

An app developed by another team here at Acme Software overrides - in fact, erases - the operating system-provided system menu (it also custom paints the minimize, maximize, and close button, but that's another issue). My opinion is that this is a bad idea; it interferes with deeply-ingrained user expectations. For example, you cannot double-click the top-left corner of the window to close the app; it maximizes instead.

Is there a valid use case for overriding the default appearance or behavior of the OS system menu? Are there good arguments for or against?

Here's an example of a slightly modified system menu which, IMHO, is acceptable:

Browsers work hard to minimize wasted space; they're intended to fall into the background and let you get on with what's below. Also, while clicking on Opera's replacement file menu does not give you the standard Move, Size, Minimize, and Maximize, hitting Alt-Space brings up a conventional menu with all of those, so keyboard users are not hindered.

Answer 1

I've got a bit of a story for this:

I'm currently designing an app which uses wxWidgets. wx was conceived in the 90s, and operates on the assumption that all controls should be system-native, and that apps should be similar to each other on an OS to avoid having to re-learn patterns all the time.

Today, this is our greatest pain-point, both in development and user perception. It's not necessarily evident in menus, but take this slider for example:

The screenshot examples here are a bit outdated - the Windows appearance of this slider now has a blue thumbtack in the middle, rather than a green/white one - but the problem is evident: A slider on Windows and Mac means "middle", the very same thing on Linux means "half full". This is a meaningful difference; if the slider goes from 0 to 100, the wxGTK appearance makes a ton of sense, if the slider goes from -50 to +50, it doesn't - why would 0 have any tail at all?

If I want to use one or the other version, it's unlikely for the OS to come along and provide me with the option, so the only solution is for us to build our own slider. And if a click into the slider means "move 10% in the click direction" on one OS but "move exactly to where the user clicked" on another, I could make the design specify different behaviors on different OSes, or I could prioritize consistency within my app no matter what OS the user is on.

The same applies to many other standard components - using the standard components is okay, until a component gets in my way. Incidentally, in my area this comes up constantly as making an audio editor in 2023 has very different component requirements than office apps had in 1992. We'll be switching to QML instead and have ~everything custom in the near-ish future.

In the case of the window title bar, it's an entire bar, often the width of your screen, which contains 3 buttons in one corner, a grabbable area, and then a menu which just repeats these options again. Any app running into space constraints and any app designer looking at the 5 stacked toolbars in their app is therefore looking at the titlebar and thinking "what if".

In the case of recent versions of Gnome/Adwaita, all major browsers and even Windows' default apps (eg Windows 11's Explorer and Settings apps), they've all come to the conclusion that the concept of a titlebar is taking up too much space, and that it's better filled with tabs, menus and other stuff. Removing the window menu in the process is messing with your "deeply-ingrained user expectations", but the overwhelming majority probably has never used this menu, or the "double click to close". Why would they, if the big red X is right there?

---

With all that said:

• Is it a good idea to disobey system standards? Yes, if you have a good reason for it. In the case of ellipses (eg "Print..." vs "Print"), I'd even go as far as saying that the standards are outdated and disobeying them should be the default.
  • NB: Disobeying them just to be different typically isn't a good reason.
• Is it a good idea to remove the window menu? Yes-ish. All of its functions are available via other means to abled users. To disabled users, keeping Alt+Space available might be useful, but if that's not possible, limited resizing and moving is available via Windows key+Arrows. Having a full replacement would be ideal (Gnome uses Alt+F7/F8).

Answer 2

I suppose the obvious use case is when you want to personalize the experience for the user. Various operating systems have tried to open up certain aspects of the user interface for this purpose, including mouse pointers/arrows, icon sets, skins for the menus and windows, etc.

I guess the only thing to consider is whether these are just visual changes that don't have other impact to the behaviour of those components, which as the OP mentioned can have a lot of unintended consequences and therefore should be more carefully considered.

For the power users, there may also be cases where the standard or default behaviours are not really suitable and can be frustrating when you have specific needs. Shortcut keys is one example that's been opened up to users, and there could be other similar use cases.