[usrbinbash]

Not the author of the above post, but happy to answer:

- Essential functionality shoved into some sub-hamburger-menu because it "didn't fit the design".

- Low information density

- Pointless cruft like animated menus and hero images + resource intensive pseudo-minimalism, where the app/page/whatever, despite the low information density, somehow still manages to load ungodly amounts of data, or eats tons of resources, or both.

- The latter point contributing to the situation where we have apps that run worse on 2022 hardware, than apps in the early 90s did on a Pentium I. I know that design isn't solely to blame for this, but it certainly played a part.

- Circumventing OS or browser default functionality. Example: Webpages that hijack the onscroll event. I use my mousewheel to scroll, not to advance through whatever the designer thought was a must-see presentation about their companies "values".

- Smooth UX breaking down the instant the user leaves the happy path. Trying to setup an account? Easy. Trying to change the auth method to MFA? A hellride.

- Modals. Modals everywhere

- Everything trying to look like a smartphone app, no matter the viewing device. I have a high resolution screen and a high precision pointing device in front of me. Why are half the webpages and many apps presenting buttons the size of texas?

- Super smart designs causing the page layout to change after it's loaded. Nothing more fun than to accidentially click the wrong thing and then having to reload the previous page because the layout changed under my thumb.

- Next to zero configurability.

Apps are tools. Webpages are tools. I am not starting a program to look at it's amazing design, same as I don't pick up a hammer to marvel at the color choice of the handle. I pick up a hammer to hammer at nails. If I get the impression that the process of picking the handle-color was getting more attention than the process of making a good, sturdy, serviceable and reliable hammer, then I will not use that hammer.

[hedora]

Also, everything has to have an account now. I just got fined $8 by a movie theater for buying a ticket without an account.

Of course, with the rise of microservices, everything that requires an account is also unreliable.

Also, there's the dark pattern of returning incorrect results during partial outages, so even when stuff is "working", it's mostly gaslighting the end user. This was pioneered by Netflix's frontend team, but it's seeped into all sorts of inappropriate things. A surefire sign of this is opening up an online-only app, and having it report stale data until it updates. My car does this. I don't care what its charge level was sixteen hours ago (typically displayed by my phone for 10-60 seconds), or four days ago (from my watch).

[ilrwbwrkhv]

Netflix has done far more damage to the software industry compared to any other large modern company. The whole microservices nonsense and the myriad of complicated tools to solve their own customer complicated situations, gosh, thankfully the company is dying out now.

[pjlegato]

It's even older than that: Amazon began doing this in the 90s.

Their initial idea was to synchronize warehouse inventory with the online store in realtime, so that users would never buy anything out of stock. That proved logistically difficult and expensive, so they decided that the frontend would merely checkpoint inventory levels at intervals. When someone inevitably ordered something that was no longer in stock, they simply sent a robo-apology note and refunded the order.

Mitigating the hit to customer satisfaction was deemed cheaper than the very expensive proposition of synchronizing distributed warehouse inventory levels in realtime over unreliable networks.

[danybittel]

> Apps are tools. Webpages are tools...

I strongly believe that's the main problem. Today UX thinks of computers as Assistants. It is clippy all over again.

That is why tech is so exited about Amazon Echo, ChatGPT.. It's the ultimate assistant.

Nobody wants to teach their users anymore, it's supposed to work out of the box. Easy, simple. There should be one button or one way of doing something (the dreaded User Story). Otherwise the user will go elsewhere. So we get these one trick apps.

In the 90s the user was seen as an intermediate user. Today it's all about onboarding.

[taneq]

I'll take it a step further and say most "UX" designers think of everything as an Experience. That's fine if I want to watch a movie but not if I want to do a thing.

[CamperBob2]

Add to list:

- Desperately trying to make everything from PCs to cars to refrigerators to space capsules look and behave like a mobile phone for no reason on (or off) God's green Earth except "Woah, trendy."

[hellweaver666]

> - Everything trying to look like a smartphone app, no matter the viewing device. I have a high resolution screen and a high precision pointing device in front of me. Why are half the webpages and many apps presenting buttons the size of texas?

