Jenkins UX

783 views
Skip to first unread message

Gus Reiber

unread,
Feb 18, 2015, 11:27:12 AM2/18/15
to jenkin...@googlegroups.com
At the end of last summer, my friend and co-worker, Tom Fennelly, along with the help of Kevin BurkeDaniel Beck, and others began the first steps of improving and modernizing the Jenkins user experience. In addition to some of the superficial enhancements, these changes are meant to add a bit of responsiveness and cross-device usability to the Jenkins GUI, as well as adding a means of creating and swapping new CSS based display themes. This effort is best summarized by this article from Jenkins-ci.org, and this thread from the Jenkinsci-users group:
As part of our second wave effort here at CloudBees, I am looking at ways of improving the usability of the Jelly based form controls used in the item creation and configuration pages and the responsiveness and interactivity of the main dashboard grid control.

In my investigations so far, I believe there are essentially 3 non-exclusive paths forward for enhancing these elements:
  1. CSS only -- Building on the last round of enhancements, we can offer a set of theme extensions that will allow the Jenkins users and community to customize basic layout, iconography, and typeface to tailor Jenkins to their own tastes.
  2. UI component expansion and refactoring -- By modifying and adding to the existing set of Jelly files and their corresponding data binding rules we can significantly modernize the way Jenkins views and configs draw themselves and potentially streamline plugin creation.
  3. Client side MVC veneers -- In a manner similar to what CloudBees has recently done with the new Workflow visualization, we can rethink our approach to new feature UIs by using a REST API based architecture coupled with client-side rendering widgets. This would allow us to use newer framework libraries like Angular.js and newer component libraries like Bootstrap and JQuery UI to add greater richness to the Jenkins user experience.
These are likely not the only paths forward, but merely the first I can think of.  With that reality in mind, I am hoping to reach out to you the Jenkins community to help ground and sculpt our thinking about what is both possible and desirable. 

If you are at all interested in the Jenkins user experience, I would love to get your feedback of any sort on this thread, which could be as simple as a "+1" or as involved as a PHD thesis or as much as you have time to type into a response box.

To the extent that it helps conversation along, I also have a handful of questions to which I would love responses:
  1. For plugin builders, can you tell me a bit about creating the UI portion of your plugin (did you use the data binding form controls, what was hard, what did you have to invent)?
  2. For regular Jenkins users, what are the UX areas of Jenkins you would most like to see improved (I think it is the item create/config and the dashboard/job list grid, but would love to hear others and general feedback)?
  3. For UXers and other Jenkins contributors, how do my 3 forward paths seem (are there others, do you have experience with any yourself, do any seem scary)?
  4. Has anyone tried to make their own themes with the new capabilities Tom has added or would you appreciate and handful of canned options to choose between?
  5. Has anyone started using Workflow on a regular basis, and in particular used the new workflow progress visualization enough to offer feedback?

Again, if any of you all are at all interested in the Jenkins UX, we at CloudBees are interested in helping move this ball forward and would love to hear your feedback.

Thanks for your help,
Gus

Bruno P. Kinoshita

unread,
Feb 18, 2015, 12:12:10 PM2/18/15
to jenkin...@googlegroups.com
Hello Gus,

I heard good feedback on the new Jenkins UI. Kudos everyone involved!

I don't really have much to contribute I think. But yesterday I posted to the dev-list about a new plug-in, Uno Choice, that is being used by researchers (both in academia and in industry).

The plug-in relies utilizes HTML DOM elements to access job parameters. Should any of these elements gets changed due to UX enhancements, the plug-in would  stop working.

What I would like to have in order to avoid having this kind of issues, is something like  global JS objects exposed by Jenkins - I'm not a JavaScript programmer, so I'm not completely sure that it is a good idea/practice.

This way, plug-ins like Uno Choice could access parameters' elements, the Queue HTML elements, enable/disable buttons, without depending directly on any screen selector. More or less something like:

# JS code used in the job parameter screen
```
var parameters = Jenkins.parameters.all();
var fields = parameters[0].getFields();
var name = parameters[0].name;
// internally Jenkins controls the selectors to access the parameters. Should any of these changes, plug-ins wouldn't be affected.
```

Not sure if that's the best option...

My +1 :^) please continue the hard work on improving Jenkins UX.

All the best,
Bruno


From: Gus Reiber <gre...@cloudbees.com>
To: jenkin...@googlegroups.com
Sent: Wednesday, February 18, 2015 2:27 PM
Subject: Jenkins UX

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/83937142-c675-4260-92ab-1dd1be82ca03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Surya Gaddipati

unread,
Feb 18, 2015, 1:26:13 PM2/18/15
to jenkin...@googlegroups.com
Poor UI performance is the no1 complaint I get from our devs when I talk to them about jenkins. 

I would be really really interested in killing ajax polling all over jenkins UI and using servlet 3.0 for async stuff. 

I posted couple of threads earlier about Servlet 3.0 upgrade but it didn't receive much attention. 

Surya Gaddipati

unread,
Feb 18, 2015, 1:28:40 PM2/18/15
to jenkin...@googlegroups.com
Oh wait KK responded to my servlet 3.0 upgrade thread. Its on the roadmap.


On Wednesday, February 18, 2015 at 10:27:12 AM UTC-6, Gus Reiber wrote:

Kanstantsin Shautsou

unread,
Feb 18, 2015, 1:47:19 PM2/18/15
to jenkin...@googlegroups.com
Some thoughts:
- Some current forms need to be fixed, for example radioButton needs lazy-loading that must exclude massive pattern checks for SCMs during rendering /configure job page.
- Some forms should be extended to provide more convenient data-binding. For example ugly expandableTextbox that i forced to parse to List/Set objects from String and back, when i need multiline configuration. Some friendly multiline form will provide better UI and help plugins developers.
In general providing good forms in core can minimise chaos in plugins UIs. 

AFAIR visualisation for workflow is CloudBees Enterprise plugin.

Gus Reiber

unread,
Feb 18, 2015, 3:05:31 PM2/18/15
to jenkin...@googlegroups.com
Thanks for your feedback, Bruno.
Your concern is exactly the concern that keeps me up at night.

Thanks also for raising Uno Choice as an example.
I am very much looking for specific examples of plugins with reasonable adoption that use the DOM to scrap bits and pieces of data out of Jenkins so I can get a test case list together.

