On Monday, May 26, 2014 3:36:23 PM UTC+1, Bruno Kühnen Meneguello wrote: > > I totally agree with you. > > I've started a mobile UI and noted how difficult is to change some things, > just because the layout is entirely locked inside tables. > Right... tables are evil for anything more than tabular data... they can make the initial layout easy but then it's locked. Also.... styling can be a pain in the ass.
> Although to "boil the ocean" should be a lot o work, maybe a major > rewrite of Jenkins interface (I liked the REST idea) will bring much more > responsiveness and reduce the bandwidth traffic that Jenkins needs today. > Our initial thoughts were that this would be a bridge too far but now I'm thinking it might be the only way to do anything meaningful in a somewhat predictable fashion. > Another great advantage is to adapt to distinct screens and layouts much > better and to add the possibility to override the default stylesheet with > plugins to fine tune. > > I personally access Jenkins frequently via smartphone and in my company it > is shown in a big screen and we have some difficult to lay out all jobs (we > don't use extreme feedback plugins). With a more semantic page design, > based in CSS, it could be more easy to adapt. > Right... this type of thing is easy enough with <div>s and css and media tags. The simple mockup I did does some of this i.e. the sidepanel drops off if the screen becomes too narrow. > If you want to make it happens, I want to collaborate. > Em 26/05/2014 10:54, "Tom Fennelly" <tom.fe...@gmail.com <javascript:>> > 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<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 jenkinsci-de...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
