Refreshing the Jenkins UI

[Tom Fennelly]

Hi guys.

I've just started looking into ways in which we can "refresh" the look and feel of the Jenkins UI, as well as looking at tackling some of the main usability issues.  I've really only started, but have committed a small bit of code to a branch on github at https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:

1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
   
2. Modified the main project/job configuration page, in an effort to make it less cluttered, by adding accordions for the different config sections.  The only way I found I could do this was to wire in some javascript to manipulate the page post-rendering.  Kohsuke says there's a way of doing the bulk of the DOM manipulation within Jelly templates, but I failed to work that one out yet - I'm sure it will be "obvious" after I see it :)  Not sure if accordions are the correct choice.  Here's a screenshot of what it looks like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

The above commit obviously breaks things e.g. the breadcrumbs + some of the styling is screwed up (I added Twitter bootstrap, causing the css's to clash).  What I've done so far is really just hacking to see what we could do.  I'm keen to hear the opinions of the community... what people thing we should concentrate on... what should we avoid... what are the risks etc etc.  I'm aware there is some prior art in this area e.g. OHTAKE Tomohiro's work, the Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:

1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
4. New more "modern" icons?

After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

So I hope there's an appetite/interest in this and I hope people will let us know where they would like to see this go (or not, as the case may be).  And of course, if anyone is interested in getting involved in a "hands-on" way, then that would be even better :)  I think the next steps are for me to gather peoples opinions and formulate an actionable plan that people can see and comment on if they want to.

Regards,

Tom.

[Bruno Kühnen Meneguello]

I totally agree with you.

I've started a mobile UI and noted how difficult is to change some things, just because the layout is entirely locked inside tables.

Although to "boil the ocean" should be a lot o work, maybe a major rewrite of Jenkins interface (I liked the REST idea) will bring much more responsiveness and reduce the bandwidth traffic that Jenkins needs today.

Another great advantage is to adapt to distinct screens and layouts much better and to add the possibility to override the default stylesheet with plugins to fine tune.

I personally access Jenkins frequently via smartphone and in my company it is shown in a big screen and we have some difficult to lay out all jobs (we don't use extreme feedback plugins). With a more semantic page design, based in CSS, it could be more easy to adapt.

If you want to make it happens, I want to collaborate.

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

[Daniel Beck]

On 26.05.2014, at 15:54, Tom Fennelly <tom.fe...@gmail.com> wrote:

> • New more "modern" icons?

IMO the background makes the icons look blander than they are. And we should use an icon style that allows plugin developers to easily find compatible (style + license) icons. Currently we're using Tango (+RRZE) icons. Is there anything comparable?

[Christopher Orr]

On 05/26/2014 03:54 PM, Tom Fennelly wrote:
> Hi guys.
>
> I've just started looking into ways in which we can "refresh" the look
> and feel of the Jenkins UI, as well as looking at tackling some of the
> main usability issues.

You often hear people say "the Jenkins UI is bad", but it's usually said
that there's a lack of concrete examples of *why* it's bad. So, just
out of curiosity, is there a list somewhere of the main usability issues
that you've been working on?

> What I've experimented with so far:
>

> 1. Tweaking the main layout in

> core/src/main/resources/lib/layout/layout.jelly (and added some CSS
> to style.css). Everything was layed out with tables, so I changed
> that to use divs instead, allowing us to more easily do things like
> make the sidebar disappear on small screens (if that was a good
> idea) etc etc. Here's a screenshot of
> that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png

> 2. Modified the main project/job configuration page, in an effort to

> make it less cluttered, by adding accordions for the different
> config sections. The only way I found I could do this was to wire
> in some javascript to manipulate the page post-rendering. Kohsuke
> says there's a way of doing the bulk of the DOM manipulation within
> Jelly templates, but I failed to work that one out yet - I'm sure it
> will be "obvious" after I see it :) Not sure if accordions are the
> correct choice. Here's a screenshot of what it looks
> like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

Nice. That job config is looking good :)

> After a few brief conversations with some of my colleagues at CloudBees
> (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most
> "doable" approach for now is to stick with making changes to what's
> there right now i.e. jelly templates, javascript and CSS. We also
> talked (not in detail) about the possibility of working towards more
> modern technologies and approaches e.g. a Single Page App using the
> Jenkins REST API Vs the current server-side approach with Stapler and
> Jelly. To do that now, however, seems a bit like trying to "boil the
> ocean" (quoting one of the guys there). What do you guys think?

I guess it depends what the goal is. If it's just "refreshing the UI",
then continuing with the changes so far and perhaps building on some of
the nice existing CSS themes out there would be reasonable, e.g.
https://github.com/Dakota628/jenkins-clean-theme


But having seen a colleague of mine use the Jenkins API and AngularJS to
build some really nice (though narrowly focussed) Jenkins front-ends for
internal apps, dashboards and for customer use, I really like the idea
of building the Jenkins UI on top of its API.

As you may have seen, this is something Tyler did some work on during
FOSDEM last year. The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y

From a user's standpoint, I actually remain fairly happy with the UI,
and I don't tend to hear complaints from colleagues about it...

But I think an "API first" way of thinking would be cool and, although
being cool and modern is not a concrete benefit in itself, it would
(hopefully) make it easier for people to build upon the API, or to make
ongoing improvements to the Jenkins UI, without really having to know
about Java or any of the fairly Jenkins-specific technologies in use
just now.


Regardless of what happens, so long as one day I can click "Build Now"
and don't need to hover my mouse over the Build History, waiting five
seconds for the progress bar to appear so I can click on it and see the
console output, I'll be happy! ;)

Regards,
Chris

[Daniel Beck]

On 26.05.2014, at 21:08, Christopher Orr <ch...@orr.me.uk> wrote:

> You often hear people say "the Jenkins UI is bad", but it's usually said that there's a lack of concrete examples of *why* it's bad.

Wait, people complain but cannot provide concrete examples? Let me!

- Jenkins uses very long forms that also change contents (collapsing/expanding elements) without indication what changed (e.g. animation, highlighting), whichmakes it quite difficult to keep track where you are.

- Inserting a new 'first' build step above half a dozen existing ones is really cumbersome. As is reordering build steps in general, as they tend to be rather tall in some plugins. Hiding everything in Advanced sections by default (see above) also doesn't help when it's a bunch of 30-50 line scripts.

- Since elements have no obvious borders (unless dragging, or hovering the delete item), it's difficult to see where one element ends and another starts (Conditional Build Step, I'm looking at you!)

- The Save/Apply area has a fuzzy "border" making it difficult to tell whether it's time to scroll when trying to edit a text field near it. You can see form elements, but not click them, because there's a low opacity white overlay over the white input field on white background.

- It's possible to save forms with errors. Either you get a stack trace (not good) or the system accepts your input, breaking something a long way down the road (worse). Or nothing breaks and you wonder what is going on with the obviously broken input validation.

- Important UI elements are not available in the model-link context menu because they're not in the side panel (notably disable/enable project and mark slave offline/online).

- Jenkins cannot decide whether it's designed for a large screen (Matrix auth table with a plugin or two installed fits barely on 2560 wide screen) or not (400x300 load statistics until a few versions ago). User input can make content too wide for other users (content-controlled width of syntax-highlighted text fields).

- It doesn't tell you which of the dozens of input fields were modified in a lengthy form you had open for a while. At least since 1.538 or so it tells you that you _probably_ changed something before navigating away, but still, starting over from scratch -- redoing everything I wanted to do, to prevent accidental changes -- is a common occurrence for me.

- The first run experience is pretty weird if you look at it with some Jenkins experience. It just dumps you onto an empty page telling you to create a job, while only a completely different page shows a severe warning (no security), and the global config requires changes (Jenkins URL, mail server, ...) or otherwise things won't work right.

[Michael Neale]

On Tuesday, May 27, 2014 7:41:10 AM UTC+10, Daniel Beck wrote:

On 26.05.2014, at 21:08, Christopher Orr <ch...@orr.me.uk> wrote:

> You often hear people say "the Jenkins UI is bad", but it's usually said that there's a lack of concrete examples of *why* it's bad.

Wait, people complain but cannot provide concrete examples? Let me!

- Inserting a new 'first' build step above half a dozen existing ones is really cumbersome. As is reordering build steps in general, as they tend to be rather tall in some plugins. Hiding everything in Advanced sections by default (see above) also doesn't help when it's a bunch of 30-50 line scripts.

Editing builds in freestyle builds is common - along with things like this - yet these are buried in the page as peers with things that you don't need to see 99% of the time (and can find when you need them). 

 

- Since elements have no obvious borders (unless dragging, or hovering the delete item), it's difficult to see where one element ends and another starts (Conditional Build Step, I'm looking at you!)

Ironically there are table borders on UI elements elsewhere, all over the place, usually where the visual cues are already there (ie executors, build lists etc - are obviously lists). I liked tom's grouping for starters. 

 

...

- The first run experience is pretty weird if you look at it with some Jenkins experience. It just dumps you onto an empty page telling you to create a job, while only a completely different page shows a severe warning (no security), and the global config requires changes (Jenkins URL, mail server, ...) or otherwise things won't work right.

Yes, I wonder if people would like some first-time jobs created (on demand, of course) - or would that just confuse people more as suddenly they have a bunch of artifacts they don't know what to do with? Some hints at the least could be nice, but most of us are far removed from first time experience it is hard to think back ;)

[Michael Neale]

On Tuesday, May 27, 2014 5:08:28 AM UTC+10, Christopher wrote:

But having seen a colleague of mine use the Jenkins API and AngularJS to
build some really nice (though narrowly focussed) Jenkins front-ends for
internal apps, dashboards and for customer use, I really like the idea
of building the Jenkins UI on top of its API.

As you may have seen, this is something Tyler did some work on during
FOSDEM last year.  The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y

I have some experience doing fairly advanced UIs on top of the various APIs - they are quite powerful (other than, notably the config - where it is more of an xml blob) for doing a lot of things. This does feel a little "boil the ocean", and even if worthwhile, the non js based UI will be around for a long time yet, so it is probably worth putting a bit if work in to that to start with. 

 

[domi]

Glad to see others coming up with this topic again!

We have talked about this on many occasions and some work has been done in a separate branch too:

https://github.com/jenkinsci/jenkins/tree/ui-changes

In JIRA we also created a special component (ui-changes) to keep track of all this: https://issues.jenkins-ci.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+Jenkins+and+component+%3D+ui-changes&runQuery=true&clear=true

…but unfortunate all/most the effort which was put into any attempts of changing the UI of Jenkins has stopped at some point. I think the biggest problem really is to find a common agreement on anything - there is always someone who does not like it. 

Although I agree, the current implementation does its job and most of the people get a long with (maybe just because they have not seen anything else yet) - I absolutely think the look and feel is way off what a user can/does expect nowadays. In fact I know of a couple of teams which have chosen an other CI server then Jenkins just because of the UI (e.g. TeamCity) - I also think Jenkins has by far more capabilities then e.g. TeamCity, but not everyone needs the more advanced plugins/features/extensionpoints and these users can happily choose a nicer looking CI server (I would too).

Also the fact that there are so many different approaches on changing the UI tells me that there is something we should improve. 

Some more examples

- https://github.com/rackerlabs/canon-jenkins

- https://github.com/djonsson/jenkins-atlassian-theme -> http://test.do/ (making Jenkins look like bamboo)

- http://isotope11.com/blog/styling-your-jenkins-continuous-integration-server

...

As a reference, there are also the notes we made about the discussions we had at another FOSDEM: https://wiki.jenkins-ci.org/display/JENKINS/UI+Enhancements

Domi

[Tom Fennelly]

On Monday, May 26, 2014 3:36:23 PM UTC+1, Bruno Kühnen Meneguello wrote:

I totally agree with you.

I've started a mobile UI and noted how difficult is to change some things, just because the layout is entirely locked inside tables.

Right... tables are evil for anything more than tabular data... they can make the initial layout easy but then it's locked.  Also.... styling can be a pain in the ass.

Although to "boil the ocean" should be a lot o work, maybe a major rewrite of Jenkins interface (I liked the REST idea) will bring much more responsiveness and reduce the bandwidth traffic that Jenkins needs today.

Our initial thoughts were that this would be a bridge too far but now I'm thinking it might be the only way to do anything meaningful in a somewhat predictable fashion. 

Another great advantage is to adapt to distinct screens and layouts much better and to add the possibility to override the default stylesheet with plugins to fine tune.

