Refreshing the Jenkins UI

classic Classic list List threaded Threaded
136 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Refreshing the Jenkins UI

Tom Fennelly
Hi guys.

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

What I've experimented with so far:
  1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
  2. Modified the main project/job configuration page, in an effort to make it less cluttered, by adding accordions for the different config sections.  The only way I found I could do this was to wire in some javascript to manipulate the page post-rendering.  Kohsuke says there's a way of doing the bulk of the DOM manipulation within Jelly templates, but I failed to work that one out yet - I'm sure it will be "obvious" after I see it :)  Not sure if accordions are the correct choice.  Here's a screenshot of what it looks like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png
The above commit obviously breaks things e.g. the breadcrumbs + some of the styling is screwed up (I added Twitter bootstrap, causing the css's to clash).  What I've done so far is really just hacking to see what we could do.  I'm keen to hear the opinions of the community... what people thing we should concentrate on... what should we avoid... what are the risks etc etc.  I'm aware there is some prior art in this area e.g. OHTAKE Tomohiro's work, the Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:
  1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
  2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
  3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
  4. New more "modern" icons?
After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

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

Regards,

Tom.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Bruno Kühnen Meneguello

I totally agree with you.

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

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

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

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

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

Em 26/05/2014 10:54, "Tom Fennelly" <[hidden email]> 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:
  1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
  2. Modified the main project/job configuration page, in an effort to make it less cluttered, by adding accordions for the different config sections.  The only way I found I could do this was to wire in some javascript to manipulate the page post-rendering.  Kohsuke says there's a way of doing the bulk of the DOM manipulation within Jelly templates, but I failed to work that one out yet - I'm sure it will be "obvious" after I see it :)  Not sure if accordions are the correct choice.  Here's a screenshot of what it looks like: https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png
The above commit obviously breaks things e.g. the breadcrumbs + some of the styling is screwed up (I added Twitter bootstrap, causing the css's to clash).  What I've done so far is really just hacking to see what we could do.  I'm keen to hear the opinions of the community... what people thing we should concentrate on... what should we avoid... what are the risks etc etc.  I'm aware there is some prior art in this area e.g. OHTAKE Tomohiro's work, the Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:
  1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
  2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
  3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
  4. New more "modern" icons?
After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

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

Regards,

Tom.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Daniel Beck
In reply to this post by Tom Fennelly

On 26.05.2014, at 15:54, Tom Fennelly <[hidden email]> 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?

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

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

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


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

Nice.  That job config is looking good :)


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

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


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

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

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

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


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

Regards,
Chris

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Daniel Beck

On 26.05.2014, at 21:08, Christopher Orr <[hidden email]> wrote:

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

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

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

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

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

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

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

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

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

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

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Michael Neale


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

On 26.05.2014, at 21:08, Christopher Orr <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="hCHzbI_rXowJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">ch...@...> 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 ;)

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Michael Neale
In reply to this post by Christopher Orr


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:
<a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;">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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

domi@fortysix.ch
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:
…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
...

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


On 27.05.2014, at 05:10, Michael Neale <[hidden email]> 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:
<a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;">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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Tom Fennelly
In reply to this post by Bruno Kühnen Meneguello

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" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="HQOQ8ifV1f8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">tom.fe...@...> 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 <a href="https://github.com/tfennelly/jenkins/tree/ui-refresh" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Ftree%2Fui-refresh\46sa\75D\46sntz\0751\46usg\75AFQjCNHH3_SAhlsBRQUrmnP3B-R7ohpB4Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Ftree%2Fui-refresh\46sa\75D\46sntz\0751\46usg\75AFQjCNHH3_SAhlsBRQUrmnP3B-R7ohpB4Q';return true;">https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... <a href="https://github.com/tfennelly/jenkins/commit/d586be517616a3ba33ac11c6b5a85965d473c8ab" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Fcommit%2Fd586be517616a3ba33ac11c6b5a85965d473c8ab\46sa\75D\46sntz\0751\46usg\75AFQjCNFAitkfsXXabbWJQDFMfoleOcah_g';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Fcommit%2Fd586be517616a3ba33ac11c6b5a85965d473c8ab\46sa\75D\46sntz\0751\46usg\75AFQjCNFAitkfsXXabbWJQDFMfoleOcah_g';return true;">Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:
  1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: <a href="https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;">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: <a href="https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;">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. <a href="https://github.com/jenkinsci/jenkins/tree/ui-changes" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;">OHTAKE Tomohiro's work, the <a href="https://wiki.jenkins-ci.org/display/JENKINS/Simple+Theme+Plugin" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FSimple%2BTheme%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNEz1hVV8pn8wUStCDyR58aA-23ptA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FSimple%2BTheme%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNEz1hVV8pn8wUStCDyR58aA-23ptA';return true;">Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:
  1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
  2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
  3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
  4. New more "modern" icons?
