Much to unpack.
As I'm talking about a pattern maybe the thing to change that most directly corelates to my proposal is the UI guide. That is complicated by this:
WARNING: much of this document is old and suggests code patterns which are not recommended. As of this writing, the official documentation for this area of Jenkins has not been written. The ui-samples plugin is somewhat better maintained than this.
That is a lot to take in. The current guide has much that is not recommended, but there's no doc describing what's recommended. How do you know what's recommended if there's nothing that describes the recommendations? Is it in someone's head? Or is there a doc that's not been published/shared?
When there is a new guide, it could say something like:
In order to present a cleaner UI, consider putting UI controls that are less often used in an expander control.
Introduce an expander judiciously since it often leads to confusing UI. When the user does not know what's inside the expander, then they have to open it to look. If they have to open it, then the utility of hiding the UI elements in the expander has been lost. So, avoid using them but if you do, label the button so that the user knows what settings are inside without looking.
For example, say the plugin is about email and there are rarely used proxy settings. Put the proxy settings in an expander labeled "Proxy settings", not "Advanced".
You're saying that what I've written is not actionable. I agree that it's not spoon feeding; about specific changes to specific views/plugins. That is by intention. I'm talking about a pattern that pervades the views/plugins. How does one change a pattern? It's not simple I agree. Implementation would involve changing many views (plugins) and the changes would be case-by-case.
I was hoping the community would support this sort of thing, but I did suspect that it would be shut down as it's out of the box thinking.
I'm talking big picture and clearly this forum is not about that sort of thing. At the end of the day, this sort of issue makes me like Jenkins less. And a response like yours even more so. We are considering a move to azure devops and I agree with the move. If instead Jenkins development was amenable to improvement I would think differently and push to stick with it.
And I do propose to get rid of all 'advanced' buttons. But, I think you misunderstand what I'm getting at. I suspect you're thinking linearly; that all UI elements under the expanders would then be located at the top level. I propose to rethink the UI so that it can be presented in a way that is abundantly clear and usable and that includes not cluttered. As I said, UI design is hard. Good UI design usually requires non-linear thinking.
You seem to discount my input. Rude.
Interesting that you mention
JENKINS-64907. You seem to be down playing the importance of it. Shameful.