Re: Jenkins UX

266 views
Skip to first unread message

Gus Reiber

unread,
Jul 16, 2015, 12:03:49 PM7/16/15
to jenkin...@googlegroups.com
As threatened, but at long last, I have a demo video and associated blog post.... not really posted to a blog, but, still something that can be read and comment on....

Please take a look, and send feedback:
video:
http://youtu.be/1Qn4jEwAeGc

post:



On Monday, June 22, 2015 at 4:37:17 AM UTC-7, Gus Reiber wrote:
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.

Mirko Friedenhagen

unread,
Jul 17, 2015, 4:04:30 PM7/17/15
to jenkin...@googlegroups.com
Hello Gus,

looks great!
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
> --
> 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/93876d10-a38e-49ef-a6d6-13b41841f2bb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Kanstantsin Shautsou

unread,
Jul 18, 2015, 10:29:41 AM7/18/15
to jenkin...@googlegroups.com
Sorry, but for me this design is the way back to 90': huge margins, full of borders instead of current clean and clear UI (like https://buildhive.cloudbees.com/job/kohsuke/job/github-api/ ) .
IMHO Many mentioned problems are caused by pure data forms and form bindings. You are demonstrating collapsible sections, but right now f:advanced can't even collapse content back. Trigger and Properties are 'bundled' and 'mixed' in UI because it's a feature.

Also i don't see any mentions about tfennelly themes work. Hope it will be possible to move such design into theme.

Kirill Merkushev

unread,
Jul 18, 2015, 5:11:56 PM7/18/15
to jenkin...@googlegroups.com
Agree with Kostya. Its better than we already have, but no so useful as it may be.

For example - job configuration page. You split every part to separate block. But it don't split user context completely. Why not to go deeper and split every part to separate tab. (As it done in TC or bamboo - http://hsto.org/storage2/d59/269/b4e/d59269b4ebb3da64d160faaf92a33d00.png)

суббота, 18 июля 2015 г., 17:29:41 UTC+3 пользователь Kanstantsin Shautsou написал:

Richard Bywater

unread,
Jul 18, 2015, 6:35:28 PM7/18/15
to jenkin...@googlegroups.com
Personally I like (some of) the proposed changes and the design looks like it would make things a lot easier to see what is going on. With respect to the example you've provided @ BuildHive, on my screen (MacOS Retina display) at least that looks like a real squashed mess of text where all the text is squashed up and there's huge amounts of whitespace that could be used.

One thing that the proposed design would show which the current design doesn't is the case where you have an Advanced button for a sub-section right above the Advanced button for the parent section. This ends up showing two Advanced buttons on top of each other and 9 times out of 10 I also end up picking the wrong one which wastes my time. A clear delineation of the sections would mean this is less likely. (Unfortunately can't remember the exact plugin that exhibits the issue described).

Richard.

Richard Bywater

unread,
Jul 18, 2015, 6:37:04 PM7/18/15
to jenkin...@googlegroups.com
-1 to tabs in my opinion. You spend a lot more time moving your mouse all around the screen going between the tab bar and the settings you are after. With them all on the same page then its easier to scroll to find the sections you are after with minimal mouse effort. (Let's not forgot those who have trouble using mice)

Richard.

Lucy Davies

unread,
Jul 18, 2015, 6:55:59 PM7/18/15
to jenkin...@googlegroups.com
I have to agree that it's good to have them all on the same page.

However, I do like the idea of being able to quickly navigate to a particular section with for example a tab bar.

Maybe have a tab bar, but which jumps you to a location on the current page, rather than switches you to a new page.

Daniel Beck

unread,
Jul 18, 2015, 7:05:33 PM7/18/15
to jenkin...@googlegroups.com

On 19.07.2015, at 00:55, Lucy Davies <strawber...@googlemail.com> wrote:

> Maybe have a tab bar, but which jumps you to a location on the current page, rather than switches you to a new page.

I recently pointed Gus to this:
http://getbootstrap.com/javascript/#js-overview

Something like the list on the right would achieve this, right?

Lucy

unread,
Jul 18, 2015, 7:08:50 PM7/18/15
to jenkin...@googlegroups.com
Yeah, that's better than what I had in mind actually.


-Lucy-


--
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/Tiz-LSqCJmg/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/46F6FAE9-500C-449B-B779-D8D7BCB452CA%40beckweb.net.

Richard Bywater

unread,
Jul 18, 2015, 7:54:50 PM7/18/15
to jenkin...@googlegroups.com
+1 for that 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.

Slide

unread,
Jul 18, 2015, 11:03:06 PM7/18/15
to jenkin...@googlegroups.com

Kirill Merkushev

unread,
Jul 21, 2015, 7:32:01 AM7/21/15
to jenkin...@googlegroups.com
Floating list with is good idea.
Scroll with mouse - can be done until your job is 50 screens long. Then you dont want to scroll anymore :)

