Best practices

Improve your users' overall experience by following these guides for Google Meet add-on design.

Authorization best practices

You're encouraged to use the following best practices for any Google Meet add-ons that require authentication or authorization.

Use Google Sign-in

Many users of Google Workspace add-ons will already have signed in to Google before joining the meeting. Therefore, having Google One Tap available as an option can save your users several clicks when going through the sign-in flow. For more information, see Manage sign-in methods for your add-on.

Open third-party sign-in page in a new window

In addition to Google sign-in, your application may offer additional sign-in mechanisms. If so, use a dialog window instead of opening a sign-in page in a new tab. This way, the user is still able to see and return to the Meet call, and will go through fewer overall clicks.

Note: Third-party sign-in pages for Google Meet add-ons don't have the same implementation requirements as Google Workspace add-ons. You can open a sign-in window directly from your iframed application. Meet add-ons also don't support Google Workspace add-on sign-in cards. You do, however, still need to redirect users to complete the third-party authentication and authorization process on your infrastructure.

Properly request scopes for Google APIs

If your Meet add-on calls Google APIs, then you must provide a complete list of OAuth scopes required by your add-on. This is done on the Google Workspace Marketplace App Configuration page. After adding these scopes, your users are shown a prompt when they install your Meet add-on that tells users what kind of data they're allowing your app to access.

Before publishing your add-on, you must also set up the OAuth consent screen. This requires adding exactly the same authorization scopes from your Google Workspace Marketplace App Configuration. Configuring the OAuth consent screen also requires setting the branding information, privacy policy, and terms of service that are displayed when scopes are requested. To publish publicly, all this information must be submitted for verification.

Note: Unlike general Google Workspace add-ons, it's not necessary for Meet add-ons to include the oauthScopes field in the manifest.

When writing code to call the Google Workspace APIs, following the JavaScript Quickstart is the easiest way to get started. This approach adheres to best practices for using Google Sign-In and dialog windows. Note that initializing the token client in JavaScript requires separately requesting the scopes that the application actually uses at runtime. For the best user experience, these requested scopes should match the ones in the Google Workspace Marketplace App Configuration page. This redundancy provides a fallback to handle the case in which a user has revoked scopes.

Maintenance best practices

The following best practices are for writing maintainable web applications, but they're particularly important when writing any Meet add-ons.

Use the latest version of the Google Meet add-ons SDK

The Meet add-ons SDK is updated regularly. The SDK adheres to semantic versioning. To find the latest version:

• When using gstatic: The latest SDK version is contained within the gstatic URL found in the instructions for using the SDK.
• When using npm: Run npm update @googleworkspace/meet-add-ons from within the directory containing the package.json for the website that hosts your Meet add-on.

Create a staging Google Cloud project

Once your Google Meet add-on is published on the Google Workspace Marketplace, any new deployments of your Google Meet add-on are instantly available to Meet users. Users will see these updates as soon as they empty their caches or the cache expires. Therefore, we recommend not pushing changes to your production site until the changes are thoroughly tested.

Important: Users might see a delay in updates to your Meet add-on depending on the cache policies of your application. Set your cache expiration time to an appropriate value for your application—ideally no longer than 24 hours—to ensure consistent user experiences. Users also see a new version if they empty their cache manually.

To avoid deploying straight to production, we recommend creating a separate Google Cloud project that is published privately to your organization. This Cloud project will host both the staging and development environments for your Meet add-on. Access for this Cloud project should be limited to a smaller team that's directly working on development of your add-on.

To create these alternate environments for your add-on, you first need to host alternate environments of your web application that contains your add-on, on a domain that you own. Then, you can create alternate environments for your Meet add-on by adding additional deployments to your staging Google Cloud project. These new deployments should have manifests which point to the alternate environments of your web application. Then, we recommend that you install each add-on environment as follows:

• Staging: Publish the staging version privately so that anyone in your organization can assist with testing.
• Development: Click Install under the Actions column to install the Meet add-on development version to just your account.

Write tests

Before deploying your Meet add-on to a development environment, we recommend writing unit tests. Your unit tests should include:

• Mocking out the Meet add-ons SDK, and then verifying that the Meet add-on calls the SDK functions as expected.
• Unit testing all non-SDK related functionality of your add-on with your preferred web testing framework.

User experience best practices

The following best practices help make a Meet add-on more intuitive and refined.

Manage all starting state in the side panel

We strongly encourage setting up your add-on based on user actions taken in the side panel. This is done by setting the activity starting state in JavaScript. All data that goes into the ActivityStartingState should be set by the initiator of the add-on (typically the meeting host) within the side panel. You can think of the first view of the side panel as a form that controls the set up of your add-on.

Close the side panel when not in use

After starting the activity by calling the startActivity() method, you should only keep the side panel open if it's an essential part of the user experience for your Google Meet add-on. You can close the side panel once the main stage is open by calling the unloadSidePanel() method.

Promote your Meet add-on through screen sharing

Meet add-ons offer a richer experience than screen sharing. However, many users are accustomed to using Meet's screen sharing feature. If a user shares a tab displaying the website that hosts your Meet add-on, Meet can be configured to display a banner to all call participants prompting them to install or use the corresponding Meet add-on. For more information, see promoting your add-on through screen sharing.

Logo design guidelines

Follow these guidelines when designing your Meet-specific logo to make it look its best now and in the future:

Do use PNG file format, sized to 256px x 256px.

Do use transparency.

Do verify your dark-mode logo looks good in dark mode by using the developer tools for Meet add-ons.

Do adhere to the graphics requirements for specific app integrations.

Don't include padding in your image. Extend the image to the boundaries of your file instead.

Related topics

• Troubleshoot and fix Meet add-on errors