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 > https://github.com/tfennelly/jenkins/tree/ui-refresh. As you might > notice... Daniel Beck has already posted some good comments/feedback on > the > commit<https://github.com/tfennelly/jenkins/commit/d586be517616a3ba33ac11c6b5a85965d473c8ab> > . > > 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 <https://github.com/jenkinsci/jenkins/tree/ui-changes>, > the Simple Theme > Plugin<https://wiki.jenkins-ci.org/display/JENKINS/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 [email protected]. For more options, visit https://groups.google.com/d/optout.
