Just a matter of personal taste, they don't deliver the fast visual clues to me that simple red and green elements do in other CI systems like bamboo. From a distance, they look quite similar and that fails to give me a quick overview. From my experience, they are a very polarizing piece of UI design :)

I agree with you, and it's very easy to test. Print 15 mixed weather icons on one sheet of paper and 15 red/green/orange circles in another. Show them to test subjects for 1-2 seconds, and ask them to assess the situation. Now repeat the test, but showing the sheets from two meters away. Our brain is really good at color cues, and especially red = danger is deeply wired into us!

> Our brain is really good at color cues, and especially red = danger is deeply wired into us!

Except for the colourblind, who need additional ways for that information to be conveyed.

I like red/green schemes too, but there always needs to be other cues.

so that can be an option instead of crippling everyone else.

It's not an either/or proposition, designs can accommodate both.

The simplest approach is to add a symbol for failures, to distinguish them from successes. Other colours can be chosen for other statuses that the colour-blind can distinguish without additional symbols.

> It's not an either/or proposition, designs can accommodate both.

And Blue Ocean accommodates both. I think this would be a good blog post :)

Red = danger doesn't seem to be so widespread outside the western world:

http://www.informationisbeautiful.net/visualizations/colours...

Since the graph list "web sources" as a source, a cursory web search of "danger sign + region" reveals that red seems predominant in danger signs from:

- India: http://3.imimg.com/data3/II/GU/MY-762554/danger-signs-boards...

- Asia: http://cache4.asset-cache.net/gc/152921698-warning-these-sig...

- Africa: http://www.lifeloveandsugar.com/wp-content/uploads/2015/06/d...

- Middle East: http://cache3.asset-cache.net/gc/474346969-an-israeli-sign-i...

Possible, on the other hand traffic lights around the world have pretty much standardized on:

- green/blue: safe/go

- (optional) yellow: caution

- red: danger/stop

I don't know of any country where this convention is not in use.

As I learnt looking into the indicators the accessibility of traffic lights had a lot more to do with their vertical position than their colors. Can't use solid green, yellow and red if we want them to be understood by people with various forms of color blindness.

But you could make colorblind-friendly color schemes available through plugins instead of making a slightly more confusing option default.

Do you mean the weather icons? They are not the alternative to properly designed status indicators. Take a look at this https://jenkins.io/images/post-images/blueocean/pr-view.png

There's more about why and when we use them in my other comments.

Look no further than mother nature, where bright colors often mean WARNING, I WILL MESS YOU UP. A few things to look up as examples:

* Rosary Pea

* Coral Snake

* Stag Beetle

* Jerusalem Cherry

* Phantasmal poison frog

* Strawberry poison dart frog

* Bittersweet nightshade berries

The Coral snake is debatable: it is so deadly that no animal can "learn" by getting bitten by it.

Instead one theory is that the mimicry is in reverse: the coral snake is mimicking the non-fatally venomous "false coral snake" which is also more numerous.

There are a variety of different theories on mimicry, and the science of the coral snake is still debated...

For the record, this was by design

I wanted the status balls to be the primary focus. The weather icons should only be looked at when all the builds are blue. If they are too attention grabbing then you don't go fixing the red (didn't built) and yellow (tests failing) builds first

Well the weather icons do have meaning - they are a historical indicator of how successful your build or deployment process is. We show these along side the color accessible status indicators except on the non-personalized dashboard. On the dashboard, they indicate the historical health of your most important branch (e.g. Master)