I personally access Jenkins frequently via smartphone and in my company it is shown in a big screen and we have some difficult to lay out all jobs (we don't use extreme feedback plugins). With a more semantic page design, based in CSS, it could be more easy to adapt.

Right... this type of thing is easy enough with <div>s and css and media tags.  The simple mockup I did does some of this i.e. the sidepanel drops off if the screen becomes too narrow. 

[Tom Fennelly]

Well, by modern, I meant something like the flat icon sets that a lot of apps use nowadays.  The current set of icons used in Jenkins are 90s or early 00s style imo (as is the default styling in general).

[Stephen Connolly]

Here's a nice set of flat icons:

--

[Tom Fennelly]

On Monday, May 26, 2014 8:08:28 PM UTC+1, Christopher wrote:

On 05/26/2014 03:54 PM, Tom Fennelly wrote:
> Hi guys.
>
> I've just started looking into ways in which we can "refresh" the look
> and feel of the Jenkins UI, as well as looking at tackling some of the
> main usability issues.

You often hear people say "the Jenkins UI is bad", but it's usually said
that there's a lack of concrete examples of *why* it's bad.  So, just
out of curiosity, is there a list somewhere of the main usability issues
that you've been working on?

Well this is a perfectly valid question and probably one I'm not best qualified to answer.  Personally though... I'd find:

1. Initial experience is a bit clunky in that you just end up on a blank page/  I think we could at least add some cheat-sheets, introductions (of the "looks like this is your first time using this Jenkins instance.  Want a tour....") or ask the user straight off if they want to set up their first Job... then have some visually appealing quickstart templates on a pallet of some sort.
2. The job config page is a badly organised nightmare.
3. The default template is definitely very dated in appearance (including the icons ;) ).  I know this is not something that would bother everyone, but I do think it possibly send out the wrong signal to potential new community members.  I would fear that many would form the opinion (maybe not intentionally) that things are stale and so would go look elsewhere.

> What I've experimented with so far:
>
>  1. Tweaking the main layout in
>     core/src/main/resources/lib/layout/layout.jelly (and added some CSS
>     to style.css).  Everything was layed out with tables, so I changed
>     that to use divs instead, allowing us to more easily do things like
>     make the sidebar disappear on small screens (if that was a good
>     idea) etc etc.  Here's a screenshot of
>     that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
>  2. Modified the main project/job configuration page, in an effort to
>     make it less cluttered, by adding accordions for the different
>     config sections.  The only way I found I could do this was to wire
>     in some javascript to manipulate the page post-rendering.  Kohsuke
>     says there's a way of doing the bulk of the DOM manipulation within
>     Jelly templates, but I failed to work that one out yet - I'm sure it
>     will be "obvious" after I see it :)  Not sure if accordions are the
>     correct choice.  Here's a screenshot of what it looks
>     like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

Nice.  That job config is looking good :)

It looks okay'sh, but the problem is that the form on that page seems to be quite sensitive to a change in the page structure.  The one Build Step I added to that page did not work after I modified the page structure.  I could probably fix that issue, but I'd bet there are 20 more issues waiting around the corner.

 

> After a few brief conversations with some of my colleagues at CloudBees
> (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most
> "doable" approach for now is to stick with making changes to what's
> there right now i.e. jelly templates, javascript and CSS.  We also
> talked (not in detail) about the possibility of working towards more
> modern technologies and approaches e.g. a Single Page App using the
> Jenkins REST API Vs the current server-side approach with Stapler and
> Jelly.  To do that now, however, seems a bit like trying to "boil the
> ocean" (quoting one of the guys there).  What do you guys think?

I guess it depends what the goal is.  If it's just "refreshing the UI",
then continuing with the changes so far and perhaps building on some of
the nice existing CSS themes out there would be reasonable, e.g.
https://github.com/Dakota628/jenkins-clean-theme

I like that a lot... maybe this is a starting point i.e. at least make Jenkins like a bit fresher.  I'm guessing this will not fix issues such as with the config page, but it's a good start.

 

But having seen a colleague of mine use the Jenkins API and AngularJS to
build some really nice (though narrowly focussed) Jenkins front-ends for
internal apps, dashboards and for customer use, I really like the idea
of building the Jenkins UI on top of its API.

As you may have seen, this is something Tyler did some work on during
FOSDEM last year.  The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y

Thanks for pointing me at this.  I'll ping Tyler and ask him to pitch in.  In some ways I feel that this might be the only real way to make meaningful usability changes to Jenkins.  Maybe we could replace parts of the UI with a SPA ... do it bit-by-bit.

[Tom Fennelly]

On Tuesday, May 27, 2014 7:29:54 AM UTC+1, Dominik Bartholdi wrote:

Glad to see others coming up with this topic again!

We have talked about this on many occasions and some work has been done in a separate branch too:

https://github.com/jenkinsci/jenkins/tree/ui-changes

In JIRA we also created a special component (ui-changes) to keep track of all this: https://issues.jenkins-ci.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+Jenkins+and+component+%3D+ui-changes&runQuery=true&clear=true

…but unfortunate all/most the effort which was put into any attempts of changing the UI of Jenkins has stopped at some point. I think the biggest problem really is to find a common agreement on anything - there is always someone who does not like it. 

I think there are quite a few technical "barriers" to making meaningful change the UI too.  This is inevitable, given the size and success of Jenkins.

 

Although I agree, the current implementation does its job and most of the people get a long with (maybe just because they have not seen anything else yet) - I absolutely think the look and feel is way off what a user can/does expect nowadays. In fact I know of a couple of teams which have chosen an other CI server then Jenkins just because of the UI (e.g. TeamCity) - I also think Jenkins has by far more capabilities then e.g. TeamCity, but not everyone needs the more advanced plugins/features/extensionpoints and these users can happily choose a nicer looking CI server (I would too).

+1

 

Also the fact that there are so many different approaches on changing the UI tells me that there is something we should improve. 

Some more examples

- https://github.com/rackerlabs/canon-jenkins

- https://github.com/djonsson/jenkins-atlassian-theme -> http://test.do/ (making Jenkins look like bamboo)

- http://isotope11.com/blog/styling-your-jenkins-continuous-integration-server

...

As a reference, there are also the notes we made about the discussions we had at another FOSDEM: https://wiki.jenkins-ci.org/display/JENKINS/UI+Enhancements

Great stuff... thanks Domi.

[Tom Fennelly]

Very nice.... thanks Stephen ;)

[Jeff King]

On 05/26/2014 11:10 PM, Michael Neale wrote:
> I have some experience doing fairly advanced UIs on top of the various
> APIs - they are quite powerful (other than, notably the config - where
> it is more of an xml blob) for doing a lot of things. This does feel a
> little "boil the ocean", and even if worthwhile, the non js based UI
> will be around for a long time yet, so it is probably worth putting a
> bit if work in to that to start with.

It'd be great if the main dashboard could be configured to pull UI
elements from the various jobs in the current view. Basically a mash-up
configurator.

For example, we have a build machine managing CI for three firmware
projects. Each firmware project has the following Jenkins jobs:
bootloader build, app build, app static analysis, app unit test,
integration test, release.

We have a view defined for each project, so it just shows the last job
status for those jobs associated with the particular project. But we
have to click through to "app unit test" to see the test history chart
and coverage graph, click through to "app static analysis" to see the
Coverity graph, etc.

It'd be really powerful for project management if there was a way to
configure the dashboard view to pull these charts and graphs from the
jobs pages and put them on the main page. A complete "project status at
a glance" as it were.

Of course, if there's already a plugin that does this I'd love to hear
about it!

[Jesse Glick]

On Mon, May 26, 2014 at 5:41 PM, Daniel Beck <m...@beckweb.net> wrote:
> It's possible to save forms with errors.

Probably fixable without fundamental changes. I swear I had this filed
in JIRA but I cannot find it now.

> Important UI elements are not available in the model-link context menu because they're not in the side panel (notably disable/enable project and mark slave offline/online).

I doubt those are so commonly used that they deserve space in the context menu.

> the global config requires changes (Jenkins URL, mail server, ...) or otherwise things won't work right.

I think these things should be admin warnings.

[Ioannis Moutsatsos]

We have been using Jenkins to build bioinformatic data and image processing and workflows and the current UI has been a big challenge!

None of the lab scientists using the Jenkins-based workflow tool is familiar with CI and Dev life cycle so hiding many of the Dev-centric UI elements and simplifying the interface would be a great improvement.

YES, the first element I would love to hide is the side bar menu, so I can leave enough space for the job submission form!

I'm following this discussion with great interest! If any of you are coming to the JUC 2014 Boston meeting in June, I would love to touch base and discuss this further.

Many thanks for the brave new world of Jenkins UI proposals out there!

best regards

--Ioannis--

[Tom Fennelly]

Thanks Ioannis.

This sounds like customisable roll-based views.  I'd imagine we'd need to put a lot in place before being able to do something like this but I do think we should keep this kind of use case in mind.  Interesting indeed.  Thanks !!

[Tom Fennelly]

On Tuesday, May 27, 2014 10:24:33 AM UTC+1, Tom Fennelly wrote:

On Monday, May 26, 2014 8:08:28 PM UTC+1, Christopher wrote:

As you may have seen, this is something Tyler did some work on during 

FOSDEM last year.  The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y

Thanks for pointing me at this.  I'll ping Tyler and ask him to pitch in.  In some ways I feel that this might be the only real way to make meaningful usability changes to Jenkins.  Maybe we could replace parts of the UI with a SPA ... do it bit-by-bit.

I pinged that thread again asking Tyler for his thoughts on the API.  To save you from linking there, here's what he said ...

The biggest challenge to the API work IMO is that it's currently not RESTful, 
and is quite difficult to make RESTful in a way that a Backbone collection can 
easily consume from. 

Part of the challenge is that Jenkins' datamodel is much more of a tree than 
most front-end toolkits are familiar with, but when you add added functionality 
from the plugins, modeling becomes extra tricky. 

I'm still of the opinion that a simple Backbone app + basic REST API exposing 
jobs, builds, basic details, would be more than enough for a large percentage 
of use-cases. Putting my code where my mouth is, isn't something I've had time 
for unfortunately. 

- R. Tyler Croy 

I get what Tyler means about the API but, for me, that does not mean we could not use it for a client-side app (including using it in SPA frameworks like backbone, angularjs etc).  Sure it would mean you can't use some of the niceness (e.g. REST $resource in angular etc).  I'd say we'd need to have a discussion about whether or not we should even use one of those frameworks in something like Jenkins.

 

[Kanstantsin Shautsou]

Some thoughts:

- Usually CMS has dropdown menu where user can choose theme that he likes

- https://github.com/Dakota628/jenkins-clean-theme has 62 forks where everybody changed something, some people found new icons http://colebemis.com/feather/. What about some gallery or separate update center for UI challenges? Based on download statistics you can define what merge to core jenkins.

[Surya Gaddipati]

We have been using 

https://github.com/kevinburke/doony 

on our jenkins installation. Just wanted to mention it.

[Kohsuke Kawaguchi]

Thanks for the list. This is great.

I notice that most of the things you wrote is about the config page.
Do you have similar list for other parts of the UI? I'd love to hear those.

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

[Kohsuke Kawaguchi]

Is it pretty close to the dashboard view plugin? Or is that missing what
you need?

[Kohsuke Kawaguchi]

On 05/26/2014 06:54 AM, Tom Fennelly wrote:
> 1. Jelly + Stapler are not the easiest to work with. At least I've

> found it quite difficult to figure out where to make changes.
> Sometimes it was obvious.... other times it was anything but e.g.
> tweaking the project config page to get Jelly to create a series of
> <table> elements (Vs one uber <table>). In the end... I found it
> easier to do it post-rendering via Javascript, which is not good imo.

> 2. What will be the effect on plugins of changing project config

> layout. I already see some strange behaviour e.g. I added an
> "Execute shell" build step... it works fine in the "uber
> <table>" layout, but is screwed up after I manipulate it - prob easy
> to fix, but still an indication that some of the plugins are
> sensitive to changes in their surroundings.
>

> 3. Use of <table> for layout seems to be quite popular Vs using <div> +
> CSS.

Let's work together on this --- getting rid of <table>s in favor of
<div>s. It sounds like that's a necessary step to enable other people to
do more aggressive experiments.

The config page layout is the most complex part of Jenkins views by far.
I think I can speed you up.

This is also an area where plugin config files are shielded from the raw
HTML tags through taglibs, and our control over the lower Jelly layer
allows us to do some backward compatibility magic if need be.

So I'm still somewhat optimistic about this. And if this exercise makes
me appreciate the problems in Stapler, that's good for me, too.

Can we schedule a two hour window (ideally your 5-7pm time which is my
9-11am time) that we do this in http://jenkins-ci.org/hangout? Perhaps
other people might be interested in chiming in.

> After a few brief conversations with some of my colleagues at CloudBees
> (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most
> "doable" approach for now is to stick with making changes to what's
> there right now i.e. jelly templates, javascript and CSS. We also
> talked (not in detail) about the possibility of working towards more
> modern technologies and approaches e.g. a Single Page App using the
> Jenkins REST API Vs the current server-side approach with Stapler and
> Jelly. To do that now, however, seems a bit like trying to "boil the
> ocean" (quoting one of the guys there). What do you guys think?
>
> So I hope there's an appetite/interest in this and I hope people will
> let us know where they would like to see this go (or not, as the case
> may be). And of course, if anyone is interested in getting involved in
> a "hands-on" way, then that would be even better :) I think the next
> steps are for me to gather peoples opinions and formulate an actionable
> plan that people can see and comment on if they want to.

