On 05/26/2014 03:54 PM, 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.
You often hear people say "the Jenkins UI is bad", but it's usually said
that there's a lack of concrete examples of *why* it's bad. So, just
out of curiosity, is there a list somewhere of the main usability issues
that you've been working on?
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
Nice. That job config is looking good :)
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?
I guess it depends what the goal is. If it's just "refreshing the UI",
then continuing with the changes so far and perhaps building on some of
the nice existing CSS themes out there would be reasonable, e.g.
https://github.com/Dakota628/jenkins-clean-theme
But having seen a colleague of mine use the Jenkins API and AngularJS to
build some really nice (though narrowly focussed) Jenkins front-ends for
internal apps, dashboards and for customer use, I really like the idea
of building the Jenkins UI on top of its API.
As you may have seen, this is something Tyler did some work on during
FOSDEM last year. The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y
From a user's standpoint, I actually remain fairly happy with the UI,
and I don't tend to hear complaints from colleagues about it...
But I think an "API first" way of thinking would be cool and, although
being cool and modern is not a concrete benefit in itself, it would
(hopefully) make it easier for people to build upon the API, or to make
ongoing improvements to the Jenkins UI, without really having to know
about Java or any of the fairly Jenkins-specific technologies in use
just now.
Regardless of what happens, so long as one day I can click "Build Now"
and don't need to hover my mouse over the Build History, waiting five
seconds for the progress bar to appear so I can click on it and see the
console output, I'll be happy! ;)
Regards,
Chris
--
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.