...and your reward for you awesome feedback is 3 more questions from me... ;^)

  1. About Uno Choice, specifically, when you talk about crawling the page for job parameters, does this happen in the create/config page, the dashboard/item table, somewhere else, or all of the above?

  2. When you talk about a global JS object, I am guessing you mean the data model of the config form, primarily.
    If not, and you are scrapping data out of the dashboard table, I am still assuming the data you are looking for is not here [ https://ci.jenkins-ci.org/job/lib-jira-api/api/json ] or burried deep down that tree, or it is, fetching it via ajax is either too onerus or too non-performant to be worth the hassle?

  3. As I see it, for much of Jenkins plugin interoperation, and even some of its core functionality, there isn't really a programmatic API, but a set of facts about how Jenkins draws things on the screen that can be exploited to make features and components that share data in meaningful and interesting ways. The rub is that now to improve the UX in almost any meaningful way requires either changing that DOM (since that is what controls the rendering and GUI driven interactivity) and breaking those makeshift APIs, or establishing a new means for UI building that is completely independant of the past DOM. In that case plugins aren't broken, but a choice is required within Jenkins, work on an old canvas where old plugins work just fine, or work on the new canvas which starts without plugins, but is more capable.
    ....so my question here is if you had to choose (and I am hoping you don't and won't) between accepting some breakage or having a sort of split-canvas choice within Jenkins, which would you choose?
    Would you need more information before you could you even make such a choice?

    Neither of these options seems very satisfying to me.

Thanks Again,
Gus


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/62264246.276219.1424279521268.JavaMail.yahoo%40mail.yahoo.com.

Ioannis Moutsatsos

unread,
Feb 18, 2015, 3:19:31 PM2/18/15
to jenkin...@googlegroups.com
Gus thanks for opening this discussion on these ideas.

I am a Jenkins user and developer with a somewhat unusual pedigree. My main interest is using Jenkins as a workflow and integration engine for research applications in life-sciences and bioinformatics. 
Jenkins proved to be more than capable in this 'off the beaten path' application, but the user interface as it exists in the vanilla job build forms almost killed any prospect of advanced users since most web application users are used to richer controls and enhanced interactivity with their web application forms.

Enter the Uno-Choice plugin as discussed earlier in this thread by Bruno @kinow of the BioUno.org project.
Working with him we were able to significantly enhance the type and interactivity of some crucial UI controls so that we can now start building advanced web analytic applications on Jenkins.

I envision Jenkins job forms and reports with rich UI and we have just started scratching the surface (see some attached screenshots). I'm currently exploring how D3 graphical elements as well as Shiny R applications can be integrated and used from within Jenkins.
Please, keep an open mind toward integrating and learning from such rich graphical UI tools as you embark on additional Jenkins UI enhancements.

Thank you and all the great people at CloudBees for continuing to support and enhance Jenkins for all!

Best regards
Ioannis
Untitled_Clipping_021815_031758_PM.jpg
Untitled_Clipping_021815_031855_PM.jpg

Gus Reiber

unread,
Feb 18, 2015, 3:19:39 PM2/18/15
to jenkin...@googlegroups.com
Thanks Kanstantsin,
  I see your concern as the converse of Brunos, namely the current Jelly controls are deficient in a number of ways making plugin development rough and as a result, constructing a polished finished UX is almost impossible.

I am taking notes of you specific examples.
...and you are correct about the workflow visualisation.

Can I ask you the same question I asked Bruno, namely, if you had to, could you choose between having 2 paths for building plugins, an old vs. new model approach, or accepting some degree of breakage for existing plugins as the component library is overhauled?

...or another way to ask the question, is UX and plugin UI building so important to you that tackling one of these options with your own plugins would be worth doing?



--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

Gus Reiber

unread,
Feb 18, 2015, 3:31:35 PM2/18/15
to jenkin...@googlegroups.com
Awesome.
Thanks Ioannis.

You are absolutely correct that we are stuck a bit in last decades web technologies as far as client-side user presentation is concerned.

Can I ask you or maybe Bruno, how are those graphs embedded into this page?
...and what page is this I am looking at (I am assuming it is a custom plugin action page or a specialized view for a custom item type)?

Looks like I need to go grab the plugin kick the tires directly.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

Bruno P. Kinoshita

unread,
Feb 18, 2015, 3:38:15 PM2/18/15
to jenkin...@googlegroups.com
Hi Gus. I have replied off-list with access to a Jenkins server where we tested the Uno Choice plug-in.

There you'll find several jobs configured to create dynamic parameters and even some graphs I think? (Ioannis feel free correct me if I'm wrong).

Will reply your questions when I arrive at home.

Thanks
Bruno


Sent: Wednesday, February 18, 2015 6:05 PM
Subject: Re: Jenkins UX

Ioannis Moutsatsos

unread,
Feb 18, 2015, 3:55:56 PM2/18/15
to jenkin...@googlegroups.com
Hi Gus;

The screenshots are from standard job build forms using Uno-Choice parameters. 
Especially the Uno-Choice Dynamic Reference parameter can directly render any arbitrary HTML. In one case (the screenshot with the chemical structure) it's a simple iframe displaying a widget from NCBI, in the other it's a locally rendered D3 interactive plot. 
The D3 graph configuration can be found here: http://162.243.246.75:8080/job/TEST_D3_SCATTERPLOT/configure

The most recent version of the plugin can be found here: https://groups.google.com/forum/#!topic/biouno-developers/REx4-sk_xSs

As we speak, we are in the process of releasing it to the Jenkins community.

Best regards
Ioannis

Bruno P. Kinoshita

unread,
Feb 18, 2015, 7:21:25 PM2/18/15
to jenkin...@googlegroups.com
> About Uno Choice, specifically, when you talk about crawling the page for job parameters, does this happen in the create/config page, the dashboard/item table, somewhere else, or all of the above?

It happens in the forms for submitting jobs with parameters. For some parameter types, we need to get the **value** of other parameters. So that if the user changes the value, we will re-evaluate the parameter using the new entered value.

> When you talk about a global JS object, I am guessing you mean the data model of the config form, primarily.

Not only that. Everything in the Jenkins UI that other plug-ins could be interested in using (e.g. I think the Queue UI elements would be another good example, for changing the length, formatting colours and icons of certain elements dynamically in the UI, etc).

