Meet with Jitsi (Atlassian Forge)

Start or join a contextual Jitsi video meeting right from your Atlassian Jira issue or Confluence page

Comment 1

Inspiration

The ongoing COVID-19 pandemic is redefining the way teams work, and even though we all hope being able to meet colleagues in person again soon, the evolving remote work scenarios are here to stay.

The resulting surge in video meetings is now part of most people's daily life, and the video conferencing market has boomed, with notable participants like Microsoft Teams, Slack's new collaboration with AWS to migrate their custom solution to Amazon Chime, and of course Zoom with all its privacy and security flaws.

There is also also the fantastic and still not widely known browser based alternative Jitsi Meet, which is a fully encrypted, 100% Open Source video conferencing solution that you can use all day, every day, for free — with no account needed. It provides similar features to commercial solutions, can optionally be self-hosted, and has a slick mobile app as well, what's not to like?

We at Utoolity have been using it via a custom deployment on AWS for quite a while, both for our team communication and during customer support. It feels very empowering to have an easy to use and basically free video conferencing solution without any prerequisites, and most importantly, without any privacy and security concerns attached.

We want to make it even easier to use by providing a contextual meeting URL right from a Jira issue for support interactions, or from a Confluence page for sprint planning and more – meet Meet with Jitsi (Atlassian Forge).

What it does

Meet with Jitsi provides a two click experience to start or or join a meeting from a Jira issue or Confluence page. It presents a dialog with the meeting URL and allows to override default options so that users can join muted, or opt-out of the otherwise preferred peer-to-peer (P2P) mode for 1-to-1 conversations, which doesn't work well on low bandwidth connections.

These options can be defaulted per project/space, including the base URL for the Jitsi instance (defaults to https://meet.jit.si/) and team prefix (defaults to the Atlassian Cloud sub-domain). In Confluence this is achieved via the readily available SpaceSettings component, in Jira we use an IssueAction as a workaround for the missing ProjectSettings component.

How we built it

We used the Forge CLI to quickly explore the various Forge modules to identify applicable UI components for the use case. We then started over with the app itself and have refined it since, which mostly meant finding sufficiently usable workarounds for encountered UX issues based on Forge UI limitations.

The Forge CLI's excellent DX makes all this a breeze, so it is a great prototyping tool for Atlassian apps in general.

Challenges we ran into

The declarative approach of Forge UI is conceptually appealing, but the resulting UX and layout restrictions leave a lot to be desired still, even for small and straight forward use cases like this one.

Also, the absence of a Jira equivalent for SpaceSettings requires a workaround that now exposes the settings to customers (we can remedy this by removing the issue action of course). Most importantly, the absence of any kind of secure app scoped settings basically means that any logged in user can override the settings via the REST API, which is a security flaw for many use cases (see FRGE-43 and FRGE-46).

We hope that the Atlassian Team will iterate quickly on providing additional modules and UI components, and more importantly, a few layout and design options so that elements can be presented in more flexible ways in dialogs, forms, and tables.

Accomplishments that we're proud of

We are really happy that the app is cross-product from the get go and works identically in Jira and Confluence (ignoring the missing project level configuration Forge UI in Jira, which will hopefully be available soon).

What we learned

We learned the ins and outs of developing a cross-product app on Forge, which highlights the benefits of the unified declarative UI, while also surfacing its current limitations in terms of an almost generational reset to table and spacer based layouts. We appreciate that a restricted set of UI components ensures a consistent user experience, but the current limitations still seem to be too significant for many use cases, in particular for commercial apps.

Based on the excellent Forge CLI DX, we also intent to use a 'Forge first' development approach for our Cloud apps going forward, because the limitations force you to stay laser focused on the customer value, while ignoring UI/UX bells and whistles during the prototyping phase. This eases developing a domain model and the backing API/SPI so that the app core remains independent from the frontend technology. Whether or not an app still requires the currently superior UI versatility of Connect then depends on how the Atlassian Cloud platform evolves over the coming months and years.

What's next for Meet with Jitsi (Atlassian Forge)

We would very much like to make this app available to users via the Atlassian Marketplace, so depending on the ETA for the public distribution of Forge based apps, we might need to migrate the app to Atlassian Connect on the short term. That's no big deal given its static characteristics, but still a pity, because once we do and need to create a likely more appealing AtlasKit based UI anyway, migrating back without disrupting users will be difficult.

Feature wise we are contemplating how to promote a meeting to a self-contained entity so that meetings can be scheduled and become possibly long-lived resources including links to the agenda, the meeting notes, and the recording. Based on feedback, we might also provide more customization options for the meeting URL, for example by using the more memorable Confluence page name.

Also, we will refine the CloudFormation template that provisions a custom Jitsi Meet instance on AWS so that it gets more cost effective and scalable. Low hanging fruits are splitting the current monolithic Jitsi Meet on Docker image into the underlying four services that can then be independently autoscaled on Amazon ECS and AWS Fargate.

Share this project:

Updates