One thing that's missing from the list in this thread so far is, more
dynamic content update in real time without page reloading. I think this
is one of the concrete feedbacks I hear when people talk about Jenkins UI.

For example, the list view should be updating itself all the time based
on what's going on.

[Jesse Glick]

On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> wrote:
> This is also an area where plugin config files are shielded from the raw
> HTML tags through taglibs

Well, only insofar as they choose to use those taglibs. In most cases
they do, but there are some places where plugins add raw <tr>s where
they expect to be inside a <table>.

> more dynamic content update in real time without page reloading.

It would be nice (especially if we can finally kill Auto Refresh!),
but you have to be very careful about the performance impact.
ajaxBuildQueue and ajaxExecutors already impose a significant burden
on the server when a lot of people are holding pages open. Anyone
proposing to add *more* AJAX stuff had better promise to fix the
performance of what is already there first. Being able to collapse
these widgets is fine but they are expanded by default and there is
currently no way to leave them expanded yet impose minimal overhead.

And the problem is that adding more dynamic updates in a modular way
(i.e., friendly to plugins) translates to a lot of separate HTTP
requests, and thus lots of overhead—unless you take care to define a
new API framework for “stuff that may be contributed by various
components and should be bundled in a periodic refresh when out of
date”, which is starting to sound like a crappy reimplementation of
Meteor.

[Stephen Connolly]

On 28 May 2014 21:37, Kohsuke Kawaguchi <kkawa...@cloudbees.com> wrote:

On 05/26/2014 06:54 AM, Tom Fennelly wrote:

 1. Jelly + Stapler are not the easiest to work with.  At least I've

    found it quite difficult to figure out where to make changes.
      Sometimes it was obvious.... other times it was anything but e.g.
    tweaking the project config page to get Jelly to create a series of
    <table> elements (Vs one uber <table>).  In the end... I found it
    easier to do it post-rendering via Javascript, which is not good imo.

 2. What will be the effect on plugins of changing project config

    layout.  I already see some strange behaviour e.g. I added an
    "Execute shell" build step... it works fine in the "uber
    <table>" layout, but is screwed up after I manipulate it - prob easy
    to fix, but still an indication that some of the plugins are
    sensitive to changes in their surroundings.

 3. Use of <table> for layout seems to be quite popular Vs using <div> +
    CSS.

Let's work together on this --- getting rid of <table>s in favor of <div>s. It sounds like that's a necessary step to enable other people to do more aggressive experiments.

The config page layout is the most complex part of Jenkins views by far. I think I can speed you up.

This is also an area where plugin config files are shielded from the raw HTML tags through taglibs, and our control over the lower Jelly layer allows us to do some backward compatibility magic if need be.

So I'm still somewhat optimistic about this. And if this exercise makes me appreciate the problems in Stapler, that's good for me, too.

Can we schedule a two hour window (ideally your 5-7pm time which is my 9-11am time) that we do this in http://jenkins-ci.org/hangout? Perhaps other people might be interested in chiming in.

Actually I was going to suggest that Tom head up to Dublin (where there is actual high speed broadband) and him and I spend a good chunk of that trying to refactor /lib/form to use divs rather than tables...

At the very least that would be helpful getting Tom up to speed.

If there is anyone else nearby I have no issues with turning it into a more open hacking session... though we might have to hunt a location to do the hacking from... similarly no objections to open it up as a hangout, though it would more be a shared hacking session as I would want to focus more on the task and unblocking Tom.

 

After a few brief conversations with some of my colleagues at CloudBees
(Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most
"doable" approach for now is to stick with making changes to what's
there right now i.e. jelly templates, javascript and CSS.  We also
talked (not in detail) about the possibility of working towards more
modern technologies and approaches e.g. a Single Page App using the
Jenkins REST API Vs the current server-side approach with Stapler and
Jelly.  To do that now, however, seems a bit like trying to "boil the
ocean" (quoting one of the guys there).  What do you guys think?

So I hope there's an appetite/interest in this and I hope people will
let us know where they would like to see this go (or not, as the case
may be).  And of course, if anyone is interested in getting involved in
a "hands-on" way, then that would be even better :)  I think the next
steps are for me to gather peoples opinions and formulate an actionable
plan that people can see and comment on if they want to.

One thing that's missing from the list in this thread so far is, more dynamic content update in real time without page reloading. I think this is one of the concrete feedbacks I hear when people talk about Jenkins UI.

For example, the list view should be updating itself all the time based on what's going on.

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

--
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-dev+unsubscribe@googlegroups.com.

[Kohsuke Kawaguchi]

On 05/28/2014 01:49 PM, Jesse Glick wrote:
> On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi
> <kkawa...@cloudbees.com> wrote:
>> This is also an area where plugin config files are shielded from the raw
>> HTML tags through taglibs
>
> Well, only insofar as they choose to use those taglibs. In most cases
> they do, but there are some places where plugins add raw <tr>s where
> they expect to be inside a <table>.

We'll check this with git-grep. I agree this is an issue, and I've done
this myself before, too, but I still think it's manageable --- by
combining (1) adding additional tags to let those plugins avoid the
direct <table> use , (2) intercepting HTML generation at a lower level
in Jelly to notice out-of-place table generation and correct it, and (3)
convincing ourselves that it's not the end of the world if we end up
breaking a few plugins given the need for changes like this.

>> more dynamic content update in real time without page reloading.
>
> It would be nice (especially if we can finally kill Auto Refresh!),
> but you have to be very careful about the performance impact.
> ajaxBuildQueue and ajaxExecutors already impose a significant burden
> on the server when a lot of people are holding pages open. Anyone
> proposing to add *more* AJAX stuff had better promise to fix the
> performance of what is already there first. Being able to collapse
> these widgets is fine but they are expanded by default and there is
> currently no way to leave them expanded yet impose minimal overhead.
>
> And the problem is that adding more dynamic updates in a modular way
> (i.e., friendly to plugins) translates to a lot of separate HTTP
> requests, and thus lots of overhead—unless you take care to define a
> new API framework for “stuff that may be contributed by various
> components and should be bundled in a periodic refresh when out of
> date”, which is starting to sound like a crappy reimplementation of
> Meteor.

I was mentally picturing WebSocket that allows various scripts inside a
page to subscribe to the events happening on the server. I also wanted
to build client-side representation of the model objects on the server
in the same form as the @Export-ed data model, and allow scripts to
declare the properties that they need through the tree path expression
we use in */api --- when the subscribed event actually happens the
client gets the model that it asked for.

So if one script wants jobs[displayName,url] and another wants
jobs[url,result], at runtime we can mechanically combine them to be
jobs[displayName,url,result] and that's what the client gets.

I don't know much about Meteor if this is starting to sound like one.

[Bruno P. Kinoshita]

It would be great if there were some standard Javascript objects or a common API to access UI elements too. Something like below:

<script type='text/javascript'>

JUI().use('parameters', function (Y) {

    var parameters = J.jobParameters(); // this could return all the parameters present in the UI if any

    ...

    var select = parameters[0];

    var remoteObject = <st:bind value="${it.getParametersProvider()}"/>

    select.setValue(remoteObject.getNewValues());

});

</script>

Sometime ago we wrote a plugin that supports updating based on other job parameters. For adding parameter types from other plugins we have to a) check whether they use the taglibs or custom HTML elements, b) provide ways to retrieve values and c) update the values in the UI. 

I think having some kind of Jenkins javascript variables or standard objects would help this kind of plug-in that relies heavily on the UI.

Thanks

Bruno

---

From: Jesse Glick <jgl...@cloudbees.com>
To: jenkin...@googlegroups.com
Sent: Wednesday, May 28, 2014 5:49 PM
Subject: Re: Refreshing the Jenkins UI

--
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-dev+unsub...@googlegroups.com.

[Kohsuke Kawaguchi]

On 05/28/2014 02:01 PM, Stephen Connolly wrote:
> Let's work together on this --- getting rid of <table>s in favor of
> <div>s. It sounds like that's a necessary step to enable other
> people to do more aggressive experiments.
>
> The config page layout is the most complex part of Jenkins views by
> far. I think I can speed you up.
>
> This is also an area where plugin config files are shielded from the
> raw HTML tags through taglibs, and our control over the lower Jelly
> layer allows us to do some backward compatibility magic if need be.
>
> So I'm still somewhat optimistic about this. And if this exercise
> makes me appreciate the problems in Stapler, that's good for me, too.
>
> Can we schedule a two hour window (ideally your 5-7pm time which is
> my 9-11am time) that we do this in http://jenkins-ci.org/hangout?
> Perhaps other people might be interested in chiming in.
>
>
> Actually I was going to suggest that Tom head up to Dublin (where there
> is actual high speed broadband) and him and I spend a good chunk of that
> trying to refactor /lib/form to use divs rather than tables...
>
> At the very least that would be helpful getting Tom up to speed.
>
> If there is anyone else nearby I have no issues with turning it into a
> more open hacking session... though we might have to hunt a location to
> do the hacking from... similarly no objections to open it up as a
> hangout, though it would more be a shared hacking session as I would
> want to focus more on the task and unblocking Tom.

That works for me.

[Tom Fennelly]

Works for me too. What day would suit? Stephen.... remember it's June
BH weekend here this weekend.

[Stephen Connolly]

Oh I had not forgotten... will need to check with herself... if sooner is better I'd say Tue/Wed/Thur are options

[Tom Fennelly]

Yeah, I think some form of push notification via something like
websockets/sockjs/comet is more appropriate than frequent polling...
lower load + better ux

[Tom Fennelly]

On 28/05/2014 19:39, Surya Gaddipati wrote:
> We have been using
>
> https://github.com/kevinburke/doony
>
> on our jenkins installation. Just wanted to mention it.
>

Nice one... thanks for telling us this.

[Jesse Glick]

On Wed, May 28, 2014 at 5:09 PM, 'Bruno P. Kinoshita' via Jenkins
Developers <jenkin...@googlegroups.com> wrote:
> var remoteObject = <st:bind value="${it.getParametersProvider()}"/>

Also be careful with st:bind. Currently it leaks memory whenever used
(unless you can use WithWellKnownURL, and until the HTTP session
expires). Which only matters a little in a configuration form, which
people only occasionally open, but which would be terrible in
something like a job list view.

[Michael Neale]

Do you mean the meteor framework or the "comet" long poll convention?

--
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/zDaX4yiWLLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

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

--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com

[Michael Neale]

It is interesting to see the diversity of uses. I think in this case, you would want the ability to turn of vast chunks of things (along with all the other good changes suggested) for your users (I probably would have given in and created a bespoke js app for this by this point - talking to the job api, but then that is one more thing you have to maintain)

On Wednesday, May 28, 2014, Ioannis Moutsatsos <imout...@gmail.com> wrote:

We have been using Jenkins to build bioinformatic data and image processing and workflows and the current UI has been a big challenge!

None of the lab scientists using the Jenkins-based workflow tool is familiar with CI and Dev life cycle so hiding many of the Dev-centric UI elements and simplifying the interface would be a great improvement.

YES, the first element I would love to hide is the side bar menu, so I can leave enough space for the job submission form!

[Christopher Orr]

On 05/28/2014 11:07 PM, Kohsuke Kawaguchi wrote:
> On 05/28/2014 01:49 PM, Jesse Glick wrote:
>> On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi
>> <kkawa...@cloudbees.com> wrote:
>> And the problem is that adding more dynamic updates in a modular way
>> (i.e., friendly to plugins) translates to a lot of separate HTTP
>> requests, and thus lots of overhead—unless you take care to define a
>> new API framework for “stuff that may be contributed by various
>> components and should be bundled in a periodic refresh when out of
>> date”, which is starting to sound like a crappy reimplementation of
>> Meteor.
>
> I was mentally picturing WebSocket that allows various scripts inside a
> page to subscribe to the events happening on the server. I also wanted
> to build client-side representation of the model objects on the server
> in the same form as the @Export-ed data model, and allow scripts to
> declare the properties that they need through the tree path expression
> we use in */api --- when the subscribed event actually happens the
> client gets the model that it asked for.

It may also be worth considering Server Sent Events — basically one-way
"push" from the server, without all the handshaking and protocol upgrade
fun of WebSockets. Could be useful if clients are just listening for
server updates, without sending anything (as is generally the case today).

Last week I wrote a quick experimental plugin to stream log events as
they happen via SSE to remote JavaScript clients for any running build;
I was surprised how simple it was to build..

