I'm increasingly seeing this crap, and I'm hereby officially adding it to my list of things that piss me off.

This window is not resizable:

WHY?!

The text that I removed from it is several lines of information, any one of which extends far beyond the width of the text area.

If this were an isolated incident then I'd chalk it up to someone being a moron and move on, but it's happening more and more and more often and it's really starting to rile me up.

PSA: PLEASE LEARN TO USE WINDOW STYLES APPROPRIATELY

I know the rest of you must have pet peeves like this. Let's air the laundry while we're here. What design failures get your goat?

Why? Making windows that properly resize in the win32 API (and I assume whatever OSX and Linux use for their base API) is non-trivial as you have to do all the math yourself. Not to mention the little hoops you need to jump through to avoid flickering.

Higher-level APIs like Windows Forms, WPF, and whatever iOS and Android use typically come with some built-in automated layout tools that make it easier.

Of course the elephant in the room is most programmers are terrible at UI design, and most companies don't care (especially not enough to hire someone to do UI design). Or they simply outsource things to the lowest bidder.

If you really want to see how bad it gets in the real world (tm) I recommend reading The Daily WTF and The Old New Thing. Both are also good at giving you that "at least I'm not that bad" feeling. ;)

What design failures get your goat?

I get really annoyed with programs where the order of yes|no buttons on dialog boxes is inconsistent.

Why? Making windows that properly resize in the win32 API (and I assume whatever OSX and Linux use for their base API) is non-trivial as you have to do all the math yourself. Not to mention the little hoops you need to jump through to avoid flickering.

Despite that, sizing an options dialog so that it's contents fit without scrolling has been a solved problem for so long that the example in the OP is really inexcusable.

What annoys me most is programs that use their own custom widgets instead of the built-in OS ones. Particularly where there are enough subtle differences in behaviour to make it a usability hell.

Most of my windows are resizable - using Qt's layouts to auto-resize the sub-widgets - but some of my widgets* need to be fixed sizes, or it majorly messes up the appearance.

Anything with a major box of content with scrollbars (like your example) can obviously resize fine though, so those windows in my project can definitely resize.

*custom ones with just enough behavior differences to annoy mhagain

I get really annoyed with programs where the order of yes|no buttons on dialog boxes is inconsistent.

I did that once by mistake. I forgot what order the standard Windows button layout was, and accidentally used the reverse, and for the next week I kept instinctively hitting "cancel" instead of "OK" until I realized my mistake.

Making windows that properly resize in the win32 API (and I assume whatever OSX and Linux use for their base API) is non-trivial as you have to do all the math yourself.

Unlike the wacky world of Microsoft Windows, making a window properly resizeable on a Mac is the result of flipping a single bit:

[window setStyleMask: [window styleMask] | NSResizableWindowMask]

Proper UI frameworks are very nice to you. Not sure why people continue to muck around with legacy APIs like Win32, when newer (and better) alternatives are widely available...

Making windows that properly resize in the win32 API (and I assume whatever OSX and Linux use for their base API) is non-trivial as you have to do all the math yourself.

Unlike the wacky world of Microsoft Windows, making a window properly resizeable on a Mac is the result of flipping a single bit:

[window setStyleMask: [window styleMask] | NSResizableWindowMask]

Proper UI frameworks are very nice to you. Not sure why people continue to muck around with legacy APIs like Win32, when newer (and better) alternatives are widely available...

Will that actually make all the contents nicely reflow though? It's not hard to make a window resizable in Windows either, but none of your controls will adjust to match. As to why people mess with Win32 it's usually the only way to get at some of the controls because some frameworks aren't kept up-to-date or don't work with C++ (*cough*Forms*cough*). Or you don't want to hack around with that MFC... thing. (In case you're wondering, yes, I prefer win32 when working with C/C++)

More on-topic - personal UI pet-peeve is when they obviously just tossed controls onto a window with no regard to tab order or even lining things up... even the basic win32 resource editor in VC has tools to make things the same size and align with each other.

Since recently switching to high DPI monitors I'm not fond of apps that don't layout properly (including some of my own :)).

The worst offender of all is Skype, which actually properly detects the DPI setting, then proceeds to automatically lower its default font-size from 10pt to 4pt to compensate and make the text use the same number of pixels as on a low DPI. Luckily it can be set back to 10 and make chat readable again, though the list of contacts is always super small.

Will that actually make all the contents nicely reflow though? It's not hard to make a window resizable in Windows either, but none of your controls will adjust to match.

No.

But the Cocoa API also has better mechanisms for dealing with control reflow on resize than Win32, where you are *basically* doing it all yourself (abstractions like Windows Forms and WPF have them though).

But the Cocoa API also has better mechanisms for dealing with control reflow on resize than Win32, where you are *basically* doing it all yourself (abstractions like Windows Forms and WPF have them though).

This. Mac UI development is effectively equivalent to how it would be on Windows if the Win32 API didn't exist, and WPF was your baseline API.

And note that's roughly how it evolved on the Mac side as well. The Win32-style C++ APIs existed in the form of Carbon up until about 4 years ago, when they were finally fully deprecated in preparation for the move to 64-bit.