Also it very useful for me to split console log for each invoked step and make same floating menu.

четверг, 16 июля 2015 г., 19:03:49 UTC+3 пользователь Gus Reiber написал:

Kanstantsin Shautsou

unread,
Jul 21, 2015, 8:05:15 AM7/21/15
to jenkin...@googlegroups.com
On Jul 21, 2015, at 14:32, Kirill Merkushev <twil...@gmail.com> wrote:

Floating list with is good idea.
Scroll with mouse - can be done until your job is 50 screens long. Then you dont want to scroll anymore :)

Also it very useful for me to split console log for each invoked step and make same floating menu.
Console handling was implemented in separated plugin.

четверг, 16 июля 2015 г., 19:03:49 UTC+3 пользователь Gus Reiber написал:
As threatened, but at long last, I have a demo video and associated blog post.... not really posted to a blog, but, still something that can be read and comment on....

Please take a look, and send feedback:
video:
http://youtu.be/1Qn4jEwAeGc

post:



On Monday, June 22, 2015 at 4:37:17 AM UTC-7, Gus Reiber wrote:
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.

--
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/Tiz-LSqCJmg/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/2c218bd6-c159-4dee-b5d1-224824fc4148%40googlegroups.com.

Lucy

unread,
Jul 21, 2015, 8:11:47 AM7/21/15
to jenkin...@googlegroups.com

Kanstantsin Shautsou

unread,
Jul 21, 2015, 8:14:06 AM7/21/15
to jenkin...@googlegroups.com
Plus ansi-color for color handling

Kirill Merkushev

unread,
Jul 21, 2015, 9:20:10 AM7/21/15
to jenkin...@googlegroups.com
https://wiki.jenkins-ci.org/display/JENKINS/Collapsing+Console+Sections+Plugin - looks a little bit ugly, but it close to what i mean. I mean sections like in travis, for each step out from the box

четверг, 16 июля 2015 г., 19:03:49 UTC+3 пользователь Gus Reiber написал:
As threatened, but at long last, I have a demo video and associated blog post.... not really posted to a blog, but, still something that can be read and comment on....

Gus Reiber

unread,
Jul 22, 2015, 6:31:39 PM7/22/15
to Jenkins Developers, gre...@cloudbees.com
Awesome, awesome, awesome feedback all around.