(Though I just noticed that it has less support than WebSockets (thanks,
Microsoft): http://caniuse.com/eventsource)

Chris

[Michael Neale]

On Thu, May 29, 2014 at 11:33 AM, Christopher Orr <ch...@orr.me.uk> wrote:

It may also be worth considering Server Sent Events — basically one-way "push" from the server, without all the handshaking and protocol upgrade fun of WebSockets.  Could be useful if clients are just listening for server updates, without sending anything (as is generally the case today).

Last week I wrote a quick experimental plugin to stream log events as they happen via SSE to remote JavaScript clients for any running build; I was surprised how simple it was to build..

(Though I just noticed that it has less support than WebSockets (thanks, Microsoft): http://caniuse.com/eventsource)

Chris

+1 on SSE. I have a fair bit of experience with websockets on servers - enough to know that almost no one gets their proxies right - and it is a source of complaints. SSE seems to work better out of the box, alternatively long polling/comet can also work (a given jenkins master doesn't have to scale to 10s of thousands concurrent users, which is the assumption for a lot of other web choices). 

Having said that, nearly halfway through 2014 websockets is probably not a controversial choice and does open up a lot of other options. If someone is accessing their jenkins via a proxy, ssl and careful configuration is required to support http upgrade and not break websocket too.  

[Tom Fennelly]

AFAIK... any proxy/gateway between the websocket client and server needs to be pretty much websocket aware.  SSE would seem like a perfect fit for Jenkins since the client is listening only (not sending back to the server - could implement that on top anyway if needed).  As far as I know SSE is a fancy long poll/comet style protocol and so would require the same considerations re number of concurrent users.

[Michael Neale]

On Thu, May 29, 2014 at 5:26 PM, Tom Fennelly <tom.fe...@gmail.com> wrote:

AFAIK... any proxy/gateway between the websocket client and server needs to be pretty much websocket aware.  SSE would seem like a perfect fit for Jenkins since the client is listening only (not sending back to the server - could implement that on top anyway if needed).  As far as I know SSE is a fancy long poll/comet style protocol and so would require the same considerations re number of concurrent users.

--

Happy to be proven wrong but I expect that even for the heaviest users of jenkins (masters) - the number of concurrent users couldn't be more than in the hundreds - mostly that will work without any web framework contortions (happy to be proven wrong). 

The biggest risk for websocket, as I see it, is the temptation to built in a real time chat client, and perhaps webrtc video conferencing (you broke the build - someone can instantly berate you via webrtc video feed). Terrible idea forget I said it ;)

 

[Tom Fennelly]

On 29/05/2014 09:01, Michael Neale wrote:

On Thu, May 29, 2014 at 5:26 PM, Tom Fennelly <tom.fe...@gmail.com> wrote:

AFAIK... any proxy/gateway between the websocket client and server needs to be pretty much websocket aware.  SSE would seem like a perfect fit for Jenkins since the client is listening only (not sending back to the server - could implement that on top anyway if needed).  As far as I know SSE is a fancy long poll/comet style protocol and so would require the same considerations re number of concurrent users.

--

Happy to be proven wrong but I expect that even for the heaviest users of jenkins (masters) - the number of concurrent users couldn't be more than in the hundreds - mostly that will work without any web framework contortions (happy to be proven wrong).

I'd say you're spot on.

The biggest risk for websocket, as I see it, is the temptation to built in a real time chat client, and perhaps webrtc video conferencing (you broke the build - someone can instantly berate you via webrtc video feed). Terrible idea forget I said it ;)

Sounds like a great idea to me ;)

[teilo]

Just so people are aware IE has no support for SSE[1].

IE is still commonly used in enterprises despite it many and continuous flaws.

So far Jenkins has been pretty browser agnostic.

/James

[1] http://status.modern.ie/serversenteventseventsource

[Michael Neale]

SSE as a concept logically falls back to long polling quite reasonably (websocket is not as easy to abstract, but plenty of libraries do it). 

The main idea is that with SSE it is a backchannel - you use regular URLs (and maybe things like rest) from client -> server, and for getting data - but you have a backchannel for server to realiably tell client that something has changed (message payload may or may not contain the change, client usually will sync). Google wave (ha, anyone remember that?) made use of this (within limits) in a somewhat pre-websocket era. 

Also - IE ruining the party yet again (yes, it is a fact of life, agree. IE 11 still doesn't have SSE). 

[Kevin Burke]

Hi! I am the author of Doony, a skin on top of Jenkins that's been downloaded/used by developers at EBay, Instagram, Netflix, the BBC, Panic, and other web companies, and starred by over 600 developers on Github. We also use it extensively at Twilio, where I worked until very recently.

Here are the problems I set out to solve with Doony:

- Jenkins by default has small click targets, for forms, buttons, and links.. Per Fitts Law, small click targets take longer to locate with the mouse and make the UI seem more frustrating. In addition some users with poor eyesight or motor control have difficulty with reading/selecting small text. I made the buttons and links much bigger, and added padding around links so a mis-click (or tap, on a iPhone) would probably still take you where you wanted to go. 

- The most common actions were not easily available. Specifically, 1) from a job's homepage, I wanted to view the console output of the latest build, and 2) I wanted to be able to trigger new builds from any page on a job.

- Various small UI changes - I felt that a lot of the icons (weather metaphors etc) did not add much value so I killed them, and the console could benefit from looking more like a console.

Here are the most frustrating problems I ran into:

- When writing a theme, it's difficult to select elements with CSS. For example, here's the rule I'm using to style the "Console Output" - hopefully nothing else in pre-1.538 Jenkins uses pre tags: https://github.com/kevinburke/doony/blob/master/src/doony.scss#L649. The bottom line is, if it's easier to select elements/skin, it's easier to get more experiments in UI and more data about what works and what doesn't. 

      NB: This has gotten better, and I've also submitted some PR's to add classes/ID's to make theming easier - see https://github.com/jenkinsci/jenkins/pulls/kevinburke?direction=desc&page=1&sort=created&state=closed.

- Some things don't have API's. For example, creating a new build doesn't return the build number, so you need to GET the job list to get the current build number and just hope the build you created will be the next one. See for example https://github.com/kevinburke/doony/blob/master/src/theme.js#L274. Similarly, there's no API for retrieving the console output. There's no API for retrieving global settings, which would be really nice and allow people to set items like the text in the title bar, or the theme's colors, or any number of things. At Twilio we routinely wrote Python scripts that simulate UI requests to trigger builds etc.

Basically with a UI, my guiding principle is make the things you do the most often the most visible, and the job homepage and the sidebar aren't great at this currently. I know people use Jenkins in a lot of different ways, but some user studies or testing could probably reveal the two or three most frequent use cases, and then the job page / instance page could be designed around those. One big win I think would be to move the console output right onto the homepage.

Finally, a few notes about specific points in this thread.

- I'm not sure about bundling websockets/a single page app with a UI redesign, for a few reasons. For one, it sounds like several large UI rewrites have failed in the past, which suggests that small, incremental changes might have a better chance of succeeding than a single bundle updating a whole lot of things. For example, one week you make the forms have round corners, add 10px padding between them and and a size 14 font, the next week you make the buttons bigger, the next week you add an API for global settings, etc. There's a lot that can be done to improve the UI/usability without necessarily making people upset.

    Second, I use Travis CI for building most of my Github projects, but one of my biggest frustrations with it is its occasional ability to pin a CPU, render a completely blank page, render nonsense, become unresponsive, etc. Travis CI is a single-page app. The failure modes of Javascript are legion, especially for people on flaky connections, and maybe not as well understood as the combination of HTML/CSS/occasional AJAX requests, for developers. Jenkins' reliability in delivering a UI should be considered a core strength.

- I didn't have too many problems with Jelly, despite never using it before. However, I did mistakenly edit one template and assume my job was done, when in fact I needed to edit an additional template to make the changes I wanted. The current level of abstraction makes things a little difficult :) Perhaps a smaller number of larger files would be easier to edit. 

- I also have not had too many problems with content not updating dynamically; it does so in the places where I expect it to (console output, triggering builds, though maybe not as quickly as I would like).

Thanks,

Kevin

PS: If someone from Cloudbees would be interested in helping me get a Doony demo running fulltime on Cloudbees, I would be very grateful. 

[Tom Fennelly]

On 29/05/2014 17:51, Kevin Burke wrote:

Hi! I am the author of Doony, a skin on top of Jenkins that's been downloaded/used by developers at EBay, Instagram, Netflix, the BBC, Panic, and other web companies, and starred by over 600 developers on Github. We also use it extensively at Twilio, where I worked until very recently.

Here are the problems I set out to solve with Doony:

- Jenkins by default has small click targets, for forms, buttons, and links.. Per Fitts Law, small click targets take longer to locate with the mouse and make the UI seem more frustrating. In addition some users with poor eyesight or motor control have difficulty with reading/selecting small text. I made the buttons and links much bigger, and added padding around links so a mis-click (or tap, on a iPhone) would probably still take you where you wanted to go. 

- The most common actions were not easily available. Specifically, 1) from a job's homepage, I wanted to view the console output of the latest build, and 2) I wanted to be able to trigger new builds from any page on a job.

- Various small UI changes - I felt that a lot of the icons (weather metaphors etc) did not add much value so I killed them, and the console could benefit from looking more like a console.

Here are the most frustrating problems I ran into:

- When writing a theme, it's difficult to select elements with CSS. For example, here's the rule I'm using to style the "Console Output" - hopefully nothing else in pre-1.538 Jenkins uses pre tags: https://github.com/kevinburke/doony/blob/master/src/doony.scss#L649. The bottom line is, if it's easier to select elements/skin, it's easier to get more experiments in UI and more data about what works and what doesn't. 

      NB: This has gotten better, and I've also submitted some PR's to add classes/ID's to make theming easier - see https://github.com/jenkinsci/jenkins/pulls/kevinburke?direction=desc&page=1&sort=created&state=closed.

- Some things don't have API's. For example, creating a new build doesn't return the build number, so you need to GET the job list to get the current build number and just hope the build you created will be the next one. See for example https://github.com/kevinburke/doony/blob/master/src/theme.js#L274. Similarly, there's no API for retrieving the console output. There's no API for retrieving global settings, which would be really nice and allow people to set items like the text in the title bar, or the theme's colors, or any number of things. At Twilio we routinely wrote Python scripts that simulate UI requests to trigger builds etc.

Basically with a UI, my guiding principle is make the things you do the most often the most visible, and the job homepage and the sidebar aren't great at this currently. I know people use Jenkins in a lot of different ways, but some user studies or testing could probably reveal the two or three most frequent use cases, and then the job page / instance page could be designed around those. One big win I think would be to move the console output right onto the homepage.

Finally, a few notes about specific points in this thread.

- I'm not sure about bundling websockets/a single page app with a UI redesign, for a few reasons. For one, it sounds like several large UI rewrites have failed in the past, which suggests that small, incremental changes might have a better chance of succeeding than a single bundle updating a whole lot of things. For example, one week you make the forms have round corners, add 10px padding between them and and a size 14 font, the next week you make the buttons bigger, the next week you add an API for global settings, etc. There's a lot that can be done to improve the UI/usability without necessarily making people upset.

    Second, I use Travis CI for building most of my Github projects, but one of my biggest frustrations with it is its occasional ability to pin a CPU, render a completely blank page, render nonsense, become unresponsive, etc. Travis CI is a single-page app. The failure modes of Javascript are legion, especially for people on flaky connections, and maybe not as well understood as the combination of HTML/CSS/occasional AJAX requests, for developers. Jenkins' reliability in delivering a UI should be considered a core strength.

- I didn't have too many problems with Jelly, despite never using it before. However, I did mistakenly edit one template and assume my job was done, when in fact I needed to edit an additional template to make the changes I wanted. The current level of abstraction makes things a little difficult :) Perhaps a smaller number of larger files would be easier to edit. 

- I also have not had too many problems with content not updating dynamically; it does so in the places where I expect it to (console output, triggering builds, though maybe not as quickly as I would like).

Thanks,

Kevin

PS: If someone from Cloudbees would be interested in helping me get a Doony demo running fulltime on Cloudbees, I would be very grateful.

Kevin, thanks for this.  This is really great information and advise.  I think you are totally on the money.  Kohsuke made the same comment about the possible reasons why other bigger efforts were not as successful as hoped and that small incremental improvements might having a better chance of success.  Makes sense, considering the rate at which the Jenkins codebase is evolving.

[Daniel Beck]

On 29.05.2014, at 18:51, Kevin Burke <kbur...@gmail.com> wrote:

> - The most common actions were not easily available. Specifically, 1) from a job's homepage, I wanted to view the console output of the latest build, and 2) I wanted to be able to trigger new builds from any page on a job.

This is easy to add in a plugin. Not saying this is a bad idea, but as users have different needs, this is probably best left to customization IMO; especially as it is much easier added than removed! Right now, you just need to open a -- admittedly difficult to open -- context menu (build list entry and breadcrumb, respectively) to do either, so it's not like it requires navigating away.

> - Some things don't have API's. For example, creating a new build doesn't return the build number, so you need to GET the job list to get the current build number and just hope the build you created will be the next one. See for example https://github.com/kevinburke/doony/blob/master/src/theme.js#L274.

