Ask an engineer: Behind the scenes of the new navigation

[Darryl Lee]

Hey @Brett Uglow - question about implementation.

Now that Administrators can individually opt-in to the new Navigation, is there any TECHNICAL reason why this more user-friendly way of rolling out the UI could not be made available to regular users?

Back in 2020 when @Matt Tse managed the rollout of a new navigation, they allowed users to opt-in on their time table. This was greatly appreciated by people like @Dennis Walsh who eloquently wrote:

I appreciate the statement that "We are also putting you in control of this change. Once your instance receives the new navigation, each of your users will be able to switch over to the new navigation on their own timeframe."  These changes look promising, but users still like to at least feel like they're in charge of their environment.

This is much better than the "just get used to it" approach used by certain "other" software companies (which shall remain nameless) who simply force-feed all of their "enhancements" on their users in one swoop, leaving the users either powerless to undo things, or -best case- forced to flail about and try to figure out on their own how to get their interface back to the way they want it.

[Debbie Jolley]

Having some form of individual control would be a much easier 'sell' to a lot of users.

I note with interest one of the statements at the top of the original post by Matt that Darryl linked to:

"We heard your feedback on the current navigation in Jira Cloud. You told us that the current navigation adds challenges to finding and quickly accessing your work. To solve this, we are building a new navigation experience that puts the navigation at the top of your screen for a more familiar look and feel."

And yet one of the big changes in this new navigation is to completely reverse that? - I'm baffled.

[Brett Uglow]

Hi Darryl (I'll write a separate response to Debbie),

Thanks for your question. There's no technical reason why we couldn't allow users to opt-in/out themselves.

The design of the rollout process has taken months. During that time, we gathered feedback from early adopters and beta-test customers. We got a lot of feedback from customer-admins saying that they would require time to update their organisation's training materials. The larger the organisation, the more time that they would require. My understanding is that this feedback primarily led to the rollout process that we see today.

Personally, I would have liked the ability for people to self-select. But every organisation is different, so we've put the Admins in control during the initial rollout phase (phase 1). In phase 2, Jira users can opt in-or-out. In the third phase, the new navigation is always on.

In comparing the rollouts, the new rollout adds an additional phase for admins to control when everyone can opt-in, before reverting to full user-opt in. So it's similar to the previous rollout, but supports large organisations better.

[Brett Uglow]

Hi Debbie,

I'm sorry that this is baffling! As to why an earlier design choice has been reversed, I can say two things:

1. The new nav announcement post provides reasons for the different changes.

2. The statements made by Matt are from 2020. In UI-design terms, that's about 1-and-a-half design generations ago. I say this not to be dismissive, but the technological landscape and user expectations in 2020 are different to 2025.

One of the big benefits of the new nav (in Jira) is the ease with which you can to switch between different projects because they are all visible in the sidebar. This wasn't possible in the previous nav because the projects weren't visible until you opened the project menu. For customers working on one project 99% of the time, this feature doesn't matter. But the majority of Atlassian customers do need to switch between projects regularly. 

[Darryl Lee]

@Brett Uglow thanks for your response, and for actually doing this AMA at all. Very brave. Or crazy. Or both! :-}

Just a small point of order:

In comparing the rollouts, the new rollout adds an additional phase for admins to control when everyone can opt-in, before reverting to full user-opt in. So it's similar to the previous rollout, but supports large organisations better.

(Emphasis mine)

I don't believe that's actually accurate, because if it was, I would not be here complaining! :-}

My understanding is that if I flip this switch, I am opting all of my users in:

This is very different than "Enable new navigation for everyone (users can opt-in)".

And the Rollout Schedule says:

April 14:

If you’re an admin of a site, you can turn on the new navigation:

For just yourself

For everyone on the site

And for Premium/Enterprise Plans - Early to Late July 2025:

For Jira and Atlassian Home, users can still turn off the new navigation only for themselves till the end of July 2025. This will not affect anyone else on the site

Again, emphasis mine, but my reading of this is that turning on new nav for everyone also opts them in.

In response to my plea that we instead have the ability to let our users opt-in on their own time table, Varsha responded:

Based on our research with admins from late 2024 to early 2025, we found that managing bespoke workflows at the user level becomes increasingly challenging for admins of the organization. To address this, we're giving admins control over whether to move their users to the new navigation starting in mid-April 2025 before we enforce the transition as per our rollout.

So YES, I appreciate having control over when we can make the new nav available. But it seems the nuance of having the new nav available vs forced on users was missed.

[James Rickards _Spark-Nel_]

Does Atlassian utilize a Correlation-ID in logs that is visible in a web request's response? I ask as I'd like to include it when reporting defects / bugs as it might aid your support teams in faster resolution.

For others following along, a Correlation-ID is generated when a web-request is made to a server as a result of an action like clicking a button. It is passed down to all downstream applications (e.g. databases or microservices) and asynchronous events triggered by the initial request. This ID is then included in application logs (logs are a record of what the system does in response to a request often used in debugging). By consolidating logs from various subsystems in a single log platform (e.g. Splunk). This allows developers to filter the massive list of logs an application produces to those relevant to that specific interaction with the system. These IDs are often displayed on error dialogs so that screenshots of the error message from users can be used to quickly identify the relevant logs.

Correlation-IDs are often included in the Response as a Header that can be viewed via the F12 developer tools provided with Chrome, Edge and FireFox.

[Brett Uglow]

Hi James,

That's a very technical question, and thanks for providing the background info - bravo!

Yes, we do use correlation IDs that allow us to trace a request through the various layers of services and infrastructure. When we get a support request that is potentially related to a network issue, the Support Engineer typically asks for a HAR file (a HTTP Archive), which captures the HTTP requests and responses for a page-load. This allows the second and third-level support teams to trace what happened across the different services, which helps identify what is going wrong.