Google Meet アドオンの設計に関するガイドに沿って、ユーザーの全体的なエクスペリエンスを改善します。
認可のベスト プラクティス
認証または認可を必要とする Google Meet アドオンには、次のベスト プラクティスを使用することをおすすめします。
Google ログインを使用する
Google Workspace アドオンの多くのユーザーは、会議に参加する前にすでに Google にログインしています。そのため、Google One Tap をオプションとして用意すると、ユーザーはサインイン フローで数回のクリックを省略できます。詳しくは、アドオンのログイン方法を管理するをご覧ください。
サードパーティのログインページを新しいウィンドウで開く
アプリでは、Google ログインに加えて、追加のログイン メカニズムを提供できます。その場合は、新しいタブでログインページを開くのではなく、ダイアログ ウィンドウを使用します。こうすることで、ユーザーには引き続き Meet の通話を表示してその通話に戻ることができ、全体的なクリック数が少なくなります。
Google API のスコープを適切にリクエストする
Meet アドオンが Google API を呼び出す場合は、アドオンに必要な OAuth スコープの完全なリストを指定する必要があります。これは、Google Workspace Marketplace アプリ構成ページで行います。これらのスコープを追加すると、ユーザーが Meet アドオンをインストールするときに、アプリにアクセスを許可するデータの種類を示すプロンプトが表示されます。
アドオンを公開する前に、OAuth 同意画面も設定する必要があります。そのためには、Google Workspace Marketplace アプリの構成とまったく同じ認証スコープを追加する必要があります。OAuth 同意画面を構成するには、スコープがリクエストされたときに表示されるブランディング情報、プライバシー ポリシー、利用規約も設定する必要があります。公開するには、これらの情報をすべて検証のために送信する必要があります。
Google Workspace API を呼び出すコードを記述する場合は、JavaScript クイックスタートに沿って作業するのが最も簡単な方法です。このアプローチは、Google ログインとダイアログ ウィンドウの使用に関するベスト プラクティスに準拠しています。JavaScript でトークン クライアントを初期化するには、アプリケーションが実行時に実際に使用するスコープを個別にリクエストする必要があります。最適なユーザー エクスペリエンスを実現するには、リクエストされたスコープが Google Workspace Marketplace のアプリ構成ページのスコープと一致している必要があります。この冗長性により、ユーザーがスコープを取り消した場合に対処するためのフォールバックが提供されます。
メンテナンスのベスト プラクティス
次のベスト プラクティスは、メンテナンス可能なウェブ アプリケーションを作成するためのものです。Meet アドオンを作成する場合は特に重要です。
Google Meet アドオン SDK の最新バージョンを使用する
Meet アドオン SDK は定期的に更新されます。この SDK はセマンティック バージョニングに準拠しています。最新バージョンを確認するには:
- gstatic を使用する場合: 最新の SDK バージョンは、SDK の使用手順の gstatic URL に含まれています。
- npm を使用する場合: Meet アドオンをホストするウェブサイトの
package.jsonを含むディレクトリからnpm update @googleworkspace/meet-add-onsを実行します。
ステージング用の Google Cloud プロジェクトを作成する
Google Meet アドオンが Google Workspace Marketplace で公開されると、Google Meet アドオンの新しいデプロイは Meet ユーザーがすぐに利用できるようになります。キャッシュを空にするか、キャッシュが期限切れになると、これらの更新がユーザーにすぐに表示されます。したがって、変更が十分にテストされるまで、本番環境のサイトに変更を push しないことをおすすめします。
本番環境に直接デプロイしないようにするには、組織に非公開で公開される個別の Google Cloud プロジェクトを作成することをおすすめします。この Cloud プロジェクトは、Meet アドオンのステージング環境と開発環境の両方をホストします。この Cloud プロジェクトへのアクセスは、アドオンの開発に直接携わる小規模なチームに限定する必要があります。
アドオン用にこれらの代替環境を作成するには、まず、所有するドメインで、アドオンを含むウェブ アプリケーションの代替環境をホストする必要があります。その後、ステージング Google Cloud プロジェクトに別の デプロイメントを追加することで、Meet アドオン用の代替環境を作成できます。これらの新しいデプロイには、ウェブ アプリケーションの代替環境を指すマニフェストが必要です。次に、各アドオン環境を次のようにインストールすることをおすすめします。
- ステージング: ステージング バージョンを限定公開して、組織内のすべてのユーザーがテストに参加できるようにします。
- 開発: [アクション] 列の [インストール] をクリックして、Meet アドオンの開発版を自分のアカウントにのみインストールします。
テストを作成する
Meet アドオンを開発環境にデプロイする前に、単体テストを作成することをおすすめします。単体テストには、次のものが含まれます。
- Meet アドオン SDK をモックし、Meet アドオンが SDK 関数を想定どおりに呼び出していることを確認します。
- 任意のウェブテスト フレームワークを使用して、アドオンの SDK 関連以外のすべての機能の単体テストを行います。
ユーザー エクスペリエンスのベスト プラクティス
以下のベスト プラクティスは、Meet アドインをより直感的で洗練されたものにするのに役立ちます。
サイドパネルですべての開始状態を管理する
サイドパネルで行われたユーザー操作に基づいてアドオンを設定することを強くおすすめします。これは、JavaScript でアクティビティの開始状態を設定することで行います。ActivityStartingState に入力するデータはすべて、サイドパネル内でアドオンの開始者（通常は会議のホスト）が設定する必要があります。サイドパネルの最初のビューは、アドオンの設定を制御するフォームと考えることができます。
使用しないときはサイドパネルを閉じる
startActivity() メソッドを呼び出してアクティビティを開始した後、サイドパネルを開いたままにするのは、Google Meet アドオンのユーザー エクスペリエンスの重要な部分である場合に限ってください。メインステージが開いたら、unloadSidePanel() メソッドを呼び出してサイドパネルを閉じることができます。
画面共有を通じて Meet アドオンを宣伝する
Meet アドオンは、画面共有よりも豊富なエクスペリエンスを提供します。ただし、多くのユーザーは Meet の画面共有機能を使い慣れています。ユーザーが Meet アドオンをホストするウェブサイトを表示するタブを共有した場合、Meet アドオンをインストールまたは使用するよう促すバナーをすべての通話参加者に表示するように Meet を設定できます。詳細については、画面共有によるアドオンのプロモーションをご覧ください。
ロゴのデザインに関するガイドライン
Meet 固有のロゴを設計する際は、次のガイドラインに沿って、現在と将来にわたって最適な外観になるようにしてください。
PNG ファイル形式を使用し、サイズを 256 ピクセル x 256 ピクセルにします。
透明性を使用する。
Meet アドオンのデベロッパー ツールを使用して、ダークモードでロゴが適切に表示されることを確認してください。
特定のアプリ統合のグラフィック要件に準拠してください。
画像にパディングを含めないでください。代わりに、ファイルの境界まで画像を拡張してください。