> If not, and you are scrapping data out of the dashboard table, I am still assuming the data you are looking for is not here [ https://ci.jenkins-ci.org/job/lib-jira-api/api/json ] or burried deep down that tree, or it is, fetching it via ajax is either too onerus or too non-performant to be worth the hassle?

In the Uno Choice case, the data - values entered by users - are sometimes still not persisted in Jenkins. 

>  you had to choose (and I am hoping you don't and won't) between accepting some breakage or having a sort of split-canvas choice within Jenkins, which would you choose? 

As a plug-in developer, I'd be fine with both. Just would take care to update the plug-in Wiki with information for users who wanted to update the plug-in. 

But from a user POV, I think it would be better without another thing to check for compatibility before updating or installing plug-ins. So I think the latter option would work best for me maybe?

> Neither of these options seems very satisfying to me.

Hopefully we will have other ideas. Maybe there're other choices that don't require breaking things and will allow us to improve the UX at same time :-)

Bruno


Sent: Wednesday, February 18, 2015 6:05 PM
Subject: Re: Jenkins UX

Tom Fennelly

unread,
Feb 20, 2015, 10:10:17 AM2/20/15
to jenkin...@googlegroups.com
Great stuff here guys.

Hopefully we can translate some of these ideas into here into JIRA feature tasks (if not already in JIRA) for tracking (label "user-experience").

Ulli Hafner

unread,
Feb 20, 2015, 6:57:28 PM2/20/15
to jenkin...@googlegroups.com
As I plug-in developer I would like to have more powerful UI building blocks that I can *easily* use. E.g., in my static analysis plug-in I’m currently using plain and old YUI tabs to categorize warnings by module, package, etc. Now that Tom improved the main view tabs in Jenkins core I also would love to improve these plug-in tabs in the same way. Is this feasible? How much effort does it take? What are the steps to do? etc. 

As you already mentioned, the job configuration is not very user friendly, especially if there are multiple Advanced, Add, Delete, etc. buttons. If the input field layout is complex then it is really hard to understand which button belongs to which group. Having some layout templates would help...

And finally what I also would like to see is the possibility to have a more appealing project view where trend graphs etc. could be rearranged (e.g., like the Jira dashboard). One of my students is planning to provide some views in a way similar to Sonar in his master thesis. Is this easy to achieve in Jenkins? Where should we start the work? Can we reuse some existing components/libraries? 

So my +1 for your path 2 and 3.

What I think is not so important is theming (but this might be a matter of taste). This works quite well for Jenkins core but as soon as other plugins are involved (and we have more than 1000) this is normally getting a mess. I would rather prefer to have *one* good looking theme for core *and* plugins. (This is quite similar to e.g. IOS themes where you get really beautiful new icons for the most important apps, but you still have a lot of other icons around that look totally misplaced in the new icon scheme). Here it would help if we would have some interested volunteers who would help plug-in developers to provide consistent icons.

signature.asc

Slide

unread,
Feb 20, 2015, 7:05:29 PM2/20/15
to jenkin...@googlegroups.com
I completely agree with the configuration page stuff. Email-ext has so many options these days that whenever someone wants a new feature, I cry a little thinking about how its going to make the UI more of a mess. I'm definitely open to any ideas people have on improving it, but it would be nice to have some additional "widgets" to grab from the taglibs.

Tom Fennelly

unread,
Feb 21, 2015, 8:58:54 AM2/21/15
to jenkin...@googlegroups.com
Yes, I think everyone agrees that the config pages are a UX nightmare. We looked at changing how they are rendered by introducing <div> sections that are then collapsible. It was somewhat of a success but what frightened me off taking it further was the fact that it was inevitably going to break plugins. Since it was early days in my efforts to make improvements to the UI, I didn't want to start by breaking shit all over the place and in so doing, turn everyone off the idea of me (and others) attempting to "fix" the ui.

So on that note I would ask the Jenkins community how they would feel about making changes to how the config pages work where those changes could cause plugins to break, requiring them to be fixed in order to work again? I think there would need to be some level of community agreement on that before we'd attempt to do it.

@Uli ... it should be easy enough to render a set of tabs the same as the tabs on the standard Jenkins Home page since they're just a set of <div>s that are styled using CSS (pure CSS i.e. no javascript involved at all). If you inspect the source there you should be able to see what's required and easily replicate it for your plugin.

@Uli as for UI Themes, I'd be of the opinion that they're not just about making the UI nice. They can also be used in terms of providing accessibility features to Jenkins e.g. allowing visually impaired people to have a personalised/custom UI experience (bigger text... different colors etc) than other people using the same Jenkins instance. Aside from that, I think everyone has different ideas about what that "one good looking theme" would be, which is the problem and which is what makes themes more attractive for me.

Ioannis Moutsatsos

unread,
Feb 21, 2015, 12:09:27 PM2/21/15
to jenkin...@googlegroups.com
Hi Tom;

Great discussion and a nice brave world that you are revealing us through your work!

I know that the fear of the unexpected consequences is always an issue. However, given the benefits of improved an Configuration UI I think we should be willing to take on some breaking changes. I did it recently (for the Uno-Choice plugin we developed) and although I admit initially it was frightening, at the end I took the plunge and never regretted it since... 

I like the idea of collapsible sections. In fact I've used the Jenkins Collapsible Sections plugin to create easy to read project configuration reports. Nested and hierarchical structures (such as the config file behind the scenes) benefit from this visualization.

I'm attaching a pdf with a wire-frame of a possible configuration screen. What I'm envisioning is that you start with a basic layout of the project with the required elements. Then each element will display a drop down menu (similar to what is currently attached to projects lets say) that will allow you to add, insert and move semantically correct (driven perhaps by a xml schema for a Jenkins project) elements to the right place in the project

Perhaps if we can isolate where each parameter, build step, and publisher gets configured it will not be so ominous. So for whatever is currently selected we can show a detail of the configuration in what I'm showing as a bottom configuration tab.

Finally, having the ability to review a project configuration in a high level summary I think it is quite enabling. Whatever, we can do to enable this will be great. Perhaps this summary can easiy displayall project dependencies (plugins, versions,external scripts etc) so it can facilitate the transfer of these projects across servers.

Best regards
Ioannis
Wireframe Jenkins Project Configuration -IKM.pdf

Kanstantsin Shautsou

unread,
Feb 21, 2015, 1:08:12 PM2/21/15
to jenkin...@googlegroups.com
@Tom, divs, css and tab it's cool, but as not UI developer i will expect "building blocks" that will allow me just to use form and databinding. This will also allow enhance/fix problems only in this block that will automatically apply to other places. 