So if I can summarize the feedback so far, it sounds to me like Kanstantsin is the most skeptical, but few if any of you are 100% sold, which is how it should be. Possible sources of discontent seem to break down like this:
  • Don't forget about Tom's work and the existing SimpleTheme plugin 
  • Color, font, and border choices: Seems like maybe we like the simple black and white better, with less borders, less margins and smaller text (though that is not a consensus)
  • Collapse mechanism: The idea of clear segmentation seems to be generally embraced (Kanstantsin being the exception), but the sort of pegged ToC tracking that Bootstrap uses might be prefered. 
  • Console log should be better, too (I totally agree with that, but didn't choose that piece of the GUI as a starting point so am punting on thinking about that for the moment)
Most of my goal here is to show the sorts of tangible benefits that an overhaul of a GUI can bring that go beyond what can be done against the current Jenkins DOM with CSS alone. KK, Daniel, Tom and I agree that is the case enough to start organizing ourselves into both code and outreach to start making that case through forums and demos like this, and pull requests which we are starting to create.

As I see it, we will want to break down pull requests along this topic into manageable bites, the first of which being largely infrastructure and only minimal visual changes, if at all. It is my belief that the first step of doing any modernizing of the config page is to pull it out of tables and refactor hudson-behavior to function with a semantic and logically nested DOM structure, such that new styles of input elements can be folded into both core config items and plugin configuration without a lot of the crazy DOM wackery that happens today. Also, I think PrototypeJS and YUI are essentially dead technologies, so we will need to cast off those shackles.

...thus our first PR is likely to be all about enabling DOM changes to the jelly resources files in the form directory (even prior to the actual DOM changes).

Anyway, in the next few days, KK and Daniel will be looking to set up a hangout in which at least some of us might be able to get together and examine the ins and outs of this technical web.

...expect a seperate note from them with more specifics, shortly.

Bruno P. Kinoshita

unread,
Jul 22, 2015, 6:40:52 PM7/22/15
to jenkin...@googlegroups.com, gre...@cloudbees.com
Thanks for all the hard work Gus.

I can try building a Jenkins version with your pull requests, or if you have .war, I can try it with the active-choices-plugin, which relies on the DOM structure created in the build with parameters screen. CSS changes won't break the plug-in, but moving tables, divs, inputs, might break it.

Cheers
Bruno


From: Gus Reiber <gre...@cloudbees.com>
To: Jenkins Developers <jenkin...@googlegroups.com>
Cc: gre...@cloudbees.com
Sent: Thursday, July 23, 2015 10:31 AM
Subject: Re: 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/a77c5054-7888-415c-9ae5-be73aa9e9af3%40googlegroups.com.

Gus Reiber

unread,
Jul 22, 2015, 6:52:01 PM7/22/15
to Jenkins Developers, gre...@cloudbees.com
..back to specific bits of feedback here, there seems to be a lot of enthusiasm (including from me), about Daniel and Lucy's references to a Bootstrap pegged ToC style of navigation and section segmentation. I do have some concerns about that approach however, so I want to toss them out there to see if you all have resolutions....

So a ToC sort of display like Bootstrap's typically relies on a separate rendering of the ToC from the actual content.
At the moment, this is nothing like the way the config page is currently rendered. There are a number of ways to fix that. We can go directly to the jelly files and loop over the form contents twice. We can parse the page with JS after it is rendered and attach a pegged ToC. And, I am sure there are other solutions I am not thinking of. In all cases, though, that means a fairly substantial change to the page DOM, ie, the injection of this ToC block and possibly anchor points to tie the two together.

With the collapsible accordions the DOM change is relatively small.

If it weren't for the slightly nutty table structure of the page, there wouldn't even need to be a DOM change.

Gus Reiber

unread,
Jul 22, 2015, 6:56:52 PM7/22/15
to Jenkins Developers, brunod...@yahoo.com.br
Cool, Bruno.

Yes please, but in the future.... :^)

Our hope is that by the end of the week, we will have such a .war or PR for folks to play with.
At the moment, not quite.

...but if you are really hungry for code, KK has just set up this branch:

...which we are busily troubleshooting.

...we will be tracking our own progress here:

Daniel Beck

unread,
Jul 23, 2015, 1:44:17 AM7/23/15
to jenkin...@googlegroups.com

On 23.07.2015, at 00:52, Gus Reiber <gre...@cloudbees.com> wrote:

> So a ToC sort of display like Bootstrap's typically relies on a separate rendering of the ToC from the actual content.
> At the moment, this is nothing like the way the config page is currently rendered. There are a number of ways to fix that. We can go directly to the jelly files and loop over the form contents twice. We can parse the page with JS after it is rendered and attach a pegged ToC. And, I am sure there are other solutions I am not thinking of. In all cases, though, that means a fairly substantial change to the page DOM, ie, the injection of this ToC block and possibly anchor points to tie the two together.

We already have something similar in the "context menu" for the 'configuration' bread crumb. Can't this be reused in some way?

Dzmitry Kashlach

unread,
Jul 23, 2015, 2:55:39 AM7/23/15
to Jenkins Developers, gre...@cloudbees.com
Hello,

