RFC-85: Modernized Layout for Confluence Content Types

[AbhinavSingh]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

---

Problem

The current Confluence content experience lacks consistency and structured discoverability across different content types. Navigation elements and extension points for apps are scattered, leading to a fragmented user experience. Additionally, existing metadata and contextual information are not easily accessible, making it harder for users to interact efficiently with their content.

Proposed Solution:

We are introducing a redesigned content experience that includes:

1. Object Header - A new, streamlined header design for all content types.
   

   

2. Overflow Menu - A redesigned overflow menu with better discoverability.
   

   

3. Byline Redesign - A refreshed byline to improve readability and contextual information display (only for pages and Live Docs)
   

   

4. Action Bar - A new persistent action bar designed for quick actions and navigation.
   

   

5. Details Panel - A dedicated panel to display metadata, properties, and other contextual information.
   

   

---

Impact on Apps

There is no immediate major impact on app extension points. The changes we are making follow the same patterns established in RFC 63. With regards to apps in byline, we will be moving the apps to exist in the same line with other byline elements, and add a show less or show more chevron, if we have more than 2 apps.

Update: Near term, we will have multiple bylines (open by default) for apps to alleviate any install order and discoverability concerns. Refer to this comment for more details

However, a few upgrades will be introduced when we reach GA:

1. Moving Apps Section: The Apps section will be relocated from the Overflow Menu into the Action Bar for better discoverability.
   

   

2. New Extension Point: A new extension point in the Details Panel will be available for metadata apps.

These enhancements will not be part of the initial beta release but will be introduced in later stages as we move towards GA (or post-GA).

---

Next Steps & Feedback

We would love for you to test out this new layout as it becomes available to you in late February on the sites in the Developer Canary program. Please let us know if you encounter any issues or have any feedback about the experience. Note: We will make it available along with Live Docs (check : RFC - 83)

Additionally, as we move the app extension points from the Overflow Menu to the Action Bar and build new extension points in the Details Panel, we would love for you to collaborate with us and share your thoughts.

The new Object Header and Overflow Menu will be available across all content types. The Action Bar and Details Panel will be initially available for Pages and Live Docs only. Rollout timeline:

• Live Docs EAP Customers on February 24, 2025
• Open Beta starting March 17, 2025

Future Rollouts: As we move toward GA, we will expand these changes to all content types and introduce additional enhancements.

[anshuman]

Hey @AbhinavSingh

The proposed changes look good and clean!

We are currently in the middle of a redesign for one of our app’s core components, which previously lived in what is now the content header. With that entry point soon to be deprecated, our only meaningful option so far has been the byline, which hasn’t been the best fit for our use case.

We’re particularly interested in learning more about the Action Bar and Details Panel, as they seem like a promising alternative for us. Could you share more details on how we can engage further to discuss plans and rough timelines? This would help us align our changes accordingly.

A few additional questions and considerations:

• The RFC mentions that “a new extension point in the Details Panel will be available for metadata apps.” Could you elaborate on what qualifies as a Metadata App in this context?
• A lot of our apps interact with page labels, and we’ve observed that customers often use a large number of them. How will the labels section in the Details Panel scale with an increasing number of labels?
• Curious to understand why reactions were not moved to the Action Bar. Additionally, what will the page comments section look like—will it also be moved to the Details Panel?
• Regarding the collapsed state of the byline, I’m not convinced that limiting it to only two apps is the best approach. Is the expectation that most apps will gradually shift towards the Details Panel? If so, I’m concerned that apps hidden in the collapsed state might lose visibility and engagement.

Looking forward to your thoughts and any additional insights you can share.

Thanks!

[scott.dudley]

Hi @AbhinavSingh

If most installations have fewer than two byline items, why not change the default display to include up to, say, 6 byline items over two lines, with further items (if any) visible in an overflow menu?

As you pointed out yourself, this change would have zero impact for the majority of customers, because most do not have that many byline items. And for those customers who do have more than two byline items, it ensures that they are visible when needed.

The problem is that all the other Atlassian data is crammed into the existing line, leaving little space, and important app bylines risk being pushed below the fold. For apps that are using this field to display (for example) a dynamic page status at a glance, users should not be required to click on anything to see it.

The problem is exacerbated in that bylines are displayed in the order of installation of the apps, and thus the set of hidden bylines is not under the control of the customer. (Admins cannot uninstall and reinstall apps to try to change the installation order, because uninstalling a Forge app deletes all Forge Storage data.)

[klaussner]

@AbhinavSingh I completely agree with @scott.dudley and @anshuman regarding the byline. Please don’t hide byline items behind an overflow menu. There are so many apps that use byline items for dynamic statuses, which users are supposed to see when they visit a page. Reducing their visibility would severely impact the value we can provide to our customers.

In my opinion, we reached a reasonable solution in RFC-63, where the compromise was to show byline items in a second row below the other page details.

Why is this design reconsidered again just four months later? You are proposing a change for which you have already received detailed feedback from several vendors in RFC-63.

When customers install apps that provide byline items, I expect them to want these items to be visible. I don’t see why the expanded state in your second screenshot under “Impact on Apps” shouldn’t be the default.