More thoughts.
- I think that other UI problem is maintainers/developers programming knowledge and lack of good documentation with good variants for them. After INFRA changes i hope people will finally be able to start enhancing documentation. 
Many plugins configurations are based on checkboxes, even -ETOOMANYCHECKBOXES in ui that leads to mess in UI and code. Maintainers are not bothering to ask any experienced jenkins devs to review their changes. Some PRs after good review ends with only few lines of change instead of many new classes and changes. 
Also jenkinsci plugin hosting for any jenkins plugin looks like a trash can  that ends with bad end-user experience in jenkins, i see many jenkins installations and many times i'm wasting time searching what plugin provided what configuration (because help files not created, or configuration names are the same, for example, maven builders from artifactory, maven and other plugins). (Should we create injected test for help files that will fail build?)

- Slide, I think email-ext absorbed many issues at once.
a) It obvious that everybody want configure job steps in any order and sending emails (or do any action) in any step. If freestyle job had had no such limitations and allow to reuse publishers, email-ext would have no implemented mix of cases in publisher (default template, for example, may exist in JobProperty).
b) AFAIR email-ext needs some better forms for some ui configurations
c) Some forms has very huge borders, intends, margins, etc. (repeatable-hetero-list?)
d) conditionals that are not provided in core and plugins implementing them and using i.e. flexible-publish loses different integrations because it not core.
This all pure API of core/freestyle that need to be enhanced and plugin developers inventing difficult code -> UI.
Wait, but workflow-plugin should resolve this issues? Do we need UI configuration now at all or should we configure jobs with coding in groovy workflow/DSL?

Gus Reiber

unread,
Feb 23, 2015, 12:21:03 PM2/23/15
to jenkin...@googlegroups.com
@Ullrich -- I love your post, as it fits with my suspicions. Tom is right that a lot can be accomplished via CSS, not all of which is just window dressing, but the concern I share is that if the communities top concerns are things like screen performance, control complexity, and clarity of what the standards are and even how the component code works, it likely sends the wrong message when we invest in things like fonts and icons. Again, that isn't to say we shouldn't also look at the fonts and icons, but that can't be all we do. 

Ullrich, correct me if I am wrong, but it sounds like you would be willing to accept some level of plugin compatibility risk to see some improvement and modernization in the Jenkins UX and an enhancement to the tool set that allows for the construction of future UIs?

Gus Reiber

unread,
Feb 23, 2015, 1:20:42 PM2/23/15
to jenkin...@googlegroups.com
@All,
   I was able to grab some of KK's time on Friday. The meeting had two halves, the first was a strategic discussion about the breadth of changes we might want to attempt and how those changes should be phased in, and the second was a tactical discussion about how to start making progress now.

For the strategic bit, I put to KK Tom and my concern about fragile nature of the existing jelly based components, and how even slight changes to the DOM they draw can lead to some very unexpected breaks both in plugins and in existing core features. But then, I turned myself around and also argued that we will eventually need to change or replace these components, compatibility issues or not, because in addition to their awkward unattractiveness, some have architectural performance problems, and none of them fit with the modern UI libraries and best practices that are prevalent in web UIs today.  

My conclusion was that we needed to set up some sort of parallel path approach for Jenkins UIs. One that remained largely unchanged and allowed existing plugins to function as they do and a new path that we at CloudBees would write all our new components with and for, that community members could also adopt or not adopt, down the road, as they see fit.

KK only bought half of that...
He has seen the UX issues and heard from other sources a diagnosis similar to mine, but what he didn't like was the idea of parallel paths. His reasoning what that if existing UI framework has problems those problems need to be fixed, not just left on the side as someone elses problems. His conclusion was we/I should man-up and fix the core.

My belief is that the correct fixes to the core still involve two parts.
For the FIX aspect, I think step one is to figure out how to adjust the DOM that the Jelly tags generate to be more semantically correct (what I mean by that is that the HTML that hits the browser really needs to follow the same sort of good encapsulation principles that any other well formed XML document would follow, rather than a ton of tags dedicated to the screen position of elements). This isn't the only problem many of the jelly controls have by a long shot, but until they are better encapsulated, they are almost impossible to work on atomically and the ocean just becomes too big to swim in.

In making these first round of changes we will also need to detangle hudson-behaviors.js, which is the main JS file, written with a mix of native JS, prototype.js, and YUI. Hopefully in doing so, some of the screen performance issues can also get sorted out and use of newer libraries like JQuery with the jelly controls will become more feasible.
   ..but...
There will be some breakage. So we at CloudBees and we in the community will need to coordinate the right time and people to perform this operation.

For the EXPAND aspect, the discussion became more tactical. 
We at CloudBees are in the process of investing heavily in JoC and Workflow. These pieces are going to have reasonably significant UI requirements and we, like you all, need better tools to build them. To address these tactical needs, KK helped me put together a new plugin, 'ui-control-plugin', on gitHub. At the moment, there is very little to show here, so I am not posting a link, but the idea is that this plugin will eventually contain both a set of new jelly controls as well as a new MVC framework for making more robust full canvas style views and widgets. A decent portion of Tom's awesome work is likely to be the first inhabitants of this set.

Hopefully it goes without saying that all this work is in the early stages and I am pushing out this information as the details are still being worked out specifically to collect input from you all to shape this work in progress. Assuming this continues to be the prevailing wind direction, I am expecting that in the not too distant future, we will be looking to solicit even more help and feedback from the community, particular in coordinating the FIX pieces of our UI puzzle. We will also be interested testing help for the EXPAND piece.

...so again and as always,
your thoughtful feedback is greatly appreciated.

Gus

Ulli Hafner

unread,
Feb 23, 2015, 5:49:11 PM2/23/15
to jenkin...@googlegroups.com
Yes I would risk some incompatibilities with plug-ins, because I’m normally updating my plug-ins quite often if there is such a core change. But here I can only speak for myself: this depends on the spare time of plug-in developers and not everybody has the time to adapt the code to the new frameworks. Just look at the release dates of the plug-ins and you will see that this might be a problem for some (or many?) plugins.  

signature.asc

Tom Fennelly

unread,
Feb 24, 2015, 6:32:49 AM2/24/15
to jenkin...@googlegroups.com
Thanks Ioannis.

On Saturday, February 21, 2015 at 5:09:27 PM UTC, Ioannis Moutsatsos wrote:
I know that the fear of the unexpected consequences is always an issue. However, given the benefits of improved an Configuration UI I think we should be willing to take on some breaking changes. I did it recently (for the Uno-Choice plugin we developed) and although I admit initially it was frightening, at the end I took the plunge and never regretted it since... 

