I don't really see it as an either/or type thing. I don't see the Jelly/stapler way of doing things ever going away. At this stage I don't really think it's practical to try replace it with something else and, in any case, I don't think we need to replace it (HTML5 concerns aside). What I thought we were talking about doing was "adding" things on top of what's already there i.e. jelly etc stays as it is, allowing what's "good" about jelly (depending on your opinion :) ) to continue being one of Jenkins "advantages", while at the same time we start introducing new libraries/patterns/etc on top that so we can hopefully help people build richer controls within Jenkins.
So trying to be a bit more concrete: 1. LESSification of CSS within Jenkins core (e.g. what we started doing with the UI Themes plugin <https://github.com/jenkinsci/uithemes-plugin>), allowing us to modularise and parameterise how we do CSS in Jenkins core and Jenkins plugins. 2. Cleanup how core/foundational Javascript libraries are used in Jenkins (e.g. jQuery, Twitter Bootstrap etc) such that plugins and core can be evolved to safely use different versions of these libraries within the same Jenkins instance i.e. an old version of a plugin using an old version of Bootstrap should be able to live alongside a newer plugin using a newer version of Bootstrap. And to do this without every component loading their own jQuery, or other such hackery. 3. Provide better tools for doing modularised Javascript in aid of richer UI components e.g. building on things like CommonJS, Browserify, Gulp. - We (at CloudBees) have experimented with some of these things while building extensions for Jenkins Workflow. We've also experimented with them in the UI Themes plugins <https://github.com/jenkinsci/uithemes-plugin>. Formalising some of what was learned there could be a start. - Again ... none of these things are replacing Jelly. They are simply building on top of them and hopefully making them more powerful in terms of the UX that can achieved. 4. Develop/suggest client side coding patterns. Move away from the "hudson-behaviors.js" type anti-patterns. - Again, we have experimented with some things here when doing the Workflow extensions and the UI Themes plugin. - We looked at trying to use things like AngularJS etc but came to the conclusion that they were not appropriate for a number of reasons e.g. too heavyweight + not appropriate for building widgets/"app-lets" in a Jelly world (frameworks like angularjs want to control/own the entire page/app). - We ended up building a very simple lightweight MVC style "pattern" (supported by some libs). I purposely used the word "pattern" here because I would not call what we did a "framework" ala angularjs, so need to get too scared :) 5. I like the idea of allowing Jenkins Core switch UIs on a per user basis. Jenkins is just so huge now that it seems crazy to think that we can have one nice UI that's nice for everyone. Seems to me that an ops guy logging into Jenkins wants to see different things than a Dev guy etc. We already have evidence of this need by virtue of the fact that so many people have build their own UIs for Jenkins (complete UIs). I think it would be good to investigate whether or not we could formalise this in some way and make it easier for people to both develop and use different Jenkins "perspectives" (as one of my other CloudBees colleagues suggested calling it - ala Eclipse perspectives). By "use" I mean making it easy for a user to switch between perspectives. The current Jenkins UI could be the "Advanced" perspective. On 8 March 2015 at 06:52, Arnaud Héritier <[email protected]> wrote: > Hi Gus, > > Myself I would love to see a Jenkins bringing a modern HTML/Web/JS > framework based on rest services BUT from my point of view it is often many > more difficult than a templating technology (Jelly, whatever) where you > just insert some dynamic stuffs in a HTML page. > What is making Jenkins so different compared to many other softs is its > large and heterogeneous community and I'm not sure such a modern JS/HTML5 > technology could have a large adoption like Jelly nowadays. Jelly UI is > perhaps ugly but it is easy to use. If Jenkins gives access to another UI > framework to developers it will have to be easy to use (or we'll have to > keep the jelly version for all plugins where there are contributors who > don't have a black belt of HTML5/CSS/JS/...). > > Arnaud > > > On Sat, Mar 7, 2015 at 11:19 PM, Gus Reiber <[email protected]> wrote: > >> Hey all, >> So it has been 2 weeks since my last post, so I want to bring everyone >> up to speed with our latest thinking at CloudBees. >> As we look around the web, we see some exciting things going on in the >> CD/CI space with tools like Docker, Codeship, Drone.io, Travis-CI, and >> Werker. >> >> These tools, while not nearly as flexible and powerful as the Jenkins >> platform have some nice things about them, especially on the >> approach-ability and usability fronts. >> Being GUI focused as I am, these tools all have a very HTML5ish vibe to >> them that I quite like. >> >> So my questions for this group are as follows: >> >> - Have any of you used any of these tools, and what do you think of >> them? >> - If you haven't used these tools but are familiar with HTML5 style >> apps, what would you think of Jenkins moving in that direction (knowing >> also such a move might have disruptive elements to it)? >> - Perhaps more controversially, could you imagine (would you want to >> image) a world were the Jelly style servlets began to be depreciated in >> favor of a more RESTful, client MVC model of GUI building? >> - and finally, if you are imagining this RESTful world, what sort of >> extension points would you want or need (or other resources) to make >> successful plugins? >> >> As always, any feedback is good feedback. >> I am eager to help keep this thread near the top of this Dev list. >> >> Thanks Again, >> Gus >> >> >> >> On Wednesday, February 18, 2015 at 8:27:12 AM UTC-8, Gus Reiber wrote: >> >>> At the end of last summer, my friend and co-worker, Tom Fennelly >>> <https://github.com/tfennelly>, along with the help of Kevin Burke >>> <https://github.com/kevinburke>, Daniel Beck >>> <https://github.com/daniel-beck>, and others began the first steps of >>> improving and modernizing the Jenkins user experience. In addition to some >>> of the superficial enhancements, these changes are meant to add a bit of >>> responsiveness and cross-device usability to the Jenkins GUI, as well as >>> adding a means of creating and swapping new CSS based display themes. This >>> effort is best summarized by this article from Jenkins-ci.org, and this >>> thread from the Jenkinsci-users group: >>> >>> - *User Interface Refresh >>> <http://jenkins-ci.org/node/501#disqus_thread>:* http://jenkins-ci. >>> org/node/501#disqus_thread >>> - *Any comments on the UI changes in 1.572 >>> >>> <https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J>:* >>> https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/ >>> jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J >>> >>> <https://groups.google.com/forum/#!searchin/jenkinsci-users/ui$20tom/jenkinsci-users/ULEV87g9iac/LaTt5J2tHV8J> >>> >>> As part of our second wave effort here at CloudBees, I am looking at >>> ways of improving the usability of the Jelly based form controls used in >>> the item creation and configuration pages and the responsiveness and >>> interactivity of the main dashboard grid control. >>> >>> In my investigations so far, I believe there are essentially 3 >>> non-exclusive paths forward for enhancing these elements: >>> >>> 1. *CSS only --* Building on the last round of enhancements, we can >>> offer a set of theme extensions that will allow the Jenkins users and >>> community to customize basic layout, iconography, and typeface to tailor >>> Jenkins to their own tastes. >>> 2. *UI component expansion and refactoring --* By modifying and >>> adding to the existing set of Jelly files and their corresponding data >>> binding rules we can significantly modernize the way Jenkins views and >>> configs draw themselves and potentially streamline plugin creation. >>> 3. *Client side MVC veneers --* In a manner similar to what >>> CloudBees has recently done with the new Workflow visualization, we can >>> rethink our approach to new feature UIs by using a REST API based >>> architecture coupled with client-side rendering widgets. This would allow >>> us to use newer framework libraries like Angular.js and newer component >>> libraries like Bootstrap and JQuery UI to add greater richness to the >>> Jenkins user experience. >>> >>> These are likely not the only paths forward, but merely the first I can >>> think of. With that reality in mind, I am hoping to reach out to you the >>> Jenkins community to help ground and sculpt our thinking about what is both >>> possible and desirable. >>> >>> If you are at all interested in the Jenkins user experience, I would >>> love to get your feedback of any sort on this thread, which could be as >>> simple as a "+1" or as involved as a PHD thesis or as much as you have time >>> to type into a response box. >>> >>> To the extent that it helps conversation along, I also have a handful of >>> questions to which I would love responses: >>> >>> 1. For plugin builders, can you tell me a bit about creating the UI >>> portion of your plugin (did you use the data binding form controls, what >>> was hard, what did you have to invent)? >>> 2. For regular Jenkins users, what are the UX areas of Jenkins you >>> would most like to see improved (I think it is the item create/config and >>> the dashboard/job list grid, but would love to hear others and general >>> feedback)? >>> 3. For UXers and other Jenkins contributors, how do my 3 forward >>> paths seem (are there others, do you have experience with any yourself, >>> do >>> any seem scary)? >>> 4. Has anyone tried to make their own themes with the new >>> capabilities Tom has added or would you appreciate and handful of canned >>> options to choose between? >>> 5. Has anyone started using Workflow on a regular basis, and in >>> particular used the new workflow progress visualization enough to offer >>> feedback? >>> >>> >>> Again, if any of you all are at all interested in the Jenkins UX, we at >>> CloudBees are interested in helping move this ball forward and would love >>> to hear your feedback. >>> >>> Thanks for your help, >>> Gus >>> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/34635bd0-0562-4acc-bc73-da4956bb66cb%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/34635bd0-0562-4acc-bc73-da4956bb66cb%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > ----- > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9%3D%3DOgTThRLMccMWKGbRJ-%3Dmhctr-f%2B7uG44QiT_Wx70Q%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9%3D%3DOgTThRLMccMWKGbRJ-%3Dmhctr-f%2B7uG44QiT_Wx70Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoK%2B15ZiuMLG%3DP%2B-Xqxrqx_ts%3DaQHQRX-i6m6TCvwGo2MQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
