RFC-59: Upcoming changes to Confluence navigation

[NedLindau]

Summary of Project

• Publish: 22-Aug-2024
• Discuss: 06-Sep-2024
• Resolve: 20-Sep-2024

At Team '24, Atlassian announced the System of Work. The System of Work is built on a common Atlassian platform and data model, delivering a connected portfolio of products with clear and discrete value propositions. It helps organizations align their work to goals, plan and track their work, and unleash knowledge across the organization, thereby simplifying product offerings and making them more intuitive for all teams.

As a part of this evolution, Confluence will be updating its navigation to ensure consistency (with some exceptions) with the navigation changes that Jira described in RFC-45.

We believe that a unified navigation will help…

• Create a consistent appearance and user experience across all our products, making it smoother to switch between Confluence and Jira (and back again).
• Establish a simpler mental model of what each section of the should be used for.
• Make navigation customizable to each of our customer’s unique use-cases.

Proposed solution

Note: This RFC uses the terms “Global Modules” and “Space Modules.” Here’s which extension points are included in each term:

Global Modules: Web-Item (inline): system.header/left, Web-Item: system.header/left

Space Modules: Web-Item (inline): system.space.sidebar/main-links, Web-Item: system.space.sidebar/main-links

The key changes in the new navigation are as follow:

1. Simplified top bar

We’re significantly decluttering the top navigation to put the focus on essential tasks like search & create.

2. Relocated product & global navigation

Product-specific navigation and global items, like Recent, Spaces, Starred, and Apps are now listed in the left sidebar.

Additional, lesser-used items like Templates, Teams, Drafts, and Tasks will appear beneath a “Show more” menu.

3. Customizable side bar

In this new navigation, individual users will be able to choose which items from the section above should appear in their primary navigation at all times. For example, if you use Tasks heavily but do not use Starred, you can add Tasks to the primary navigation while hiding Starred beneath the “Show more” menu.

Note: This is a user-specific preference.

4. Simplified space navigation

The space section of the navigation will remain mostly the same with a few small changes. Namely, we will be adding a new … overflow menu to the right of the space name, and we will move many settings and advanced / admin user features to this overflow menu.

Here is the current list of items we will be moving to the overflow menu:

What do these changes mean for Ecosystem developers and partners?

1. Placement of apps

Current Navigation:

The Global Modules tab and menu items are placed in the top navigation bar:

New Navigation:

Global Modules and menu items are now in the left sidebar:

2. Show/hide apps

Current Navigation:

You can’t hide/show Apps as a menu item.

New Navigation:

Individual users can choose to add or remove Apps (or any other item) from their primary navigation. Note: Even when users choose to hide Global Modules from the primary navigation, the navigation item will still exist within the “Show more” menu.

3. Popular Apps

Current Navigation:

Popular Apps appears underneath installed Global Modules:

New Navigation:

Popular Apps section is removed. Currently, the Popular Apps section is a simple, hard-coded list of 5 apps (less whichever apps the instance already has installed):

1. Slack
2. Google drive
3. Lucidchart
4. Miro
5. Invision

We think the user experience here could and should be improved, and we will iterate on it in the future.

4. Manage apps for admins

Current Navigation:

From the top navigation, go to Apps > Manage your apps to access this feature:

New Navigation:

From the left sidebar, go to Apps > 3 dots > Manage apps to access this feature:

5. Side navigation while using Global Modules

Current Navigation:

There is no sidebar for single-page Global Modules

New Navigation:

The sidebar is persistent while using Global Modules. Users can collapse the sidebar if they prefer:

6. Space Modules section of sidebar

Current Navigation:

Space Modules section of sidebar is expanded by default.

New Navigation:

The Space Modules section of the sidebar is collapsed by default to match the behavior of the rest of the expandable items in the new nav.

If a user is viewing a Space Module, then the Apps menu will expand in the sidebar:

Asks

We’d appreciate any reactions you have to this RFC, and we’re especially interested in learning more about:

1. What impact do you see with your APIs/apps due to the navigation menu items changing with respect to their placements?
2. How can we help you adopt the new navigation changes with minimal impact?

Rough timeline

• The timelines below are targets based on our current understanding of the work involved. With that said, they could change.
• Designs are still evolving, and we will share final designs at a later date via Product Tech Talks, Community posts, and/or webinars.
• We can enable the new navigation for partners in test environments at the beginning of the Early Access Program to provide as much time as possible to plan for any changes to apps.