I agree with you there and I know others probably do. That said, I would not do it unless there was some form of consensus e.g. it was given a blessing on the bi-weekly community PM meeting (I forget what they call it :) ).

Tom Fennelly

unread,
Feb 24, 2015, 6:36:50 AM2/24/15
to jenkin...@googlegroups.com

On Saturday, February 21, 2015 at 6:08:12 PM UTC, Kanstantsin Shautsou wrote:
@Tom, divs, css and tab it's cool, but as not UI developer i will expect "building blocks" that will allow me just to use form and databinding. This will also allow enhance/fix problems only in this block that will automatically apply to other places. 

Sure, I think we need to create a centralised wiki to contain doc on how best to do "ui thinks". I'm not aware of such a community resource.

That said... I'm sure if you can get your head around jelly then you can get your head around a few <div>s :)
 

More thoughts.
- I think that other UI problem is maintainers/developers programming knowledge and lack of good documentation with good variants for them. After INFRA changes i hope people will finally be able to start enhancing documentation. 

Agreed, we need to do this. See above comments.
 

Gus Reiber

unread,
Mar 7, 2015, 5:19:26 PM3/7/15
to jenkin...@googlegroups.com
Hey all,
   So it has been 2 weeks since my last post, so I want to bring everyone up to speed with our latest thinking at CloudBees.
As we look around the web, we see some exciting things going on in the CD/CI space with tools like Docker, Codeship, Drone.io, Travis-CI, and Werker.

These tools, while not nearly as flexible and powerful as the Jenkins platform have some nice things about them, especially on the approach-ability and usability fronts.
Being GUI focused as I am, these tools all have a very HTML5ish vibe to them that I quite like.

So my questions for this group are as follows:
  • Have any of you used any of these tools, and what do you think of them?
  • If you haven't used these tools but are familiar with HTML5 style apps, what would you think of Jenkins moving in that direction (knowing also such a move might have disruptive elements to it)?
  • Perhaps more controversially, could you imagine (would you want to image) a world were the Jelly style servlets began to be depreciated in favor of a more RESTful, client MVC model of GUI building?
  • and finally, if you are imagining this RESTful world, what sort of extension points would you want or need (or other resources) to make successful plugins?
As always, any feedback is good feedback.
I am eager to help keep this thread near the top of this Dev list.

Thanks Again,
Gus



On Wednesday, February 18, 2015 at 8:27:12 AM UTC-8, Gus Reiber wrote:

Arnaud Héritier

unread,
Mar 8, 2015, 1:53:07 AM3/8/15
to jenkin...@googlegroups.com
Hi Gus,

  Myself I would love to see a Jenkins bringing a modern HTML/Web/JS framework based on rest services BUT from my point of view it is often many more difficult than a templating technology (Jelly, whatever) where you just insert some dynamic stuffs in a HTML page. 
  What is making Jenkins so different compared to many other softs is its large and heterogeneous community and I'm not sure such a modern JS/HTML5 technology could have a large adoption like Jelly nowadays. Jelly UI is perhaps ugly but it is easy to use. If Jenkins gives access to another UI framework to developers it will have to be easy to use (or we'll have to keep the jelly version for all plugins where there are contributors who don't have a black belt of HTML5/CSS/JS/...).
  
Arnaud


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
-----
Arnaud Héritier
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Tom Fennelly

unread,
Mar 8, 2015, 8:19:47 AM3/8/15
to jenkin...@googlegroups.com
I don't really see it as an either/or type thing. I don't see the Jelly/stapler way of doing things ever going away. At this stage I don't really think it's practical to try replace it with something else and, in any case, I don't think we need to replace it (HTML5 concerns aside). What I thought we were talking about doing was "adding" things on top of what's already there i.e. jelly etc stays as it is, allowing what's "good" about jelly (depending on your opinion :) ) to continue being one of Jenkins "advantages", while at the same time we start introducing new libraries/patterns/etc on top that so we can hopefully help people build richer controls within Jenkins.

So trying to be a bit more concrete:
  1. LESSification of CSS within Jenkins core (e.g. what we started doing with the UI Themes plugin), allowing us to modularise and parameterise how we do CSS in Jenkins core and Jenkins plugins.
  2. Cleanup how core/foundational Javascript libraries are used in Jenkins (e.g. jQuery, Twitter Bootstrap etc) such that plugins and core can be evolved to safely use different versions of these libraries within the same Jenkins instance i.e. an old version of a plugin using an old version of Bootstrap should be able to live alongside a newer plugin using a newer version of Bootstrap. And to do this without every component loading their own jQuery, or other such hackery.
  3. Provide better tools for doing modularised Javascript in aid of richer UI components e.g. building on things like CommonJS, Browserify, Gulp.
    • We (at CloudBees) have experimented with some of these things while building extensions for Jenkins Workflow. We've also experimented with them in the UI Themes plugins. Formalising some of what was learned there could be a start.
    • Again ... none of these things are replacing Jelly. They are simply building on top of them and hopefully making them more powerful in terms of the UX that can achieved.
  4. Develop/suggest client side coding patterns. Move away from the "hudson-behaviors.js" type anti-patterns.
    • Again, we have experimented with some things here when doing the Workflow extensions and the UI Themes plugin. 
      • We looked at trying to use things like AngularJS etc but came to the conclusion that they were not appropriate for a number of reasons e.g. too heavyweight + not appropriate for building widgets/"app-lets" in a Jelly world (frameworks like angularjs want to control/own the entire page/app).
      • We ended up building a very simple lightweight MVC style "pattern" (supported by some libs). I purposely used the word "pattern" here because I would not call what we did a "framework" ala angularjs, so need to get too scared :)
  5. I like the idea of allowing Jenkins Core switch UIs on a per user basis. Jenkins is just so huge now that it seems crazy to think that we can have one nice UI that's nice for everyone. Seems to me that an ops guy logging into Jenkins wants to see different things than a Dev guy etc. We already have evidence of this need by virtue of the fact that so many people have build their own UIs for Jenkins (complete UIs). I think it would be good to investigate whether or not we could formalise this in some way and make it easier for people to both develop and use different Jenkins "perspectives" (as one of my other CloudBees colleagues suggested calling it - ala Eclipse perspectives). By "use" I mean making it easy for a user to switch between perspectives. The current Jenkins UI could be the "Advanced" perspective.


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9%3D%3DOgTThRLMccMWKGbRJ-%3Dmhctr-f%2B7uG44QiT_Wx70Q%40mail.gmail.com.

Gus Reiber