Well, at that time, there's no build number assigned yet, so it cannot be returned (it does return the queue item that will eventually tell you the resulting build). I elaborated on this in a comment in Jira, with API usage instructions:
https://issues.jenkins-ci.org/browse/JENKINS-12827?focusedCommentId=201381&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-201381

> Similarly, there's no API for retrieving the console output.

/job/foo/42/consoleText returns the full log output (unless the build still runs, when it only returns the first 10k lines IIRC). .../progressiveText returns an arbitrary chunk specified by the ?start=<offset> parameter. It sets headers with length printed and whether there's more. Can't you use these?

[Tom Fennelly]

Hi guys.

As Kohsuke suggested, it would be a good idea for as many of us as possible to hook up on google hangout to have a chat about this, maybe do some hacking and bounce some ideas around.  I'm aware there's a Jenkins Office Hours, but maybe it would be better to have a dedicated session to focus on this.

I created a doodle in an effort to find out who's interested in jumping into a chat + possible times we could do it.  Hopefully people can join: http://doodle.com/uge3rz5n3ias5ceq

[Kohsuke Kawaguchi]

Thanks. This is very insightful.

On 05/29/2014 09:51 AM, Kevin Burke wrote:
> - Some things don't have API's. For example, *creating a new build
> doesn't return the build number*, so you need to GET the job list to get

> the current build number and just hope the build you created will be the
> next one. See for example
> https://github.com/kevinburke/doony/blob/master/src/theme.js#L274.

This is because Jenkins doesn't yet assign a build number while the task
is in the queue.

In recent version of Jenkins, hitting the .../build URL returns 200 with
Location header pointing to the URL of the item in the queue. The caller
can track that queue item and resolve it to the URL of the build when it
actually starts. I should document this better.

> Similarly, there's no API for retrieving the console output. There's no
> API for retrieving global settings, which would be really nice and allow
> people to set items like the text in the title bar, or the theme's
> colors, or any number of things. At Twilio we routinely wrote Python
> scripts that simulate UI requests to trigger builds etc.

I'm not quite following the part about exposing global settings (Jenkins
does appear to have http://localhost:8080/jenkins/config.xml exposed if
you have sufficient permissions), but if you are thinking about
configurable theme colors and etc, sounds like you'd be writing a
Jenkins plugin, so that can expose the data in any way it sees fit.

Alternatively, you can ask the admin to place something in
$JENKINS_HOME/userContent and that can be seen from clients (see
https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins)


> Basically with a UI, my guiding principle is *make the things you do the
> most often the most visible*, and the job homepage and the sidebar

> aren't great at this currently. I know people use Jenkins in a lot of
> different ways, but some user studies or testing could probably reveal
> the two or three most frequent use cases, and then the job page /
> instance page could be designed around those. One big win I think would
> be to move the console output right onto the homepage.

OK, we can do this. Let's do this.

> Finally, a few notes about specific points in this thread.
>
> - I'm not sure about bundling websockets/a single page app with a UI
> redesign, for a few reasons. For one, it sounds like several large UI
> rewrites have failed in the past, which suggests that small, incremental
> changes might have a better chance of succeeding than a single bundle
> updating a whole lot of things. For example, one week you make the forms
> have round corners, add 10px padding between them and and a size 14
> font, the next week you make the buttons bigger, the next week you add
> an API for global settings, etc. There's a lot that can be done to
> improve the UI/usability without necessarily making people upset.

+1. Exactly.

(At the same time I'd still also love to see an experimentation to build
a new subsystem / a part of Jenkins built in more "modern" API-first
manner. I think we'll learn a lot from that.)

> Second, I use Travis CI for building most of my Github projects,
> but one of my biggest frustrations with it is its occasional ability to
> pin a CPU, render a completely blank page, render nonsense, become
> unresponsive, etc. Travis CI is a single-page app. The failure modes of
> Javascript are legion, especially for people on flaky connections, and
> maybe not as well understood as the combination of HTML/CSS/occasional

> AJAX requests, for developers. *Jenkins' reliability in delivering a UI
> should be considered a core strength.*

>
> - I didn't have too many problems with Jelly, despite never using it
> before. However, I did mistakenly edit one template and assume my job
> was done, when in fact I needed to edit an additional template to make
> the changes I wanted.

> <https://github.com/jenkinsci/jenkins/pull/1100/files> The current level

> of abstraction makes things a little difficult :) Perhaps a smaller
> number of larger files would be easier to edit.
>
> - I also have not had too many problems with content not updating
> dynamically; it does so in the places where I expect it to (console
> output, triggering builds, though maybe not as quickly as I would like).

One that I've heard and felt myself is the list view, and the orb that
represents the status. A number of people I've worked with in the
Jenkins training course I taught expected the flashing ball to become
solid as soon as the build is done.

(But then I see that you got rid of that bouncy ball completely, so
perhaps that's a non-issue to you)

[Kohsuke Kawaguchi]

Perhaps I should have mentioned it more explicitly, but I was only
thinking about using it to do updates after the initial page load, with
most of the server-side initial HTML rendering intact.

So when WebSocket/SSE/etc does not work, all you lose is the dynamic
update, which I think is acceptable loss.

> --
> 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
> <mailto:jenkinsci-de...@googlegroups.com>.

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

[Michael Neale]

On Friday, May 30, 2014 2:51:15 AM UTC+10, Kevin Burke wrote:

Hi! I am the author of Doony, a skin on top of Jenkins that's been downloaded/used by developers at EBay, Instagram, Netflix, the BBC, Panic, and other web companies, and starred by over 600 developers on Github. We also use it extensively at Twilio, where I worked until very recently.

Nice work! that is pretty solid endorsement. I quite like this - this tackles a few pretty common annoyances in a non controversial way. I think this, along with some of the other themes that tom has talked about could be a great starting point. 

I have tried this locally and on DEV@cloud - it seems to work - not sure if it is the version, but there are some odd variations of font sizes on a given page (easy fixed though, maybe is my eyes!). I really like it! Things are far more clickable, and the console 100x more first class and visible.

If anything, I would say that taking it a tiny bit further - using some slight background shades like the other examples work, would mean that the tables/borders could be relaxed. This makes it even clearer what is clickable and more "console like", for example: https://camo.githubusercontent.com/d7600a483eb5ee599cd9d842bcbad3eea3b66b91/687474703a2f2f692e696d6775722e636f6d2f4257683555304c2e706e67 - the clickable and information bits are less crowded by lines grouping them as the background does the job splitting things up. 

Really impressive stuff, I like how much thought was put into it. 

 

    Second, I use Travis CI for building most of my Github projects, but one of my biggest frustrations with it is its occasional ability to pin a CPU, render a completely blank page, render nonsense, become unresponsive, etc. Travis CI is a single-page app. The failure modes of Javascript are legion, especially for people on flaky connections, and maybe not as well understood as the combination of HTML/CSS/occasional AJAX requests, for developers. Jenkins' reliability in delivering a UI should be considered a core strength.

Never thought of that, but that is a good point. I suspect a parallel REST/SPA app will probably go on, but for now, I think this is a great (probably best) place to start?

 

PS: If someone from Cloudbees would be interested in helping me get a Doony demo running fulltime on Cloudbees, I would be very grateful. 

I can help - I set it up on one of my test accounts (theme/jquery plugin isn't enabled by default). Perhaps we could setup an OSS project to show it off. It doesnt' interact perfectly with DEV@cloud jenkins as it has its own css/js going on for the toolbar, so perhaps it isn't the best way to showcase it? 

 

[Kohsuke Kawaguchi]

To use any of those async servlet features, we need Servlet 3.0, but it turns out that the servlet spec has designed this feature in such a way that webapp would have to opt into this support through web.xml.

Unfortunately, what this means is that if we want to start using servlet 3.0 functionality, we'd have to leave behind people who are running earlier versions of the container. There's no graceful fallback that works with servlet 2.5 containers.

Now, servlet 3.0 came out in 2009, and in 1.535 Jenkins moved to Jetty-8 based Winstone 2.x that supports servlet 3.0, so we'd think good portion of the user base is already running on compatible servlet container. But I decided to look into this anyway.

Many users run Jenkins through "java -jar jenkins.war", we expect that users of more recent Jenkins versions will likely run servlet 3 compatible container.

When I look at people who are running >=1.509 and later, 70% of them run on servlet 3 compatible container. The number for >=1.532 is 84%, then for >=1.554 it's 94%.

When I look at which container is dragging us down as of >= 1.554, you see that there's a sizable Tomcat6 deployments (2.5%). If we start requiring Servlet 3.0 these people will be in a nasty surprise. Then there's about 1.8% who claims to be running on Winstone 0.9.10, which is really puzzling, but I'm assuming these people are getting OEM-ed Jenkins of a sort (multiple large companies are known to do this), so these people will likely be able to update to Winstone 2.x automatically by virtue of getting a new jenkins.war from their upstream.

So all in all I'd say if we start requiring Servlet 3.0 today, there'll be about 3% user base who will be impacted, which IMHO is acceptable loss to move forward.

The results are in https://docs.google.com/spreadsheets/d/14YzFgKBB6BvbRU_1OjChC3efECWPs77TEGTU09t3KGw/edit#gid=873989456

Note that the spreadsheet only lists 20 or so most common containers. The total number does include the entire long tail (which amounts to less than 1%), so the estimate errs on the slightly conservative side.

an email to jenkinsci-dev+unsubscribe@googlegroups.com

<mailto:jenkinsci-dev+unsub...@googlegroups.com>.

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

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

--
Kohsuke Kawaguchi

[Stephen Connolly]

I'd put that decision on the agenda for the next meeting.

I'd also recommend pinging the users's list for feedback... there could be a large number of tomcat 6 people behind firewalls preventing the ping-back... now if they are not engaged with the users list... well let's do all we can to see if we can move forward with this

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

[Tom Fennelly]

On 30/05/2014 07:06, Michael Neale wrote:

On Friday, May 30, 2014 2:51:15 AM UTC+10, Kevin Burke wrote:

    Second, I use Travis CI for building most of my Github projects, but one of my biggest frustrations with it is its occasional ability to pin a CPU, render a completely blank page, render nonsense, become unresponsive, etc. Travis CI is a single-page app. The failure modes of Javascript are legion, especially for people on flaky connections, and maybe not as well understood as the combination of HTML/CSS/occasional AJAX requests, for developers. Jenkins' reliability in delivering a UI should be considered a core strength.

Never thought of that, but that is a good point. I suspect a parallel REST/SPA app will probably go on, but for now, I think this is a great (probably best) place to start?

 

It's a great point indeed and one of the main things I have learned from this thread i.e. move it forward incrementally + be very careful not to throw out the baby with the bathwater !!

I'd love to see us bring Kevin at al's Doony work back into Jenkins.  If the community (and Kevin) were agreeable to that, I'd be more than happy to work on it.  I guess we'd need to audit the changes made in Donny and work out any licensing issues if there are any.

[Surya Gaddipati]

I'd love to see us bring Kevin at al's Doony work back into Jenkins.  If the community (and Kevin) were agreeable to that, I'd be more than happy to work on it.  I guess we'd need to audit the changes made in Donny and work out any licensing issues if there are any.

I definitely think this great idea. Devs at organization absolutely love doony theme, we had to make minor changes like swapping out red/green icons because color blind people were having hard time distinguishing between them.  But overall it has been great. 

Since most of the time people spend most of their time in jenkins looking at console output, It would be nice to give it a little facelift by 

  1. Adding linkable line numbers like this 

https://travis-ci.org/cjdrake/pyeda#L62

  2. Foldable sections, this plugin achieves this somewhat but it leaves a lot to be desired 

https://wiki.jenkins-ci.org/display/JENKINS/Collapsing+Console+Sections+Plugin 

  3. Colors in console, something like this

 https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin

All of out projects manage their configuration through .ci.yml files so we dont usually run into usability issues with configure page.

- Surya

On Monday, May 26, 2014 8:54:21 AM UTC-5, Tom Fennelly wrote:

Hi guys.

I've just started looking into ways in which we can "refresh" the look and feel of the Jenkins UI, as well as looking at tackling some of the main usability issues.  I've really only started, but have committed a small bit of code to a branch on github at https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:

1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
   
2. Modified the main project/job configuration page, in an effort to make it less cluttered, by adding accordions for the different config sections.  The only way I found I could do this was to wire in some javascript to manipulate the page post-rendering.  Kohsuke says there's a way of doing the bulk of the DOM manipulation within Jelly templates, but I failed to work that one out yet - I'm sure it will be "obvious" after I see it :)  Not sure if accordions are the correct choice.  Here's a screenshot of what it looks like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

The above commit obviously breaks things e.g. the breadcrumbs + some of the styling is screwed up (I added Twitter bootstrap, causing the css's to clash).  What I've done so far is really just hacking to see what we could do.  I'm keen to hear the opinions of the community... what people thing we should concentrate on... what should we avoid... what are the risks etc etc.  I'm aware there is some prior art in this area e.g. OHTAKE Tomohiro's work, the Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:

1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
4. New more "modern" icons?

After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

So I hope there's an appetite/interest in this and I hope people will let us know where they would like to see this go (or not, as the case may be).  And of course, if anyone is interested in getting involved in a "hands-on" way, then that would be even better :)  I think the next steps are for me to gather peoples opinions and formulate an actionable plan that people can see and comment on if they want to.

Regards,

Tom.

[Stephen Connolly]

On Friday, 30 May 2014, Surya Gaddipati <suryap...@gmail.com> wrote:

I'd love to see us bring Kevin at al's Doony work back into Jenkins.  If the community (and Kevin) were agreeable to that, I'd be more than happy to work on it.  I guess we'd need to audit the changes made in Donny and work out any licensing issues if there are any.

I definitely think this great idea. Devs at organization absolutely love doony theme, we had to make minor changes like swapping out red/green icons because color blind people were having hard time distinguishing between them.  

Yeah it's surprising the number of people who get bitten by colour blind requirements... As my first paying gig was for a colour blind person (interesting to note that Lloyd as a surname means "grey" and colourblindness is hereditary on the male line) I always try to ensure that there is more than a colour change in icons that indicate state (for example in the CloudBees RBAC plugin the icons for regular roles vs pinned roles don't just have a different colour but gain a paper clip for the pinned role so that colour blind people have more clues to work with)

(Oh and colour blind friendly colour schemes designed by colour blind people look awful... But a feature letting them customise the colour scheme is really appreciated)

Colour blindness is not just red-green.

But overall it has been great. 

Since most of the time people spend most of their time in jenkins looking at console output, It would be nice to give it a little facelift by 

  1. Adding linkable line numbers like this 

https://travis-ci.org/cjdrake/pyeda#L62

  2. Foldable sections, this plugin achieves this somewhat but it leaves a lot to be desired 

https://wiki.jenkins-ci.org/display/JENKINS/Collapsing+Console+Sections+Plugin 

  3. Colors in console, something like this

 https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin

All of out projects manage their configuration through .ci.yml files so we dont usually run into usability issues with configure page.

- Surya

On Monday, May 26, 2014 8:54:21 AM UTC-5, Tom Fennelly wrote:

Hi guys.

I've just started looking into ways in which we can "refresh" the look and feel of the Jenkins UI, as well as looking at tackling some of the main usability issues.  I've really only started, but have committed a small bit of code to a branch on github at https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:

1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
   
2. Modified the main project/job configuration page, in an effort to make it less cluttered, by adding accordions for the different config sections.  The only way I found I could do this was to wire in some javascript to manipulate the page post-rendering.  Kohsuke says there's a way of doing the bulk of the DOM manipulation within Jelly templates, but I failed to work that one out yet - I'm sure it will be "obvious" after I see it :)  Not sure if accordions are the correct choice.  Here's a screenshot of what it looks like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

