New UI, form spacing and poor usability

I am a 10+ year user of Jenkins freestyle jobs with many parameters. I use Jenkins as an a analysis and data management tool so most jobs have interactive forms with many parameters I am also in the middle of migrating from Jenkins v2.222.1 to a most recent LTS release (reviewing v2.346.3 LTS although it seems less and less likely due to bugs with the approval of scripts and scriptlets).

Although I’m enjoying the modern sleek new Jenkins UI, I’m also posting here to present a request that the ongoing great improvements in the UI of Jenkins do not eat into usability (the same way continuous security improvements are eating into functionality :face_with_hand_over_mouth:

The updated table to div transition and the new CSS for the layout of job parameters have dramatically increased the length of the forms. The move of parameter descriptions from after the parameter input, to before, creates confusion. Lack of indentation makes it harder to quickly pick the key concepts on the screen

As an example, I present to you the screen for editing a scriptlet script. In my eyes at least, the ‘denser’ UI of the old Jenkins versions wins hands-down in terms of usability. I can review almost everything I need in one monitor’s height. Not so with the new Jenkins versions where I need to scroll 2pages before I can review 12 lines of code vs 20 before.

Am I missing something like a theming plugin that can improve these shortcomings? For example, it would be great if we could apply a ‘dense’ display theme to improve some of the issues I mentioned.

Thank you again for all your efforts in modernizing our beloved Jenkins
Best regards
Ioannis

Hey,

thanks for the feedback so far!

I agree, the old design from 2 years ago is more compact indeed, but lacks standards and defaults.
To reduce the length of a form, the author of the scriptler plugin could choose to remove the comments and place them as help items (? next to the field name), given that is the standardized approach to provide additional information or instructions about a field, over inline comments.

Above comments addressed via DOM could look like the example below, in practice:


The script console is almost fully visible without scrolling again.
Arguably, the parameter input uses ancient form elements, which could be modernized and fine-tuned to save space, which I didn’t do here.

Most notably, the scriptler plugin isn’t much up to date, in terms of UX and UI-accessibility and there’s much room for improvement, if the plugin author decides to do so.

1 Like

Alexander, thank you for the improved Scriptler layout example and the feedback.

As one of the maintainers of the Active Choices parameter plugin (which heavily contributes to job build form UI) I think it is important to identify cross-cutting changes in the UI/Layout of the core (that affect all plugins), and then changes for which plugin author/maintainers are responsible to follow certain standards that the community is developing.

Although I demonstrated some of the issues I’m facing with the Scriptlet configuration screen, my present concern is with freestyle build forms themselves. For those, parameter descriptions are still presented in line and issues with parameter font, indentation and line height create a challenge.
Maybe this is not much of an issue for a form with a few parameters, but what do you think of a form with 20-30 parameters? Just for fun take a look at one of our turn Jenkins into a SQL Developer tool forms (on Jenkins v2.222.1). I hope my challenge comes more into focus now as I try to move these to v.2.361.1. Best regards, Ioannis

1 Like

I am seeing the exact same issue after upgrading from: Jenkins 2.263.4 to 2.346.3.

This seems have occurred for build forms parameters for all types of Jobs.

Here is a pipeline job example, showing before (top form) and after (bottom form).

The new String parameter name, description and value are all rendered on top of each other. Whereas before the value was directly across from the name, and the description was below the value in a smaller font.

Just to agree with @imoutsatsos, to me the new rendering layout is far less clean, and is also more confusing when you have builds with a lot of parameters.

Will a future version of Jenkins address this usability issue?

I don’t think that there are plans to change that again. Customization of UI elements should be done through themes only.

Maybe it would help to describe in more details what your requirements are (or problems with the current approach)? Does it take too much vertical space? Are the fonts too small? Just saying that it was better before is a little bit vague for a UX designer.

Hi @uhafner I was just echoing @imoutsatsos comments.

I would say the fonts are too large, and the new layout also is not very space efficient.
As I mentioned the new layout has the Parameter Name, Description and Text box for the value all on top of each other.

Previously the Name and Value Text were horizontally aligned with the Description text (smaller) and just below the Text box. For me the old layout was much more compact and readable. In my opinion the new layout is much less compact and less usable, because the Name and Value text box are now separated from each other, in forms with large amounts of inputs, it can be confusing what Input Parameter Name and Value correspond to each other (especially if you have a lot of description text).

So yes, it takes too much vertical space. I would say the fonts are too big - the Description font is certainly too big - it was previously smaller - as it should be subordinate to the Parameter name.

I understand that refreshing the Jenkins UI has been a priority for some, but at the same time perfectly functional free-style parameterized jobs are becoming less and less usable. The new layout (as both myself and @ptha have demonstrated with the provided examples) is wasting screen real estate and confusing users. The suggested option of adding little question mark tips to every job parameter, means that the user has to hover over each parameter and scroll down pages to figure out the description/explanation for input parameters. Some of my jobs have 20-30 parameter and the new UI is neither user friendly nor enhancing comprehension! Please, consider providing some configuration options or explain how to better use the ‘theme plugin option’ for all of us that still depend on the efficiency and clarity of the old parameter layout to continue doing our work. Thank you for your consideration UIX team and volunteers!

1 Like

Why is that? Currently the help text appears right below the input field. Or is this different for parameters? Then this is a bug.

Isn’t a theme more appropriate than a configuration option? I think someone in the UX Gitter channel started working on such a theme:

Maybe you can help so that this theme will be actually available in the update center.

@uhafner
Why is that? Currently the help text appears right below the input field. Or is this different for parameters? Then this is a bug.

In an earlier comment @NotMyFault mentioned that:

To reduce the length of a form, the author of the scriptler plugin could choose to remove the comments and place them as help items (? next to the field name), given that is the standardized approach to provide additional information or instructions about a field, over inline comments.

I think he may have been referring to help on plugin configuration options and not parameter.

I will take a look at the theme option. Thank you! If that works, I agree it would be preferable. and I would love to find out if it can help with mu multi-parameter freestyle jobs