Can I also insert my 5 cents(although I'm not a Jenkins contributor/committer).
Idea with collapsable/expandable sections is great alone with floating list.
But a lot of lines/margins break down jenkins minimalism, which I consider as a huge plus.
So, something between current TC UI and current Jenkins design(with collapsable sections/floating bar) would be good, IMHO.

Dzmitry Kashlach

unread,
Jul 23, 2015, 5:01:16 AM7/23/15
to Jenkins Developers, gre...@cloudbees.com
One more question: will these changes have influence on existing plugins? 
How about back-compatibility? Thanks in advance.


On Thursday, July 16, 2015 at 7:03:49 PM UTC+3, Gus Reiber wrote:

Bruno P. Kinoshita

unread,
Jul 23, 2015, 7:24:19 AM7/23/15
to jenkin...@googlegroups.com, gre...@cloudbees.com
Hi Gus

Had trouble with `mvn -Plight-test install`. Some JS tests were failing, and `mvn -Plight-test install -DskipTests=true` didn't seem to disable JS tests (would be cool to have some way to disable it I think).

Tried `cd war && npm rebuild` with no success. Removing war/node* -rf and executing maven again did the trick.

Then the frontend-maven-plugin was failing with "gyp_main.py: error: no such option: --no-parallel". The hack in this SO http://stackoverflow.com/questions/28486891/uncaught-error-module-did-not-self-register solved the problem and the project was built locally.

I had an old job already configured to test a file upload parameter, which is looking strange with the new UI (attached - strange-upload-button.png).

The Build Executor Status seems to be missing a space between the executor ID and the status (attached - text-no-space.png).

But the active-choices-plugin is still working :) Attached a GIF with the plug-in in action - GIFrecord_2015-07-23_224531.gif

The param003 is created dynamically based on the choices of other parameters, and the list of values varies depending on the options and what the Groovy script evals.

Looks like if some of the children elements of the div[class='tr form-group'] are bigger than the parent div, it doesn't resize and the next div[class='tr'] with the Build button doesn't move down.

Not sure if I explained it well, but if you look at the GIF, you can see the Build button right next the list of values for the parameter param003. Attached an example of how it renders with 1.620 - current-behaviour.png

Kudos for working so hard to keep backward compatibility. I will have more time in the next days to help testing if necessary. CC'd your e-mail in case the mailing-list filters the images.

Thanks!
Bruno


From: Gus Reiber <gre...@cloudbees.com>
To: Jenkins Developers <jenkin...@googlegroups.com>
Cc: brunod...@yahoo.com.br
Sent: Thursday, July 23, 2015 10:56 AM
Subject: Re: Jenkins UX

strange-upload-button.png
text-no-space.png
current-behaviour.png
GIFrecord_2015-07-23_224531.gif

Gus Reiber

unread,
Jul 23, 2015, 11:02:09 AM7/23/15
to jenkin...@googlegroups.com
Daniel Beck: We already have something similar in the "context menu" for the 'configuration' bread crumb. Can't this be reused in some way?

For the approach, I am pretty sure that is script scraping the page and appending DOM after the page renders, which we can do. But in terms of using some portion of shared code, definately not. In general, page scraping and appending DOM has the illusion of being a safeish change. The problem is that it becomes a maintenance nightmare because the DOM upon which the scraper is dependant has no indication of the nature of that dependency. The screen rendering really shouldn't be treated as an API, which is what ends up happening and leads to the sorts of refactoring issues we are confronted with now.


--
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/Tiz-LSqCJmg/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/805A1DB3-DBD4-4F2E-958D-F6C901AFEE95%40beckweb.net.

Craig Rodrigues

unread,
Sep 15, 2015, 3:25:07 PM9/15/15
to jenkin...@googlegroups.com


On Wed, Feb 18, 2015 at 8:27 AM, Gus Reiber <gre...@cloudbees.com> wrote:


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.



Two use cases that I use the Jenkins UI for are:
  (1) configuring Jenkins and jobs
  (2) reporting results of jobs

For (2), the default reporting in Jenkins is OK, but not ideal.
I've seen people write dashboards to report the results of Jenkins jobs, instead of
using the default Jenkins UI for reporting the status of jobs.

With the stuff you are working on, would it be possible to generate reports that
look like the waterfall in Buildbot?  Something like:

