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