After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

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

Regards,

Tom.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="HQOQ8ifV1f8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jenkinsci-de...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Tom Fennelly
In reply to this post by Daniel Beck

On Monday, May 26, 2014 7:22:31 PM UTC+1, Daniel Beck wrote:

On 26.05.2014, at 15:54, Tom Fennelly <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3g6CnFquez4J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">tom.fe...@...> 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?

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

stephenconnolly
Here's a nice set of flat icons:

Inline images 1


On 27 May 2014 09:57, Tom Fennelly <[hidden email]> wrote:

On Monday, May 26, 2014 7:22:31 PM UTC+1, Daniel Beck wrote:

On 26.05.2014, at 15:54, Tom Fennelly <[hidden email]> 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?

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Tom Fennelly
In reply to this post by Christopher Orr


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

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

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


> What I've experimented with so far:
>
>  1. Tweaking the main layout in
>     core/src/main/resources/lib/layout/layout.jelly (and added some CSS
>     to style.css).  Everything was layed out with tables, so I changed
>     that to use divs instead, allowing us to more easily do things like
>     make the sidebar disappear on small screens (if that was a good
>     idea) etc etc.  Here's a screenshot of
>     that: <a href="https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;">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: <a href="https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;">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.
<a href="https://github.com/Dakota628/jenkins-clean-theme" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FDakota628%2Fjenkins-clean-theme\46sa\75D\46sntz\0751\46usg\75AFQjCNHQJ4yFepGt2DaMcOAe1DxW8RuHqw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FDakota628%2Fjenkins-clean-theme\46sa\75D\46sntz\0751\46usg\75AFQjCNHQJ4yFepGt2DaMcOAe1DxW8RuHqw';return true;">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:
<a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;">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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Tom Fennelly
In reply to this post by domi@fortysix.ch


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:
<a href="https://github.com/jenkinsci/jenkins/tree/ui-changes" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;">https://github.com/jenkinsci/jenkins/tree/ui-changes
In JIRA we also created a special component (ui-changes) to keep track of all this: <a href="https://issues.jenkins-ci.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+Jenkins+and+component+%3D+ui-changes&amp;runQuery=true&amp;clear=true" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fissues.jenkins-ci.org%2Fsecure%2FIssueNavigator!executeAdvanced.jspa%3FjqlQuery%3Dproject%2B%253D%2BJenkins%2Band%2Bcomponent%2B%253D%2Bui-changes%26runQuery%3Dtrue%26clear%3Dtrue\46sa\75D\46sntz\0751\46usg\75AFQjCNEd-5uUYeDQqSHyOAIzsn-U_M0vsA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fissues.jenkins-ci.org%2Fsecure%2FIssueNavigator!executeAdvanced.jspa%3FjqlQuery%3Dproject%2B%253D%2BJenkins%2Band%2Bcomponent%2B%253D%2Bui-changes%26runQuery%3Dtrue%26clear%3Dtrue\46sa\75D\46sntz\0751\46usg\75AFQjCNEd-5uUYeDQqSHyOAIzsn-U_M0vsA';return true;">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
- <a href="https://github.com/rackerlabs/canon-jenkins" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Frackerlabs%2Fcanon-jenkins\46sa\75D\46sntz\0751\46usg\75AFQjCNH9JWHbckXGrwZ7ToPQVOmq5cyi7g';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Frackerlabs%2Fcanon-jenkins\46sa\75D\46sntz\0751\46usg\75AFQjCNH9JWHbckXGrwZ7ToPQVOmq5cyi7g';return true;">https://github.com/rackerlabs/canon-jenkins
- <a href="https://github.com/djonsson/jenkins-atlassian-theme" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjonsson%2Fjenkins-atlassian-theme\46sa\75D\46sntz\0751\46usg\75AFQjCNFVC6X4DnYk3LIkGLWBufQFvfs4gg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdjonsson%2Fjenkins-atlassian-theme\46sa\75D\46sntz\0751\46usg\75AFQjCNFVC6X4DnYk3LIkGLWBufQFvfs4gg';return true;">https://github.com/djonsson/jenkins-atlassian-theme -> <a href="http://test.do/" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftest.do%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHaRKm9KeTkvXBf1AV3NiWOVVB2Cw';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftest.do%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHaRKm9KeTkvXBf1AV3NiWOVVB2Cw';return true;">http://test.do/ (making Jenkins look like bamboo)
- <a href="http://isotope11.com/blog/styling-your-jenkins-continuous-integration-server" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fisotope11.com%2Fblog%2Fstyling-your-jenkins-continuous-integration-server\46sa\75D\46sntz\0751\46usg\75AFQjCNGQYWX_lz_PWNpLc-vaWoxcnL3dGA';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fisotope11.com%2Fblog%2Fstyling-your-jenkins-continuous-integration-server\46sa\75D\46sntz\0751\46usg\75AFQjCNGQYWX_lz_PWNpLc-vaWoxcnL3dGA';return true;">http://isotope11.com/blog/styling-your-jenkins-continuous-integration-server
...