The above commit obviously breaks things e.g. the breadcrumbs + some of the styling is screwed up (I added Twitter bootstrap, causing the css's to clash).  What I've done so far is really just hacking to see what we could do.  I'm keen to hear the opinions of the community... what people thing we should concentrate on... what should we avoid... what are the risks etc etc.  I'm aware there is some prior art in this area e.g. OHTAKE Tomohiro's work, the Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:

1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
4. New more "modern" icons?

After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

So I hope there's an appetite/interest in this and I hope people will let us know where they would like to see this go (or not, as the case may be).  And of course, if anyone is interested in getting involved in a "hands-on" way, then that would be even better :)  I think the next steps are f

--

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.

--
Sent from my phone

[Michael Neale]

On Saturday, May 31, 2014 7:38:25 AM UTC+10, Surya Gaddipati wrote:

All of out projects manage their configuration through .ci.yml files so we dont usually run into usability issues with configure page.

I like that solution to the config page problem: don't have a config page problem! (obviously not suitable for everyone but a great example of a problem that in some cases can just naturally go away). 

 

[Kevin Burke]

On Fri, May 30, 2014 at 2:38 PM, Surya Gaddipati <suryap...@gmail.com> wrote:

  2. Foldable sections, this plugin achieves this somewhat but it leaves a lot to be desired 

https://wiki.jenkins-ci.org/display/JENKINS/Collapsing+Console+Sections+Plugin 

  3. Colors in console, something like this

 https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin

+1 to both of these; was thinking a lot recently about how to define metadata in console output to allow for automatic section folding, as well as coloring, though maybe this isn't the right list for that.

--

Kevin Burke | Claremont McKenna

phone: 925.271.7005 | kburke.org

[Tom Fennelly]

On 30/05/2014 22:38, Surya Gaddipati wrote:

I'd love to see us bring Kevin at al's Doony work back into Jenkins.  If the community (and Kevin) were agreeable to that, I'd be more than happy to work on it.  I guess we'd need to audit the changes made in Donny and work out any licensing issues if there are any.

I definitely think this great idea. Devs at organization absolutely love doony theme, we had to make minor changes like swapping out red/green icons because color blind people were having hard time distinguishing between them.  But overall it has been great. 

Since most of the time people spend most of their time in jenkins looking at console output, It would be nice to give it a little facelift by 

  1. Adding linkable line numbers like this 

https://travis-ci.org/cjdrake/pyeda#L62

  2. Foldable sections, this plugin achieves this somewhat but it leaves a lot to be desired 

https://wiki.jenkins-ci.org/display/JENKINS/Collapsing+Console+Sections+Plugin 

  3. Colors in console, something like this

 https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin

All of out projects manage their configuration through .ci.yml files so we dont usually run into usability issues with configure page.

- Surya

That sounds great Surya.  As suggested by others, I think it would be a good idea to bite off smaller chunks where we can so as to make progress.  So, maybe we could start by adding Doony and then look at making some of the above improvements, right?

Mic (Neale) was thinking that maybe we should implement Doony as a self contained plugin as a way of getting one step closer.  I was wondering if it would be as easy to just go all the way and merge it into Jenkins core.  I'll be having a chat with Kevin tomorrow so I can ask him what he thinks.

[Vincent Latombe]

I had made a PoC of line numbers plugin a-la-travis some time ago, I just pushed it on GitHub.

https://wiki.jenkins-ci.org/display/JENKINS/Line+Numbers+Plugin

Vincent

[Sandell, Robert]

Let me attempt to prove you wrong,

 

We are running a slight fork of Jenkins where we have removed the queue widget and the ajax call from the buildhistory so it doesn’t list queued builds on job pages. When we did that the UI responsiveness got improved a lot, I don’t know exactly how many simultaneous human users we have I think they are in the hundreds, but many of them have several tabs open (luckily chrome seems to pause javascript on on none visible tabs). But we saw that all our http threads in tomcat were occupied with serving and filtering the queue and these just kept piling up, dialing up the number of http threads in tomcat only delayed the inevitable. This was due to a synchronization block in the queue and things has been done in core to mitigate this in newer versions, but we still remove it since one less http request per user per second still provides better responsiveness.

 

Also all users are not “human users”, we had to redesign some of our tool integrations that uses the Jenkins HTTP API when we started to use Jenkins with lazy loading of builds, because again, http requests that was waiting for all builds to load for a job occupied all the http threads during peak hours and none was left to serve the humans.

 

So my personal experience is to not have long running http calls for big Jenkins installs, even if the user base is “in the hundreds”.

 

Someone told me that fronting Jenkins/tomcat with ngix would solve these problems. I haven’t tried it yet, does anyone have any experience with it?

 

 

 

Robert Sandell

Software Tools Engineer - SW Environment and Product Configuration

Sony Mobile Communications

--

[Tom Fennelly]

Are we talking abut the same thing though?  If I read your email correctly I think you're talking about the current mechanism of periodic polling requests (coming form 100s of users), right?  What the guys were talking about was something different i.e. SSE, where the 100s of clients open long running connection to the server, over which notifications are pushed.  As I see it, this is different in that it's ot constantly creating and destroying connections from the client to the server + it's not constantly processing ajax requests, most of which are probably returning the same data as last time.

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/zDaX4yiWLLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Robert Sandell]

I am mainly commenting on how it behaves today. 

I'm not familiar enough with SSE to be able to predict how It would behave server side if it was implemented, last time I used SSE it was brand new and we used a specialized app server designed to handle thousands of users, so I don't know how tomcat/jetty has implemented it. It was the "long running connection to the server" expression that prompted me to express my concern. 

Just don't hog my precious HTTP workers! ;)

/B

[Jesse Glick]

On Thu, May 29, 2014 at 12:51 PM, Kevin Burke <kbur...@gmail.com> wrote:
> creating a new build doesn't return the build number

Because you are only *scheduling* a new build, which may or may not
get started sometime later (possibly after a restart). In fact the
remote API offers all the information you need to find the queue item
you just created, then track its progress (including across restarts)
including possible future build creation.

> there's no API for retrieving the console output.

Huh? Build console display is done using “AJAX” updates in the regular
Jenkins UI, so there is certainly an API for accessing it. (In fact
the NetBeans client uses it to display ongoing build progress just
like a browser would.) Or are you talking about something else?

[Tom Fennelly]

On Monday, June 2, 2014 11:50:03 AM UTC+1, Tom Fennelly wrote:

As suggested by others, I think it would be a good idea to bite off smaller chunks where we can so as to make progress.  So, maybe we could start by adding Doony and then look at making some of the above improvements, right?

I created a branch and merged Doony.  It's more-or-less "as is" at the moment.

Next steps (also see Kevin's notes below):

1. The ProgressCircle does not seem to be working atm... need to fix that.
2. Go through doony.css looking for potentially ambiguous CSS.  Where relevant, see if we can add class/id metadata to jelly scripts so as to fix potential css issues.
3. As with #1, go through doony.js looking for potentially ambiguous/troublesome jQuery selectors etc etc
4. Related to #2, review doony.js and see what needs to be improved.  It's doing some funky things atm that maybe could be done in a better way e.g. 
• How it's replacing the bouncy/floaty balls.
  
• How it's getting the next build number after the "Build Now" button is pressed.
• How it's deciding if it's on the "job" related page or not based on the active url in the browser.
5. Remove dependency on jQuery (??).
6. Normalize CSS i.e. merge doony.css into jenkins core style.css, removing existing style.css rules where we can.
7. 
   

Kevin (Burke) and I had a quick chat on Skype yesterday afternoon.  Here are Kevin's detailed notes and thoughts on what changes are in Doony and how we can use/evolve that work.  Very useful info... thanks Kevin !!!

[Tom Fennelly]

Duh... forgot to add a link to the branch... https://github.com/tfennelly/jenkins/tree/doony-merge 

[Tom Fennelly]

So unless there are any objections, let's go for next Tuesday June 10th at 5pm GMT (9am PDT).

[Tom Fennelly]

I have a test instance running here: http://166.78.9.27:8080/ 

[Jesse Glick]

On Wed, Jun 4, 2014 at 1:58 PM, Tom Fennelly <tom.fe...@gmail.com> wrote:
> I have a test instance running here: http://166.78.9.27:8080/

The added message

> Build #5 created, you will be redirected when it is ready.

is ironic, seeing as I _just_ merged a PR that specifically removed
this kind of message from the log of an upstream build: unless and
until the new build actually starts, you do not know for sure what its
number will be, you can only guess. (Particularly if the job is marked
concurrent-capable.)

[Tom Fennelly]

Thanks for point that out.  We're not looking to push this right now.  Was just talking to Kevin (Doony author) and we're going to break Doony out into separate parts (layout, orbs/icons etc) and shoot for individual PRs on the separate parts.  So, when it gets to parts like the above message we'll be able to figure out what's best to do (or leave as is).

[Marco Ambu]

Hi,

I like the idea.

Talking about plugins... The dashboard-view-plugin requires the tables that are currently created by Jenkins in order to work (i.e. I add <tr> without a table because I am already rendering inside a table).

Just changing to divs will probably break the plugin.

However the good news is that I have a version of the dashboard-view-plugin using divs internally instead of tables (it was created a long time ago and might need updated). The experiment went well but because the divs are inside tables created by Jenkins, they sometimes are not rendered correctly... that's why I haven't submitted it yet.

Should this idea move forward, I may update that version of the plugin to remove the dependency on tables created and see how it goes with the new look and feel.

Marco

On 26 May 2014 14:54, Tom Fennelly <tom.fe...@gmail.com> wrote:

Hi guys.

I've just started looking into ways in which we can "refresh" the look and feel of the Jenkins UI, as well as looking at tackling some of the main usability issues.  I've really only started, but have committed a small bit of code to a branch on github at https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:

1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
   
2. Modified the main project/job configuration page, in an effort to make it less cluttered, by adding accordions for the different config sections.  The only way I found I could do this was to wire in some javascript to manipulate the page post-rendering.  Kohsuke says there's a way of doing the bulk of the DOM manipulation within Jelly templates, but I failed to work that one out yet - I'm sure it will be "obvious" after I see it :)  Not sure if accordions are the correct choice.  Here's a screenshot of what it looks like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

