So I have let this thread go idle for over a month now, but over the course of the last few weeks I have had some pretty interesting discussions with both KK and Tom here inside CloudBees and now have some wireframes that examine the item creation and configuration GUI in jenkins and looks at ways to make the GUI a little more approachable for new users, while not losing or significantly changing the existing screens' general approach to collecting and displaying the configuration settings.
I am going to post them here in the hopes that all of you interested in the Jenkins GUI will toss in your comments and feedback. So, here we go....
Item type selection
As it stands today, most folks first interaction with Jenkins is a fairly dry list of radio buttons, asking him/her to select which type of item to create. Not only is the radio list fairly dry in appearance, as users add plugins it does little help the user scan the page to find the particular item type he/she is looking for. As users add additional functionality to Jenkins, the page scanning challenge grows. This new take on that first page in the creation process seeks to address that by adding the concept of categories to Jenkins items. This would allow them to be grouped and displayed in a bit more artful an arrangement.
Freestyle first steps
Similarly, the freestyle configuration page is not only difficult to scan but is particularly vulnerable to 'plugin pollution', as it too has only minimal visual category indications. The good news however, is that for the most part, the form actually is divided up into helpful categories, but the visual divisions between those categories is pretty minimal and sometimes the logical divisions determining what goes in what categories is a bit muddled. This wireframe adds the concept of collapsible region categories, and in this "Overview" step, weeds out some of the non universal input settings that are currently in the first segment of the item creation/editing.
To make sure those settings are not lost, this wireframe shows a new category, "General Process Rules" which would include the settings that are currently oddly appended to an "Advanced" button in the first input category. Not shown here, these checkboxes would behave roughly as they do today, showing additional setting only when selected, but in this wireframe, I have been careful to make sure additional input settings are not mixed in direction to the checkbox item selection, so as to give some degree of uniformity to the options in the list.
Similarly for radio buttons. Here with the "Source Code Management", all is the same as it ever was...
...Yawn, and "Build Triggers".... just being complete...
Freestyle critical steps
...not all steps in a freestyle build however are just basic item selections. Some are iterative step configurations that are particularly defining of what the build process is going to do. (arguably, "Build Triggers" is a similarly fundamental input category, so please argue away.... ). Because of this importance, and iterative sub-process nature, I am pulling the list of step operations out of its current pull-down list and giving each a bit of visual meat. Beyond being decorative, this is meant to help the user scan quickly for the process step he/she wants and in a sense, wake the user up with a little reminder that this is likely to be where the important choices need to be made.
Once selected, the inputs for that new build step should be similarly framed for emphasis and simplicity. The nesting of the layout should be clearly communicating the subroutine nature of creating steps.
Once created, the step, along with the existing steps is collapsed back to its minimized form, helping to keep the workspace clean and to allow more efficient dragging and reordering of step items (notice now the collapsed panel, "Step: Execute shell script" above the newly re-opened add step control).
After the steps are created, the "Post-Build Actions" employs the same, "look at me" style GUI. I felt this guy should get extra weight as well, as this is likely where your deployment action would happen. Does that really make it more important than the trigger? Maybe.
"Notifications" would be another boring control set, so I am not going to bother showing it, but hopefully you get the idea.
As always, feedback is something I love.