• Q4 2024 (Oct-Dec): Early Access Program for new navigation begins — this will be the first opportunity for ecosystem partners and interested customers to test the new navigation.
• Early-mid Q1 2025 (Jan-Mar): Beta start
• Late Q1 2025 (Jan-Mar) or early Q2 2025 (Apr-Jun): General availability rollout start

[david]

Oh man. Where to begin?

I don’t even know whether its worthwhile commenting on this. I mean Atallsian have already decided on this mad direction, just like they did for Jira.

Some initial thoughts:

• The top bar is not currently cluttered apart from the “Popular Apps” in the Apps dropdown - that was always pointless
• The top bar will essentially be a big waste of space with just a huge search box
• All the present top nav will now be squeezed into the left nav, which is a complete cluttered mess
• All content related (e.g. page tree) stuff will now be pushed down, likely below the fold for a lot of users, but “it’s OK you can customise it” to remove the new clutter thats preventing you from seeing the space navigation section
• You’ll have 2 sections on the left named “Apps” that’s weird

In all, I’d grade this as “could try much harder”.

[tobias.viehweger]

I agree with David, even though I fear commenting on the navigation itself will not change much… Pushing the Confluence space navigation down is really something else, UX wise. Working on smaller laptop screens is going to be mad.

Regarding the app implementation, I second

@david

You’ll have 2 sections on the left named “Apps” that’s weird

This seems confusing for new users, when to choose which Apps menu… As they are on the same visual hierarchy (left navigation, only separated by a divider), I’m not sure if new users will get the distinction?

Appreciate the early heads up!

[NedLindau]

Thank you for the feedback!

You’ll have 2 sections on the left named “Apps” that’s weird

One alternative we considered was to consolidate the apps entry points so that the menu would have sections for “Global Apps” and “Space Apps.” Here’s a quick mock:

Would this be preferable @tobias.viehweger @david?

We were initially worried it would adversely impact things for partners with apps relying on Web-Item (inline): system.space.sidebar/main-links or Web-Item: system.space.sidebar/main-links. If that’s not the case, I definitely agree that this would be a more intuitive solution.

Pushing the Confluence space navigation down is really something else, UX wise. Working on smaller laptop screens is going to be mad.

I hear you @tobias.viehweger @david. We’re working really hard to mitigate this problem by taking a number of the advanced features that currently occupy real estate in the side nav (Automation, Analytics, Content Manager, Settings, etc) and moving them to an overflow menu. Removing those items from the primary nav ensures that we actually do not end up pushing content farther down than it is today.

[ThorstenKamann]

Mhh, I am not fine with this idea. How many things should be in the sidebar? I am in a space, I want to see only relevant information about this space. In common this is the content, sometimes some links to calendar, blog, shortcuts. Not more.

Why should I see a section that isn’t relevant for the work I want to do in a space. And what are the benefits of moving the product navigation into the sidebar? I cannot find a reason for this.

Best
Thorsten

[anshuman]

Thanks for sharing the RFC. While (kind of) get the intention/motivation, I still see a lot of challenges - many of which have been highlighted in David’s comment above. Here are some of my initial thoughts -

• The mixing of the two contexts Global+Space just feels very weird and confusing to me
• Two apps section on the same level is confusing! Even if you club them together, I strongly feel that it doesn’t work.
• It’s weird that the global page will now have the left navigation. from a mental model aspect, it creates more confusion that it solves.
• The “Space apps” section was already pushed down with previous changes and now with this, they’ll become practically invisible. I can see this as a big bummer for “space level apps” that rely on that entry point only.
• TBH, I do like a bigger more prominent search bar, but not that big and not at the cost of cluttering the side nav.

If we’re stuck with the current suggestions, some ideas i can think of are to further reduce the number of items in the Product+Global Nav section.

Regards,
Anshuman

[dlindsay]

Hey @NedLindau , thanks for bringing this initiative to RFC.

While I can get on board with some of the rationale to simplify the UI, I can’t help but see this being done at the expense of app vendors. There’s a lot in this design that changes how apps are treated as part of the Confluence experience and I can’t help but see this hurting our businesses. Here are a few key points:

• The design moves the Apps category away from a focus area with close proximity to an action that Confluence users regularly interact with (the create button on the top bar)
• It reduces the weighting & visual real estate for apps (making it easier to miss)
• It allows the Apps section to be hidden by users
• There is no feedback loop for vendors on who disables the apps section & why.

