2

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:

The top-left corner of an Opera browser The same Opera snippet, with the menu expanded

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.

4
  • 3
    I had no idea you could double-click the top-left corner to close a window. I've been using the × all my life like a loser. Aug 30, 2018 at 20:26
  • Is this specifically the menu/shortcut you're concerned about? My guess is that this override would go mostly unnoticed. Aug 30, 2018 at 20:28
  • 1
    @maxathousand: I may be showing my age; back in Windows 3.x days, there was no X button, and double-clicking the system menu was the main way to close an app. Those were the dark ages, of course. To send a tweet, one needed a slip of paper and a homing pigeon. I have other UX concerns about this app, but this specific issue - overriding the system menu - is what I'm asking about. Aug 30, 2018 at 20:29
  • Hahha, got it. Evidently, I'm not a user who would be affected by this change, but you are proof that some users might be. For what it's worth, Microsoft hasn't continued with that double-click-top-left-to-close functionality in their new Microsoft Apps architecture. They even hide the typical system menu for these desktop apps (the Restore, Move, Size, Minimize, Maximize, Close options) behind a right-click/long-press interaction. Aug 30, 2018 at 20:45

2 Answers 2

2

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:

wxslider

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).
1
  • +1 that's quite a story you've got there. A good example of knowing the rule and knowing when to break the rule.
    – Michael Lai
    Aug 5, 2023 at 22:12
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.