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:
- 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
- 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:
- 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.
- 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.
- Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
- 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.
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.
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?
On 05/26/2014 03:54 PM, Tom Fennelly wrote:You often hear people say "the Jenkins UI is bad", but it's usually said
> 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.
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?
> 1. Tweaking the main layout in
> What I've experimented with so far:
>
> core/src/main/resources/lib/layout/layout.jelly (and added some CSS> 2. Modified the main project/job configuration page, in an effort to
> 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
> make it less cluttered, by adding accordions for the differentNice. That job config is looking good :)
> 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
I guess it depends what the goal is. If it's just "refreshing the UI",
> 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?
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
Wait, people complain but cannot provide concrete examples? Let me!
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.
- 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.
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 ;)
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.
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:
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/djonsson/jenkins-atlassian-theme -> http://test.do/ (making Jenkins look like bamboo)
...
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
--
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.
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.
If you want to make it happens, I want to collaborate.
Em 26/05/2014 10:54, "Tom Fennelly" <tom.fe...@gmail.com> escreveu:
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:
- 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
- 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:
- 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.
- 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.
- Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
- 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.
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).
Here's a nice set of flat icons:
--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.
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:
- 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.
- The job config page is a badly organised nightmare.
- 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.
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
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: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/djonsson/jenkins-atlassian-theme -> http://test.do/ (making Jenkins look like bamboo)...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.
DomiOn 27.05.2014, at 05:10, Michael Neale <michae...@gmail.com> wrote:
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.--
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.
Very nice.... thanks Stephen ;)
On 05/26/2014 11:10 PM, Michael Neale wrote:It'd be great if the main dashboard could be configured to pull UI
> 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.
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!
On Mon, May 26, 2014 at 5:41 PM, Daniel Beck <m...@beckweb.net> wrote:Probably fixable without fundamental changes. I swear I had this filed
> It's possible to save forms with errors.
in JIRA but I cannot find it now.
I doubt those are so commonly used that they deserve space in the context menu.
> 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 think these things should be admin warnings.
> the global config requires changes (Jenkins URL, mail server, ...) or otherwise things won't work right.
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--
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 !!
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 duringFOSDEM 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/dV680PGiI1YThanks 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.
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.
We have been using
on our jenkins installation. Just wanted to mention it.
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
Is it pretty close to the dashboard view plugin? Or is that missing what
you need?
On 05/26/2014 06:54 AM, Tom Fennelly wrote:
> 1. Jelly + Stapler are not the easiest to work with. At least I've
> 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.
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.
> 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.> 2. What will be the effect on plugins of changing project config
> 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.
> layout. I already see some strange behaviour e.g. I added an> 3. Use of <table> for layout seems to be quite popular Vs using <div> +
> "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.
>
> 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.
One thing that's missing from the list in this thread so far is, more
> 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.
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.
On Wed, May 28, 2014 at 4:37 PM, Kohsuke KawaguchiWell, only insofar as they choose to use those taglibs. In most cases
<kkawa...@cloudbees.com> wrote:
> This is also an area where plugin config files are shielded from the raw
> HTML tags through taglibs
they do, but there are some places where plugins add raw <tr>s where
they expect to be inside a <table>.
It would be nice (especially if we can finally kill Auto Refresh!),
> more dynamic content update in real time without page reloading.
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.
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've2. What will be the effect on plugins of changing project config
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.3. Use of <table> for layout seems to be quite popular Vs using <div> +
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.
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.
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.
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.
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-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On 05/28/2014 01:49 PM, Jesse Glick wrote:
> 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.
> 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.
> On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi> Well, only insofar as they choose to use those taglibs. In most cases
> <kkawa...@cloudbees.com> wrote:
>> This is also an area where plugin config files are shielded from the raw
>> HTML tags through taglibs
>
> 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.
> It would be nice (especially if we can finally kill Auto Refresh!),
>> more dynamic content update in real time without page reloading.
>
> 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.
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
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.--To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsub...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
For more options, visit https://groups.google.com/d/optout.
On 05/28/2014 02:01 PM, Stephen Connolly wrote:That works for me.
> 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.
Works for me too. What day would suit? Stephen.... remember it's June
BH weekend here this weekend.
BH weekend here this weekend.
Oh I had not forgotten... will need to check with herself... if sooner is better I'd say Tue/Wed/Thur are options
--To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
For more options, visit https://groups.google.com/d/optout.
Yeah, I think some form of push notification via something like
On 28/05/2014 22:07, Kohsuke Kawaguchi wrote:
> On 05/28/2014 01:49 PM, Jesse Glick wrote:
websockets/sockjs/comet is more appropriate than frequent polling...
lower load + better ux
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.
On Wed, May 28, 2014 at 5:09 PM, 'Bruno P. Kinoshita' via JenkinsAlso be careful with st:bind. Currently it leaks memory whenever used
Developers <jenkin...@googlegroups.com> wrote:
> var remoteObject = <st:bind value="${it.getParametersProvider()}"/>
(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.
Do you mean the meteor framework or the "comet" long poll convention?
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
On Thursday, May 29, 2014, Kohsuke Kawaguchi <kkawa...@cloudbees.com> wrote:
On 05/28/2014 01:49 PM, Jesse Glick wrote:
--On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi
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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
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 <imoutsatsos@gmail.com> wrote:
On Wednesday, May 28, 2014, Ioannis Moutsatsos <imoutsatsos@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!
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 wayIt may also be worth considering Server Sent Events — basically one-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.
"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
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.
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.
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 ;)
I'd say you're spot on.
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).
Sounds like a great idea to me ;)
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 ;)
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
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).
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.
On 29/05/2014 17:51, Kevin Burke wrote: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.
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.
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.
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.
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:
> - 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.
https://issues.jenkins-ci.org/browse/JENKINS-12827?focusedCommentId=201381&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-201381
/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?
> Similarly, there's no API for retrieving the console output.
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
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 theThis is because Jenkins doesn't yet assign a build number while the task
> next one. See for example
> https://github.com/kevinburke/doony/blob/master/src/theme.js#L274.
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.
I'm not quite following the part about exposing global settings (Jenkins
> 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.
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 ofOK, we can do this. Let's do this.
> 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.
+1. Exactly.
> 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.
(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.)
> AJAX requests, for developers. *Jenkins' reliability in delivering a UI
> 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
> should be considered a core strength.*
>> <https://github.com/jenkinsci/jenkins/pull/1100/files> The current level
> - 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.
> of abstraction makes things a little difficult :) Perhaps a smallerOne that I've heard and felt myself is the list view, and the orb that
> 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).
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)
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
>
> 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
> 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> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> an email to jenkinsci-de...@googlegroups.com
> For more options, visit https://groups.google.com/d/optout.
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?
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.
--
Kohsuke Kawaguchi
Kohsuke Kawaguchi
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.
For more options, visit https://groups.google.com/d/optout.
On 30/05/2014 07:06, Michael Neale wrote:
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 !!
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?
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'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
2. Foldable sections, this plugin achieves this somewhat but it leaves a lot to be desired
3. Colors in console, something like this
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:
- 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
- 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:
- 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.
- 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.
- Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
- 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.
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 by1. Adding linkable line numbers like this2. Foldable sections, this plugin achieves this somewhat but it leaves a lot to be desired3. Colors in console, something like thisAll 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:
- 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
- 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:
- 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.
- 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.
- Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
- 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 fYou 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.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
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).
+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.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 desired3. Colors in console, something like this
--
Kevin Burke | Claremont McKenna
phone: 925.271.7005 | kburke.org
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?
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 by1. Adding linkable line numbers like this2. Foldable sections, this plugin achieves this somewhat but it leaves a lot to be desired3. Colors in console, something like this
All of out projects manage their configuration through .ci.yml files so we dont usually run into usability issues with configure page.
- Surya
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.
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
https://wiki.jenkins-ci.org/display/JENKINS/Line+Numbers+Plugin
Vincent
--To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
For more options, visit https://groups.google.com/d/optout.
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
From: jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] On Behalf Of Tom Fennelly
Sent: den 29 maj 2014 10:27
To: jenkin...@googlegroups.com
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-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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.
On 02/06/2014 17:03, Sandell, Robert wrote:
--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
From: jenkin...@googlegroups.com [mailto:jen...@googlegroups.com] On Behalf Of Tom Fennelly
Sent: den 29 maj 2014 10:27
To: jenkin...@googlegroups.com
Subject: Re: Refreshing the Jenkins UI
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 ;)
--
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.
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.
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
On Thu, May 29, 2014 at 12:51 PM, Kevin Burke <kbur...@gmail.com> wrote:Because you are only *scheduling* a new build, which may or may not
> creating a new build doesn't return the build number
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.
Huh? Build console display is done using “AJAX” updates in the regular
> there's no API for retrieving the console output.
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?
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):
- The ProgressCircle does not seem to be working atm... need to fix that.
- 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.
- As with #1, go through doony.js looking for potentially ambiguous/troublesome jQuery selectors etc etc
- 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.
- Remove dependency on jQuery (??).
- Normalize CSS i.e. merge doony.css into jenkins core style.css, removing existing style.css rules where we can.
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 !!!
Duh... forgot to add a link to the branch... https://github.com/tfennelly/jenkins/tree/doony-merge
So unless there are any objections, let's go for next Tuesday June 10th at 5pm GMT (9am PDT).
I have a test instance running here: http://166.78.9.27:8080/
On Wed, Jun 4, 2014 at 1:58 PM, Tom Fennelly <tom.fe...@gmail.com> wrote:The added message
> I have a test instance running here: http://166.78.9.27:8080/
> 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.)
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).
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:
- 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
- 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:
- 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.
- 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.
- Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
- 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>
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.
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 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)
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
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 group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/zDaX4yiWLLw/unsubscribe.
For more options, visit https://groups.google.com/d/optout.
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
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.For more options, visit https://groups.google.com/d/optout.
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.
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.
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.
On 07/06/2014 16:17, Daniel Beck wrote:
Maybe we could do this:
- Provide CSS based icons (I think we can eliminate the
Javascript completely).
- Migrate core Jenkins to use the CSS based icons. We've
already done this on our branch.
- 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?
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 group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/zDaX4yiWLLw/unsubscribe.
For more options, visit https://groups.google.com/d/optout.
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
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.
Anyway... yes... maybe we could scan the plugin and open tickets on them.
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/
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.
For more options, visit https://groups.google.com/d/optout.
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.
For more options, visit https://groups.google.com/d/optout.
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)
> <https://github.com/tfennelly/jenkins/blob/orb-orb/core/src/main/resources/lib/layout/orb.js#L80>
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
> 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
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();
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();
I suspect we need a compatibility plugin like this anyway to hide the
layout changes (<div> vs <table>) and so on.
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...
--
Sent from my phone
You can see some of our progress in the div-fanatic-experiment branch... Still need to fix structured form submission mind you ;-)
--To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
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.
> <mailto:jenkinsci-dev%2Bunsubscribe@googlegroups.com>
> <mailto:jenkinsci-dev+__unsubscribe@googlegroups.com
> <mailto:jenkinsci-dev%2Bunsubscribe@googlegroups.com>>.
>
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.
> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> 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.
>
> --> an email to jenkinsci-dev+unsubscribe@__googlegroups.com
> You received this message because you are subscribed to the
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails
> from it, send
> <mailto:jenkinsci-dev%2Bunsubscribe@googlegroups.com>
> <mailto:jenkinsci-dev+__unsubscribe@googlegroups.com
> <mailto:jenkinsci-dev%2Bunsubscribe@googlegroups.com>>.
>
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.
>> Kohsuke Kawaguchi
>
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
>
>
>
>
> --
>> send an email to jenkinsci-de...@googlegroups.com
> --
> 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,
> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google> an email to jenkinsci-de...@googlegroups.com
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
--
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:
With the compatibility plugin, plugins can look consistent regardless of
> 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.
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.)
> <https://github.com/tfennelly/__jenkins/blob/orb-orb/core/src/__main/resources/lib/layout/orb.__js#L80
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>>> send an email to jenkinsci-de...@googlegroups.com.
> 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,
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.
>
>
>
> --
> Sent from my phone
>
> --> an email to jenkinsci-de...@googlegroups.com
> 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
> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
--
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.
<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.
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):
- Updated buttons styles
- Friendlier/newer form control styles.
What might be the cause of some debate are the changes in PR 1289, where we've:
- Redone the main Jenkins layout to use <div>s (as opposed to <table>s).
- Restyled the header.
- Sticky footer
- 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:
- Better support for icons - away from using embedded <img>s and over to css based.
- Getting rid of tables on config pages (and form tags).
We'll report back on these in due corse.
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
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):
- Updated buttons styles
- Friendlier/newer form control styles.
What might be the cause of some debate are the changes in PR 1289, where we've:
- Redone the main Jenkins layout to use <div>s (as opposed to <table>s).
- Restyled the header.
- Sticky footer
- 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.--
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
--
Marco Ambu
E-mail: marco...@gmail.com
LinkedIn profile: <http://www.linkedin.com/in/marcoambu>
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?
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
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.
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).
The issue has been around for a while, I just mentioned it since there were updates to the layout.
--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.
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.
The new higher contrast buttons make it certainly more noticeable.
Following Tom's lead, I am also starting to poke around at the Jenkins UI.
On Monday, May 26, 2014 6:54:21 AM UTC-7, Tom Fennelly wrote:
My initial branch is here:
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:
- 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
- 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:
- 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.
- 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.
- Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
- 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.
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.
Isn't this backwards, if you don't know yet which items need to be shown more prominently?
On 19.06.2014, at 01:45, Gus Reiber <gusr...@gmail.com> wrote:
> 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)
All globally relevant entries' availability depends on your situation/configuration:
* Project Relationship and Check File Fingerprint (only shown if there are fingerprints recorded),
* My Views (only if you're a logged in user, i.e. requires enabled security and being logged in),
* Manage Jenkins (only if you have Administer permission).
Everything else that exists by default in the sidepanel for top-level views is context specific:
* New Item: specific to ItemGroup (and even view!)
* People: specific to View
* Build History: specific to View
* Edit View (not on the 'All' view): specific to View
* Credentials (bundled plugin): One globally, one per folder
While you could add some entries from 'Manage Jenkins', they basically all require admin permissions.
That's basically what's "Manage Jenkins" is for. Everything that's management-related in the sidepanel is added by plugins. Often, these make sense, e.g. in the case of Credentials, I imagine the reason being consistency with different credential stores (e.g. the Jenkins-wide credential store accessed similar to a per-folder credential store, just on a different object).
> Jenkins Management, in particular seems like it really should be clearly separated as a global set of actions
Looks great, would it be possibly to vertically center align labels to it's attached item?, in the second one, the label for the text box is slightly over the text input field?
--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.
|
| Mads Nielsen Consultant Praqma A/S Tel: +45 50 98 18 09 |
While I did tweak the top styling a bit, this PR is primarily about
changing the layout to use divs vs tables.
So I totally agree... sorting out font types and sizes, adding more responsive features (collapsible menu etc etc) would be things we should try and do, but I wasn't planning on doing it in this PR.
So I totally agree... sorting out font types and sizes, adding more responsive features (collapsible menu etc etc) would be things we should try and do, but I wasn't planning on doing it in this PR.
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.
While your response heavily emphasizes the negatives as you see them, I
think there's some very useful info in there that Gus can take and work
with in a positive way.
I think your comments were primarily targeted at his experiments with
the navigation, right? Or maybe it was both the navigation and the
restyling of the tables?
On navigation, I'd say Gus is like me in that he doesn't yet totally
understand the logic behind navigation within Jenkins, other than the
fact that it's not very intuitive. I think he's trying to throw out a
conversation starter that can eventually lead to something working
better after a number of iterations. Or, maybe we'll discover that
it's not practical to try restructuring it.
So if it's generally acknowledged that navigation in Jenkins causes
issues/confusion/frustration for users, then what can we do about it? I
thought what Gus did at least looked like there was potential in it that
was worth exploring in a positive way. For me, it + your comments has
me wondering how can we better separate navigation so that the different
types of nav items (contextual, global etc etc) are presented in a more
useful/understandable way.
I wonder would it make sense to take a step back and draw a map of the
current navigation and how it changes depending on where you are in
Jenkins? Armed with that, then maybe we can make some proposals?
think there's some very useful info in there that Gus can take and work
with in a positive way.
I think your comments were primarily targeted at his experiments with
the navigation, right? Or maybe it was both the navigation and the
restyling of the tables?
On navigation, I'd say Gus is like me in that he doesn't yet totally
understand the logic behind navigation within Jenkins, other than the
fact that it's not very intuitive. I think he's trying to throw out a
conversation starter that can eventually lead to something working
better after a number of iterations. Or, maybe we'll discover that
it's not practical to try restructuring it.
So if it's generally acknowledged that navigation in Jenkins causes
issues/confusion/frustration for users, then what can we do about it? I
thought what Gus did at least looked like there was potential in it that
was worth exploring in a positive way. For me, it + your comments has
me wondering how can we better separate navigation so that the different
types of nav items (contextual, global etc etc) are presented in a more
useful/understandable way.
I wonder would it make sense to take a step back and draw a map of the
current navigation and how it changes depending on where you are in
Jenkins? Armed with that, then maybe we can make some proposals?
I pulled your branch and had a peek. Comments inline...
I think it makes sense to make better use of the top navbar for global stuff along the lines you've shown here. From Daniel's comments though, it's clear we need to work out what can and can't go there if this approach is followed. I wonder too... for global management type stuff you don't use too often, how about providing access to it through a settings type icon (a spanner/cog type icon e.g. from Github http://goo.gl/Y7wRBW) in the top right (to the left of the search), which is an approach many apps follow?
Can someone explain to me why are the "People" and "Credentials" nav items not inside "Manage Jenkins"?
I think it would be great to draw a app nav map as things stand today and from that, hopefully we could extract some patterns.
+s:
On 19/06/2014 00:45, Gus Reiber wrote:
Following Tom's lead, I am also starting to poke around at the Jenkins UI.My initial branch is here:
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.htmlIt 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.
- I think it looks a LOT better than the original project view tabs.
- Love that more tables are gone and replaced with divs
- Any side effects on other page?
- Anything we need to be careful of wrt plugins?
- Creates a hard dependency on jQuery. Maybe that's not such a
biggie, but one we need to watch.
The navigation is something that others have id'd as being confusing/awkward, so I think it's grat to start a conversation on this. I do think, however, that we should probably split it into a separate discussion.
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.
I think it makes sense to make better use of the top navbar for global stuff along the lines you've shown here. From Daniel's comments though, it's clear we need to work out what can and can't go there if this approach is followed. I wonder too... for global management type stuff you don't use too often, how about providing access to it through a settings type icon (a spanner/cog type icon e.g. from Github http://goo.gl/Y7wRBW) in the top right (to the left of the search), which is an approach many apps follow?
Can someone explain to me why are the "People" and "Credentials" nav items not inside "Manage Jenkins"?
I think it would be great to draw a app nav map as things stand today and from that, hopefully we could extract some patterns.
> I think your comments were primarily targeted at his experiments with the navigation, right? Or maybe it was both the navigation and the restyling of the tables?Right, my response was only about the "promotion" of some items that are always shown to the top bar, not about the client-side list view improvements. While we already have sorting, filtering might be really interesting if it performs well. I really only responded to the following:
> [Gus Reiber:] 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.
It also seems I misunderstood that part quite badly, I can no longer find where Gus wrote that the new "prominent items bar" should always contain the same items!
Navigation is essentially the breadcrumbs bar and the sidepanel. The problem in understanding them probably results from how complex it is: Jelly allows including other Jelly fragments, Stapler decides what get loaded at all, Jenkins behaves as if some items are implied (the default view), and by overriding a Java class you can also override resources. Some resources:
> I wonder would it make sense to take a step back and draw a map of the current navigation and how it changes depending on where you are in Jenkins? Armed with that, then maybe we can make some proposals?
* http://stapler.kohsuke.org/what-is.html
* http://stapler.kohsuke.org/reference.html
Breadcrumbs are created by iterating over the items shown in the URL. If it's not in there, it's missing (except if on a config page, that can also show up there with its sections). Depending on which interfaces the items implement, you get a context menu (down arrow) and/or a children menu (right arrow).
The sidepanel is entirely provided by the currently active item:
* On the home page, it's the "Jenkins" object.
* In a folder, it's the folder.
* In a view, it's the view.
* In a job, it's the job.
* Other special pages, like plugin manager or security configuration, provide their own sidepanel.
However, these implementations can reference other objects that may or may not show up in the URL, have optional items, etc.
As an example, this is how the home page's sidepanel is built (# indicates a Jelly file being read, - an item created, * another remark) to give you an introduction in both reading these files, as well as what's involved in building the sidepanel for the home page:
# core/src/main/resources/jenkins/model/Jenkins/sidepanel.jelly:
* Jenkins just forwards to its primary view in determining the items to be shown
# core/src/main/resources/jenkins/model/View/sidepanel.jelly:
# Optional: Owner's tasks-top.jelly: If the view's owner/parent has a fragment for tasks to show at the top, include it. Not in the case of Jenkins.
# Optional: Owner's tasks-new.jelly: Show the fragment of the 'owner' that shows the 'New Item' link. The included file can also be empty, removing the link.
- If there's no such fragment provided by the owner, show the default 'New Item' link. Backwards compatibility if I had to guess.
- Create the 'People' link (URL depending on whether it's the 'All' view or not: If it's not, add the view to the URL, resulting in .../view/Foo/asynchPeople).
- 'Build History' link.
* If the view is editable (the default 'All' view is not, but another view can be selected to be default):
- Show 'Edit View'
* Can the view be deleted (the default view cannot, but others usually can be unless the view's owner has some code that prevents it)?
- If so, show 'Delete View'
* Are there fingerprints recorded by Jenkins? If so:
- Show 'Project Relationship'
- Show 'Check File Fingerprint'
# Optional subtype's sidepanel2.jelly: Subtypes of 'View' can provide additional items here without having to override this entire sidepanel.jelly they'd otherwise inherit. This is a bit like the strategy pattern if you know that from Java.
- If you use Nested Views ("TreeView" in the code), this is where 'New View' is added.
# core/src/main/resources/lib/hudson/actions.jelly: Display any actions associated with the current view
* The view gets asked for actions to be displayed, and gathers actions to be shown in a view from its owner (jenkins.model.Jenkins#getViewActions()) and adds its own (hudson.model.View#getActions()). This is where plugins can just add arbitrary stuff by e.g. extending TransientViewActionFactory
- If the action defines an icon, icon and display name are shown and link to the action's URL.
Awesome... thank you Daniel.... this is really useful information. I'm
still digesting it though ;) Thanks !!!
still digesting it though ;) Thanks !!!
Behavior of 'People' depends on the view you're in: Unless you're on the 'All' view, it only lists users that have been active in the current view's items. If the view is empty, the list is empty.
On 19.06.2014, at 12:29, Tom Fennelly <tom.fe...@gmail.com> wrote:
> Can someone explain to me why are the "People" and "Credentials" nav items not inside "Manage Jenkins"?
Credentials are likely there as they're contextual: If you're on the home page, you configure the instance-wide credentials, if you're in a folder, you configure the credentials valid within that folder. Hiding the 'main' Credentials in Manage Jenkins, and having per-folder credentials show up in the folder sidepanel would be weird.
Also the "Manage Jenkins" page is only accessible by administrators, so any settings done in there can't be delegated to "normal" users.
Awesome.
Thanks for the feedback Daniel.
So you are totally right about the backwardness of my examination of the the left action menu.
The thing is that I am investigating at two levels, how does the code work and thus what is feasible, and then what is actually desirable. What I am showing in my screenshot is just an affirmation that splitting out the left actions menu is reasonably easy to accomplish and converting it into a bootstrap navigation bar is also fairly straight forward.
To the question of does it make sense, your responses are super helpful.
If I am summarizing your responses correctly, you are basically saying that you are sceptical that it make sense, as the UX model Jenkins follows is that the user navigates into a context, and then the actions present themselves in the left menu based on their relationship to that context, and that makes sense and is good.
My thought that it might make sense is based on a general feeling about UIs, that they should in general not hide or remove fundamental tools when the app state changes. That's not to say this is an iron rule, but in general, the less buttons jump around as an app shifts state, the easier it is to find and remember what buttons do what.
For picking out actions of fundamental importance, it is definitely true that this set (if it even exists in Jenkins) will likely change based on user role and plugin set. None-the-less, in my own use, some actions, like going straight to the console-out of the most recent build within a job, are so fundamental and repeated that making that button big and not require any drill-down that they are maybe worthy of special designation.
...but again, that is really an ask.
Can Jenkins benefit from the general principle that bigger buttons and few clicks for most common actions is good?
If so, does anyone have their own list of actions that they do a lot but find tedious, or remember them being difficult to discover when they were first starting out?
--
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.
I also think that the credentials link should be part of the Manage Jenkins section. When improving the UI we should focus on the most widely spread Jenkins installations which do not use the folders plugin. I think we will find a way to get the credentials hook into a good place if the folders plugin is installed.
> --
> 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.
> --
> 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.
I like the idea to put some actions in the top-level bar! Especially the system configuration and create job would make a good candidate. Also having the ‚New' action there would make sense.
The new tabs for the different views also look very promising. The ‚+‘ action to add a new view also looks good (currently it is hard too see that this + actually creates a new view).
--<jenkins_magicTables.png>
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.
Am 19.06.2014 um 14:07 schrieb Daniel Beck <m...@beckweb.net>:Maybe there should be an option to disable the people view at all (or move it from core into a plugin).
>
> On 19.06.2014, at 12:29, Tom Fennelly <tom.fe...@gmail.com> wrote:
>
>> Can someone explain to me why are the "People" and "Credentials" nav items not inside "Manage Jenkins"?
>
> Behavior of 'People' depends on the view you're in: Unless you're on the 'All' view, it only lists users that have been active in the current view's items. If the view is empty, the list is empty.
>
I think it would improve the usability if we add some „shortcuts"
Am 19.06.2014 um 18:32 schrieb Gus Reiber <gusr...@gmail.com>:
> Awesome.
> Thanks for the feedback Daniel.
>
> So you are totally right about the backwardness of my examination of the the left action menu.
> The thing is that I am investigating at two levels, how does the code work and thus what is feasible, and then what is actually desirable. What I am showing in my screenshot is just an affirmation that splitting out the left actions menu is reasonably easy to accomplish and converting it into a bootstrap navigation bar is also fairly straight forward.
>
> To the question of does it make sense, your responses are super helpful.
> If I am summarizing your responses correctly, you are basically saying that you are sceptical that it make sense, as the UX model Jenkins follows is that the user navigates into a context, and then the actions present themselves in the left menu based on their relationship to that context, and that makes sense and is good.
>
> My thought that it might make sense is based on a general feeling about UIs, that they should in general not hide or remove fundamental tools when the app state changes. That's not to say this is an iron rule, but in general, the less buttons jump around as an app shifts state, the easier it is to find and remember what buttons do what.
>
> For picking out actions of fundamental importance, it is definitely true that this set (if it even exists in Jenkins) will likely change based on user role and plugin set. None-the-less, in my own use, some actions, like going straight to the console-out of the most recent build within a job, are so fundamental and repeated that making that button big and not require any drill-down that they are maybe worthy of special designation.
>
> ...but again, that is really an ask.
> Can Jenkins benefit from the general principle that bigger buttons and few clicks for most common actions is good?
> If so, does anyone have their own list of actions that they do a lot but find tedious, or remember them being difficult to discover when they were first starting out?
>
>
What I’m using frequently (global):
- Manage Jenkins->Configure System (the rest of the "Manage Jenkins" items I’m not using very often).
- Create a new job
During the process of creating a job I’m always in the loop
1) Open Job configuration
2) Run Job
3) If the Job failed: Look at the console log, what is the reason for the failure and go to 1)
After step 1 it would be helpful if we would have not only „Save" and „Apply" but also a „Save and Run" button.
In step 3 it is quite cumbersome to navigate to the console log. This should be more intuitive. New users often ask me where they can see why the job failed. (Maybe the ball indicating that a build failed or is unstable should provide a link to the reason)
While viewing the console it would be good to have an option to navigate to 1) with one click. (Kohsuke mentioned that we could add a link to the console text but up to now you need to scroll back to the top of the page to find the Back to project link and then you can configure the project).
Already filed at https://trello.com/c/oJnGvleL
On 19.06.2014, at 21:23, Ulli Hafner <ullrich...@gmail.com> wrote:
> Maybe there should be an option to disable the people view at all (or move it from core into a plugin).
After talking with Tom a bit yesterday, he suggested that it makes sense for us to divide up the look refresh effort into neat and compact sub-tasks that will make for if not atoms, molecules, that the community can easily choose to embrace independently of other elements of the UI effort.
I think our initial list of project tasks looks something like this:
1) Replacing table based layout structure with Bootstrap's responsive columns (Tom and Kevin seem like they have pretty much rocked this one already)
2) Adopt LESS as a means of segregating and targeting style enhancements to manageable sub-sections of the GUI
3) Adopt a new base-font and typography scheme to make the GUI more device friendly and modern looking
4) Adopt a new icon library, likely based on a glyph-font library like Font-Awesome to enhance performance and device friendliness
5) Apply Bootstrap or Bootstrap-like DOM and class naming conventions to UI widgets like panels, tabs, tables and form elements to modernize the look and make future skinning easier to drive via CSS
6) Give main tables dynamic client-side controls to enable more responsive data view manipulation
7) Examine menu construction mechanisms for ways to highlight common tasks and shorten click-counts
8) Look for additional ways to improve, perhaps by moving e more controls into the client to further enhance responsiveness and a modern feel to the GUI
Although I have put these in the rough order that I think it will make sense for use to pursue each initiative, my hope/belief is that a lot of them could be done in parallel and most could be done not-at-all with minimal ramifications to the other sub-projects in the effort.
Please feel free to smack me and correct me if my list seems not right, or if it is already better articulated somewhere else.
Please feel free to smack me and correct me if my list seems not right, or if it is already better articulated somewhere else.
...or if you have other stuff you would like to add or change.
--
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.
> 4) Adopt a new icon library, likely based on a glyph-font library like Font-Awesome to enhance performance and device friendlinessWhat exactly is the problem with normal icons? Jenkins isn't dial-up friendly anyway, so optimizing the first-time loading of 5 icons won't make a difference. What specifically does 'device friendliness' refer to?
Font-Awesome seems to be pretty small and doesn't have icons with "modifiers" (e.g. New Item's star, Build History's pencil). Isn't this going to be a problem?
Does this mean single color icons instead of properly colored icons? Will these be all the same color, or color still be used to distinguish the icons?
There should be a migration strategy for plugins that makes old plugins not look out of place (and new plugins on then-current LTS installs). I think I've mentioned it before, but having to install the latest & frequently-not-greatest because plugins raise their minimum version to get new _icons_ wouldn't a good solution.
-----
Icon-related issue that could be cleaned up while this is being worked on:
- "Manage Jenkins » Script Console", "Build History", "(Build) » Changes", and "(Build) » Edit Build Information" use the same icon
- as do "Manage Jenkins » CLI", "Console Output", and "(Node) » Script Console"
Yeah, so fair questions...
...and my list here definitely remains an ask, not a tell.
What I mean by device friendly, is that a font can scale in size, up or down, to fit into a variety of screen sizes in a way that an image does not. Additionally, a font can take advantage of your phone or pad's anti-aliasing to get that full sub-pixel clarity out of your Retina display. And in general, a phone's cache space and browsing bandwidth are going to be more variable and limited, so reducing download size and number of requests is particularly helpful for less powerful devices.
...granted phones are getting better and better, but when would you ever want a page to load more slowly, even as that margin of difference goes down?
Here is an article that lays out the main arguments for why font icons are good:
1) Number and size of server requests, in a bare-bones Jenkins install I count 15 server requests for icons, that may not seem like a ridiculous number of additional requests, but it is more than an order of magnitude more requests than are necessary.
2) Vector based imagery is easier to deal with for page design and readability
3) Fonts are easily programmatically and CSS manipulatable to reflect states and status in a way that images are not
4) Using fonts provides a convenient way to package a base-pack of icons plugin authors can easily borrow from
5) The simplification forced by the abstraction into a single color makes creation of new and matching icons a little easier
6) At the moment, anyway, they are on-trend, or at least have a bit more modern vibe than the Tango Feet icon pack, currently in use
I think you are right, the big down-side is the lack of multiple colors and the relative ease of creating 1-off custom icons as a PNG. It is hard to beat the tried-and-true bitmap for whipping up that 1 button you need right this second. If we were to embrace font-based icons, we would definitely need to handle backwards compatibility, so my hope would be that if a community member wanted to use PNGs, they still could. Conceivably, by swapping CSS files, they could swap fonts for PNGs on a global basis, if that was the users preference.
--
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.
Moving away from <img> based icons to using CSS does not mean
we have to change the actual icons that are visible to the user, so
I think maybe we can avoid a debate on that for now. I'm currently
working on the CSS to back this up and, at the moment, the user
still sees the same old icons.
Here's a gist of what the CSS look like atm: https://gist.github.com/tfennelly/f43c42c7efa68dd701cc . We could obviously clean that up a lot using a CSS preprocessor (ala Less), but I think you can get the point that after making this change, it will be a lot easier to change how we handle icons e.g. one could easily use the old icons of today, or swap in something like Font Awesome.
From a Jelly point of view... I updated the <task> tag + there's a simple <l:icon> tag. Some examples:
Here's a gist of what the CSS look like atm: https://gist.github.com/tfennelly/f43c42c7efa68dd701cc . We could obviously clean that up a lot using a CSS preprocessor (ala Less), but I think you can get the point that after making this change, it will be a lot easier to change how we handle icons e.g. one could easily use the old icons of today, or swap in something like Font Awesome.
From a Jelly point of view... I updated the <task> tag + there's a simple <l:icon> tag. Some examples:
- <l:icon name="document_add-16x16"/> (instead of <img
src="${imagesURL}/16x16/document_add.png"/>)
- <l:task href="${rootURL}/" icon="up-24x24" title="${%Back
to Dashboard}"/>
- I've also written a tool that can be used to search through all the .jelly files in a filesys tree and replace the existing icon markup with the what we'd be proposing as the new task/icon tags.
- I will write a Jenkins plugin to make the tags backward
compatible on earlier version of Jenkins.
Btw... we created a Trello board in an effort to help track this work a bit: https://trello.com/b/RmlNnRxq/jenkins-ui-refresh
On Friday, June 20, 2014 11:20:29 PM UTC+1, Tom Fennelly wrote:Moving away from <img> based icons to using CSS does not mean we have to change the actual icons that are visible to the user, so I think maybe we can avoid a debate on that for now. I'm currently working on the CSS to back this up and, at the moment, the user still sees the same old icons.
I created a WIP pull request for jenkins core changes relating to this: https://github.com/jenkinsci/jenkins/pull/1297
After talking to Stephen Connolly, seems like the best first step is a straight replacement for the img icons with an icon tag that just renders the img as is. A future changeset can introduce CSS.
So... working on this now: https://github.com/tfennelly/jenkins/tree/icon-tag
I've just translated the "obvious" ones so far (ones that I could automate the translation of via script)... need to do another sweep now and translate the less obvious ones.
On Thu, Jun 19, 2014 at 3:10 PM, Ulli Hafner <ullrich...@gmail.com> wrote:Why not just encourage broader use of Folders?
> When improving the UI we should focus on the most widely spread Jenkins installations which do not use the folders plugin.
Guys, I broke out a new thread for a discussion on icons ... https://groups.google.com/forum/?hl=en#!topic/jenkinsci-dev/GOiQdvctBB0
Hello,
I did a PR to allow better UI on mobile devices.
Could someone pls review that?
https://github.com/jenkinsci/jenkins/pull/1070
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
I did a PR to allow better UI on mobile devices.
Could someone pls review that?
https://github.com/jenkinsci/jenkins/pull/1070
> --
On Fri 27 Jun 2014 01:22:52 PM BRT, Tom Fennelly wrote:
> Guys, I broke out a new thread for a discussion on icons
> ... https://groups.google.com/forum/?hl=en#!topic/jenkinsci-dev/GOiQdvctBB0
>
> 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> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> an email to jenkinsci-de...@googlegroups.com
On Wednesday, July 2, 2014 7:05:02 PM UTC+1, Bruno Kühnen Meneguello wrote:Hello,
I did a PR to allow better UI on mobile devices.
Could someone pls review that?
https://github.com/jenkinsci/jenkins/pull/1070
Hey Bruno. Thanks for that. This work looks very compatible/complementary to https://github.com/jenkinsci/jenkins/pull/1310. I wonder if we could merge the two efforts?
Sure! How can we coordinate this?
--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.
Sure!
> --> <mailto:jenkinsci-dev+unsubscribe@googlegroups.com>.
> 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
Hi Gents,
I need to rename the build button to "deploy" for one of the jobs and "commit" for another job. Not able to find out hot to accomplish the same . Can you please let me know if this possible to do in Jenkins.
Any help will be appreciated .
Regards,
Arun
On Monday, May 26, 2014 7:24:21 PM UTC+5:30, 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:
- 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
- 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:
- 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.
- 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.
- Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
- 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.
hi folks,
i would love to contribute to this UI refresh.
i am looking for ressources to understand how it is organised and how to test my new theme locally. (i know nothing about java, i am a front end dev)
i can't find docs about theming, can you show me please ?
Hey Kayn!
Awesome.
Unfortunately, theming has died on the vine here a little bit. My friend and co-worker, Tom Fennelly had/has queued up some some core changes for Jenkins geared toward enabling LESS driven CSS to manipulate a significant portion of the Jenkins GUI, but that PR died in review.
Since then, he and I with some guidance from KK and Daniel Beck have been looking for inroads to refactor the existing Jenkins DOM to be a little more semantic and refactor the Javascript to be a little more modern and a little more amenable to testing via Node.js and Jasmine.
...so the good news is that you are at the very front of the line for providing input on how all this should be done. The bad news is that at the moment, there isn't really any doc, largely because the enabling infrastructure isn't yet fully born.
If you can tolerate some amount of work-in-progress vibe, feel free to contact me direction and I will do what I can to get you up and show you around, greiber(at-sign)cloudbees(dot-com).
You can also follow my efforts (an any other Jenkins GUI efforts I am aware of) via Twitter: @gusreiber
You can also follow me on Google+: plus.google.com/+GusReiberUI/posts
I also think it would be great for those who are less into java to be able to focus on the UI (as Kayn mentioned on another thread), a worthy goal.
On Wednesday, October 7, 2015 at 6:09:17 AM UTC+1, Michael Neale wrote:I also think it would be great for those who are less into java to be able to focus on the UI (as Kayn mentioned on another thread), a worthy goal.
Right, using more modern JS frameworks + being able to upgrade them (+ being able to deprecate them when they become extinct) should help this. That said, because of how Jenkins is built, I don't think people will be totally able to avoid Java and Jelly unless they are really really lucky.
glad to hear it is still up!
no problem with jelly, i am used to Twig template engine and Angularjs, it should be not so different.
I recommend to use NPM and Gulp for front-end workflow improovements (auto refreshing localhost, compiling, concatenating, managing dependencies, check test coverage).
I personally prefer SASS than less to compile the css, it is more powerful and fast.
Jasmine is also a great companion to test things.
bootstrap and font-awesome are also great sidekicks to theme with ease. All these tools could be launched easily when you start from scratch by an other one called Yeoman webapp generator ("yo" on NPM).
so as a first step i cloned the official repo to my own github
i also found this uitheme plugin, https://github.com/jenkinsci/uithemes-plugin maybe i would be more efficient to contribute on this if i want to build a custom theme, but i should first understand how to make a processor module if i understood well the readme.
Hi Kayn.
There's also an ongoing conversation about Jenkins 2.0. It's hoped that a big part of this will be improvements to the UX. KK listed UX as being high on his wish list.
From a UX perspective, we've been trying to put some things in place to help us do things better (using more modern tools, better patterns etc). See my early contribution on this topic to the Jenkins 2.0 thread. Hopefully it will help give some perspective.
Regards,
Tom.