One of the biggest pain points we hear from customers is how complex configuring projects in JIRA is. There are so many buttons and dials available to push in the administration screens that it’s easy to get lost trying to change one aspect of the project. This not only hurts existing customers, but loses us potential customers who are evaluating JIRA. Even though JIRA is flexible enough to be customised for their specific needs, they give up in frustration because it’s not obvious where they need to go.
Dogfooding at Atlassian means we feel the pain too, whenever we have to configure JIRA projects. One of my favourite quotes from our research probably sums up JIRA project configuration:
“After a while, it’s like a I saw the Matrix Code. Then a week later, it’s gone again”.
We are excited to share with you not only the spanking new project configuration pages, but also how we dogfooded our own plugin development framework to get there!
In JIRA 4.4, we overhauled the project configuration pages to give them a more project-centric view. The project configuration screen went from:
Exposing more information at a glance, and more logically organising the categories involved with project configuration.
Significant UI changes always carry a disproportionate amount of risk, particularly for commonly used pages. Our View Issue page revamp in 4.1 was a good example of this, and we wanted to make sure the new project administration pages were well received by both new customers as well as existing ones. To make it easy to gather feedback and respond quickly, we decided to try something new and split the development of this feature up into several stages; we would develop our prototype as a plugin that we could let customers try, and constantly update the plugin to accommodate feedback as we got them. Only after collecting this feedback would we actually build the feature into core JIRA, as one of its bundled plugins.
There were a number of reasons why we went with this approach, some of which I have outlined below.
Separate release cycle, quick turnaround time
We wanted to give customers something to play with. JIRA Project configurations can vary widely between customer instances, and the best way for someone to see how the new configuration interface would work in practice is to use it on their existing data. By developing as a plugin, we were able to release it indpendent of the ongoing streams of work going on for JIRA 4.3. Each time we made a change or improvement, we would release a new version of the plugin on PAC for customers to trial. This also helped us discover bugs and other edge cases that we had not considered in our internal testing. We would also track ongoing feedback from plugin users on our public JIRA instance at jira.atlassian.com .
Much of what has gone into the final project configuration pages have been shaped by the customer feedback collected via the plugin, as well as the technical difficulties we encountered in developing the initial plugin. The results have been largely positive, and it is definitely an approach we will continue to consider when developing other high visibility features.
Improve our plugins API by using it
By building the feature as a plugin, we only had access to the services and components that plugin developers have. While we had the luxury of adding to interfaces or changing backend behaviour, external plugin developers do not. The good news is, any enhancements to JIRA’s API that we make are also available to plugin developers.
In particular, our new UI had a number of client-side components that needed to interact with the server to retrieve data. To accommodate these requirements, we had to expose some of JIRA’s services through REST resources, and these additions are now available to plugin developers. One example of this is the new version page, whose development has lead to more version resources added to our REST API.
Using client-side controls has allowed us to provide a more responsive user experience, as simple version operations such as creating a version or editing its description no longer require a page refresh.
Going forward, as more of JIRA’s core features are developed using plugins, we hope to flesh out both JIRA’s code-level API as well as its REST API to make it easier for plugin developers to consume services that JIRA provides.
Feel plugin pain
Much of JIRA’s development happens in its core, and we are often less mindful of the pain that plugin developers have to go through when dealing with our products. Developing the new configuration UI provided an opportunity for us to experience these pains first hand, and see if any of the pain points we ran into could be addressed, for the benefit of plugin developers in later releases.
To give you an idea of how this feedback loop looked like when working on the plugin, it was something like:
- Start with
which starts JIRA in debug mode
in a separate terminal1atlas-cli
- Make a change to the plugin
- Switch back to the browser and voilà, your changes are in!
- Rinse and repeat 3 – 5 to your heart’s content
With static resources like
files, it’s even simpler. There’s no need to do a
, switching to your browser and reloading the page after making the change is enough. Too easy
Sadly, the picture is not always so rosy when making changes to source code. There is a long standing issue in JIRA’s plugin system that require a restart when certain plugin modules, such as Webwork, are reloaded during dynamic installation of a plugin. Our initial prototype made heavy use of webwork actions, so a
would sometimes still give us outdated plugin and we would need to do a restart of JIRA to see our changes.
I am glad to say that as of JIRA 4.4, plugin modules are fully reloadable, but we have a better appreciation now for how much time can get wasted restarting JIRA just to see changes in a single plugin module.
Paradoxically, developing the initial prototype involved an easier feedback loop than developing it for real in JIRA. Our initial prototype plugin was developed against a fixed version of JIRA 4.2, which meant we had a stable version of services and managers to work with. When developing the plugin for bundling in JIRA, and needing to make a change to a service, manager, or really any part of core JIRA, we had to:
- Change the service/manager
- Compile core JIRA, installing it to the local maven repository
- Compile our plugin against this new, updated version of core JIRA
- Restart JIRA
Before we could continue with our original plugin feedback loop.
Interestingly enough, when we had to make changes to parts of JIRA that were also plugins, such as the JIRA REST plugin, we could do it without restarting JIRA as we would just
the REST plugin, before doing a
on our plugin. In other words, the more features we develop in the future as plugins, the easier developing plugins in JIRA will become for us. Yet more reason to make plugin driven development the norm rather than the exception.
Some elements of the process we went through to get this feature out the door are not new. We often do a spike of a feature to get an idea of the technical challenges behind implementing it.
Starting initial development of the project configuration pages as a plugin, however, went beyond this as the results of the ongoing spike were made available to customers, evolving as we got more feedback. It has also allowed us to contribute back to the plugin development experience by improving and expanding the APIs we expose as well the core plugins system in JIRA. It is something we will definitely keep in our toolbox for future feature work.