This is an extraordinarily lazy way of not solving any problems, but just making a load more.
Please come back again when you’ve actually thought some of this through. In. The meantime, just cancel the RFC.
3 Likes
I hate this.
I agree with the question. This aspect should be clarified. The icon is significant for our app.
1 Like
Hey everyone, we’ve heard your feedback and we’re making some changes:
Dynamic byline content
- The byline icon and text will be dynamic
- We will no longer be hiding the apps by default in the byline. A user can hide the apps if they like but the apps will be open by default
- We will not be making any changes to the ordering i.e It will be exactly the same as it currently is
NB: User’s have on average 1 app in the byline and 8 apps in total
Deprecations
We’d really like to hear from you about how you’re using these locations so we can better understand alternatives if possible. I’ve made myself available for virtual calls tomorrow. I’m currently on the West Coast and would love to connect with you via Zoom. Feel free to book in time with me here
3 Likes
I use alt.footer to inject background scripts in published pages. Connect apps don’t have any “background process” feature so if you want to keep things client-side (as customers want) then you often need to run a script on page load.
eg one of my apps is a word count that updates the byline dynamically:
- On page load a script is loaded into
alt.footer - Script checks if the page version has changed against a content property
- If it has, it does a new word count on the content and updates the dynamic byline
If you deprecate that location then the only alternative for this use case will be to inject this script into alt.general and the user will see the Atlassian “loading app…” spinning loader at the top of every page.
If there are a dozen other apps installed that also take this approach, then the user will see a dozen stacked spinning loaders at the top of every page.
2 Likes
This is pretty much the same use case as our app, except without the byline.
We use the atl.footer location to read a bunch of things from the page then send data to Google Analytics.
No one wants to see a random loading spinner from Connect at the top of the page. It would be quite off putting.
2 Likes
Will these be available on Connect apps? I seem to remember Forge having access to something like this already, but not Connect.
These extension points could open up lots of opportunities for us to enrich the user experience, depending on the implementation. If we want to take some action based directly on the content that was highlighted, we obviously need to know what that content is - what data specifically would be provided to the app about the highlighted content (and in what format)?
Hi @TamimNoorzad,
One concern I have with the new approach to the content byline is that it seems no longer possible to add small images in the byline or update them via dynamic properties (currently possible). This is a handy feature and we use it to display important information at a glance.
We understand the need to de-clutter the current experience, but perhaps certain small allowances can be made (small images/customize the brief content shown so we are not just limited to app title).
In the spirit of decluttering the byline, will Atlassian also be removing the “version comments” and the “X page comments” segments?
If not currently in scope I suggest removal be considered. If they are being retained they should be added back into the mockups.
Chris C
Digital Rose
4 Likes
Being able to tell if something is enabled/disabled at a glance in the byline is handy. It’s not clear if this will be retained.
1 Like
For those concerned about losing atl.footer; would it be helpful if we provided a new extension point that would allow you to run background scripts as an alternative?
2 Likes
I think my comment here might answer this question. Please let me know if you need additional clarity on the new byline designs.
Yeah a background script location would be good for that use case. Although better to lean more towards “if it ain’t broke, don’t fix it”.
No joke, the overwhelming majority of my time as an app developer on this platform is filling in holes that Atlassian digs.
Almost every RFC is a business risk for vendors and it’s very clear that the platform is too complicated for any individual or team within Atlassian to know what the implications are for any given intervention.
6 Likes
I second this point and raise you the ‘See how many people viewed this page’ item, which takes up pretty much the whole width of the byline on my screen 
4 Likes
This would probably be OK if such an extension point would be provided system-wide, meaning displayed on every single type of Confluence page at launch. (Meaning: if you go this route, please deliver it 100%, rather than launching it for 80% of “commonly-used” page types and indicating that the rest will come “later”. The whole reason it’s useful is that it’s on every page, rather than on “most” pages.)
Also, how would this background script delivery work, if not through the existing Connect webPanel module type (which can include UI assets)?
I also understand Atlassian policy is that all new extension points are to be delivered on Forge, but it would not be acceptable from a vendor perspective to remove the atl.footer extension point from existing Connect apps and make the replacement available only on Forge. The ecosystem already has enough moving pieces to deal with and vendors should not need to transition app types or adopt Forge just to maintain an existing feature.
7 Likes
Hi @TamimNoorzad under Deprecation of existing locations, you did not mention atl.page.metadata.banner
system.content.buttonand system.editor.precursor.buttons anymore.
Can you confirm that this means that they are not under consideration to be deprecated anymore? – Thanks for the additional insights and updated concepts.
Like @scott.dudley said, this would probably be OK provided that the new extension point was available for Atlassian Connect and not just a Forge-only feature.
Failing to do so would continue to kill our app which is currently on Atlassian Connect as Forge is still not ready yet to allow migration of our app from Connect.
2 Likes
Hi @RobertMayerK15t,
Thanks for your message. We are still considering the deprecation of those locations (atl.page.metadata.banner, system.content.button, and system.editor.precursor.buttons).
Hi @TamimNoorzad ,
We want to express our concerns regarding the decision to deprecate the specified extension points (atl.page.metadata.banner and system.content.button).
This decision is very undesirable and could negatively impact the functionality of our application.