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

Reply via email to