How much bad UI design comes from a focus on making the UI consistent with underlying code that was designed based on ease of implementation in the programmer’s language of choice?
This process should be inverted: a consistent UI that can be fully understood by end users should have its principles encoded, & a language & toolkit chosen to match this design. This requires ignoring the selection of widgets toolkits provide & ignoring your own tech preferences in favor of problem fit — which requires stack cosmopolitanism.
But, the end result is that the UI becomes fully understandable to the end user & maintaining the system becomes straightforward. Users stop feeling imposed upon by the inexplicable whims of a powerful dev priesthood.
The norm for a system is that, to understand why the UI behaves the way it does, you need to understand the structure of the program and the facilities of the language — and thus, what was easy for the coder. So, modeling & predicting behavior accurately is something end-users can’t do with these systems unless they learn to code. This is “I drink your milkshake” shit.
This is not a defense of skeuomorphism. People have a mental model of their tasks, and machinery needs to match that mental model of the task, rather than matching devices previously used to perform that task.
The real problem is that instead of thinking about the end goal (what is the most efficient way for the user to think about their task) the programmer thinks about what tools they are most familiar with and how they can use vice grips and duct tape to solve a distorted version of part of the problem with those. (This isn’t always bad. I do this kind of thinking when I’m solving problems for myself, because I’m the end user. Also: ‘ease’ differs between tasks and users and much of the time it makes sense to require study when the user is amenable to it & a dumbed-down interface would simply be inefficient to the point of unusable for an expert user.)