While I understand these are more business decisions from Atlassian, the output in this RFC is one of very few outlets for us to voice our concerns. If there is any way to mitigate some these concerns, we’d really appreciate it.

Question:

• What happens when 4+ Apps are installed on an instance? Your screenshot only shows 3, are the remainder hidden in the ‘more’ section and if that’s the case, how do you select the 3 to display?

[scott.dudley]

Hi Atlassian,

I admit that I am not at all a fan of the sidebar-based navigation, but I suspect that this boat has already sailed, so let’s instead talk about one of the stated goals:

@NedLindau

Create a consistent appearance and user experience across all our products, making it smoother to switch between Confluence and Jira (and back again).

I detect a certain incoherence between the stated goals and the suggested treatment of third-party apps. The overriding theme of the, uh, retheming, seems to be that Atlassian wants customers to feel like they are using one single app, allowing customers to easily switch between Atlassian products without having to spend mental energy thinking about where one product begins and another ends.

This is all well and good, but it is at odds with the decision to lump “Apps” into a separate menu (or two separate menus, as proposed).

I thought the point was that customers should not have to think about where an “app” begins or ends, so why not provide plugin points allowing vendors to populate items where they see fit, instead of throwing everything under a catch-all Apps menu? I assume that this menu will also be collapsed by default, which further hides possibly-desirable app functionality.

If a user wants to (say) create a diagram, why do they have to realize that this functionality is an “app” and that they have to go some place special to do it, rather than going to a logical location that makes sense given the context? Isn’t that loosely the opposite of what this harmonization is supposed to accomplish?

The only difference seems to be that those apps are “ours” and not “yours”, but should this really make a difference? It would be like asking users to click “Apps → Jira” in order to access Jira features from Confluence.

The main reason mentioned in the past for not doing this was that it would easily overcrowd the menus. It seems like we have a kitchen-sink style sidebar anyway, and Atlassian has already proposed methods for streamlining that problem in this post: users can decide what to hide if it gets overwhelming.

This would allow vendors to use their best judgment as to where to display items.

I would agree that there is in intractable problem when trying to balance space-specific content in the same location as navigation/app controls. But this is a problem created by the choice of the sidebar nav, and I just hope that this doesn’t get partially solved at the expense of app vendors.

If app vendors absolutely cannot be trusted to manage this properly, what about still allowing (say) up to X apps (3?) to display natively in the sidebar, with the rest in an overflow menu, allowing either the site admin or even individual users to define the ordering of what is displayed and what falls below the fold? This seems like it is practically almost already there in your mockup of “Show/hide apps”.

I would also suggest that Atlassian think about whether there might be a place for sticky scrolling here for certain sidebar elements. For example, if a space has a large content tree, what happens when the sidebar is scrolled? Does the top “nav” section remain in place, or does it disappear (partially or completely)? And would the users have to scroll down to the very bottom of the space content to find the “space apps” menu, or would it remain always visible without scrolling?

Perhaps there might also be ways to leverage “hover to expand” or “show on hover” to help discoverability.

Either way, I think it would also be helpful to provide example screenshots with enterprise-sized content trees (meaning those that exceed the vertical height of the viewport) so we can get a better idea of what you want this to look like in real life.

[Stavros_EasyApps]

Agree:

@david

The top bar is not currently cluttered apart from the “Popular Apps” in the Apps dropdown - that was always pointless
…
You’ll have 2 sections on the left named “Apps” that’s weird

Two sections with the same heading “Apps”. Creating mass confusion for the average user who does not understand nor care about the difference between global/space.

[Stavros_EasyApps]

This is an excellent suggestion:

@scott.dudley

why not provide plugin points allowing vendors to populate items where they see fit, instead of throwing everything under a catch-all Apps menu?

This has longer term value for users which in the end is the primary goal not making vendors happy. Apps help users get things done, they do not much care about the name of an app, they want to access them where and when need the functionality.

[RobertMayerK15t]

Hi, thanks for the heads up. Makes sense to align the experience across your products. Two ideas for improvements:

• As a user, I’d like to keep my focus on the task at hand. For some global apps, the opened navigation sidebar is an unwanted distraction, taking away valuable screen estate. → It would be great if app vendors could choose to collapse the sidebar when their app is opened in a global Module.
• As a user, I am hesitant to customize the sidebar as I have learned from previous manipulations (e.g. adding shortcuts or hiding apps) that they will be visible for everyone. → Make it clear that sidebar customizations will only affect one’s personal view.

[NedLindau]

Thanks for the feedback @ThorstenKamann.

Why should I see a section that isn’t relevant for the work I want to do in a space. And what are the benefits of moving the product navigation into the sidebar? I cannot find a reason for this.

Eventually, our aim is for all Atlassian products to have a consistent nav look and feel, and a consistent top nav is an important step in that direction. Another reason for moving product-specific menu items (like Recents, Starred etc) to the sidebar is to be able to differentiate them from the global menu items (Search, Create etc).

[NedLindau]

Thank you for the feedback @anshuman!

Two apps section on the same level is confusing! Even if you club them together, I strongly feel that it doesn’t work.

I provided context on another option we considered here. Between these two options, which do you think works better?

It’s weird that the global page will now have the left navigation. from a mental model aspect, it creates more confusion that it solves.

Eventually, our aim is for all Atlassian products to have a consistent nav look and feel, and a consistent top nav is an important step in that direction. Another reason for moving product-specific menu items (like Recents, Starred etc) to the sidebar is to be able to differentiate them from the global menu items (Search, Create etc).

The “Space apps” section was already pushed down with previous changes and now with this, they’ll become practically invisible. I can see this as a big bummer for “space level apps” that rely on that entry point only.

The alternative design approach proposed above where we consolidate apps entry points in the nav could help here.

If we’re stuck with the current suggestions, some ideas i can think of are to further reduce the number of items in the Product+Global Nav section.

What’s your take on which items should be removed from the default view that are currently there?

[NedLindau]

Thanks for the feedback @scott.dudley!

This is all well and good, but it is at odds with the decision to lump “Apps” into a separate menu (or two separate menus, as proposed).

Want to make sure I understand this one. Apps are already lumped into these two separate menus today, right? Or am I missing something in your comment here?

I thought the point was that customers should not have to think about where an “app” begins or ends, so why not provide plugin points allowing vendors to populate items where they see fit, instead of throwing everything under a catch-all Apps menu? I assume that this menu will also be collapsed by default, which further hides possibly-desirable app functionality.

Thanks for this suggestion! Could you provide an illustrative example of where you’d want to have a plugin point in the new nav and what you’d do with it?

If a user wants to (say) create a diagram, why do they have to realize that this functionality is an “app” and that they have to go some place special to do it, rather than going to a logical location that makes sense given the context? Isn’t that loosely the opposite of what this harmonization is supposed to accomplish?

Want to make sure I understand this one. Isn’t this how it works today? For example, to create a Gliffy diagram, I have to know that Gliffy is an app and know how to create it from within a page.

If app vendors absolutely cannot be trusted to manage this properly, what about still allowing (say) up to X apps (3?) to display natively in the sidebar, with the rest in an overflow menu, allowing either the site admin or even individual users to define the ordering of what is displayed and what falls below the fold? This seems like it is practically almost already there in your mockup of “Show/hide apps”.

We are planning on showing all installed apps in the sidebar when the menu is expanded instead of cutting apps off after n.

I would also suggest that Atlassian think about whether there might be a place for sticky scrolling here for certain sidebar elements. For example, if a space has a large content tree, what happens when the sidebar is scrolled? Does the top “nav” section remain in place, or does it disappear (partially or completely)? And would the users have to scroll down to the very bottom of the space content to find the “space apps” menu, or would it remain always visible without scrolling?

Great suggestion! We’re thinking about this for sure. Currently, we will “stick” the space name when a user scrolls downward, but all of the product/global items about that will scroll off the screen. Is this how you’d expect it to work?

Either way, I think it would also be helpful to provide example screenshots with enterprise-sized content trees (meaning those that exceed the vertical height of the viewport) so we can get a better idea of what you want this to look like in real life.

Will work on this.

[NedLindau]

Thank you for the feedback here @RobertMayerK15t!

As a user, I’d like to keep my focus on the task at hand. For some global apps, the opened navigation sidebar is an unwanted distraction, taking away valuable screen estate. → It would be great if app vendors could choose to collapse the sidebar when their app is opened in a global Module.

Great point — I’ll look into feasibility here.