As a reference, there are also the notes we made about the discussions we had at another FOSDEM: <a href="https://wiki.jenkins-ci.org/display/JENKINS/UI+Enhancements" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FUI%2BEnhancements\46sa\75D\46sntz\0751\46usg\75AFQjCNFVu74w7SA_DXqilGjKCGM3_Z0ydQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FUI%2BEnhancements\46sa\75D\46sntz\0751\46usg\75AFQjCNFVu74w7SA_DXqilGjKCGM3_Z0ydQ';return true;">https://wiki.jenkins-ci.org/display/JENKINS/UI+Enhancements

Great stuff... thanks Domi.
 

Domi


On 27.05.2014, at 05:10, Michael Neale <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Cfe-7HbTqtIJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">michae...@...> 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:
<a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Cfe-7HbTqtIJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jenkinsci-de...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Tom Fennelly
In reply to this post by stephenconnolly
Very nice.... thanks Stephen ;)

On Tuesday, May 27, 2014 10:12:28 AM UTC+1, Stephen Connolly wrote:
Here's a nice set of flat icons:

Inline images 1


On 27 May 2014 09:57, Tom Fennelly <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="fRAB3MfhIc8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">tom.fe...@...> wrote:

On Monday, May 26, 2014 7:22:31 PM UTC+1, Daniel Beck wrote:

On 26.05.2014, at 15:54, Tom Fennelly <[hidden email]> 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?

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

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="fRAB3MfhIc8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jenkinsci-de...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

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

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

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

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

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

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Jesse Glick-4
In reply to this post by Daniel Beck
On Mon, May 26, 2014 at 5:41 PM, Daniel Beck <[hidden email]> wrote:
> It's possible to save forms with errors.

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

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

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

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

I think these things should be admin warnings.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Ioannis Moutsatsos-2
In reply to this post by Tom Fennelly
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--

On Monday, May 26, 2014 9:54:21 AM UTC-4, 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 <a href="https://github.com/tfennelly/jenkins/tree/ui-refresh" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Ftree%2Fui-refresh\46sa\75D\46sntz\0751\46usg\75AFQjCNHH3_SAhlsBRQUrmnP3B-R7ohpB4Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Ftree%2Fui-refresh\46sa\75D\46sntz\0751\46usg\75AFQjCNHH3_SAhlsBRQUrmnP3B-R7ohpB4Q';return true;">https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... <a href="https://github.com/tfennelly/jenkins/commit/d586be517616a3ba33ac11c6b5a85965d473c8ab" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Fcommit%2Fd586be517616a3ba33ac11c6b5a85965d473c8ab\46sa\75D\46sntz\0751\46usg\75AFQjCNFAitkfsXXabbWJQDFMfoleOcah_g';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Fcommit%2Fd586be517616a3ba33ac11c6b5a85965d473c8ab\46sa\75D\46sntz\0751\46usg\75AFQjCNFAitkfsXXabbWJQDFMfoleOcah_g';return true;">Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:
  1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: <a href="https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;">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: <a href="https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;">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. <a href="https://github.com/jenkinsci/jenkins/tree/ui-changes" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;">OHTAKE Tomohiro's work, the <a href="https://wiki.jenkins-ci.org/display/JENKINS/Simple+Theme+Plugin" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FSimple%2BTheme%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNEz1hVV8pn8wUStCDyR58aA-23ptA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FSimple%2BTheme%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNEz1hVV8pn8wUStCDyR58aA-23ptA';return true;">Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:
  1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
  2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
  3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
  4. New more "modern" icons?
After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

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

Regards,

Tom.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Tom Fennelly
Thanks Ioannis.

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

On Tuesday, May 27, 2014 4:50:35 PM UTC+1, Ioannis Moutsatsos 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!

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

