Hi! I am the author of Doony <http://github.com/kevinburke/doony>, a skin on top of Jenkins that's been downloaded/used by developers at EBay, Instagram, Netflix, the BBC, Panic, and other web companies, and starred by over 600 developers on Github. We also use it extensively at Twilio, where I worked until very recently.
Here are the problems I set out to solve with Doony: - *Jenkins by default has small click targets,* for forms, buttons, and links.. Per Fitts Law<http://www.asktog.com/columns/022DesignedToGiveFitts.html>, small click targets take longer to locate with the mouse and make the UI seem more frustrating. In addition some users with poor eyesight or motor control have difficulty with reading/selecting small text. I made the buttons and links much bigger, and added padding around links so a mis-click (or tap, on a iPhone) would probably still take you where you wanted to go. - *The most common actions were not easily available.* Specifically, 1) from a job's homepage, *I wanted to view the console output of the latest build*, and 2) *I wanted to be able to trigger new builds from any page on a job.* - Various small UI changes - I felt that a lot of the icons (weather metaphors etc) did not add much value so I killed them, and the console could benefit from looking more like a console. Here are the most frustrating problems I ran into: - When writing a theme,* it's difficult to select elements with CSS*. For example, here's the rule I'm using to style the "Console Output" - hopefully nothing else in pre-1.538 Jenkins uses pre tags: https://github.com/kevinburke/doony/blob/master/src/doony.scss#L649. The bottom line is, if it's easier to select elements/skin, it's easier to get more experiments in UI and more data about what works and what doesn't. NB: This has gotten better, and I've also submitted some PR's to add classes/ID's to make theming easier - see https://github.com/jenkinsci/jenkins/pulls/kevinburke?direction=desc&page=1&sort=created&state=closed. - Some things don't have API's. For example, *creating a new build doesn't return the build number*, so you need to GET the job list to get the current build number and just hope the build you created will be the next one. See for example https://github.com/kevinburke/doony/blob/master/src/theme.js#L274. Similarly, there's no API for retrieving the console output. There's no API for retrieving global settings, which would be really nice and allow people to set items like the text in the title bar, or the theme's colors, or any number of things. At Twilio we routinely wrote Python scripts that simulate UI requests to trigger builds etc. Basically with a UI, my guiding principle is *make the things you do the most often the most visible*, and the job homepage and the sidebar aren't great at this currently. I know people use Jenkins in a lot of different ways, but some user studies or testing could probably reveal the two or three most frequent use cases, and then the job page / instance page could be designed around those. One big win I think would be to move the console output right onto the homepage. Finally, a few notes about specific points in this thread. - I'm not sure about bundling websockets/a single page app with a UI redesign, for a few reasons. For one, it sounds like several large UI rewrites have failed in the past, which suggests that small, incremental changes might have a better chance of succeeding than a single bundle updating a whole lot of things. For example, one week you make the forms have round corners, add 10px padding between them and and a size 14 font, the next week you make the buttons bigger, the next week you add an API for global settings, etc. There's a lot that can be done to improve the UI/usability without necessarily making people upset. Second, I use Travis CI for building most of my Github projects, but one of my biggest frustrations with it is its occasional ability to pin a CPU, render a completely blank page, render nonsense, become unresponsive, etc. Travis CI is a single-page app. The failure modes of Javascript are legion, especially for people on flaky connections, and maybe not as well understood as the combination of HTML/CSS/occasional AJAX requests, for developers. *Jenkins' reliability in delivering a UI should be considered a core strength.* - I didn't have too many problems with Jelly, despite never using it before. However, I did mistakenly edit one template and assume my job was done, when in fact I needed to edit an additional template to make the changes I wanted. <https://github.com/jenkinsci/jenkins/pull/1100/files>The current level of abstraction makes things a little difficult :) Perhaps a smaller number of larger files would be easier to edit. - I also have not had too many problems with content not updating dynamically; it does so in the places where I expect it to (console output, triggering builds, though maybe not as quickly as I would like). Thanks, Kevin PS: If someone from Cloudbees would be interested in helping me get a Doony demo running fulltime on Cloudbees, I would be very grateful. On Thursday, May 29, 2014 6:17:48 PM UTC+9, Michael Neale wrote: > > SSE as a concept logically falls back to long polling quite reasonably > (websocket is not as easy to abstract, but plenty of libraries do it). > > The main idea is that with SSE it is a backchannel - you use regular URLs > (and maybe things like rest) from client -> server, and for getting data - > but you have a backchannel for server to realiably tell client that > something has changed (message payload may or may not contain the change, > client usually will sync). Google wave (ha, anyone remember that?) made use > of this (within limits) in a somewhat pre-websocket era. > > Also - IE ruining the party yet again (yes, it is a fact of life, agree. > IE 11 still doesn't have SSE). > > On Thursday, May 29, 2014 7:01:51 PM UTC+10, teilo wrote: >> >> Just so people are aware IE has no support for SSE[1]. >> >> IE is still commonly used in enterprises despite it many and continuous >> flaws. >> >> So far Jenkins has been pretty browser agnostic. >> >> /James >> >> [1] http://status.modern.ie/serversenteventseventsource >> >> On Thursday, 29 May 2014 08:26:38 UTC+1, Tom Fennelly wrote: >>> >>> >>> On 29/05/2014 02:57, Michael Neale wrote: >>> >>> >>> On Thu, May 29, 2014 at 11:33 AM, Christopher Orr <[email protected]>wrote: >>> >>>> >>>> It may also be worth considering Server Sent Events — basically >>>> one-way "push" from the server, without all the handshaking and protocol >>>> upgrade fun of WebSockets. Could be useful if clients are just listening >>>> for server updates, without sending anything (as is generally the case >>>> today). >>>> >>>> Last week I wrote a quick experimental plugin to stream log events as >>>> they happen via SSE to remote JavaScript clients for any running build; I >>>> was surprised how simple it was to build.. >>>> >>>> (Though I just noticed that it has less support than WebSockets >>>> (thanks, Microsoft): http://caniuse.com/eventsource) >>>> >>>> Chris >>>> >>>> >>>> >>>> >>> +1 on SSE. I have a fair bit of experience with websockets on servers >>> - enough to know that almost no one gets their proxies right - and it is a >>> source of complaints. SSE seems to work better out of the box, >>> alternatively long polling/comet can also work (a given jenkins master >>> doesn't have to scale to 10s of thousands concurrent users, which is the >>> assumption for a lot of other web choices). >>> >>> Having said that, nearly halfway through 2014 websockets is probably >>> not a controversial choice and does open up a lot of other options. If >>> someone is accessing their jenkins via a proxy, ssl and careful >>> configuration is required to support http upgrade and not break websocket >>> too. >>> >>> AFAIK... any proxy/gateway between the websocket client and server needs >>> to be pretty much websocket aware. SSE would seem like a perfect fit for >>> Jenkins since the client is listening only (not sending back to the server >>> - could implement that on top anyway if needed). As far as I know SSE is a >>> fancy long poll/comet style protocol and so would require the same >>> considerations re number of concurrent users. >>> >> -- 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.
