RFC-63: Page Extension in Editor, Design changes and more

Well, it depends on what “background script” means and what an app can do with such a script.

Our requirements would the same as for a web-panel iframe:

  • It has to be supported by Connect.
  • It needs to be running in the browser.
  • It needs to have access to the context of the content in which it is running. In Connect speak: AP.context and AP.navigator functions have to be working.
  • It needs to be running in the context of the authenticated Confluence user. This means AP.currentUser function would provide access to the current user. The context JWT would contain the information of the user so that a request sent to the backend server of the app could be handled on behalf of that user.
  • There should be the possibility to interact with the user, e.g. by showing a flag.
  • It needs to be available for different content types at least for pages, blogposts and the editor of page templates. Ideally for every content type (whiteboards, etc.).

Btw. it is kind of surprising how atl.footer landed on the deprecation list. It wasn’t mentioned in the initial post. After Scott made you aware that it was removed w/o notice you silently added it to the deprecations :thinking:

5 Likes

Hi Atlassian team,

As a software developer of Communardo, vendor of the Metadata for Confluence app, I would totally agree with the previous feedback already given here. There would be significant blockers for our app in the proposed changes.

Deprecation of the atl.page.metadata.banner

Our users would be interacting with a panel in the form a button inserted into atl.page.metadata.banner extension point, that triggers the opening of a dialog used for assigning/editing metadata.

Our major concern is usability. Not only are the customers accustomed to the existing way of interacting with the app but changing it into a Byline item would mean reducing visibility, not being easily noticeable and therefore preventing our app from effectively communicating with the users.

Currently, the panel itself displays dynamic information. Because you recommend a limit of 20 characters for the Byline item, we are forced to change again the feature of our app and this way we would hide more information from the users.

Deprecation of system.editor.precursor.buttons

The functionality explained below is similarly implemented from the page editor side, adding to the system.editor.precursor.buttons extension point. You mentioned that the updated Byline designs should be able to cater for the deprecated locations. Does this mean that the Byline location would be present in the Confluence page editor? If yes, how does that work, the same as for the page rendering view? Maybe sharing a screenshot for the page editor part, would help.

Deprecation of the atl.editor.savebar

We would need an alternative for it because we are using the location as a substitute for a background running script. In the current solution, we could execute the script in the context of the content in which it is running, we have access to the currently logged user, and we are able to show a flag notifying the users.

Considering atl.general location as a substitute, you have informed us that the atl.general is going to be included in the editor of a page as well. But, as others have already mentioned, users would get confused a lot if they see a loading spinner at the top of the page and then not render anything.

Sidebar overflow menu

We are using the current system.content.action/modify location so that the user can interact with the app easily. As for the change on consolidating the existing extension points into a menu item ‘Apps’, it would contribute to further hiding app functionality, diminishing the user experience overall. As a user, I would get confused not seeing the buttons anymore on first level of the menu. Also, it can happen that a user could not be able to identify which button comes from which app and get furthermore confused.

1 Like

Hi @TamimNoorzad,

Can you expand on the desire to remove atl.footer in the first place? Is there some technical reason why Atlassian cannot provide it, or is it an aesthetic concern related to not wanting to provide an arbitrary amount of additional screen real estate?

If the latter is your concern, what about continuing to allow atl.footer as it currently exists as a standard webPanel, but forcing the web panel size to be 0x0 when rendered in this context? It seems like this would satisfy the concerns that have been mentioned by vendors on this thread (still allowing script loading, providing user context, and maintaining the ability to interact with the user) but also not create a ton of work for Atlassian or vendors.

4 Likes

Hi everyone, I wanted to inform you that we will be extending the RFC discussion period by an additional week to ensure we have enough time to review and consider all the feedback. The updated dates have been updated in the original post as well.

This would also work for our apps using it.

2 Likes

Hello,

Our team have several concerns regarding this RFC. Deprecation of the atl.page.metadata.banner will affect UX when interacting with our app. A core feature of our app Compliance for Confluence allows users to classify content with classification levels. The atl.page.metadata.banner location and ability to display dynamic content allows users to see how content is classified at a glance. We worry moving this to the byline would obfuscate the classification of content and make this feature more difficult to interact with.

We’re concerned that changing the location of the classification level (and any items in these locations being used by other apps) may disrupt user expectations, as they are accustomed to seeing it in its current position, and overall lead to a more negative user experience. Relocating is likely to seem unnecessary to users who rely on this placement for their workflow, rather than meeting your intended goal to make a “more consistent UI”.

5 Likes

Hi everyone, thank you for all the feedback. We will now be closing the RFC discussion phase now and will share the outcomes with you by the 11th of October.

Closure statement

What did we hear?

  • There were concerns about the potential loss of dynamic byline items, as many apps rely on this feature to display crucial information at a glance.
  • Many expressed that hiding apps in the byline and consolidating app extension points into the sidebar and byline might reduce discoverability and negatively impact user experience.
  • Additionally, concerns were raised about the deprecation of key extension points like atl.footer and atl.page.metadata.banner, which are critical for some apps.

What did we change?

In response to the feedback, we made the following adjustments:

Byline improvements:

  1. We revised the experience to display up to 4 apps by default in the byline by default and increased the text size for improved visibility. If a page contains more than 4 apps, the additional apps will be hidden in an overflow menu that users can open to display all byline apps. Based on current and projected app installations, we anticipate that this change will not cause any major issues but will monitor user feedback.

  2. Apps can have dynamic names (up to 25 characters) and dynamic icons, which addresses the need for displaying real-time information. If the app display name is longer than 25 characters, it will be truncated.

  3. Visibility control: The ability for admins or users to control app visibility and order in the byline is being considered for future implementation, although it’s currently outside the scope of this RFC.

What is coming next?

  1. atl.metadata.banner
    Based on design requirements, we believe the byline location will serve as a suitable replacement.

  2. atl.footer
    After considering your input, we’ve decided to retain the atl.footer location but will remove the UI component, allowing it to be used for running background scripts only and not displaying content to Confluence users.

  3. Deprecation: We are still considering the deprecation of:

    1. page.metadata.banner
    2. atl.page.metadata.banner
    3. system.content.button
    4. atl.editor.savebar
    5. system.editor.precursor.buttons
  4. NB: Deprecation notices will be sent out shortly

We are also exploring adding new locations and alternative design solutions, which will be introduced in a future RFC.

Timelines - next steps:

  1. The extension point changes in this RFC will be tested with the Live Pages Early Access Program (EAP) at the end of October 2024.

  2. Later in December, we will offer an optional open beta for existing customers, allowing them to opt-in to the new experience. This will bring the changes outlined in this RFC to both the editor and renderer, creating design parity across both.

  3. Further updates will be shared as we approach the planned rollout for April 2025. Keep an eye out for upcoming discussions.

Thank you for your feedback and collaboration on this RFC. Your input has been invaluable in shaping our approach. We appreciate your support!

1 Like