As a user, I am hesitant to customize the sidebar as I have learned from previous manipulations (e.g. adding shortcuts or hiding apps) that they will be visible for everyone. → Make it clear that sidebar customizations will only affect one’s personal view.

Also a great point. We’ll work on clarifying this in the UI.

[anshuman]

@NedLindau

I provided context on another option we considered here. Between these two options, which do you think works better?

If I had to pick from the two options then I would go for the original version as that clearly separates the two contexts - Global and space

[scott.dudley]

Hi @NedLindau

@NedLindau

This is all well and good, but it is at odds with the decision to lump “Apps” into a separate menu (or two separate menus, as proposed).

Want to make sure I understand this one. Apps are already lumped into these two separate menus today, right? Or am I missing something in your comment here?

Yes, they are currently lumped into separate menus. That is also exactly my point. This navigational change is being driven by wanting to (in Atlassian’s words) “Create a consistent appearance and user experience across all our products, making it smoother to switch between [various Atlassian products]”.

Since you are redesigning to make switching smoother, why perpetuate the point of friction by pigeonholing certain functionality into being part of an “apps” menu? Can apps not be part of the smoother switching too?

If a user wants to (say) create a diagram, why do they have to realize that this functionality is an “app” and that they have to go some place special to do it, rather than going to a logical location that makes sense given the context? Isn’t that loosely the opposite of what this harmonization is supposed to accomplish?

Want to make sure I understand this one. Isn’t this how it works today? For example, to create a Gliffy diagram, I have to know that Gliffy is an app and know how to create it from within a page.

Yes, it is how it works today, and as above, I would argue that it is a paradigm to be avoided. (And I thought it was also the paradigm behind this entire redesign.) The user wants to create a diagram, period. Why should the user need to know that this is an “app”, any more than the customer should need to know that they need to switch to Jira before they can search for Jira issues in the new proposed system? (Aren’t both just implementation details?)

And if apps should be treated separately, why do certain Atlassian apps (for example, Team Calendars) get special treatment and get elevated out of the “app” menu into prime sidebar real estate, while third-party apps cannot display there? The reasons mentioned many moons ago have been lack of screen real estate and possible contention with many apps installed, but it seems like the proposed changes to showing/hiding sidebar items already solves those problems.

At the end of the day, Solutions Partners sell a combined set of products that work together, including Jira, Confluence, and third-party apps. The entire goal of this change seems like it is to harmonize switching between products. While you are doing this work, why not allow Marketplace partners to benefit as well, instead of enforcing the status quo? Instead of siloing apps simply because they come from a third-party vendor, why not allow vendors (and users) to organize their apps’ touchpoints in appropriate locations based on functionality?

I would also suggest that Atlassian think about whether there might be a place for sticky scrolling here for certain sidebar elements. For example, if a space has a large content tree, what happens when the sidebar is scrolled? Does the top “nav” section remain in place, or does it disappear (partially or completely)? And would the users have to scroll down to the very bottom of the space content to find the “space apps” menu, or would it remain always visible without scrolling?

Great suggestion! We’re thinking about this for sure. Currently, we will “stick” the space name when a user scrolls downward, but all of the product/global items about that will scroll off the screen. Is this how you’d expect it to work?

I am personally a fan of the Confluence DC system of having (for example) a sticky Space Tools menu at the bottom of the sidebar. Not sure how that would transition into your new paradigm. My answer also depends on how you decide to implement the sidebar navigation.

For example, when a user navigates to a page, will the page tree render as automatically fanned open and already scrolled to highlight the current page that the user is visiting?

If so, the global space features will almost always be hidden.

If not, users will presumably have a hard time figuring out how to navigate laterally through content, especially if they have to manually retrace the breadcrumbs in the tree.

How is this implementation envisioned?

Cheers,
Scott

[david]

@scott.dudley is exactly correct with everything above.

My name is David and I approve of this message.

[scott.dudley]

One other question: will this functionality be rendered differently on mobile? (Is it responsive design?) For the sake of the question, assume that users may be either using the mobile web or possibly the “request desktop view”.

[anshuman]

@NedLindau

What’s your take on which items should be removed from the default view that are currently there?

If possible, I’d have the global apps in a fly out menu similar to Recent, Starred etc.

Regarding which menu items to remove/hide, I’d hope that’s something that’ll depend on the how frequently the options are used and if they are valuable to a big enough cohort of users.