When I started at Atlassian in January this year, my manager Brendan asked me to take a look at our internally-used
wallboards with the aim of making them maintainable, flexible and ideally: shippable. Here’s what I came up
The old wallboards were originally created as a ShipIt project. They were written more as a proof-of-concept than as a completed implementation – there was lots more work to do. To further complicate matters, different teams within the company had forked the original project to include additional data sources specific to their product.
There were 6 core components to the wallboards: a bar chart of who was blocking the most JIRA issues by not completing Crucible reviews, a burndown chart of hours recorded against issues in the current sprint, a performance metrics graph of a specific bamboo test suite, how many days were left in the current sprint, a bar graph showing how many JIRA issues were unstarted, in progress or completed.
Here’s what the old wallboards looked like:
and here’s what its insides looked like:
an Atlassian plugin or through iGoogle (satisfying shippability).
Even better, the custom gadget dashboard could use the resources of JIRA gadgets and dashboards (itself powered by Shindig), and just use custom layout and styles to replicate the old wallboard.
Pretty early on we realised that the wallboard dashboard would need some way of knowing whether a gadget was written
specifically for a dashboard, or whether it was just a regular gadget which the user wanted in their wallboard –
aesthetics be damned. Our resident gadget-guru Tim had the cool idea of creating a new view type for Wallboard mode.
A bit of background on gadget views: A gadget developer has the ability to know what context the gadget is being
viewed in. Options include a large “CANVAS” mode where the gadget is expected to be given the majority of browser
real estate and “HOME” where the gadget is placed in amongst a number of other gadgets – typically within an iGoogle
dashboard, a JIRA dashboard or some other equivalent.
By defining a “WALLBOARD” gadget view type the wallboard can tell whether it’s getting a gadget designed
specifically for a wallboard (when it has a content tag with view=”WALLBOARD”) or not (when it gets a content with
view=”DEFAULT” – the fallback viewType).
This had a really cool side-effect that allows existing gadget developers to take the gadgets they’ve already made
and implementing a new “WALLBOARD” view alongside their gadgets’ existing views. The new view would likely use most
A few weeks into this project the folks at Panic Inc. posted this
blog. It looks great. Everyone within Atlassian got excited about it, it got praised in countless blogs and
forums and all over Twitter. The only comments I ever saw were that could be interpreted as negative were that
people wanted a sexy status board of their own. The concept of information radiators is by no means a new concept –
Brendan’s summit presentation for some history. But what Panic’s
wallboard really drove home to me was that none of these wallboards exist as off-the-shelf offerings. Every
wallboard I’ve seen are custom, in-house setups. The really nice thing about doing our wallboards as a
JIRA+GreenHopper plugin is that anyone using JIRA and GreenHopper can get one too.
Around early May I got to the point where I had a bunch of gadgets and a servlet which together mimiced the old
wallboard pretty well. It was around this time that everyone had the realisation that it was ugly. Moreover, we had
just picked up Jake - an awesome new designer – on our team. He was more than capable of de-uglifying the
wallboard. He and I worked closely together over a few weeks to completely overhaul the UI, leaving it looking more
Those of you that attended Summit would have seen some wallboard screenshots in the key note. Additionally, you may
have noticed a large screen showing the progress of the JIRA team’s current sprint. These weren’t mockups. The JIRA
team is running the wallboards plugin on their dogfood JIRA instance and it was this exact JIRA instance which was
powering the big-screen demo. Additionally, the Crucible team are using an instance of the wallboard plugin running
on our public JIRA instance. This was
used for some of the screenshots shown throughout the event.
On hitting the “View as Wallboard” link on a JIRA dashboard, the request goes to a servlet provided by the plugin.
The servlet looks up the user and finds the id of the dashboard that they’re coming from. It then looks up the
gadgets which are in that dashboard and generates iframe URLs for each of them (iframes being the mechanic used for
embedding gadgets into dashboards of any kind). The placement into the wallboard is determined by a combination of
columns and gadget border color. The wallboard itself is an Apache
Velocity template containing 4 divs placed in each of the wallboard’s corners. It looks like this:
The servlet embeds the iframe elements into the corresponding placement’s div. The resulting webpage, when ready,
calls a function which considers these four divs. For each of these divs, if the number of iframes inside it exceeds
one, the ready() function sets up the div to cycle through each of the iframes inside it on a 10 second schedule.
This cycling is performed using the jQuery Cycle plugin.
The bundled gadgets are all just OpenSocial gadgets (using the wallboard view-type extension) implemented using jQuery, flot and AUI. Originally the story status gadget used Google
Vizualisation but was rewritten to allow for us to better optimize for a wallboard.
I’ve already heard from some JIRA Wallboards users that they’re considering writing some wallboard gadgets of their
own. This is awesome and I hope more people consider it. We’re still considering how to best partition
responsibilities between the wallboard itself and the gadgets inside it. We will issue specific guidelines once we
have formalised them better, but in the short-term, here’s the gadget development documentation and here’s specific instrucitons
on how to make your gadgets fit in with the other wallboard gadgets:
- Have a Content tag in your gadget XML with view=”wallboard”
- Have a background color of #141414
- Use a font-colour pallete of #999999, #333333 and #FFFFFF
- Use a non-neutral colour pallete of #990000, #0099CC, #336600, and #FF9900
- Give each gadget padding of “20px 40px 20px 0”;
- Use a font-family list of ‘Helvetica Neue Light’,Helvetica,Arial,sans-serif.
- When the gadget is fully loaded at the class .gadget-loaded applied to at least one element within the gadget’s
This last point is a bit curious – it’s the mechanic used for the wallboard to determine when to take down the “loading” overlay.
Of course you’re free to experiment and try out different styles – but if you follow these instructions it will at
least look consistent.
Install the plugin and give it a try (you’ll need JIRA 4.1.1+ and GreenHopper 4.4.1+). It’s a little rough
at the edges – it’s alpha for a reason. Help us make it better.
You should also try making some gadgets of your own for it. You could make a gadget which uses data from JIRA or
Crucible or any other product, or you could use external sources to make a live feed of sales data or a share price
As for what we’re doing with it? We’re still discussing that – it may get bundled into JIRA itself or be made part of
GreenHopper. It will probably depend on feedback from you guys. In the spirit of “open company, no
bullshit”, we’re letting you all try it out in its alpha stages, and we would love to get your input on how
you’re using it. What is great? What is broken? and most importantly – how do you see yourself using it in the
future? The plugin is hosted on our JIRA Studio instance SPAC,
and it’s available for download from PAC. Give it a try and let us
know what you think.
In terms of wallboard gadgets as a concept? It would be really cool to actually get the wallboard viewtype formalised
in the OpenSocial spec and maybe even get the wallboard dashboard view rolled into Shindig. We’ll keep you posted.