Just a minute ago, I clicked a "Transfer" button on my online banking UI. It's a beautiful button with an appealing font and a subtle, pleasing background gradient. But when clicked, it shows no indication that it was depressed, and I have to rely on the appearance of a modal spinner to know that I have actually pressed it. For me, peak UI was Windows 89/2000 -- largely uniform and monochrome, but just enough detail in the third dimension to know where to click, and what to expect when clicked. Also: keyboard shortcuts.
This is what actual UI design is supposed to encompass. Making sure the software behaves in the way the user expects, effectively communicates state, etc. Not just fussing over icons and colours.
Users' expectation changes. You ask someone who grew up with Windows 98 and they will tell you that d'oh of course onscreen buttons should have a depressed state to indicate they are pressed. You ask someone who grew up with Snapchat and the entire idea of having buttons is optional: tap on this area of the screen for this functionality, tap on that area for a different functionality, and swipe left for this swipe right for that with no indication that the UI is even swipeable.
It is perhaps a problem that there are a lot of visual designers around, because that is something for which a classical education exists and which has a certain prestige, and very few UX designers, for which no classical education exists and which seems to have little prestige. Good UX design is usually not fancy, form follows functions isn't flashy, and the whole thing seems kinda nerdy (not cool).
About the return of skeuomorphism, I do believe it's happening because people are fed up with flat everything in two colors, but I wish there was less oscillation around the center. As many have mentioned, Win2k was very good, and it was a middle ground between the extremes we're seeing today. Actually, it was extreme in one way: you could tell what a UI element was going to do without trying to click every pixel and seeing what happens.
In a desktop application, if a button stays in the pressed state when you let go of the mouse button, it means that the developer was lazy and is doing work on the UI thread. In a classic Windows UI, the transfer dialog would be closed, or it would disable all controls until the operation completes and then show a confirmation message.
Well, kind of.
Actually, the developer should really do some work in the UI thread beyond just sending out a "button pressed" message: When I press the button, I need immediate feedback that it was pressed and that pressing it had an effect, that things are now happening. Too many UIs, especially in the web where round-trip-times can be long, rely on just firing of a message or a network request. The response to the user, by displaying a spinner, progress bar, modal or new page only happens asynchronously and after a comparatively long delay. This means that users will sometimes repeatedly click because "nothing happens", leading to multiple messages, leading to multiple actions, leading to a big mess.
So the UI thread should synchronously trigger user feedback, take a lock or other measures to prevent unintended repeated actions and start a timeout callback in case the triggered action doesn't happen in a sensible timeframe.
> For me, peak UI was Windows 89/2000 -- largely uniform
The UI back then was sometimes janky, but it was so much more useful. Icons were meaningful and easy to recognize despite the low resolution. Quite often interfaces were customizable, they were not afraid of users becoming power users. Peak UI for me was probably Winamp 2.
Nowadays it is just a bunch of flat glyphs, things hidden in hamburger menus, arcane submenus, etc. Probably done to increase "engagement" or whatever bullshit metric they want to minmax for.