You're making a very broad assumption here that everyone is like you. The fact is, they aren't. Big click targets are important for accessibility (if you want to read more, theres a pretty good article on the topic here: https://ishadeed.com/article/clickable-area/)

[usrbinbash]

> Big click targets are important for accessibility

Apparently not, because we went for decades without them, and no one complained about a bad UX from buttons that are too small to click. Which could have something to do with the aforementioned high-precision pointing device, which btw. can be configured to the motoric requirements of the individual user.

However, a lot of people complain about UX gone to hell as of right now. So I'd say its a pretty safe bet that things, as a whole, didn't go into the right direction

Besides, a requirement on a PHONE is not an excuse to do the same thing on a DESKTOP. My desktop PC isn't a phone, and I value information density more than click-area. If an interface ignores these facts, then it is a bad UX for me.

[hulitu]

> Big click targets are important for accessibility

So that's why Microsoft made the calc.exe fill the whole screen. /s

This does not explain however why the scrollbars are so small. Are they no click targets anymore ?

[JohnFen]

> why the scrollbars are so small.

Not to mention essentially nonexistent window borders and putting active controls in the title bar. Have people forgotten that those are click targets, too? Sometimes I want to move the window or resize it, and Windows makes that hard.

[alxlaz]

This article, like seemingly ever design-focused article in the last decade, parrots Fitts' Law but doesn't run any numbers:

> An important law to be followed in UX design. In simple words, the larger and closer the touch or click target is, the less time it will require the user to interact with it.

...and mistakenly concludes that, if you just make buttons bigger and add more whitespace everywhere, you get widgets that are easier to click.

If you try to run the numbers on "facelifted" modern interfaces vs. their older counterparts, you'll find that many of them actually fare worse even in terms of Fitts' model.

E.g. if you have three equally-sized widgets side by side -- three buttons, for instance -- simply making them wider by some proportion of the initial width increases the difficulty of getting from the center of the leftmost widget to the center of the rightmost widget, because the distance (up in the nominator) increases by a higher factor than the width (in the denominator). In practice, increasing widget sizes increases the index difficulty in basically every UI that has more than two widgets laid out along a given direction, because it causes the distance to targets to grow by more than the widget size.

(Edit: this is commonly forgotten because "literature" drones about Fitt's conclusion without explaining the context in which it was determined: repetitive motion over a single direction between two already widely-spaced physical items. Making the items bigger resulted in lower distance because, unlike in a modern fluid UI, where widgets are placed at constant paddings that are a fraction of their physical size, that did not cause their centers to drift further apart. Whereas in practical UI cases, increased paddings and widget sizes often result in the average distance to widget centers increasing by way more than (half) the widget width, so the ID actually grows).

The example shown in the article just so happens to fare better because it makes a widget taller by about 10%, while reducing the distance between the only two widgets shown on screen about three times. IRL padding between widgets has steadily grown, so while the numbers line up, this isn't a very representative example -- in fact, many designers would probably object that the design on the right is also bad because there's not enough space between the text field and the button.

But even if we take the design example at face value, generalizing from it is a really bad idea. Because the ID is logarithmically-derived, if you were to take the "narrow" button on the left and just bring it 16px away from the text field, the difference would be minute -- no more than 5% (assuming strictly vertical motion between the midline of the text field and the midline of the button; in practice it's probably way lower than that, since LTR users tend to click towards the left of the field; although FWIW I bet in practice moving the two widgets close together has barely any impact at all, as the text field is likely auto-focused, so motion will commonly happen between wherever the cursor happens to be on the screen and the center of the button).

That's a good trade-off if you only have two widgets on the screen, as in a form -- you don't lose anything other than some whitespace by making a widget bigger. If you have more elements to show, though, that's a very bad trade-off to make. An ID difference of 5% is barely noticeable (IIRC it's just above the "noise floor" in a standard Fitts experiment), which is more than offset by the additional difficulty introduced by scrolling (because you can fit fewer elements on the screen).

[palm-tree]

> - Super smart designs causing the page layout to change after it's loaded.

This seems to happen far too much. Nowadays usually causes me to give up on a site and go somewhere else. Feels like eliminating stuff like this should be low-hanging fruit UX-wise (albeit not especially exciting, I guess)

[Torwald]

> - Circumventing OS or browser default functionality. Example:

Google search bar breaks macOS keybindings eg. option-arrow doesn't work as expected.

[hedora]

What web browser are you using? Option arrow works right for DDG's location bar on safari + firefox, and duckduckgo.com and google.com's search bar's option arrow works properly under safari.

[Torwald]

If you are in the pull down of search suggestions and in the search field is standing (copied) the suggestion where you currently are, then when you hit arrow, the search field jumps back to your search string. It should instead led you edit the selected suggestion.

[karlshea]

This was somewhat recent and it’s incredibly irritating.

[balls187]

It seems like in your experience, either UX did it's job and came up with all the wrong solutions, or UX wasn't involved and all the gripes you listed would have been alleviated by true UX professionals.