ウェブ プラットフォームでは、ユーザーは Screen Capture API を使用して画面を共有できます。Chrome の getDisplayMedia() の実装には、ユーザーがタブ、ウィンドウ、画面を共有するためのメディア選択ツールが含まれています。Chrome 107 以降、このダイアログを少し変更し、タブを最初のオプションとして表示して、ユーザーが画面全体ではなくタブを共有するよう促すテストを実施しました。これは、質問の表現方法が回答の分布に影響するというよく知られた概念に基づいています。これは、ナッジ理論（子どもには「お願い」として知られている）と呼ばれ、初期のいくつかの障害を乗り越えた後、テストは大きな成功を収め、この新しいエクスペリエンスがすべてのユーザーにリリースされました。
前述のように、通常はタブを共有することをおすすめします。
- 他のアプリ、通知、デスクトップの壁紙、設定から個人情報が漏洩する可能性が大幅に低くなるため、プライバシー保護に優れています。
- 受信側の画面領域をより有効に活用できる。
- 共有するピクセル数が少ないため、ネットワーク リソースの使用率が向上します。
そこで、タブを最初のオプションとして表示するテストを行いました。
試験運用版の最初のリリースでは、タブを先に配置することで、ユーザーが現在のタブを選択する割合が増加するという、望ましくない副作用が明らかになりました。多くのアプリケーション、ほとんどのアプリケーションでは、これは望ましくありません。たとえば、ビデオ会議アプリでは、このため「鏡の回廊」効果が生じ、リモート参加者が混乱し、通話が中断される可能性があります。そのため、試験運用版を一時停止しました。
幸い、Chrome 107 以降では selfBrowserSurface オプションが利用可能になりました。このオプションを使用すると、アプリは、ユーザーに表示されるタブのリストに現在のタブを含めるか除外するかを Chrome に指示できます。これは新しいコントロールであるため、ほとんどのウェブアプリでは明示的な値が指定されていません。更新されたテストでは、Chrome 108 以降、デフォルト値を "include" から "exclude" に切り替えました。これにより、望ましくない効果を排除しながら、特殊なアプリが以前の動作を呼び出すことを許可しました。
テストの一環としてデフォルト値を変更したことで、独自のメリットがもたらされました。自己キャプチャはキャプチャ セッションの約 0.8% からほぼ 0% に減少し、以前は 100 人に 1 人近くに影響していた自己妨害のケースがほぼすべて排除されました。
この試験運用版は Chrome 108 で再開されました。ユーザーの 50% に達した時点で、次の結果が確認されました。
- タブの共有が 16% から 30% に増加しました。
- ウィンドウの共有が 14% から 20% に増加しました。
- 画面共有は 55% から 36% に減少しました。
- セルフキャプチャ（タブベース）が 0.8% から 0% に減少しました。
- キャンセルはさまざまな程度で増加しました。詳しくは、以下をご覧ください。
- アクティベーション（
getDisplayMedia()の呼び出し回数）がさまざまな程度増加しました。
タブ、ウィンドウ、画面を共有する頻度が変更されたことに、非常に満足しています。ただし、解約と有効化の変化は懸念の原因となる可能性があります。
テストを長期間実施した結果、テストグループでの解約数はコントロール グループに近づいてきました。これは、ユーザーが見慣れないダイアログを見た時点で離脱し、その後徐々に慣れていくという Google の仮説と一致しています。
有効化の増加は、上記の理論では部分的にしか説明できません。これは、数字が合わないことと、テストグループでの有効化数が引き続き高かったためです。アクティベーションの増加の理由として考えられるのは、ユーザーが画面全体を共有する場合、他の共有を開始するためにキャプチャを停止して再起動する必要がなかったことです。タブとウィンドウの共有頻度が高まったため、キャプチャを再起動する頻度も高くなりました。今後、さまざまなサーフェスのキャプチャをよりシームレスに切り替えられるようにすることで、さらに改善していきたいと考えています。