unread,
Apr 20, 2015, 5:41:07 PM4/20/15
to jenkin...@googlegroups.com
Hey all,
   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.

Tom Fennelly

unread,
Apr 21, 2015, 2:43:39 AM4/21/15
to jenkin...@googlegroups.com
Hey Gus, these look really great and would be a huge step forward imo. I can see new users having a much easier/happier time with this ux.

In terms of styling (colour, icons etc), what you have here is very different to what's in Jenkins atm. What's the plan there?

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

Daniel Beck

unread,
Apr 21, 2015, 3:15:30 AM4/21/15
to jenkin...@googlegroups.com
On 20.04.2015, at 23:41, Gus Reiber <gre...@cloudbees.com> wrote:

> 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

I don't see how this is an improvement in any way for that "first interaction". There should be descriptions what each item is. Imagine the first interaction with Jenkins replaced by a single tile ("Jobs and Workflows") with 1-4 entries (depending on which bundled plugins are enabled) with no further explanation what each item is. Seems to be a huge step backwards.

Also, what's the default for any plugin not supporting this? An 'Unknown'/'Unclassified' section? Or default to 'Jobs and workflows'?

How does this view look with 15-20 entries in the 'jobs' category and 1-2 in others? You're presenting the 'best case' distribution of items, but that's not what it will really look like.

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

Could you explain how you'd get there from here? Because today there are no icons, and hundreds of plugins would need to be updated to add these to the builders and publishers they contribute (not to mention any trademark messes related to those icons). How does that design look like with all non-bundled builders having no icon, or the same generic icon?

> "Notifications" would be another boring control set, so I am not going to bother showing it, but hopefully you get the idea.

Actually, I'd be interested in how you determine into which set each Publisher goes. Are 'Post-build actions' those that don't inherit from Notifier? I have some concerns about how Jenkins determines execution order, as this grouping would worsen today's problem that the UI does not properly show the order in which post-build steps are actually executed.

> 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


Assuming this will be implemented for all config forms to keep things consistent, could you show the Edit View form in this new design as well? My first hunch is that it'll look really empty.

What's also completely missing in these designs is the help button next to each item. Are there plans to change these as well, or did you just leave them out?

I wonder about the title 'Create Freestyle Build'. For one thing, the terminology is wrong (it's a job or project, not a build), and the only form that today appears before the corresponding item has been created is the initial slave creation form.

Why are you collapsing the first section at all? Shouldn't name and description excluded from the collapsing sections? Will the form hide the information what users are editing by default, relying on e.g. bread crumbs?

IIRC Tom's first attempt (last year or so?) at collapsible sections suffered from navigation issues (as in the viewport moving around) due to all the scrolling going on when collapsing/expanding sections. How are you planning to deal with that?

How are you going to address the problem that users will no longer be able to see at a glance the handful of options/build steps they have in simple projects? 'Expand all'/'Collapse all' buttons? Indicator how many steps/enabled options are in each section on the title line?

Marius Gedminas

unread,
Apr 21, 2015, 7:52:44 AM4/21/15
to jenkin...@googlegroups.com
On Mon, Apr 20, 2015 at 02:41:07PM -0700, Gus Reiber wrote:
> 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....

Loving this!

> <https://lh3.googleusercontent.com/-VQTnSplC6g0/VTVuEFAfhiI/AAAAAAAAAvs/rEGmmI4VP2w/s1600/freestyle_3.png>
> Similarly for radio buttons. Here with the "Source Code Management", all is
> the same as it ever was...

Have you considered a dropdown instead of radio buttons?

> <https://lh3.googleusercontent.com/-79DlKNvDDGk/VTVuxbx-JJI/AAAAAAAAAv8/2GEn0gan4Js/s1600/freestyle_5.png>
> ...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.
>
> <https://lh3.googleusercontent.com/-Rbbgi2_94Ww/VTVwOiRCNVI/AAAAAAAAAwI/WMlqbIX2sDY/s1600/freestyle_6.png>
> 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.

I'd love a "(?)" button somewhere near the bottom right corner of the
text are, with a popup listing what environment variables I can use in
the shell script.

(Ideally plugins that define new variables should be able to extend that
list.)

> <https://lh3.googleusercontent.com/--CdfQbVIfYU/VTVwwQJM0OI/AAAAAAAAAwQ/4wTYXNw60Es/s1600/freestyle_7.png>
> 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).

I have some doubts about reordering collapsed steps when they look the
same ("Execute shell script"), but perhaps that's not common.

I hope expanding will be instant (i.e. pure JavaScript/CSS without HTTP
roundtrips), and that it will be possible to expand more than one step,
in order to see the entire build process.

> <https://lh3.googleusercontent.com/-9Tz4ic1EEIc/VTVxlAh6zII/AAAAAAAAAwY/9NnZLAhIYnM/s1600/freestyle_8.png>
> 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.

These are excellent!

Marius Gedminas
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
-- Avi Kivity
signature.asc

Daniel Beck

unread,
Apr 21, 2015, 12:02:35 PM4/21/15
to jenkin...@googlegroups.com

On 21.04.2015, at 13:52, Marius Gedminas <mar...@gedmin.as> wrote:

> I'd love a "(?)" button somewhere near the bottom right corner of the
> text are, with a popup listing what environment variables I can use in
> the shell script.
>
> (Ideally plugins that define new variables should be able to extend that
> list.)

That already exists (and is already extensible). Not a button, but a link below the text area opening a new window.

Balder VC

unread,
Apr 21, 2015, 3:15:58 PM4/21/15
to jenkin...@googlegroups.com
Yes, always horrible, yet another tab opening in my usually to crowded
browser tab bar. ;)
>

Balder VC

unread,
Apr 21, 2015, 3:24:33 PM4/21/15
to jenkin...@googlegroups.com
Hey Gus

In general, I like the overhaul. But the big icon buttons are a bit
overkill. The could be much smaller.
And indeed as a long time jenkins user, I too am used to seeing all
config at one sinlge glance but yes I sometimes still loose my may and
spend some time looking ( ctrl+f ing ) for a setting in the huge config.

I like your categorization and UI but It would be great to have a
separate view mode for just viewing the config. A short popup-able
version of the configuration. (without the big bars and lot of
whitespace) I confess, I sometimes just read the xml config..


Keep up the good work.
Perhaps it would be good to ask feedback from users on de user list, if
you didn't already, I would assume they have a slightly different view
then developers of Jenkins.


On 04/20/2015 11:41 PM, Gus Reiber wrote:
> Hey all,
> 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....
>


