Since we’ve all gone beyond just one piece of feedback, here’s more of mine, from top of mind:
Problem: From the reliability angle, the whole experience with the rollout of the Fabric editor was a nightmare for our team, and others that I have observed. Poor to no communication, little testing with Connect macros before it was deployed to production, and an adherence to a vision that vendors tried to communicate would break existing Connect UX flows which seemed to land on deaf ears. Technically no APIs changed, but the change in UX both dropped details in the integration contract and otherwise broke previously legitimate ways to develop Connect macros. Now over a year after Fabric began rolling out to production there are still major defects or deficiencies in the integration of Connect macros with Fabric pages. To confuse things more the new editor has become only one of two, and yet the Connect experience for developing macros behaves as if there’s only one from the developer’s point of view. It’s been an awful, time consuming experience that still has no satisfying conclusion.
Asks: Please provide first class support for Connect macros in Fabric, and support for rendering macros appropriately in each type of editor now that Atlassian has committed to supporting both simultaneously.
Problem: Also, the Confluence REST APIs are not only some of the worst examples of HTTP-based APIs I’ve seen, they seem to get very little attention in terms of bug fixes or improvement. There’s something moderately-to-seriously wrong with every one of them I have used over the last few years. Poor error handling aside, the JSON-RPC APIs that they replaced were much more intuitive, clean, and functional (probably because they mapped to the Java APIs that Atlassian used to build the product, unlike the REST APIs which appear to be something that exist largely only for third party integrations). If you want to make life better for cloud developers, you need to prioritize the quality of the APIs they have at their disposal.
Asks: Commit more resources to the maintenance of your APIs. Build some commercial products on them in anger yourselves… or give us access to the APIs you do use (cough GraphQL cough).
Problem: Despite some light messaging to the contrary, in practice it feels like the Connect-based developer experience is now barely being supported while Atlassian piles on resources to Forge. Forge sure looks promising for a certain class of new app dev some day in the distant future, but doesn’t really do anything for us today beyond add stress – we know we should be trying to stay abreast of it and be ready to hit the ground running one day when you can build monetizable apps with it, yet in the meantime small teams like us struggle to keep the lights on with the existing cloud apps we require to stay in business.
Asks: Don’t forget about Connect while fervently racing to deliver Forge, even if Forge is internally being thought of as simply a new facet of Connect (or vice versa).
You’re about to have 3 third party integration platforms, yet the first two aren’t even getting the support they need to deliver a winning developer experience. I know and respect many members of the “incredible team that’s doing everything they can to make our cloud developer experience delightful,” but from this side of the fence the experience is anything but delightful.
Problem: We do interact with a few individuals on CDAC regularly that are extremely helpful. It’s unclear whether or not they are actually acting as support agents, or simply going out of their way to be helpful. Either way, we appreciate them tremendously! That said, it’s hard to know if we should lean on them when in need or not (out of respect for their generosity if they are simply volunteers).
Asks: It’d be amazing to have some kind of org chart and/or understanding of the Atlassian personalities we do get support from on CDAC so that we could know what to expect of them or what their organizational capabilities really are. It’s hard to know who to reach out to and when and whether we would be burning someone’s good will instead of leveraging an intended contact.
This is fundamentally part of the problem in using CDAC as a support system. We don’t really know whether someone is acting as a support agent or not, nor do we know if our posts raising non-critical issues are being read methodically (as they would in a support queue) or simply casually (if and when someone happens to have time to pay attention).