Bridging the gap between Connect and Custom UI

I’m Adam, a new product manager on the Forge team, here to share some details on a project we’re about to kick off. I’d love some input from the community before we get started.

We know there is still a bunch of things that you can do with the Connect Javascript API that you can’t do with Forge’s Custom UI bridge. These gaps can sometimes prevent you from building the user experiences you want on Forge.

So, over the next couple of months, we’ll be bringing the remaining capabilities from the Connect Javascript API to the Custom UI bridge. The APIs won’t be mirrored exactly, but we’ll make the same outcomes possible in a way that makes sense for Forge.

The things we’re looking at include:

So if you have any thoughts on how these things should work on Forge or which ones we should prioritise first please let me know below. If you have any ideas to improve on Connect we’d love to hear them too!

Thanks for your input. I’ll keep this post updated as things roll out.

17 Likes

Hi Adam,
Currently, you can set a Connect app as a “Time Tracking Provider.” We need the same support for Forge apps. Without it, customers will see duplicates of every time tracking functionality, like the “Log Work” action. I have also created [FRGE-562] - Ecosystem Jira for this.

2 Likes

Hey Adam,

For our use cases, this list looks quite complete. However, at this stage, this feedback feels very theoretical. As long partners cannot migrate to stage 1 it does not seem to make much sense for us to start spending time on Connect on Forge. According to my last info stage 1 and 2 will not be available before the end of the calendar year.

It would be good if enabling stage 1 could be prioritized.

1 Like

Hi,

I know this is still an early stage and the request is quite specific, but what we’ve missed in connect is the possibility to open dialogs from another app.

We need this for integration of our apps (e.g. use a shortcut in one app’s UI to navigate directly to a specific feature of the other app) and currently the only somewhat crude workaround is the event bridge and empty iframes that slow down page loads.

Would be awesome if you could consider it.

Cheers,
Jens

1 Like

More control over the size of custom UI modals (e.g., by setting their width and height in pixels) would be great. At the moment, we can only choose between small, medium, large, and xlarge but that’s often not enough, especially because the aspect ratio of the modal can’t be changed.

1 Like

Hello @AdamMoore, thanks for reaching out to us developers. I assume the things you listed are planned not to be supported by Forge?

May I ask why a user’s locale and timezone will not be available? Will there be other means to retrieve locale and timezone?

What are the plans to allow localization and showing dates in the user’s timezone within Forge? See also FRGE-387 for more context.

Would be great to get more details what else will not be available within Forge as soon as possible.

Thanks!

2 Likes

Hello @AdamMoore ,
The list you wrote is quite comprehensive on what is related to the Custom UI side of things.
There are some other gaps we’ve found but are more related to Forge, rather to Custom UI like:

  • Being able to define Confluence Custom Content Types from the manifest
  • Using createHistory in global pages (only tried Confluence, but I assume the same would happen in Jira)
  • Being able to send email (or other type of) notifications to users

I know these are not strictly Custom UI related but they’re also a reason why we’re having trouble moving our apps to Forge.

1 Like

Hi Adam,

Great to hear you’re looking at bringing more to Forge’s Custom UI bridge.

What our team is highly interested in is the ability to use inline macros in Forge. Please, see FRGE-511 for more background on this. Hope for a quick prioritizing and implementation from you. And thanks for keeping us updated :slightly_smiling_face:

1 Like

Rich text macros
Rich text macros serve too many use cases to list, allowing the user the work with the regular Confluence editor composing macro bodies using all the rich-text features Confluence has to offer, including nesting other custom and native Confluence macros. The recently-previewed referentiality feature does not and is not seemingly intended to meet these use cases, as has been discussed in on that page.

Inline macros
Another feature available on both server/DC and Connect going back many years. We have several macros which depend on this and would not make sense to have as block macros.

Custom editor
We’ve invested significant time building a custom editor for our macros, providing highly customized and focused user experiences. We have macro features and functionality which cannot be replicated using the basic Forge macro config components.

Ability to determine edit/view mode
This may be covered in the context token mentioned. Additionally please consider the navigator which allows us to detect preview mode.

Content API
At the moment some of the expand options on the content API do not return expected data for Forge macros, specifically the view and styled_view. Connect macros in these views are displayed with the expected HTML, while a Forge macro has an error.

These are the primary blockers for us adopting Forge.

https://ecosystem.atlassian.net/browse/FRGE-216
https://ecosystem.atlassian.net/browse/FRGE-601
https://ecosystem.atlassian.net/browse/FRGE-511

10 Likes

To me, it seems like a well-made Events API would provide the most flexibility at the moment and could also enhance a lot of the UI kit experience provided you give us a way to fire events from within UI Kit Components. It could be used to handle many of the things on your list such as closing dialogs or reloading the parent page if done well. So while this might be a more complex piece of work, I think the payoff would be high for us developers

2 Likes

I thought the list was of the things they want to make available in forge, not the other way around.

1 Like

As for the Dialogs: in Connect we are able to implement a full screen dialog to solve a few limitations we had with the default dialog. This way we have full control over the dialog (optic and functionality) to implement more complex dialogs

@denizoguz - the Jira team will publish a separate update coming soon, specifically on the roadmap for Jira extensibility.

@JakubMierzewski has also created FRGE-619 for tracking interest in time tracking providers specifically. Please vote and watch that issue :slight_smile:

@tbinna thanks for the feedback, glad the list looks good. This is just one stream of work and we’re continuing to work on things like migration, storage, observability etc. in parallel.

You can tune in to our next webinar to get a more high-level view of everything going on.

@jens thanks, cool idea. I’ll throw it in the mix and see what we can come up with.

@BenRomberg - @JuliaWester is right. The list is functionality we will be bringing to Forge.

3 Likes

@AdamMoore thanks for the clarification! It sounded like a list of things that won’t be possible in Forge, but glad to be proven wrong :slight_smile:

Please also add openIssueDialog (openCreateIssueDialog is already in progress) from the Jira module.

Thanks!

1 Like

@klaussner it was a deliberate design decision to be more restrictive around the sizing of modals in Forge. This allows us to have responsive web functionality built-in. Apps would start breaking on different screen sizes otherwise.

It is true that you can’t control the aspect ratio of the modal, but it will stretch vertically allowing for content to grow (until it reaches the end of the screen when it adds a scroll bar). Maybe one option to effectively set the aspect ratio would be matching your content height to one of the set widths?

@m.herrmann this is really interesting, it’s on the list of “maybes” at the moment - can you give some specific examples of how you would use the full-screen dialog? I’m curious whether we could also just solve some of the limitations in the default dialog.

@AdamMoore The full-screen dialog is mostly used to get rid of a lot of the iframe limitations. While the modal iframe is using the whole screen, we only use a part of it to display the dialog. The remaining area is using a transparent background and makes the following possible

  • Dropdowns / menu / DatePicker can expand outside the dialog without issues
  • Dialog can enter a real full screen mode when the user needs it (we have a grid view of issues and sometimes you need more space to work with it)
  • Open confirm dialogs within the dialog that may exeed the size of the original dialog

I’m not sure if all of these limitations still apply to the forge CustomUi Dialog. It’s been a while since we switched to use this dialog type.

1 Like