Hi @EshaaSood
I have huge concerns about this approach:
1. The choice to display messages in end user iframes amounts to a change in scope with insufficient notice
The idea of “we will plaster messages across app iframes” is a major departure from the previous messaging of “we will display a message in the Connected Apps center”. I am less concerned about the Connected Apps page, but the app iframes are a huge issue.
Dumping scary warnings in the user-visible modules of an app is a scare tactic and no vendor will be happy to have this in their app. This will generate support requests, vendors will lose customers, and it generates unnecessary user worry. What goal does Atlassian achieve by scaring end users before the end of support, other than the hemorrhage of customers and loss of vendor goodwill? No one wants to be still on Connect, but many vendors are still forced to anyway due to lack of platform parity.
Further, placing this messaging in user-visible modules was not previously announced and it was not part of any RFC. Even the title of RFC-129 is just “Surfacing … to Site Admins”. I think this fact alone necessitates more notice.
I also want to push back significantly against end user iframe notification in the first place. Why does this even need to exist? Why do end users need to care? Why display it before EOS? Why can this not be surfaced only in the Connected Apps location, where admins are trusted to make the decision? (If the answer is: admins never go to the Connected Apps page…then this is something that vendors have been complaining about for years regarding app updates, so please find a way to fix that problem directly rather than burdening app iframes and ignoring the root cause that Atlassian itself created.)
Realistically, one of my apps uses a set of features that are on the long tail of the Forge implementation roadmap. If they become available at all before EOS, it will probably be only shortly before EOS. If a feature is scheduled to be built by Atlassian in December, does that mean that Atlassian will force my customers to suffer through needless iframe warnings in September, October and November just because Atlassian is dragging its heels? Atlassian almost never commits a date to anything until a feature is actually shipped, so I cannot even mark my migration status correctly until the feature is out. I want to move to Forge with you, but none of this is under my control.
2. Missing clarity on scope and messaging of iframe warnings
Other than anecdotal evidence in this thread, it is not clear where Atlassian will display these end user iframe warnings in September. The Forge module page only talks about the Connected Apps page. The early comments in this thread suggest that they will appear in “some” app iframes. Which iframes will be impacted? What layout issues can we expect to have to deal with?
Knowing specifically which modules will have their iframes “decorated” is crucial to understanding how this will impact the UX, and unless I missed something, Atlassian has not provided this detail anywhere.
Furthermore, although the Forge module page describes how the different module settings will impact the Connected Apps pages, it does not describe at all about what will happen on end user iframes. Which migration module settings will cause which warnings to appear (or not appear) on end user iframes? When messages do appear, exactly what will they say?
3. Lack of clarity from Atlassian on which blockers will be accepted before EOS hinders determination of migration status
@rmassaioli posted about Atlassians’ intent to triage Connect blockers before EOS, and the post indicates that three monthly triages were scheduled in March, April and May. As far as I can tell, there have been only 3 issues (!) marked as “accepted” during that process.
That leaves a significant number of vendors in the dark. Unless I have misunderstood the labeling system, I believe the stats look like:
- 80 issues were requested for Connect EOS triage
- 54 of those issues were rejected
- Another 14 were rejected (without seemingly having been tagged as requested in the first place)
This leaves us with 3 accepted issues, 68 rejected issues, and two dozen or so with no status that I can find. It seems unfair for Atlassian to ask vendors to provide their EOS status when vendors are still left in the dark by Atlassian itself.
4. End user messaging is disconnected with Atlassian’s announced Connect EOS plan
The official Connect EOS messaging is clear that Connect is becoming unsupported, but not that it is being removed from service. Why do the messages earlier in this thread say that apps “might stop working”? Why tell one thing to vendors and a different thing to customers?
The proposed message in the migration module page is better (“This app is running on a platform that will be unsupported after December”). It is unfair to soft-sell the problem to site admins but try to scare end users in iframes by saying the app might stop working. The messages should be harmonized. I also agree with other commenters that the specific EOS date should be listed (is it Dec 1, Dec 31, or something else?).
5. Lack of notice of new effective requirement to become Connect-on-Forge
I also have concerns about the timing and the lack of prior notice about another new requirement that is being introduced by this change. The Connect EOS is in December, and if Atlassian stays true to its word, vendors should not be required to move to Forge until then. This is again not due to lack of desire: many are waiting on Atlassian to deliver the required platform parity.
The first problem is that Atlassian has made this a Forge-only module, so apps currently running as pure Connect cannot even use it, regardless of their migration readiness. I believe this point was raised in the RFC thread.
This move effectively creates a brand new constraint for pure Connect apps, with a short deadline to move to CoF.
You will argue that vendors should be required to move to Connect-on-Forge before then, but this requirement to move to CoF is:
(a) something that has not been communicated in advance (until now),
(b) a technically inferior solution (CoF apps can no longer publish release notes, CoF apps inherit the inherent additional instability and any downtime of the Forge app install process, and others),
(c) tying vendors’ hands to a technical implementation that should not be Atlassian’s to dictate. If I prefer to one-shot my app from Connect to Forge, why are you forcing vendors to make a technically-unnecessary extra transition just to avoid losing customers with scary messages?
You can argue that apps are not “required” to become CoF, but this is a slight of hand: apps are not required to become CoF, unless you mind having scary warnings in all of your app pages (which is satisfactory to effectively no one).
6. Requirement to backport module to major versions
It seems kind of silly that vendors need to backport the migration module to every released major version of the app (as the module docs imply) in order to display the correct message to all users. It implies that vendors also need to redo the backporting every time the status changes. Did any vendor actually ask to be able to provide the “version-specific messaging” that this supposedly facilitates? This feels like a bug, not a feature. Can Atlassian please pull the message from the latest version of the app for all tenants to eliminate busywork?