On Monday, May 26, 2014 9:54:21 AM UTC-4, 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 <a href="https://github.com/tfennelly/jenkins/tree/ui-refresh" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Ftree%2Fui-refresh\46sa\75D\46sntz\0751\46usg\75AFQjCNHH3_SAhlsBRQUrmnP3B-R7ohpB4Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Ftree%2Fui-refresh\46sa\75D\46sntz\0751\46usg\75AFQjCNHH3_SAhlsBRQUrmnP3B-R7ohpB4Q';return true;">https://github.com/tfennelly/jenkins/tree/ui-refresh.  As you might notice... <a href="https://github.com/tfennelly/jenkins/commit/d586be517616a3ba33ac11c6b5a85965d473c8ab" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Fcommit%2Fd586be517616a3ba33ac11c6b5a85965d473c8ab\46sa\75D\46sntz\0751\46usg\75AFQjCNFAitkfsXXabbWJQDFMfoleOcah_g';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ftfennelly%2Fjenkins%2Fcommit%2Fd586be517616a3ba33ac11c6b5a85965d473c8ab\46sa\75D\46sntz\0751\46usg\75AFQjCNFAitkfsXXabbWJQDFMfoleOcah_g';return true;">Daniel Beck has already posted some good comments/feedback on the commit.

What I've experimented with so far:
  1. Tweaking the main layout in core/src/main/resources/lib/layout/layout.jelly (and added some CSS to style.css).  Everything was layed out with tables, so I changed that to use divs instead, allowing us to more easily do things like make the sidebar disappear on small screens (if that was a good idea) etc etc.  Here's a screenshot of that: <a href="https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fvngs5jjailatanq%2FScreenshot%25202014-05-26%252012.49.31.png\46sa\75D\46sntz\0751\46usg\75AFQjCNHwSwKaAGIqaaawMqrofqUr57DP_Q';return true;">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: <a href="https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwww.dropbox.com%2Fs%2Fwsy96r1czhzhy5z%2FScreenshot%25202014-05-26%252012.54.39.png\46sa\75D\46sntz\0751\46usg\75AFQjCNFMSw-Ipvggb_zxPxjk-9tRLAoADg';return true;">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. <a href="https://github.com/jenkinsci/jenkins/tree/ui-changes" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Ftree%2Fui-changes\46sa\75D\46sntz\0751\46usg\75AFQjCNG1iaxPXTNrBDQV5lxjjLaij9MEoQ';return true;">OHTAKE Tomohiro's work, the <a href="https://wiki.jenkins-ci.org/display/JENKINS/Simple+Theme+Plugin" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FSimple%2BTheme%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNEz1hVV8pn8wUStCDyR58aA-23ptA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fwiki.jenkins-ci.org%2Fdisplay%2FJENKINS%2FSimple%2BTheme%2BPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNEz1hVV8pn8wUStCDyR58aA-23ptA';return true;">Simple Theme Plugin and others.

General comments/challenges/risks, as I see it:
  1. Jelly + Stapler are not the easiest to work with.  At least I've found it quite difficult to figure out where to make changes.  Sometimes it was obvious.... other times it was anything but e.g. tweaking the project config page to get Jelly to create a series of <table> elements (Vs one uber <table>).  In the end... I found it easier to do it post-rendering via Javascript, which is not good imo.
  2. What will be the effect on plugins of changing project config layout.  I already see some strange behaviour e.g. I added an "Execute shell" build step... it works fine in the "uber <table>" layout, but is screwed up after I manipulate it - prob easy to fix, but still an indication that some of the plugins are sensitive to changes in their surroundings.
  3. Use of <table> for layout seems to be quite popular Vs using <div> + CSS.
  4. New more "modern" icons?
After a few brief conversations with some of my colleagues at CloudBees (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most "doable" approach for now is to stick with making changes to what's there right now i.e. jelly templates, javascript and CSS.  We also talked (not in detail) about the possibility of working towards more modern technologies and approaches e.g. a Single Page App using the Jenkins REST API Vs the current server-side approach with Stapler and Jelly.  To do that now, however, seems a bit like trying to "boil the ocean" (quoting one of the guys there).  What do you guys think?

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

Regards,

Tom.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Tom Fennelly
In reply to this post by Tom Fennelly


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


On Monday, May 26, 2014 8:08:28 PM UTC+1, Christopher wrote:
As you may have seen, this is something Tyler did some work on during 
FOSDEM last year.  The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
<a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;">https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y

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


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

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

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

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

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Refreshing the Jenkins UI

Kanstantsin Shautsou-2
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.


On Wednesday, May 28, 2014 12:24:26 PM UTC+3, Tom Fennelly wrote:


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


On Monday, May 26, 2014 8:08:28 PM UTC+1, Christopher wrote:
As you may have seen, this is something Tyler did some work on during 
FOSDEM last year.  The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
<a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;">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.


<a href="https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y" target="_blank" onmousedown="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;" onclick="this.href='https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y';return true;">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.
 

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
1234 ... 7