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 ユーザーがすぐに利用できるようになります。これらの更新は、ユーザーがキャッシュを空にするか、キャッシュの有効期限が切れるとすぐに表示されます。そのため、変更が徹底的にテストされるまで、変更を本番環境サイトにプッシュしないことをおすすめします。
本番環境に直接デプロイしないようにするには、組織に非公開で公開される別の 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 アドオンのデベロッパー ツールを使用して、ダークモードのロゴがダークモードで適切に表示されることを確認してください。
ロゴ（およびその他のグラフィック アセット）がハイ コントラスト モードで適切に表示されることを、Web Accessibility In Mind（WebAIM）の Contrast Checker などのコントラスト チェッカーを使用して確認してください。
特定のアプリ統合のグラフィック要件を遵守してください。
画像にパディングを含めないでください。代わりに、画像の範囲をファイルの境界まで広げます。