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

General Request for Comments (RFC)
, ,
42

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:

4 Likes
43

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
44

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
45

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.

46

This would also work for our apps using it.

2 Likes
47

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”.

4 Likes
48

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.