The above commit obviously breaks things e.g. the breadcrumbs + some of the styling is screwed up (I added Twitter bootstrap, causing the css's to clash).  What I've done so far is really just hacking to see what we could do.  I'm keen to hear the opinions of the community... what people thing we should concentrate on... what should we avoid... what are the risks etc etc.  I'm aware there is some prior art in this area e.g. OHTAKE Tomohiro's work, the Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:

1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
4. New more "modern" icons?

After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

So I hope there's an appetite/interest in this and I hope people will let us know where they would like to see this go (or not, as the case may be).  And of course, if anyone is interested in getting involved in a "hands-on" way, then that would be even better :)  I think the next steps are for me to gather peoples opinions and formulate an actionable plan that people can see and comment on if they want to.

Regards,

Tom.

--

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.

--
Marco Ambu
E-mail: marco...@gmail.com
LinkedIn profile: <http://www.linkedin.com/in/marcoambu>

[Tom Fennelly]

On Friday, June 6, 2014 3:58:47 PM UTC+1, mambu wrote:

Hi,

I like the idea.

Talking about plugins... The dashboard-view-plugin requires the tables that are currently created by Jenkins in order to work (i.e. I add <tr> without a table because I am already rendering inside a table).

Just changing to divs will probably break the plugin.

However the good news is that I have a version of the dashboard-view-plugin using divs internally instead of tables (it was created a long time ago and might need updated). The experiment went well but because the divs are inside tables created by Jenkins, they sometimes are not rendered correctly... that's why I haven't submitted it yet.

Should this idea move forward, I may update that version of the plugin to remove the dependency on tables created and see how it goes with the new look and feel.

Marco

Thanks Marco... we'll keep you posted on that. 

[Tom Fennelly]

All the icons in Jenkins are hardcoded as images in the Jelly scripts.  We were hoping to move away from this (ala Doony) by using CSS + some Javascript (for the animation).  Seems like this is not possible to do without getting into screen-scraping hacks because the <img>s are used out in plugins too (not just in the core Jenkins code) e.g. the maven plugin.

I guess this means we're stuck with using images Vs CSS +Javascript ?

[Michael Neale]

You mean the paths/file names are hard coded in jelly? Is changing the icons themselves not on te cards? An alternative is what some of the plugins do now which is to serve up different icons for specific paths (like I think the green balls plugin does)

On Saturday, June 7, 2014, Tom Fennelly <tom.fe...@gmail.com> wrote:

All the icons in Jenkins are hardcoded as images in the Jelly scripts.  We were hoping to move away from this (ala Doony) by using CSS + some Javascript (for the animation).  Seems like this is not possible to do without getting into screen-scraping hacks because the <img>s are used out in plugins too (not just in the core Jenkins code) e.g. the maven plugin.

I guess this means we're stuck with using images Vs CSS +Javascript ?

--
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/zDaX4yiWLLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

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

--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com

[domi]

I don't think this is too much of a problem, all we have to do is to keep the images (the same ones or new ones) with the same names as of today. Independent whether the core uses it or not.

I'm sure plugins which do not look nice with the new style will be changed soon.

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.

[Daniel Beck]

On 07.06.2014, at 13:14, domi <do...@fortysix.ch> wrote:

> I'm sure plugins which do not look nice with the new style will be changed soon.

It'd be best if core provided CSS/JS equivalent images (it doesn't need to use them itself) so plugins referencing these resources would automatically inherit the new design as much as possible. They could then gradually adopt use of CSS/JS instead of images when it makes sense.

Forcing all plugins that use affected core resources to choose between looking outdated and requiring the latest and greatest as minimum compatible version would be a bad idea.

[Tom Fennelly]

Maybe we could do this:

1. Provide CSS based icons (I think we can eliminate the Javascript completely).
   
2. Migrate core Jenkins to use the CSS based icons.  We've already done this on our branch.
   
3. Provide a plugin that can be added to perform the JS screen-scraping hacks to transform non Jenkins core icon <img>s (e.g. from plugins) to the new CSS style.

I think this would encourage plugin maintainers to migrate to the new CSS resources (because their plugins will have the old style by default), while at the same time provide an interm option for people to have the new style throughout their Jenkins install.

wdyt?

[Michael Neale]

Only risk is that it works so well that plugin maintainers don't feel the need to change anything ;) I guess we can always crawl the repos for plugins that use img and open a generic ticket for each (or something like that). 

--

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/zDaX4yiWLLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Fennelly]

Hmmm... I was hoping that the fact that their plugin would not display the new styles by default would be enough of an encouragement.

Anyway... yes... maybe we could scan the plugin and open tickets on them.

[Tom Fennelly]

I created a simple plunker to try test browser compatibility for the specific CSS3 animation I'm looking to use to (to replace the JS version from Doony).

If you have a few mins, please browse to the plunker using whatever browsers you have and filling in the form: http://run.plnkr.co/0tu9emUDQCEK5n1i/

[do...@fortysix.ch]

Tom, the given plunker URL does not work anymore...

On 08 Jun 2014, at 16:10, Tom Fennelly <tom.fe...@gmail.com> wrote:

I created a simple plunker to try test browser compatibility for the specific CSS3 animation I'm looking to use to (to replace the JS version from Doony).

If you have a few mins, please browse to the plunker using whatever browsers you have and filling in the form: http://run.plnkr.co/0tu9emUDQCEK5n1i/

--

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.

[Tom Fennelly]

Sorry... they must disable the run after a while.... http://plnkr.co/O1KfxBES2nt1guhVMBty

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/zDaX4yiWLLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Kohsuke Kawaguchi]

I assume we are only talking about the flashing orb here --- other icons
(say the terminal icon) are just fine with them being images, and
whatever animations you might require (like fading, etc) can be done
with img+css.

As for the compatibility issue, what if we produce a plugin that
encapsulates the fallback behaviour?

For the flashing ball images, the said plugin can define a tag file like:

<c:ball icon="${run.iconColor}" size="24" />

