Hi All
Thanks for sharing your concerns and thoughts.
The aim of this RFC is to share the plans around navigation changes. We will get back on your feedback but meanwhile can we pls request that you DO NOT SHARE the plans in social channels and collaborate here instead .
Thanks!
Euh… well, that’s awkward. I mean, I explicitly asked (RFC-45 - Upcoming changes to Jira navigation - #15 by remie) if this was OK and got confirmation before posting on LinkedIn.
Do you want me to remove my posts?
Hi Remie,
I can respond on behalf of Arsi as it is a bit late for her. I am sure Ian meant that the post was unlisted earlier not because of confidentiality, but due to concerns about image quality. However, he definitely didn’t intend for this information to be shared on social media. This RFC was intended to be shared with partners to understand the edge cases and app impact primarily as well as overall feedback.
We have acknowledged the feedback regarding one of your posts, and the team will review it and collaborate with partners to work on an optimal solution.
Yes, please remove the posts and continue sharing the feedback here. The respective teams are taking note of the feedback and will engage in a two-way discussion soon.
Also, we apologize for the image quality issues; it took some time to update the post from our end.
Hi @ChandanaMeka , as a token of good faith I’ve removed the posts, although I’m still confused by all of this.
The RFC is not considered confidential, the URL is publicly available through CDAC and the OP never mentioned anything about not sharing this.
There are partner exclusive NDA restricted area’s both on CDAC as well as on the partner portal that would allow Atlassian to post anything that all Marketplace Partner know are not to be shared with the public. This RFC was not posted in any of those restricted areas.
I’m not entirely sure why we cannot share this information on social channels if this information is publicly available?
Hi @remie
Thanks for removing the posts. Given the ANZAC day public holiday in AUS, there was a delay with responding to your question around whether you can post this in social media. The intention of RFC was to invite feedback here and collaborate on the solution. Our original plan did not anticipate or intend for this to be shared on social channels. We ask that comments remain focussed on the discussion at hand to ensure productive exchange for everyone involved.
We will explore options to lock this down, if necessary.
Thanks for understanding.
How will shortcuts be supported? We have a high adoption of appending shortcuts in the current left-pannel navigation, mostly to easily access plan views and dashboards from a software project.
I’m concerned that this will make the project/board difference even fuzzier than it already is. The relatively-recent update to cluster board-specific options (Backlog, Kanban board, Active Sprints, Reports) with the Board dropdown helped users understand the concept a bit!
This new navigation doesn’t appear to have any affordance for the board/project distinction. I can’t tell what board is currently open, or which project tabs will use issues from the board filter query.
Most Easy Agile app use Jira boards, not projects. The flexibility and configurability of boards is really useful. Customers appreciate being able to customise what issues are included by changing the board filter. They use this to see cross-project work, split one project into multiple parts, or create custom views.
It’s important for our customers to be able to:
Switching from left nav to top nav in 2020 helped unify the Jira Cloud and Jira DC/Server experience a little. That’s really valuable for organisations that are migration to Cloud: it gives users a bit of familiarity so they can start finding their way around in a new environment.
I’m concerned about users having to re-learn Jira navigation, especially while so many organisations are migrating. This could be another barrier to entry for customers considering moving to Jira Cloud.
Hello,
nice to see these changes before a release.
Our app provides a quite large sidebar navigation on the left itself on a jira:globalPage as Forge app.
Would this mean, that we will have our customers to experience a 2nd sidebar on the left and our app will provide less horizontal space on the page?
This seems to limit our app’s effort to provide our own navigation and to deliver focus.
I’m getting the feeling that we are running in circles for the sake of running in circles.
As others have also mentioned, just flipping from top to side navigation is a wast of resources since not only Atlassian but also all the partners have to dedicate people to adopt this “new” navigation “style”.
I say “new” because well it is just the same navigation in a different location.
The problem as mentioned by the quotes of users is the navigation itself, not the location of the navigation.
Why not look at the actual problem, figure would what structure of navigation is needed and then find the best location for this structure?
I’m getting the sicking feeling we will have this discussion again in a couple of years when we move back to a top navigation. Or that there will be enough people that want a right or bottom navigation to start over.
On the flip side: I do like that Apps can have a more structured navigation in places where its a single page now, it can become a section with multiple items in the future.
As others have pointed out, I’d urge you to look at the feedback received when this was attempted last time around. I can’t see this ending in any other outcome except reverting to the existing navigation, causing frustration for customers and app vendors and distracting us from delivering value to customers.
One thing that needs to be addressed is grouping Apps together. Atlassian often forgets, doesn’t realise or is willfully blind to the fact that customers see the Application experience as the combination of the host application and the Apps. The host application is missing functionality that apps provide in some way. Segregating Apps away in their own menu adds unnecessary cognitive overhead to users. They have to know that the functionality of their system is an app. There doesn’t appear to be a good reason why they would need to know that distinction between host application and app.
Hi @david
Understand and acknowledge that this is a big change for you. In order to help you get hands on and better understanding of the changes to Apps in Global and Jira product, we are working on
You can expect these to be made available to you by this week.
Hi @remie
Absolutely. I will prepare a video walkthrough of the changes and share by this week.
We are targeting Oct this year to begin EAP Alpha with a closed community group for early feedback. Would you be interested to participate?
I think all Jira app vendors would want to be included in this. If we’re not - I would be very dissapointed since this has large impact on the entire ecosystem (considering that the Marketplace just hit $4 billion in lifetime sales - I would expect this be one of Atlassians priorities).
Hi @danielwester
Thanks for the feedback.
The sidebar is collapsible to display only the icons. This should give you more realestate to work with.
Ability to opt out of the sidebar or collapse sidebar by default when users are in Apps - let me explore this with our design team and get back to you.
@dmitry.astapkovich The images issue have since been addressed. We had to use images due to limitation with the tool not allowing for tables or inline images to render properly. Sorry for the inconvenience. I am also putting together a video walkthrough of the changes this week, hope that helps.
Hi @SvenSchatter
Eventually, our aim is for all Atlassian products to have a consistent nav look and feel and experience. We are starting with Jira and will share specifics on the other product changes when we get there. Thanks!
Hi @ZsoltNagy
Thanks for the feedback.
The purpose of moving product specific menu items (like Projects, Recents, Starred etc) to the sidebar is to be able to differentiate them from the global menu items (Search, Create etc) and also allow the top nav to scale. The customisation options in the sidebar allows for hiding unused menu items, so users can view and focus based on relevance.
On your question around sidebar and horizontal nav taking up the space - The sidebar can be collapsed, allowing for more horizontal real estate. The Project specific menu items in the horizontal nav bar can also be collapsed (we are exploring an explicit collapse\expand and a collapse on scroll) to allow for more vertical real estate.
@arajah I completely agree with @danielwester here. I understand that it might be difficult to organise a way for all marketplace partners to provide feedback. But this is such a big change for partners, the EAP should not be made exclusively available to a happy few. This might work for customers, but not for Marketplace Partners.
I encourage you to make this available through the developer EAP program as soon as possible, preferable through already existing developer canary / EAP channels or alternatively to allow partners to provide an instance URL that will be switched to the new UI as soon as possible.
I believe this was also done previously with the 2020 navigation change and IIRC also with the 2017 navigation change. To ensure mass adoption of the new navigation by apps it is imperative that this becomes available at least 3-6 months prior to GA
Thank you for all the work on your side to make this overhaul. Unfortunately, I think it will not meet the described need of simplifying the UI, but as a user I do appreciate that within this plan we’ll get more powerful project features in Jira Software, including calendars and lists.
Here are some general comments:
Right now, marketplace partners decide whether an app can be accessed from the app menu, from the project page property, from both, or from none. With these changes, it seems like you are removing the project page properties as a quick way to access the app and listing every app in the instance mandatorily in the app section. This enormously decreases the versatility of the UI.
In particular, the ability to rearrange the order of the elements in the sidebar and to allow this to happen per user (if I understood well) is nice, but from the logic of usability I think “all or nothing” doesn’t really capture the reality of app usage. If a company has 10 apps, out of those 10 apps some of them will be generally used by a high percentage of users, with others being way more specialized, and only adopted in a subset (including admins). Additionally, listing every app mandatorily in that section of the sidebar will make the list crowded and irrelevant for most users. I think that if the idea is to let end users customize their own sidebar, the order of the apps within the app list, or the mere presence of apps in the list, should be something users would be able to customize.
In the long run, what I can see happening is that more and more apps will release project navigation options so that they can make it to the top menu and be top of mind. I am aware that you are already reacting to this risk with the admin ability for admins to hide apps, but in general the fact remains that the trend will be towards a very crowded space where users with different needs and behaviors will have to lobby their admins in order to gain access to their most used apps. I wonder if this speaks for the convenience of giving the permission to end users for customizing their own views of the project, and at least aligning those permissions with the customizability of the side bar.
I have to agree with what has been said by others. It is extremely difficult to determine the actual extent of the impact of these changes to our apps until we have more detailed documentation and the ability to play with a version of this design. Please make that generally available to marketplace partners ASAP and allow to submit feedback within this RFC up until we’ve had two solid working weeks to make our analysis. There is an event this week we’re all familiar with which doesn’t make the communicated timeframe very conducive to detailed work on this RFC, and I was just lucky I couldn’t sleep after 3:00 am and my only way to spend time was to engage over here.
Additionally, I was initially really confused by the screenshots in the section on Apps for JS and Jira Work Management projects. Trying to think it through, here are my concerns:
The new UI is planned for JS and JWM, leaving JSM aside. This means that the existing consistency in how apps are navigated across all Jira applications is going to break, and we will have to maintain different navigation modes that currently are unified. This will be a lot of work for no added value, and double the amount of maintenance, testing, and UI design that is required in for anything we ship. Once the current project pages are deprecated, users who are JSM agents will have a significantly different way to access the app: since the project pages don’t have sub items, we will still need to rely on in-page elements for navigation, making this potentially redundant on occasions.
There are still significant issues with the clarity of the content in the screenshots. Please use graphic elements (arrows, rectangles, etc) to highlight what the screenshot is about, there’s a lot of noise and while the screenshots are beautiful, they are not clear. It took me several reads to find the relevant information on how to hide and show tabs, since I was obsessively looking at the new side menu.
I don’t think I need to add anything new to my comment, as the others already covered the topic quite well. I endorse most of the comments here, and I don’t see how this change will benefit users. Needless to say, it will generate a huge disruption for vendors to adjust their apps.
I hope Atlassian can hear what has been said here, nothing less than a unanimous negative response, and re-think this plan. Why not focus on improving the current navigation instead, make it possible to edit the side-bar, add mechanisms to declutter the UI, etc?
Additionally, I don’t see how we’d update our app to adjust to this proposal in less than a couple of months of work, so the presented timelines are not fair to vendors as well.