Maybe it's me but I don't care about historical health. For my projects I only care about its current health because anything Jenkins builds is going to successfully build (when it doesn't it's a fluke because we shouldn't be checking in broken things).

Not sure if I'm in the minority here or not though but it actually bothers me if, say, I misconfigured something, build breaks, I fix it but now it's showing it's cloudy. It also took me way too long to realize that cloudy meant it built but failed in the past. I remember my first experience with Jenkins trying to figure out why the build was failing before realizing it wasn't failing and cloudy somehow meant it's good.

Noted - let me have a think about that. Might be worth having a look at the Personalised Dashboard in the blog again - that always shows the current status. Most screens refer either to the status of each branch or a specific job result. for the former a single status indicator wouldn't be appropriate. But what I'm hearing is the non-Personalised dashboard may be a point of contention.

I'd like to add a me too comment, but with another thought about historical build health. It's not that I don't find it useful, but I'd rather see it along with my other metrics rather than included in the UI of my CI tool. If Jenkins could be used as a Grafana source or were able to export build metrics to Influx/Prometheus, people could use existing tooling/dashboards to display build health over time while keeping the main Jenkins UI clean and focused on the current state of the builds.

Also, and I apologize if this is no longer how the Jenkins weather indicators work, but the last time I used Jenkins, the weather indicators were based on the number of failed builds, not the time the build wasn't green. For me, the number of failed builds is far less interesting than the amount of time that the build was failing. If a developer scrambles with three checkins in 15 minutes that attempt to fix the build and the third one succeeds, that's a better situation than a developer who takes a more measured approach that fixes the build four hours later on the first checkin. The first developer might have created a slightly messier commit history, but the second developer blocked the entire team for half a day. Taking the view that historical build information is really time series data would, to me, be much more insightful.

You can expose some metrics via https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin but not the per job success and failure counters you'd need to build what you suggest. That would make a good addition.

Team members should have sandbox builds available. Its maybe not true that the integration build is blocking everybody. I don't think this statistic is worthwhile. Just knowing its broken, and making steady progress on integrating a working system, is often enough.

Curious why you need sandbox builds if you've got builds per branch?

So the point here is that the weather icons are slightly misunderstood and underused.

Way back in the way back, a colleague and I were looking to get some extra information onto the Jenkins (then Hudson) jobs screen. I had some chats with KK over IRC and at the time he did not want to open up having multiple columns in the jobs screen. His then view of the world is that the jobs screen should be somewhat opinionated and clean.

So I said, well what about if we add just a second icon beside the status ball and if you hover over it you get a tooltip that displays some detail message. KK said that didn't seem so bad... so off hacking I went.

What I wanted was a kind of health column that would tell you the worst health of your job at a glance.

The idea we had was that some jobs may have low test coverage, some jobs may have a flaky build, some jobs may have lots of TODO comments in the code, etc. So you would define the criterial levels of each metric and score jobs against those levels.

Then we would pick the worst score and display an icon for that score.

So off looking for icons I went... keeping in with the Tango theme that was used by the project at the time...

My initial idea was that you would maybe have a heart that gets into worse and worse shape as the score went from 100% to 0%... but the red colour was too distracting...

So I soon realized that - unlike the status balls - we wanted something that was not quite as high a contrast. You want to see the status balls first... if something is yellow or red, you fix that first... only when everything is blue do you want to start looking at the health (which is why the column is called "H")

What I did find is that the weather icons gave me 5 levels of "health" and were subtle enough not to distract from the red and yellow balls... plus my colleague and I thought it would be really cool to have the code coverage metric be an umbrella and as the code coverage gets worse the umbrella would loose bits of fabric so that 0% coverage would be a tattered frame.

So I had my patch and submitted it to KK and it got merged and the rest is history.

For the initial patch I wanted there to be something for every job already, so the default job health is based on the last 5 builds (because there are only 5 levels of the default icons, and scanning any more would just be pointless)

We also added contributors for the code coverage plugins and the violations plugin (which my colleague was the initial author of)

Then of course you get distracted in other things...

What disappoints me greatly is that in the 700 or so releases of Jenkins that have had the weather icons... nobody has actually gone and implemented the custom icons for job health feature that is embedded directly in the code and was available from the very first day the patch landed...

I don't know if this is because the weather icons are just enough... or if it is because nobody noticed that you can do that...

I know for the code coverage icon, neither Peter nor I are good enough artists to come up with 5 levels of umbrella in various states of disrepair... another idea was a pie chart or a small trend graph... but we always seemed to have more important things to do... and since I joined CloudBees I've been too busy to get back to that area.

So anyway, I guess my point is that the weather icons were designed to be more subtle than the build status and the API was designed to allow plugins to contribute their own health and even their own icons... but whatever about other plugins contributing to health reports... nobody has bothered to contribute the customized icons!

-Stephen (the originator of the weather icons in Jenkins)

I like the weather icons.

In less disciplined environments (most likely the majority of dev environments) they help nudge people by showing that the track record is less stellar than the green icon shows.

Please keep them :)

That was certainly the use case that I had in mind for keeping them around. Need to weigh this up more but I am glad you like them regardless.

If it helps, I can actually provide several data points from companies I've worked for. I've managed 3 (4?) large Jenkins installations and after the initial exploration almost all developers I've worked with understood what the weather icons meant and liked them. Managers definitely liked them :)

Could the current general lack of appreciation for them be related to where they are located in the Jenkins UI?

In Jenkins 1.x and 2.x they are visible on the top level dashboard alongside the green/blue orbs and I often wonder if that's a source of distraction because I (as a user) am looking at both of these indicators now and wondering how to interpret the state based on both of them, when maybe I shouldn't.

Would it help if the top level dashboard(s) contained only one general build status indicator (vs two), and then the trend/health indicators were "down" on the pipeline details page alongside other health/metrics info (static analysis info)?

They seem to have advantage for color blind people, no?

It's easier to disambiguate shapes than colors.

It's easier to disambiguate shapes and colors than just shapes or just colors -- something like a checkmark of one color, and an X of a different color.

FWIW We've got colored indicators that have appropriate iconography for these kinds of users.

Yes, please, either remove them or at replace them with something more meaningful. Every time I see one I have to hover over it to figure out whether something's actually wrong, and (confession time...) sometimes I even deliberately trigger a bunch of (non-)builds so it goes sunny again.

If you want to show the state of the last 5 builds, then... show the state of the last 5 builds. e.g. ynyyY (imagine unicode ticks and crosses instead)

Just my tuppence. For the record, Jenkins is amazing in how it has sparked a revolution in the CI world, and I love it, but the weather icons do wind me up somewhat.

Edit: replaced unicode ticks and crosses with y and n because they weren't showing up.

A mini pie-chart would suffice to show recent history. Current status could be in the center with five or six slices around the perimeter showing historical results.

It's not supposed to be just recent history. The weather is also supposed to be:

* the code coverage of the most recent build,

* the findbugs / violations count of the most recent build

* any other health metric that plugins decide to contribute to the build.

The icon is supposed to be the icon of whichever report is the worst health and FTR each plugin has always had the option to define their own icons (see my other reply for a more detailed background)

Pie charts are almost always a poor way to show information.

http://www.businessinsider.com/pie-charts-are-the-worst-2013...

For what you're suggesting a horizontal thermometer shape might work, as that would make the historical order more obvious

(Y)nnyyn

They are poor for showing relative proportion. In this application they would be fine since it would only be ancillary info that doesn't need to be scrutinized.

That's a great idea - will take it into consideration :)