https://build.webkit.org/waterfall
http://build.chromium.org/p/chromium/waterfall

These are not the prettiest things, but for some things they quite effectively
report the status of build jobs in a concise view.

--
Craig
  

Daniel Beck

unread,
Sep 15, 2015, 3:28:09 PM9/15/15
to jenkin...@googlegroups.com

On 15.09.2015, at 21:25, Craig Rodrigues <rod...@FreeBSD.org> wrote:

> With the stuff you are working on, would it be possible to generate reports that
> look like the waterfall in Buildbot? Something like:
>
> https://build.webkit.org/waterfall
> http://build.chromium.org/p/chromium/waterfall
>
> These are not the prettiest things, but for some things they quite effectively
> report the status of build jobs in a concise view.

I see no reason why this couldn't be done… in a plugin. So it's not really related to Gus' changes IMO.

Robert Sandell

unread,
Sep 19, 2015, 12:28:43 PM9/19/15
to jenkin...@googlegroups.com
I noticed the config screen loaded/rendered even slower than I'm used see it in your demo, maybe it's just on your machine, but would it be possible to lazy/on demand load each section upon expansion and then start with just the first one expanded and all other collapsed? That could increase the responsiveness quite a bit.

/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/74BF6CFA-C45B-4DD7-B1BE-E471DCFB6682%40beckweb.net.

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



--
Robert Sandell
Software Engineer
CloudBees Inc.

Gus Reiber

unread,
Sep 23, 2015, 1:18:07 PM9/23/15
to Jenkins Developers
Wow. I am totally behind in responding to this thread.
@Craig Rodrigues, I want to thank you for sending along some example of reporting visuals that you find helpful.

So far, I have been focused on the config end of the Jenkins user experience and not so much on the monitoring/reporting. I am hoping to shift that way soon, but sadly not today. Here is sketch video of some of my initial thoughts on reporting in Jenkins: http://youtu.be/J8AHhicq0_A

Tangentially related to reporting, I have just completed a pair of workflow prototype videos:

....the relation to reporting, is that I think that if Jenkins were to be a little more leading/prescriptive in how jobs should be assembled, it would a lot easier to aggregate interesting data. In building a GUI for Workflow construction, we have a chance to provide some of that guidance. Which in turn would allow for results presentations and groupings that are more independent of a folder structure.

PS. I have a webinar tomorrow, so I am shamelessly hyping it: http://devops.com/2015/09/09/webinar-evolving-the-jenkins-ui/

Also, @gusreiber on Twitter, IRC and https://plus.google.com/+GusReiberUI/posts on Google+

Michael Neale

unread,
Sep 25, 2015, 1:02:36 AM9/25/15
to Jenkins Developers, rod...@freebsd.org
Yes those are good clear visualisations. You mention writing dashboards, but I think to get a view like that it would effectively be a "dashboard" in the sense that it would have to take over the whole Jenkins UI to allow that much information to "radiate" out. Would be nice if people didn't need bespoke plugins for such visualisations though. 

Michael Neale

unread,
Sep 25, 2015, 4:39:58 AM9/25/15
to Jenkins Developers
On the topic of configuring workflow, curious to hear feedback on some ideas. I often hear that a "blank text area" is a bit intimidating, and of course docs and the snippet builder helps, but there can be more. Would people like to hear more about: 

1) Richer content aware text/code editing (an editor that knows a bit about syntax, content assistance etc) - either on web or in an IDE? 
2) Enhanced snippet builder that gives you a pallette of things to choose from
3) A more visual editor 

(last 2 are similar to what Gus showed if you watch his demo). 

I have been amused by google blockly (https://developers.google.com/blockly/?hl=en)
enough to come up with a part of a block definition (attached example). While this looks odd, it is designed to be extensible and educational. 

Another approach (also attached) I have been experimenting with is a editable pipeline metaphor (this assume stages are the most visible elements as things move through a notional pipeline).

Would love to talk more.  
Screen Shot 2015-09-23 at 3.05.48 pm.png
Screen Shot 2015-09-25 at 5.41.08 pm.png
Reply all
Reply to author
Forward
0 new messages