I like the idea to put some actions in the top-level bar! Especially the system configuration and create job would make a good candidate. Also having the ‚New' action there would make sense.
The new tabs for the different views also look very promising. The ‚+‘ action to add a new view also looks good (currently it is hard too see that this + actually creates a new view). Am 19.06.2014 um 01:45 schrieb Gus Reiber <gusrei...@gmail.com>: > Following Tom's lead, I am also starting to poke around at the Jenkins UI. > My initial branch is here: > https://github.com/gusreiber/jenkins/tree/gustables > > What I am most excited about in what Tom has done so far is replacing the > main table layout with responsive bootstrap columns. > In addition to making the UI line up a little better and be a little neater, > it offers the promise of better cross device usability, which I think would > be huge. > > In my first stab here, I am looking at doing 2 things: > > 1) Give the Jenkins projects/build pages a bit of client-side richness with > minimal intrusion on the potentially customized or plugin modified DOM that > might live within that main table. > I have started with this JQuery plugin: > http://www.datatables.net/examples/styling/bootstrap.html > It has the nice feature of accepting the rendered static table as its > datasource and then adds a host of client-side magics: filtering, sorting, > grouping, and column switching resizing and pegging. I don't see this as > being particularly revolutionary in terms of UI/UX, but so far anyway, its > insertion seems to be going smoothly and for users with big job lists, rich > sorting tools seems like it could be a nice win. > > 2) I find the Jenkins action list (the list of hyperlinks shown in the left > column above the build queue) a little jarring, in that all the links are > given equal display weight despite what is often radically different amounts > of functional utility. As an example configuring the job and viewing the > console out (two things I do a good amount), are the same simple blue links > that configuring roles is (something I never do). Compounding that a bit is > the fact that those links are always contextual, namely, depending on your > view, that list changes around quite a bit. > > As a possible remedy to that bit of awkwardness, I am looking at pulling some > of the 'action' link list items out and displaying them in a global toolbar > sort of context. Jenkins Management, in particular seems like it really > should be clearly separated as a global set of actions, and not bound to any > particular build or custom view. > > At the moment, I am merely doing a proof of concept examination of how the > link list gets generated, but I would love to get community feedback as to > whether or not it does make sense to separate out a portion of the Jenkins > actions, splitting the contextual from the global and the high-use/high-value > actions from necessary but tangential or highly specialized actions. > > Attached is a screenshot. > (the top menu shown here isn't really the right set of global options, but > instead just a strawman to see if I can grab the action buttons and put them > into a bootstrap nav-bar, which I can) > > > > > On Monday, May 26, 2014 6:54:21 AM UTC-7, 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. 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. > > What I've experimented with so far: > 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 > 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, > the Simple Theme Plugin and others. > > General comments/challenges/risks, as I see it: > 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. > 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. > Use of <table> for layout seems to be quite popular Vs using <div> + CSS. > 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. > For more options, visit https://groups.google.com/d/optout. > <jenkins_magicTables.png>
signature.asc
Description: Message signed with OpenPGP using GPGMail
