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 アドオンの代替環境を作成できます。これらの新しいデプロイには、ウェブ アプリケーションの代替環境を指すマニフェストが必要です。次に、各アドオン環境を次のようにインストールすることをおすすめします。
- ステージング: ステージング バージョンを限定公開して、組織内のすべてのユーザーがテストに参加できるようにします。
- 開発: [Actions] 列の [Install] をクリックして、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 アドオンのデベロッパー ツールを使用して、ダークモードのロゴがダークモードで適切に表示されることをご確認ください。
特定のアプリ統合に関するグラフィックの要件に準拠してください。
画像にパディングを含めないでください。代わりに、ファイルの境界まで画像を拡張してください。