Kind Regards

Balder

Gus Reiber

unread,
Apr 21, 2015, 4:09:47 PM4/21/15
to jenkin...@googlegroups.com
Hey Daniel, 
   Awesome feedback. You have pointed out a few things that I have totally missed and a few things that I have just not shown well with my wireframes. So, let me see if I can work my way through your feedback:
  • Item selection page issues:
    • No descriptive text: I very much agree that is important, but I am thinking that text could move to a hover. Maybe not though, but I should have shown the hover in my pics here.
    • Default category: All the uncategorized items would get pushed under the "Plugins" category, though that name may or may not be right. It would be important that new categories make their way back into the community on a regular basis so plugin authors could self-select the category they want their new item to be associated with. This would all need to be documented, but for now...
    • Not realistic category distribution: This is definitely the tricky bit, because it would have to be done well to be helpful. For what its worth, the categorization I am showing is based on the plugins CloudBees actually uses internally. That isn't a great sample size, but it isn't cherry picking, either. You are absolutely right, the categories need to proven out in a handful of real-life scenarios.
  • Build step icons:
    Again, you are right that this only works if it really works. We would offer three (imperfect) pieces to help it work:
    • We at CloudBees (with the permission of the plugin author) would take the work of backfilling icons for commonly used plugins
    • We would offer a set of images that are pictorial abstractions for common job related functions that plugin authors could pick from
    • We offer a default icon or icons
  •   This view as config:
    • So while I have jiggled some of the names around a little bit and some of the category membership around a little as well, in general, this form form should map with logical equivalence to the existing form. The main thing that is changing is the underlying DOM structure and the CSS and JS that glues visuals and effects on the top. To the extent the current create form works as a config page, this version should work just as well.
    • Collapsing makes the page look empty: in general, I think that is a good thing. Each time I look at the Jenkins config screen, I see a giant list of options, most of which I don't care about for my particular job. Ideally, we would make the GUI smart enough to open all and only those sections that have values set in them when the user is using the form in config mode.
    • Read only view: We have also talked a bit internally here about showing a read-only initial state to the config form. The read-only view would make it a lot easier to see what the current settings are because it wouldn't need to be burdened with all the GUI goop of editing the settings and the other goop of settings not being used. You would then choose to edit that view and all the config options would then be presented.
  • Help Buttons:
    • Shame on me, yes, I just left them out. I do think our current help text metaphors are pretty good, but could use a little bit of refinement to make them look a little nicer, but in general, I mean to only be adding context, not removing it.
  • Hide/not hide first section:
    • I think hiding helps, even for the first section, but I am often wrong.
  • Scrolling behaviors:
    • So just as an FYI, what I have shown here are actually screenshots of semi-functional HTML. Smooth screen scrolling has not yet emerged as a problem in the prototypes, but it may be that my dataset is insufficient to really stress my proposed GUI gestures. But, not having scrolling problems would be an essential aspect of anything we would want to try to pass-off as an improvement.
  • Simple builds:
    • My hope here is that by silencing the noise of job configuration steps not in play, but cleanly naming and differentiating those categories, the simple job gets a lot simpler as the create/config process takes on more of a guided wizard type experience. Again, though, the simple build case is indeed a critical use case, so we would need to prove that experience was in fact better, not worse.
Anyway, hopefully my answers help you know where I do or do not understand your feedback, because it is definitely my goal incorporate as much of it as possible. I want to keep the bar of improvement as high as possible.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

Gus Reiber

unread,
Apr 21, 2015, 4:34:23 PM4/21/15
to jenkin...@googlegroups.com
Hey Marius,
   Thanks for your awesome feedback.
You express a concern about the delays of server round-trips, so before I take your comments in order, I want to say, I am envisioning these changes not actually requiring much functional change to the existing config/create form. Mostly these are DOM layout and CSS changes only (plus a little JS for page effects). The big thing with that is that these changes are meant to avoid changes to the forms data model, the inputs data binding mechanism, and the page loading sequence. 
...so any showing and hiding I am showing here is just the superficial sort, where the dom elements are statically loaded up front, same as they ever were. For better or worse, I am just changing the display styles on them.

  • Dropdown menus: So for choosing your SCM system, I don't like the compactness of a dropdown because I think a user wants to see the options available for this important choice up front. I suspect in many cases a particular company or group will always use the same SCM system, so equally important might be the ability to set a default for the Jenkins Master as a whole so you don't need to answer this question over and over.
    ...but if you do often switch between SCM, the SCM you are using is probably a significant context indication of what sort of job you are creating.

    ...let me know if that rings true. We pretty much always use Git, here. I haven't always used Git, but I can't remember when I worked at an organization that used switched SCM systems from project to project (or ever, honestly).

  • Missing Question marks: Bad GUS! Sorry, I just didn't add them in into my mock-ups. I am envisioning that they wouldn't change all that much

  • Collapsed sections look the same: Yeah, for that to work well, I would need to find some way to bubble up differences between the steps even when collapsed. At the moment, I am lacking a good solution.

  • Will it be slow: I hope not. See above about my plan to mostly not change the page-load dynamics

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

Gus Reiber

unread,
Apr 21, 2015, 4:43:10 PM4/21/15
to jenkin...@googlegroups.com
Hey Balder,
  Thanks for the feedback.
I have not posted to the de list, but I am eager to get quantity of feedback. Can you give me the URL to that list? I have to confess I am not familiar with it.

I hear you about the big icons.
In some respects it can look a bit like a kid drew the form inputs in crayon and thus wasted a lot of screen real estate. My mind has changed a little on that thought, though as now I have a 7" tablet with the same resolution as my 24" desktop screen. I think the key will be for the layout to be correctly responsive, but the first step in that is for me to be correctly responsive and try iterations that reflect yours and similar suggestions.

 

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

Gus Reiber

unread,
Apr 21, 2015, 4:55:36 PM4/21/15
to jenkin...@googlegroups.com
Hey Tom,
   So for the most part, my screens are still in a pre style refinement stage and are just meant to convey particular layout concepts and not any particular art.

...that having been said...
You are catching me starting to try to sneak some possible icon and typographic changes into my concepts. The font I am showing is called Railway which most importantly has good screen readability without being a particularly wide font, but also has a little bit of an Art Deco sort of flair that is subtle but akin to the idea of boom-times and buttler.

