On Monday, May 26, 2014 8:08:28 PM UTC+1, Christopher wrote: > > 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? >
Well this is a perfectly valid question and probably one I'm not best qualified to answer. Personally though... I'd find: 1. Initial experience is a bit clunky in that you just end up on a blank page/ I think we could at least add some cheat-sheets, introductions (of the "looks like this is your first time using this Jenkins instance. Want a tour....") or ask the user straight off if they want to set up their first Job... then have some visually appealing quickstart templates on a pallet of some sort. 2. The job config page is a badly organised nightmare. 3. The default template is definitely very dated in appearance (including the icons ;) ). I know this is not something that would bother everyone, but I do think it possibly send out the wrong signal to potential new community members. I would fear that many would form the opinion (maybe not intentionally) that things are stale and so would go look elsewhere. > > > 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 :) > It looks okay'sh, but the problem is that the form on that page seems to be quite sensitive to a change in the page structure. The one Build Step I added to that page did not work after I modified the page structure. I could probably fix that issue, but I'd bet there are 20 more issues waiting around the corner. > > > > 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 > I like that a lot... maybe this is a starting point i.e. at least make Jenkins like a bit fresher. I'm guessing this will not fix issues such as with the config page, but it's a good start. > > > 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 > Thanks for pointing me at this. I'll ping Tyler and ask him to pitch in. In some ways I feel that this might be the only real way to make meaningful usability changes to Jenkins. Maybe we could replace parts of the UI with a SPA ... do it bit-by-bit. > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
