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" <tom.fenne...@gmail.com
<mailto:tom.fenne...@gmail.com>> 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-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
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.
