On 29/05/2014 17:51, Kevin Burke wrote:
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.
Kevin, thanks for this. This is really great information and advise. I
think you are totally on the money. Kohsuke made the same comment about
the possible reasons why other bigger efforts were not as successful as
hoped and that small incremental improvements might having a better
chance of success. Makes sense, considering the rate at which the
Jenkins codebase is evolving.
--
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.
