[JENKINS-64908] Advanced buttons are bad UI/UX

[timja]

Jenkins UI has an engrained pattern of buttons named advanced. But it's bad UI. What does advanced mean? Nothing useful. It's a place to put UI elements since there's no better way to organized the information. It's a band aid that seems to be considered a good way to handle complexity.

For one: the term is scary, and it's never good to scare a user. If I click on a button labeled advance, what should I expect to happen? I have no idea. It's like a red button in the control room. I want to press it, but I'm afraid since I don't know what will happen.

Second: it's not informative. What's under an advanced button? I don't know ... advanced stuff. I know there's stuff under there. That it's advanced doesn't help me decide whether it's stuff I need to see or change.

I see many bugs and enhancement related to advanced buttons on various screens. They all miss the point. Git rid of all of the advanced buttons. Putting the complicated UI under a button labeled advanced does not cut it.

I'm venting. I'm complaining. And there is no simple solution. UI is hard. But, at the end of the day, Jenkins (as any software) is the user interface. It needs better UX.

---

Originally reported by sbroshar, imported from: Advanced buttons are bad UI/UX

• status: Closed
• priority: Minor
• resolution: Won't Do
• resolved: 2022-06-18T05:04:51+00:00
• imported: 2022/01/10

[timja]

ianw:

The use of the jelly form control "Advanced .." is outlined in the Jenkins Developer Forms Control page and in the legacy Form Controls wiki page.

It explains this is an "Expandable" control. I agree the text does not elaborate what belongs in that section from a usage or implementation perspective, but that is often a contextual decision. We can perhaps agree from universal experience that what tends to belong there are settings not related to, or necessary for, the "basic" functionality of the plugin. They are thus hidden from use from the user so as not to clutter the UI and overwhelm the simple use. More advanced, fine-grained or seldom used controls are made available by clicking on the "Advanced" button, exposing them to the user. This "skeuomorph" has a long history, both in the analog world (eg: an equalizer hidden behind a panel on a stereo unit) to the digital (eg: the simple vs advanced presentations of the audio controls".

Ultimately, each developer is free to implement the available controls necessary for their plugin as they see fit and in response to feedback from the community.

The Community has undertaken major work under Epic JENKINS-60919 - "Visual revamp of the Jenkins UI through CSS changes", as well as JENKINS-62437 - "Change Jenkins configuration UI from tables to divs" to give Jenkins a more modern, less cluttered look. If you have used Jenkins for a while you may have seen the changes last year in a major overall of the UI (Jenkins UI Gets a Makeover) as shared by the CD Foundation. This is a continuation of a long evolution of the Jenkins UI.

You make clear, "I'm venting. I'm complaining". You propose, "Git rid of all of the advanced buttons". This would confront the user with a very extensive and probably cluttered interface, likely resulting in a far worse User EXperience.

If there are specific concerns you have with implementations of the "Advanced .." button, I'd recommend creating plugin-specific issues outlining your concerns and how the UI, or perhaps more usefully, the documentation can be improved (my experience is usually not, "what is that doing there (location) ?", rather "what is that doing (purpose) there ?").

If you are venting/complaining about the potentially ambiguous or inappropriate wording on the button as "Advanced .." (in the same vein as you disagreed to the terms master/slave - JENKINS-64907 ) , if there is a more suitable term you feel contextually fits better, then feel free to change the Description from a rant to a proposal for consideration.

 

[timja]

JIRAUSER131195:

Much to unpack.

On specifics:

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".

 

 

On tone:

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. 

 

[timja]

markewaite:

Jenkins UX changes are progressing since Jenkins 2.277.1 with more changes in Jenkins 2.332.1 and even more changes arriving in Jenkins 2.346.1 in June 2022. This specific suggestion is much broader than the current implementations. It would require changes in many plugins and the proposed simplifications would likely risk compatibility for existing users.

Closing the issue