If you want to reduce “clutter,” I think a better solution would be to allow admins to rearrange byline items and choose which and how many items are visible by default.

[adapps]

I want to add to the points already made. Hiding the byline is a terrible idea. Many apps, including ours, use the byline as the primary interaction point with the user. The purpose of the byline is to allow users to view and interact with the page statuses quickly. Hiding these options makes customers’ lives much more difficult.

A practical example: Our app extends Confluence by adding multilingual support. Like many similar apps on the marketplace, it uses the byline extension to display the current language of the page, allowing users to switch it with a single click.
If the language switch option is placed in a hidden section, potential users will not even know that the page supports multiple languages unless they manually search for it.

Moreover, if most customers really have fewer than two apps, having two lines of components to interact with would be minimal, making concerns about cluttering irrelevant.
The key point is that, based on our experience, the most critical customers typically have multiple apps installed that they interact with daily, so the risk of an app ending up in the hidden section is real. These are the users to whom this change would significantly impact.

Blockquote
Note: Majority of our customers have less than two apps in the byline so we don’t see discoverability as an immediate problem.

Can we have more concrete data on this statistic? Which customers were considered, and how many were included? Does it include customers on the free plan or inactive instances?
Additionally, is it possible to have this data grouped by tiers? For example:

Less than 10 users
10-100 users
100-1000 users
etc.

This is another reminder not to make assumptions or take conclusions without consulting the community. This approach allows for a more comprehensive view, thanks to the experience of those who work daily with extensions and the customers who actively use them

[AbhinavSingh]

Thanks @klaussner , @scott.dudley , @adapps , and @anshuman for the thoughtful feedback! I hear your concerns and really appreciate the ideas around customization and reordering—we’re already starting to explore those.

Right now, we’re discussing some potential near-term solutions for the Byline apps treatment internally. We’ll check back in early next week with an update.

Our goal is to create a modern, intuitive experience that feels useful and engaging. That means making apps easier to discover (e.g., action bar instead of the overflow menu) and adding more contextual extension points (e.g., details panel). Keep the feedback coming—it’s super helpful as we shape this!

[david]

Please don’t accidentally remove the atl.footer extension point without warning again when you make this change.

Cc: @JamesDumay

[NathanPooledev]

The changes seem positive overall!

We (AppFox) share many of the same concerns already expressed about how apps will be chosen/prioritised on the content byline. Further clarity on this would be appreciated. We suggest the addition of settings to allow users to choose the ordering of apps on the byline so the apps most important to their use cases are guaranteed to be immediately visible on a page.

[ShahrimanMohammad]

Hi,

I have discover that the app webitem button is missing. Can you please check on this. Log in with Atlassian account

[AbhinavSingh]

Hey team,

Circling back on the byline apps treatment. Given the importance of glanceability in the byline, our near-term approach will support multiple bylines for apps with an open by default state, allowing users to collapse them as needed. This aligns with the current customer experience while introducing a visual refresh.

Here’s how it will work:

• Apps will be placed in the first byline alongside other properties.
• As more apps are installed, they will overflow into additional bylines (no cap on the number of bylines).
• All bylines will be open by default, and users will have the ability to collapse them each time.

Since the majority of users have fewer than two apps, this approach ensures that tenants with more apps can fully leverage all available byline apps without install order limitations.

Note: We will revisit this design in future based on user feedback and as we introduce byline customization options, including reordering.

This should resolve any near term concern! Thanks again for the jam and keep the feedback flowing!

[anshuman]

@AbhinavSingh

The updates regarding the byline sound good. Thanks for hearing folks out here! Really appreciate it!

On a related and urgent note, we are seeing some discrepancies in the rollout/deprecation timelines that are affecting our apps and out customers. Could you please comment on the following?

1. This new layout (which removes the system.content.button from Pages) is available to Live Docs EAP Customers on February 24, 2025
2. Now, according to this deprecation notice, the system.content.button and other entry points should not be deprecated until 2025-04-29T22:00:00Z
3. Now the issue is that the new layout changes removes a critical component of our app Scroll Documents for Confluence which is affecting customers (and will continue to do so as the Open Beta begins in March)

We are currently in the process of finding an alternative for the deprecating extension point, but this will not be rolled out in the next couple of weeks.

Can you please verify and confirm if this was intentional or if the timelines were uncoordinated?

Thanks!

[AbhinavSingh]

Thanks, @anshuman.

The deprecation notice remains in effect, and the team will proceed with deprecating those extension points for GA after April 30, 2025.

For our EAPs and BETAs, before customers opt-in, we will inform them upfront that certain app extension points won’t be available, allowing them to make an informed decision. In specific cases where customers encounter breaking changes after opting in, we can provide a temporary opt-out until April 30, 2025, by which we expect our app partners to have viable alternatives in place.

For our Live Docs EAP customers, we will be notifying them soon in case they are impacted by this change.

[Stavros_EasyApps]

Byline reordering is a must. As mentioned they appear in order of being installed, so as an admin I add an important byline that will not show as have two other bylines I would be happy to see move to the overflow menu.

I agree with @scott.dudley and others that displaying only two seems unnecessarily small and creates problems while for those with only two it’s a moot point.