... and the tag can expand to <img> (if running on today's Jenkins) or
<div> (if running on tomorrow's Jenkins)

On 06/06/2014 10:33 AM, Tom Fennelly wrote:
> All the icons in Jenkins are hardcoded as images in the Jelly scripts.
> We were hoping to move away from this (ala Doony) by using CSS + some
> Javascript (for the animation). Seems like this is not possible to do
> without getting into screen-scraping hacks

> <https://github.com/tfennelly/jenkins/blob/orb-orb/core/src/main/resources/lib/layout/orb.js#L80>

> because the <img>s are used out in plugins too (not just in the core
> Jenkins code) e.g. the maven plugin.
>
> I guess this means we're stuck with using images Vs CSS +Javascript ?

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

[Kohsuke Kawaguchi]

Yes, better mention that it's just queued. But Tom, don't worry, leave
those correctness changes to us. Just keep the fresh breeze coming and
deliver what you think the user should see.



BTW, for others, you can now wait for the queued item to get started
with something like this:

Future<Build> f =
queue.schedule2().getItem().getFuture().getStartCondition();

int n = f.get().getNumber();

[Kohsuke Kawaguchi]

I suspect we need a compatibility plugin like this anyway to hide the
layout changes (<div> vs <table>) and so on.

[Stephen Connolly]

Ha! I got quite far retaining compatibility... There are a few plugins that copy&paste the tags rather than using the tag directly (eg some of the ones I wrote do that to work around bugs in the core tags in eg 1.424 or 1.460) given those baselines are quite old I suspect just reverting back to using tags directly would be sufficient to get all plugins working either side of the big UI switch to divs...

You can see some of our progress in the div-fanatic-experiment branch... Still need to fix structured form submission mind you ;-)

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

--
Sent from my phone

[Kohsuke Kawaguchi]

On 05/30/2014 12:46 AM, Stephen Connolly wrote:
> I'd put that decision on the agenda for the next meeting.
>
> I'd also recommend pinging the users's list for feedback... there could
> be a large number of tomcat 6 people behind firewalls preventing the
> ping-back... now if they are not engaged with the users list... well
> let's do all we can to see if we can move forward with this

I posted http://jenkins-ci.org/content/thinking-about-moving-servlet-30
and created https://issues.jenkins-ci.org/browse/JENKINS-23378 to
solicit feedbacks.

Let's see how it goes.


> On 30 May 2014 07:45, Kohsuke Kawaguchi <kkawa...@cloudbees.com
> <mailto:kkawa...@cloudbees.com>> wrote:
>
> To use any of those async servlet features, we need Servlet 3.0, but
> it turns out that the servlet spec has designed this feature in such
> a way that webapp would have to opt into this support through web.xml.
>
> Unfortunately, what this means is that if we want to start using
> servlet 3.0 functionality, we'd have to leave behind people who are
> running earlier versions of the container. There's no graceful
> fallback that works with servlet 2.5 containers.
>
> Now, servlet 3.0 came out in 2009, and in 1.535 Jenkins moved to
> Jetty-8 based Winstone 2.x that supports servlet 3.0, so we'd think
> good portion of the user base is already running on compatible
> servlet container. But I decided to look into this anyway.
>
> Many users run Jenkins through "java -jar jenkins.war", we expect
> that users of more recent Jenkins versions will likely run servlet 3
> compatible container.
>
> When I look at people who are running >=1.509 and later, 70% of them
> run on servlet 3 compatible container. The number for >=1.532 is
> 84%, then for >=1.554 it's 94%.
>
> When I look at which container is dragging us down as of >= 1.554,
> you see that there's a sizable Tomcat6 deployments (2.5%). If we
> start requiring Servlet 3.0 these people will be in a nasty
> surprise. Then there's about 1.8% who claims to be running on
> Winstone 0.9.10, which is really puzzling, but I'm assuming these
> people are getting OEM-ed Jenkins of a sort (multiple large
> companies are known to do this), so these people will likely be able
> to update to Winstone 2.x automatically by virtue of getting a new
> jenkins.war from their upstream.
>
> So all in all I'd say if we start requiring Servlet 3.0 today,
> there'll be about 3% user base who will be impacted, which IMHO is
> acceptable loss to move forward.
>
> The results are in
> https://docs.google.com/spreadsheets/d/14YzFgKBB6BvbRU_1OjChC3efECWPs77TEGTU09t3KGw/edit#gid=873989456
>
> Note that the spreadsheet only lists 20 or so most common
> containers. The total number does include the entire long tail
> (which amounts to less than 1%), so the estimate errs on the
> slightly conservative side.
>
>
>
> 2014-05-29 19:48 GMT-07:00 Kohsuke Kawaguchi
> <kkawa...@cloudbees.com <mailto:kkawa...@cloudbees.com>>:
>
>
> Perhaps I should have mentioned it more explicitly, but I was
> only thinking about using it to do updates after the initial
> page load, with most of the server-side initial HTML rendering
> intact.
>
> So when WebSocket/SSE/etc does not work, all you lose is the
> dynamic update, which I think is acceptable loss.
>
>
>
> On 05/29/2014 02:01 AM, teilo wrote:
>
> Just so people are aware IE has no support for SSE[1].
>
> IE is still commonly used in enterprises despite it many and
> continuous
> flaws.
>
> So far Jenkins has been pretty browser agnostic.
>
> /James
>
> [1] http://status.modern.ie/__serversenteventseventsource
> <http://status.modern.ie/serversenteventseventsource>
>
> On Thursday, 29 May 2014 08:26:38 UTC+1, Tom Fennelly wrote:
>
>
> On 29/05/2014 02:57, Michael Neale wrote:
>
>
> On Thu, May 29, 2014 at 11:33 AM, Christopher Orr
> <ch...@orr.me.uk <mailto:ch...@orr.me.uk>
> <javascript:>> wrote:
>
>
> It may also be worth considering Server Sent
> Events —
> basically one-way "push" from the server,
> without all the
> handshaking and protocol upgrade fun of
> WebSockets. Could be
> useful if clients are just listening for server
> updates,
> without sending anything (as is generally the
> case today).
>
> Last week I wrote a quick experimental plugin
> to stream log
> events as they happen via SSE to remote
> JavaScript clients for
> any running build; I was surprised how simple
> it was to build..
>
> (Though I just noticed that it has less support
> than
> WebSockets (thanks, Microsoft):
> http://caniuse.com/eventsource__)
>
> Chris
>
>
>
>
> +1 on SSE. I have a fair bit of experience with
> websockets on
> servers - enough to know that almost no one gets
> their proxies
> right - and it is a source of complaints. SSE seems
> to work better
> out of the box, alternatively long polling/comet
> can also work (a
> given jenkins master doesn't have to scale to 10s
> of thousands
> concurrent users, which is the assumption for a lot
> of other web
> choices).
>
> Having said that, nearly halfway through 2014
> websockets is
> probably not a controversial choice and does open
> up a lot of
> other options. If someone is accessing their
> jenkins via a proxy,
> ssl and careful configuration is required to
> support http upgrade
> and not break websocket too.

>
> AFAIK... any proxy/gateway between the websocket client
> and server
> needs to be pretty much websocket aware. SSE would
> seem like a
> perfect fit for Jenkins since the client is listening
> only (not
> sending back to the server - could implement that on
> top anyway if
> needed). As far as I know SSE is a fancy long
> poll/comet style
> protocol and so would require the same considerations
> re number of
> concurrent users.
>

> --
> 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-dev+unsubscribe@__googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>
> <mailto:jenkinsci-dev...@googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>>.
>
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
>
>
>
>
> --

> Kohsuke Kawaguchi

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

> <mailto:jenkinsci-de...@googlegroups.com>.

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

> 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

> <mailto:jenkinsci-de...@googlegroups.com>.

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


--

[Kohsuke Kawaguchi]

OK, great.

So maybe not for the form changes, but I think the idea is still
generally useful to answer the question Daniel Beck raised (below) in a
satisfactory way:

> Forcing all plugins that use affected core resources to choose between
> looking outdated and requiring the latest and greatest as minimum
> compatible version would be a bad idea.

With the compatibility plugin, plugins can look consistent regardless of
Jenkins versions they run on, without forcing the latest & greatest
as the minimum required version.

(And in 100 or so releases, plugins can drop this plugin as a
requirement and simply start relying on the new core.)

On 06/09/2014 04:30 PM, Stephen Connolly wrote:
> Ha! I got quite far retaining compatibility... There are a few plugins
> that copy&paste the tags rather than using the tag directly (eg some of
> the ones I wrote do that to work around bugs in the core tags in eg
> 1.424 or 1.460) given those baselines are quite old I suspect just
> reverting back to using tags directly would be sufficient to get all
> plugins working either side of the big UI switch to divs...
>
> You can see some of our progress in the div-fanatic-experiment branch...
> Still need to fix structured form submission mind you ;-)
>
> On Monday, 9 June 2014, Kohsuke Kawaguchi <kkawa...@cloudbees.com

> <https://github.com/tfennelly/__jenkins/blob/orb-orb/core/src/__main/resources/lib/layout/orb.__js#L80

> <https://github.com/tfennelly/jenkins/blob/orb-orb/core/src/main/resources/lib/layout/orb.js#L80>>
> because the <img>s are used out in plugins too (not just in
> the core
> Jenkins code) e.g. the maven plugin.
>
> I guess this means we're stuck with using images Vs CSS
> +Javascript ?
>
>
>
>
>
>
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
>
> --
> 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
> <https://groups.google.com/d/optout>.

>
>
>
> --
> Sent from my phone
>

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

> <mailto:jenkinsci-de...@googlegroups.com>.

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


--

[Andrew Kujtan]

Apologies if this has been brought up already, but all my emails contain the orbs, my email-ext template currently has,

<IMG SRC="${rooturl}static/images/32x32/(blue.gif/red.gif/yellow.gif)" />

Would converting to a js/css orb blow this away? I tried adding this to an email and (unsurprisingly) Outlook doesn't show anything. Not even a yellow square.

<div style="width:32px;height:32px;display:inline-block;border-radius:50%;background:yellow;background-image: radial-gradient(circle at 3px 3px, white 0%, #FFB738 100%);" />

-Andrew

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

[Tom Fennelly]

Posting back here again to solicit feedback.

We've already pushed some styling tweaks into upstream master.  We don't think they'll cause too much controversy (thanks to Kevin Burke):

1. Updated buttons styles
2. Friendlier/newer form control styles.
   

What might be the cause of some debate are the changes in PR 1289, where we've:

1. Redone the main Jenkins layout to use <div>s (as opposed to <table>s).
   
2. Restyled the header.
3. Sticky footer
4. More responsive to media display:
• Horizontal flow rolls over to a single column on narrower displays.
• We toyed with hiding some things on smaller displays but decided to undo that for now and tackle it separately.

We've setup a temp instance here: http://166.78.9.27:8080/ where you can see all these changes.  Obviously... please don't create big heavy-duty jobs + please delete any jobs when you're done.

If people are OK with these changes we'd like to push them upstream ASAP.

Thanks for all the feedback so far (Daniel, Mic et al).

We've also been working on some bigger tasks such as:

1. Better support for icons - away from using embedded <img>s and over to css based.
   
2. Getting rid of tables on config pages (and form tags).

We'll report back on these in due corse.

[Slide]

Is there anything that can be done about the unaligned buttons that often appear?

​

To me, there is no rhyme or reason as to why they are not aligned.

--

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.

--
Website: http://earl-of-code.com

[Marco Ambu]

On 18 June 2014 13:25, Tom Fennelly <tom.fe...@gmail.com> wrote:

Posting back here again to solicit feedback.

We've already pushed some styling tweaks into upstream master.  We don't think they'll cause too much controversy (thanks to Kevin Burke):

1. Updated buttons styles
2. Friendlier/newer form control styles.
   

What might be the cause of some debate are the changes in PR 1289, where we've:

1. Redone the main Jenkins layout to use <div>s (as opposed to <table>s).
   
2. Restyled the header.
3. Sticky footer
4. More responsive to media display:
• Horizontal flow rolls over to a single column on narrower displays.
• We toyed with hiding some things on smaller displays but decided to undo that for now and tackle it separately.

We've setup a temp instance here: http://166.78.9.27:8080/ where you can see all these changes.  Obviously... please don't create big heavy-duty jobs + please delete any jobs when you're done.

If people are OK with these changes we'd like to push them upstream ASAP.

-- 

Hi,

Just to clarify, what do you mean with "upstream"? Is it the main Jenkins branch or is there a new branch for this changes?

Have you tried any plugins that rely on tables to see what happens? How do we coordinate for updating plugins to get work without parent tables? 

Thanks

[Tom Fennelly]

On Wednesday, June 18, 2014 1:47:25 PM UTC+1, slide wrote:

Is there anything that can be done about the unaligned buttons that often appear?

Are you saying this is an issue that has been introduced by these changes, or is it a separate comment?

[Mark Waite]

Thanks very much for hosting that server.  I ran the git-client-plugin from the new user interface and found no issues with Chrome, Firefox, or Internet Explorer on Windows 8.1.

When I displayed the same job on Chrome on my Android phone, it used too small a font for me to read easily, and it seemed to widen the build executor status column to the full width of the browser.  That was surprising, but I assume that since smaller displays will be tackled separately, that is an expected condition.

Thanks!

Mark Waite

--

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.

--

Thanks!

Mark Waite

[Tom Fennelly]

On Wednesday, June 18, 2014 2:12:47 PM UTC+1, mambu wrote:

Hi,

Just to clarify, what do you mean with "upstream"? Is it the main Jenkins branch or is there a new branch for this changes?

The upstream Jenkins repo at https://github.com/jenkinsci/jenkins

 

Have you tried any plugins that rely on tables to see what happens? How do we coordinate for updating plugins to get work without parent tables?

I assume you are talking about the changes we're looking at making to the config pages i.e. getting rid of tables and replacing with divs?  This will undoubtedly have an effect on plugins, quite a few of which seem to be using tables - I wrote a simple script to pull all repos (numbering ~ 690) and grep'd across them... there were quite a few tables.  We need to figure out a best strategy for this but yes, there will be side effects and we'll try minimize them as best we can.

[Tom Fennelly]

On Wednesday, June 18, 2014 2:13:27 PM UTC+1, Mark Waite wrote:

Thanks very much for hosting that server.  I ran the git-client-plugin from the new user interface and found no issues with Chrome, Firefox, or Internet Explorer on Windows 8.1.

When I displayed the same job on Chrome on my Android phone, it used too small a font for me to read easily, and it seemed to widen the build executor status column to the full width of the browser.  That was surprising, but I assume that since smaller displays will be tackled separately, that is an expected condition.

Thanks!

Mark Waite

Hi Mark.  Are you saying that that instance of Jenkins now looks worse on your Android device?  We have not adjusted font sizes in these changes (or done anything else like that for smaller devices).

[Slide]

The issue has been around for a while, I just mentioned it since there were updates to the layout.

--

[Tom Fennelly]

On Wednesday, June 18, 2014 2:42:52 PM UTC+1, slide wrote:

The issue has been around for a while, I just mentioned it since there were updates to the layout.

Thanks for mentioning it.  Hopefully we'll be able to tackle issues like that once we've sorted out the basic structure of config pages.  I think it would be a few layers of change down before we would get to that.

[Daniel Beck]

The new higher contrast buttons make it certainly more noticeable.

[Gus Reiber]

Following Tom's lead, I am also starting to poke around at the Jenkins UI.

My initial branch is here:

https://github.com/gusreiber/jenkins/tree/gustables

What I am most excited about in what Tom has done so far is replacing the main table layout with responsive bootstrap columns.

In addition to making the UI line up a little better and be a little neater, it offers the promise of better cross device usability, which I think would be huge.

In my first stab here, I am looking at doing 2 things:

1) Give the Jenkins projects/build pages a bit of client-side richness with minimal intrusion on the potentially customized or plugin modified DOM that might live within that main table.

I have started with this JQuery plugin: http://www.datatables.net/examples/styling/bootstrap.html 

It has the nice feature of accepting the rendered static table as its datasource and then adds a host of client-side magics: filtering, sorting, grouping, and column switching resizing and pegging. I don't see this as being particularly revolutionary in terms of UI/UX, but so far anyway, its insertion seems to be going smoothly and for users with big job lists, rich sorting tools seems like it could be a nice win.

2) I find the Jenkins action list (the list of hyperlinks shown in the left column above the build queue) a little jarring, in that all the links are given equal display weight despite what is often radically different amounts of functional utility. As an example configuring the job and viewing the console out (two things I do a good amount), are the same simple blue links that configuring roles is (something I never do). Compounding that a bit is the fact that those links are always contextual, namely, depending on your view, that list changes around quite a bit.

   

As a possible remedy to that bit of awkwardness, I am looking at pulling some of the 'action' link list items out and displaying them in a global toolbar sort of context. Jenkins Management, in particular seems like it really should be clearly separated as a global set of actions, and not bound to any particular build or custom view.

At the moment, I am merely doing a proof of concept examination of how the link list gets generated, but I would love to get community feedback as to whether or not it does make sense to separate out a portion of the Jenkins actions, splitting the contextual from the global and the high-use/high-value actions from necessary but tangential or highly specialized actions.

Attached is a screenshot.

(the top menu shown here isn't really the right set of global options, but instead just a strawman to see if I can grab the action buttons and put them into a bootstrap nav-bar, which I can)

On Monday, May 26, 2014 6:54:21 AM UTC-7, Tom Fennelly wrote:

Hi guys.

I've just started looking into ways in which we can "refresh" the look and feel of the Jenkins UI, as well as looking at tackling some of the main usability issues.  I've really only started, but have committed a small bit of code to a branch on github at https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:

1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
   
2. Modified the main project/job configuration page, in an effort to make it less cluttered, by adding accordions for the different config sections.  The only way I found I could do this was to wire in some javascript to manipulate the page post-rendering.  Kohsuke says there's a way of doing the bulk of the DOM manipulation within Jelly templates, but I failed to work that one out yet - I'm sure it will be "obvious" after I see it :)  Not sure if accordions are the correct choice.  Here's a screenshot of what it looks like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

The above commit obviously breaks things e.g. the breadcrumbs + some of the styling is screwed up (I added Twitter bootstrap, causing the css's to clash).  What I've done so far is really just hacking to see what we could do.  I'm keen to hear the opinions of the community... what people thing we should concentrate on... what should we avoid... what are the risks etc etc.  I'm aware there is some prior art in this area e.g. OHTAKE Tomohiro's work, the Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:

1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
4. New more "modern" icons?

After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

So I hope there's an appetite/interest in this and I hope people will let us know where they would like to see this go (or not, as the case may be).  And of course, if anyone is interested in getting involved in a "hands-on" way, then that would be even better :)  I think the next steps are for me to gather peoples opinions and formulate an actionable plan that people can see and comment on if they want to.

Regards,

Tom.

[Michael Neale]

On Wed, Jun 18, 2014 at 10:25 PM, Tom Fennelly <tom.fe...@gmail.com> wrote:

Posting back here again to solicit feedback.

Looks great - I tried on chrome, safari (both mac) and iphone - the responsive-isms are much appreciated. 

2 things that stood out: 

Font is still tiny - I find it hard to read (had to bump it up a few sizes) - Helvetica (as mentioned in another PR) works nicely here as you bump it up a bit - doesn't stand out as much compared to every other web app :) Sure with a smaller font you can see a but more - but you end up skipping over things as it is too small to read. 

When you narrow the window (eg mobile) the menu links really stand out as out of place (I think Gus mentioned that in another thread). A "classic" responsive thing to do here would be to collapse them into some pop-over menu (often the infamous pancake icon is used here) - this may be overkill, but I thought it was interesting how well responsive worked but for those stubborn links and their icons.  

Have attached the before/after with the larger/helvetica font change.