Thank you all for your thoughtful feedback and timely responses. Before I get into the specifics, I wanted to make sure that we share the “why we’re doing this” in a bit more detail.
So why the changes?
Jira Cloud’s sidebar navigation has gone through several iterations over the past couple of years, both from a UX and an architectural standpoint. We are now at the point where the architecture is slowing us down and limiting us from making performance improvements in the product. We know that performance of our Jira Cloud products is extremely important for our Cloud customers; it is often cited as one of the top pain points. Improving the sidebar is one of the many initiatives we’re doing to improve performance. Given that the sidebar is rendered everywhere in Jira, this new structure will benefit every single page in Jira.
Jira Cloud is moving towards a single-page application (SPA) and our current sidebar was designed in a way that is very hard to scale. As an example, our sidebar API returns way more data than is actually needed on the page just to account for all possible configurations, which prevents us from making optimizations like effective caching. A way to tackle these issues without introducing waterfall scenarios is by leveraging better URL patterns; by having unique URLs per location we can preemptively fetch and load only the data and the assets required. This approach helps us get closer to our target of having Jira pages rendered in <1s and interactive in ~2s in the next two years.
Another benefit for our Cloud customers is that these URLs will make it easier for Jira users to understand where they are in the product. We have seen from research and customer interviews that many of our users use the browser URL as a means to navigate and orient themselves in the product. We know how difficult it can be for users to find things in Jira and our hope is that moving to better-formatted URLs will improve usability over time.
Now to address some of the specifics:
Regarding the URL changes - we will not rush these changes as we understand that ecosystem developers will need time to update their respective documentation to mitigate any influx of support tickets. We want to assure you all that these changes are not going to happen tomorrow. We are however planning on tackling the URL changes within the next 2 months (see the detailed implementation plan below). When this does start, we will ensure that we still support the old/current URL pattern during this time and provide a solution to handle both URLs for 6 months. This date is flexible and we can accommodate a longer period if we’re still seeing lots of apps on using the old URLs.
Regarding the deprecation of
advanced_menu_section/advanced_section - thank you for sharing your feedback with us about the permissions checks. As part of this, we can reassure you that these checks will be maintained in
admin_plugins_menu. Some of you are asking why we would deprecate this section at all. Aside from reducing the calls we’re making to load the system admin menu, we believe that it is more intuitive and easier for users to find your respective Apps’ admin settings from admin_plugins_menu . Below is a snapshot of the engagement of the two different sections for one particular App that currently uses both locations. We see roughly ~5x more engagement in the last 90 days.
We understand there are some Apps out there that only use
admin_menu_section/advanced_section, so our plan would be to programmatically carry forward these Apps’ admin pages into their corresponding section.
Of course, it’s also completely possible for you to define the section it belongs to. This can be done by using the existing webSections or webItems module.
Implementation plan (open for feedback)
- Create a redirect that supports the old URLs, starting late July 2020.
- Create the new URL structure, starting early August 2020, targeting to be rolled out by 100% by end of August 2020.
- 6 month deprecation notice for admin_menu_section/advanced_section goes up in June 2020. Our proposed solution for handling this is implemented and rolled out to 100% by December 31, 2020.
Thanks again for your time! We really appreciate this level of engagement and care.