WebXR Device APIのorigin trialは仮想体験を足す前に通常の案内と試験対象を分ける

WebXR Device APIを試すときは、仮想体験を見せるpageと、誰でも読める通常の案内pageを分けます。空間の中で見る映像や物体は、施設、商品、作品の印象を伝える手段になります。しかし、体験用の画面を開けない読者にも、何を扱っているのか、利用条件は何か、次にどこへ連絡すればよいかを渡せなければ、siteの入口としては不足します。

Chromeは4月30日、Chrome 67 BetaでWebXR Device APIのorigin trialを案内しました。WebXR Device APIは、mobile deviceとdesktopのVRやAR体験を扱うためのAPIです。origin trialでは、実装を試すsiteがtokenを申請し、sampleやdocumentを参照しながら試験できます。これは、全ての読者に同じ体験を約束する正式な公開ではありません。まず試験の目的と対象を決め、通常のpageを残したまま確かめます。 Chromium Blogの案内

仮想体験と事業の案内は別に用意する

WebXR Device APIで作れる体験には、360度のvideo、空間の中で見る2Dまたは3Dの映像、商品や作品を見る画面などがあります。体験の中で見せる情報は、見る方向や操作によって変わります。最初に見た場所だけで、料金、所在地、対応範囲、予約方法まで確実に伝わるとは限りません。

そのため、通常のpageには、体験の対象、見られる内容、必要な環境、問い合わせ先を文章と画像で置きます。仮想体験のpageは、その説明を補う場所です。体験画面だけをlink先にすると、対応していないdeviceや操作を始めない読者は、何を見逃したのかすら分からないことがあります。体験を始めるbuttonの近くに、通常の説明へ進むlinkを残します。

たとえば、展示空間を見せる仮例では、通常のpageに展示名、開催場所、期間、入場方法、写真を置きます。そのうえで「空間を見渡す」として試験用のpageへ案内します。体験画面の中で作品を選べるようにしても、通常のpageにある日付や連絡先を消しません。見せ方を増やすことと、必要な案内を置き換えることは別です。

origin trialは公開範囲を小さくして試す

origin trialは、新しいAPIを試すための仕組みです。試験用のtokenを得たことは、対象pageが全てのdeviceで使えることや、事業の主要な案内を任せられることを意味しません。試すと決めたら、最初に一つのpage、一つの体験、一つの読者の行動へ範囲を絞ります。

試験対象を決めるときは、次の四つを書きます。

この表は、技術者だけの作業表ではありません。内容を決める人は、体験で何を伝えるかを決めます。実装する人は、token、media file、試験するenvironmentを管理します。公開を確認する人は、通常の案内と試験画面がどちらも読めるかを見ます。一人で兼ねる場合も、役割を分けて書けば、映像の修正と公開判断を同じ理由で進めずに済みます。

対応していない画面で見えるものを先に決める

WebXR Device APIの試験では、すべてのbrowserとdeviceが同じように動く前提にしません。特定のenvironmentで体験を開くことを確かめる前に、開けないときに何を見せるかを決めます。何も表示しない画面や、開始buttonだけが残るpageでは、読者は技術上の問題なのか、操作が足りないのかを判断できません。

試験用のpageには、体験の短い説明、通常の画像またはvideoへのlink、通常の案内pageへのlinkを置きます。利用できない場合は、その案内へ進めるようにします。これは、体験に失敗した読者を切り捨てないためだけではありません。公開後にtoken、media、scriptのどこで問題が起きたかを調べるとき、通常の案内が読めるかを比較できます。

読み込むmediaも一度に増やしません。最初は一つの短いsceneや、一つの見せ方で確認します。大きい映像、複数のmodel、音声、外部scriptを同じ日に追加すると、画面が開かない原因を切り分けにくくなります。体験の内容を増やす作業と、WebXR Device APIを動かす作業を別の変更として記録します。

体験の評価は再生回数だけで決めない

仮想体験をpageへ置くと、開始された回数を見たくなります。しかし、buttonが押されたことだけでは、読者が必要な情報を得たかは分かりません。通常の説明を読んだ人が体験へ進んだのか、体験の途中で通常の案内へ戻ったのか、問い合わせ先が見つかったのかは、pageの構成と確認する行動によって別に見ます。

説明用の仮例として、部屋の広さを見せる体験を考えます。体験を始めた読者が多くても、寸法、所在地、見学の条件が通常のpageに見つからなければ、次の行動を選べません。反対に、通常のpageだけで条件が分かり、体験は室内の印象を補っているなら、体験を開かない読者にも案内は届きます。体験を採用する理由は、閲覧回数を増やすことだけでなく、通常の説明だけでは伝えにくい内容を補えるかで決めます。

確認する記録には、体験を置いたURL、通常の案内URL、試したdeviceとbrowser、体験を開始できたか、通常の案内へ戻れたか、問題が出たときの状況を書きます。実際の読者数や成果を作らず、試験で確かめた動作と未確認の範囲を分けて残します。数字が出る前に、何を成功とみなすかを決めます。

tokenとmediaの管理を引き継げるようにする

origin trialでは、試験に使うtokenと、体験へ読み込むfileの管理場所が必要になります。制作会社や映像制作者が作業を進めても、siteを持つ側は、どのdomainで試しているか、tokenを誰が申請したか、media fileをどこで更新できるか、試験を止めるときに何を外すかを把握します。

体験の見た目が完成していても、tokenの期限や申請先が分からなければ、継続するかやめるかを判断できません。映像の納品と、WebXRの試験環境を維持する責任も別です。token、source code、media、通常page、確認記録を一つの担当だけが持つ状態にしないでください。

最初の一手は、通常のpageを一件選び、その中で文章や写真だけでは伝わりにくい内容を一つ書くことです。その内容を補う短い体験だけを試験対象にします。WebXR Device APIは、仮想体験を作るためのAPIです。siteの役割は、体験を始められる人だけでなく、通常の案内を読む人にも必要な情報を渡すことにあります。