For the icons, as I am suggesting we use more of them, we would need a means of loading them into the browser efficiently and creating a library of them easily. Simple wire-n-knockout style icons are relatively easy to create (compared to full color/faux 3D), are lighter to load in the browser, and can be converted into a font (which super greatly reduces the server load while upping their use flexibility).

...so my real answer is that I am just starting with the art bits so it may well change significantly, but feedback is always helpful.

 

Jesse Glick

unread,
Apr 22, 2015, 6:55:02 AM4/22/15
to Jenkins Dev
On Tue, Apr 21, 2015 at 12:24 PM, Balder VC <li...@redlab.be> wrote:
>> Perhaps it would be good to ask feedback from users on de user list, if
>> you didn't already, I would assume they have a slightly different view
>> then developers of Jenkins.

On Tue, Apr 21, 2015 at 4:43 PM, Gus Reiber <gre...@cloudbees.com> wrote:
> I have not posted to the de list, but I am eager to get quantity of
> feedback. Can you give me the URL to that list? I have to confess I am not
> familiar with it.

@Gus reread, he said the users list.

https://groups.google.com/forum/#!forum/jenkinsci-users

Robert Sandell

unread,
Apr 22, 2015, 8:37:03 AM4/22/15
to jenkin...@googlegroups.com
If the collapsed/minimized form of the build step config was made pluggable (ex a collapsed.jelly next to config.jelly) the the readability of the overview could maybe be improved, for example a read only view of the first two lines of the execute shell step, the git url for the scm, the include path of the unit test collection etc.
Or would that have a risk of cluttering too much? Perhaps could be mitigated with good style guides/default css?

/B


--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3zkaB3MiGf3sUVUCR7FvLqJ6X6p6v0HBfoNhtOZKTJyA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Robert Sandell
Software Engineer
CloudBees Inc.

martinda

unread,
Apr 22, 2015, 9:55:36 AM4/22/15
to jenkin...@googlegroups.com
Hello,

Thanks a lot for looking into UI improvements. As a Jenkins job config admin, here are some comments about the current job build UI.

Radio buttons are not dense enough, it wastes horizontal space and increases the vertical scrolling.

For the collapsed and hidden items (e.g. those under "Advanced" buttons), I would like an indication that something is lurking under there so I am visually reminded to expand them.

For the text boxes, please get rid of the need for horizontal scrolling.

Big fonts and big icons: density matters. I'd rather see a lot of information at a time with a high density font than have to scroll all the time at a pretty font.

Side history panel and upper left corner links: more space for configuration if they are removed when configuring a job.

Keep up the good work and thank you again,
Martin

Ullrich Hafner

unread,
Apr 23, 2015, 9:27:08 AM4/23/15
to jenkin...@googlegroups.com
Am 21.04.2015 um 22:09 schrieb Gus Reiber <gre...@cloudbees.com>:

Hey Daniel, 
   Awesome feedback. You have pointed out a few things that I have totally missed and a few things that I have just not shown well with my wireframes. So, let me see if I can work my way through your feedback:
  • Item selection page issues:
    • No descriptive text: I very much agree that is important, but I am thinking that text could move to a hover. Maybe not though, but I should have shown the hover in my pics here.
    • Default category: All the uncategorized items would get pushed under the "Plugins" category, though that name may or may not be right. It would be important that new categories make their way back into the community on a regular basis so plugin authors could self-select the category they want their new item to be associated with. This would all need to be documented, but for now...
    • Not realistic category distribution: This is definitely the tricky bit, because it would have to be done well to be helpful. For what its worth, the categorization I am showing is based on the plugins CloudBees actually uses internally. That isn't a great sample size, but it isn't cherry picking, either. You are absolutely right, the categories need to proven out in a handful of real-life scenarios.
I think it would be a great improvement if 80% of the uses cases would be easy to achieve. So it looks very promising to have such a minimalistic view with just the icons. Maybe there needs to be some kind of ‚Advanced‘ section where one can edit all details.

  • Build step icons:
    Again, you are right that this only works if it really works. We would offer three (imperfect) pieces to help it work:
    • We at CloudBees (with the permission of the plugin author) would take the work of backfilling icons for commonly used plugins
    • We would offer a set of images that are pictorial abstractions for common job related functions that plugin authors could pick from
    • We offer a default icon or icons
That would be a great help, I think most developers would love to use icons from a predefined icon set that matches the rest of the graphics/style. 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXy1OTc657jL__6qu15rtjeW8HpLhD7Lhvf0tVr8FoiAdw%40mail.gmail.com.
signature.asc

Kanstantsin Shautsou

unread,
Apr 23, 2015, 9:33:09 AM4/23/15
to jenkin...@googlegroups.com
Will this “UI”/“theme” be in separate plugin?

Rafael Ribeiro Rezende

unread,
Apr 23, 2015, 10:29:06 AM4/23/15
to jenkin...@googlegroups.com
Hello Gus,

The layout looks quite pleasing imo. I'm curious about the look-and-feel for the Workflow job-type. ;-)

Anyway, I just would like to comment that the sbt logo you used there seems to come from a brazilian tv channel, not the "scala build tool".
So, unless the idea is to build some tv stuff :-) the correct logo should be either one of these:
The first one comes from Wikipedia and the second from the official sbt website. This one is actually a variant from the Typesafe company logo. I don't know if there are legal issues implied...

Gus Reiber

unread,
Jun 22, 2015, 7:37:17 AM6/22/15
to jenkin...@googlegroups.com
Hey all,
Been a long time since my last post, as I had been cramming getting a prototype built for JUCs DC and London. I am happy to report Tom and my presentation was well received in DC. Now we are off to the UK.

Now that we have a simifunctional prototype, we will be working to figure out how to best post it so community members can provide feedback.

Thanks again for your interest. Please stay tuned.

Mark Ribau

unread,
Aug 10, 2016, 9:55:14 PM8/10/16
to Jenkins Developers
Any updates since 2015-06? Is this still an active effort? Or has the discussion/updates moved somewhere else?

Thanks!!

James Dumay

unread,
Aug 11, 2016, 3:01:42 AM8/11/16
to Jenkins Developers
Have you seen Blue Ocean? That's where most of the UX effort is happening right now.

https://jenkins.io/blog/2016/05/26/introducing-blue-ocean/

JordanGS

unread,
Mar 19, 2017, 7:13:05 PM3/19/17
to Jenkins Developers
Can someone please update this thread, the images are no longer there.

https://jenkins.io/blog/2015/07/15/advancing-the-jenkins-gui-configuring-items-in-jenkins/

Reply all
Reply to author
Forward
0 new messages