Apple Engine

Apple, iPhone, iOS, その周辺のことについて

AR UI 概論 抜粋版

f:id:x67x6fx74x6f:20181203164159j:plain

AR の UI について他ではあまり語られていないためまとめてみる。

抜粋したのだが今回は割と長く、最初は UI について書いているため、必要なければ飛ばしていただいて AR の UIAR UI パターンだけでよいと思われる。

また、面倒なのでここでは Mixed Reality についても AR として扱っている。
お許しくださいまし。

 

UI (User Interface ) とは何か

ここで言う、UI とはコンピュータとその利用者の間での情報をやりとりするための入出力インタフェースを指す。
管楽器が口の延長として音が鳴り響くと説明されているように、UI の入力は手などの身体の延長であり、
機械とコミニュケーションをとるための操作。
出力はその操作を促すものや操作を画像や音、アニメーションや動画、アクチュエータによる振動などで反応を返すフィードバックである。

UI とはコンピュータとコミニュケーションを取る手段とその反応であるフィードバックである。
そのため、UI の入出力は我々の身体に大きく依存し、数々の制約がある。

例えば、ボタン。
人の指は握るようにつくられており、本来はボタンを押すようにはつられていない。
指は内側と外側の筋肉に引っ張られるため、ほんの少し握った状態がリラックスした状態だ。
赤ん坊が眠っている際の手の形を思い出してもらえばわかるだろう。 本来なら軽く握った状態で操作する入力装置が世の中に溢れているべきだが、機械的な制約や身体的な制約でそういう装置が少ない。

身体的な制約といえば、人間の腕というものは重い。
腕が痺れた際にもう片方の手で持とうとするとわりと重かったりする。
そのため、壁や空中にボタンがありそれを長時間操作し続けると次第に腕が重くなってくる。
所謂、ゴリラハンド問題であり、Apple はラップトップの画面にタッチスクリーンを利用するテストを幾度と行なったが断念らしい。
液晶のペンタブレットやキーボードなど机の上で操作し手が何かに支えられるためこれが起きづらい。

 

UI の使いやすさ

UI の使いやすさとは使いたい機能へ最短でアクセスできるかどうかである。
それと共にアクセスに生じてしまう待ち時間をどれだけ緩和できるか。

機能が増えてくると UI は複雑になり、ネットワークに繋ぐとなると機能へのアクセスや画面遷移で待ち時間が増える。
どうすれば最短でアクセスできるようになるかを考えたり、 いらない機能を省くなど考えたりするわけだが、問題が多種多様で明確な解はないと思っている。

また、人は慣れだったり学習することで UI 使いやすさが変わってしまう。

 

学習と慣れ

最初は使い方がわからなくても、学習することで UI の使いやすさが変わってくる。

過去の携帯電話ではボタンを押す操作が主流だったが、スマートフォンではタッチパネルでの操作に変更された。
そのため、タップは物理キーの延長でそのまま理解できるが、
ダブルタップやピンチイン/アウトを知らないと拡大縮小ができない。
いまやタッチパネル上での操作は当たり前となっているが、これらは学習して得た技能である。

UI 操作には慣れがあり複雑な操作でも行い続けると速く操作できることがある。
一見、複雑な UI でも操作上の慣れで意味を持ったものになるものもある。(ならないものもあるが……)

慣れには予期せぬエラーを起こす可能性があり、一連の流れで異なるものがある場合、操作ミスをしてしまう場合がある。
使用するアプリによって決定とキャンセルのボタンが異なる場合は間違えて操作する可能性は高くなるだろう。
OS や多くのアプリで UI を統一しているのはこれを軽減するためだ。

また、人は注目の行かないものに対してそれを認識しないことがあるため、 複雑な UI でも部分的にしか見ていない場合もある。

(注目がそれる現象に関しては「見えないゴリラ」という有名な心理実験があるので、その内容の本を参照していただきたい)

それらを考えると複雑さが必ず使いにくいものではないということである。

日本のテレビリモコンはボタンがありすぎて複雑だと話題に上がるが、 わりとリモコンは使用用途に合わせてうまくレイアウトしてある。
(そこにそのボタンってのもあるけど、自分が使用している東芝のリモコンはわりと上手く配置されている気はする)

f:id:x67x6fx74x6f:20181203161103p:plain
TOSHIBA TV リモコン

 

Apple TV などのリモコンはボタンなど操作できる部分が少なく、操作しやすいように思えるが、
テレビで録画した番組を再生するのと、Apple TV でのコンテンツを再生するのでは、
操作するステップは変わらないか、検索しなければいけない分操作が増える可能性もある。

f:id:x67x6fx74x6f:20181203161152p:plain
Apple TV / Fire TV Stick 用のリモコン

 

あと、よく悪い UI で 100 徳ナイフの話題が引き合いに出されるが、
専用の用途につくられたものなので、それ自体に意味があるものである。
100 徳ナイフの意味合いを都合の良い方向に導いており、自分はあまり好ましいとは思えない。

セブンカフェの UI の様にシンプルするだけで使い勝手の向上するとは限らず、使用するユーザーやユーザー層を考慮する必要がある。

 

UI 歴史

長くなるのでかなり飛ばして 2001 年頃から一部。
いつかちゃんと書く。

 

Mac OS X と Windows XP から始まるリッチデザイン(スキューモーフィズム / Skeuomorphism)

一般的にリッチなデザインを使用した UI はカラー表示ができるようになったゲーム端末が発祥だと思われる。
その後、DTM / DAW などクリエイティブ系のもので UI が概念的で伝わりにくいものを現実を模していった。

 

f:id:x67x6fx74x6f:20181203164544j:plain
Propellerheads Reason。裏面を表示させるとシールド(ケーブル)が揺れるなど UI にリアルな表現を追求した。

 

そして、Mac や PC の OS にもその流れがやってくる。

衝撃的な初代 iMac が世に出て数年後、Mac OS X がリリースされ、Aqua という UI が採用され、
メニューバーやウインドウ、アイコンの色調が増え、リッチなアニメーションが行われ、ボタンは飴のような見た目となった。
アイコンはより写実的になり、フォントの表示も美しくなった。

f:id:x67x6fx74x6f:20181203165700p:plain

ジョブズはこの UI で「スクリーン上のボタンはカッコよすぎて舐めたくなるほど」と言っていた程気に入っていたらしい。

この時点で触りたくなる UI というものを何らかのものに模すことで実現しようとしていたように思える。

表示が綺麗になった代償として、描画が重くなりすぎ、UI 表示部分を GPU で補助するようになる。
近年ではスマートフォンも含め当たり前ではあるがこの頃は画期的であった。
(UI の見た目はよくなったが、個人的に OS 的に UI と機能がちゃんとしたと思えたのはかなり先の 10.6 Snow Leopard)

 

もう一つは、同時期のリリースされた OS。
frog design がデザインを行った Windows XP の UI である。

f:id:x67x6fx74x6f:20181203170533p:plain

 

Windows 98、2000 や Me、などは灰色の基調とし青の単色やグラデーションをウインドのタイトルバーという簡素なものだったが、Windows XP ではビビットな色合いとウインドウの枠が光沢が強めのものとなり、立体感が増していった。

その後の Vista ではウインドの一部などが半透明で軽くボカシが入る Windows Aero の Aero グラス が採用され、
すりガラスのような視覚効果持たせることになる。

f:id:x67x6fx74x6f:20181203171019p:plain

 

Windows 8 の際に Windows Aero は消滅したが、
すりガラスの効果は現在の Apple 製品の各 OS では使用されており、近年の Web サイトではたまに見られる表現である。
(確か、Web サイトの CSS の blur を含む filter をリリース版のブラウザで最初にサポートしたのは Apple の Safari だったはず)

そして、Windows 10 で再度採用されることとなった。

 

iPhone の登場、スマートフォンのタッチインターフェイスとミニマムな UI

f:id:x67x6fx74x6f:20181203172854p:plain
iPhone 3G

iPhone 3G からアプリの開発が可能になり、
Android など他のタッチインターフェイスのスマートフォン登場で タッチ操作での Web サイトの閲覧が可能になった。

既存のアプリケーションの操作とは異なり
マウスなどポインティングデバイスを使用せず、指という肉体を使うことで直感的かつ
素早いレスポンスやフィードバックが求められるようになり UI 設計の複雑化が顕著になっていく。

UI や UX などはクリエイティブ系のツールやゲームなどでよく論議されていた議題ではあったが、
この辺りから、ゲームに限らず UI や UX の重要性が各所で語られることとなる。

タッチインターフェイスのスマートフォンの先駆者である iPhone 3G は画面が 3.5 インチ。
当時出ていた携帯電話の中では画面はかなり大きかったが、画面サイズが 320 x 480 と小さく、さらにステータスバーやナビゲーションバー、タブ、ツールバーなど、そこからさらに領域を取られ、iPhone の Human Interface Guidelines 上でボタンには 44px の領域が必要であったため、制限のあるミニマムな UI 設計を強いられることとなった。

その後、iPhone 3GS 発売ししばらくした後 iOS 3.2 とともに、iPhone の OS ベースの iPad がリリースされ、
大画面のタッチインターフェイスの UI とともにタブレットというカテゴリが浸透する。

 

iPhone 3G が端末的に素晴らしいと最初に思ったのは音楽や動画などメディア再生機能やブラウザだったが、もう一点はタッチパネルと UI。
UI として手にして画期的だと思ったのはいくつかあるが、リスト表示をするテーブルビューと表示を階層化するナビゲーションビュー(ナビゲーションバー)だった。

iPod の UI を踏襲したものだが、ナビゲーションで階層化されたテーブルビューを辿れば、基本的にはアプリケーションとして大体の操作ができた点である。テーブルビューの実装的には現状もほぼ表示するセルの部分のみ処理しているため、多量の項目がある状態でスクロールしても端末の負荷がない。

f:id:x67x6fx74x6f:20181203172219p:plain
上にフリックした際には、下から必要なセルが追加され、画面外(上部)に行ったものは消される。基本的には見える部分のセルだけしか描画されない。

(無限スクロールについて:上にスクロールした際は画面で表示する必要のなくなった最上部のセルは破棄され、最下部は表示するためセルを生成する。データが 10000 件あり、セルが同量の 10000 あったとしても、画面に最大 10 個のセルが表示される場合は OS は 10 個までしか表示されず、セルに表示されるデータだけが変わる。iOS 10 では画面外のセルをいくつか描画しておりスクロールの際の引っ掛かりを低減させている)

また、カテゴリ的に分けたい場合は下部のタブを使用すれば、複数の区分をつくることができ、初期からタブの入れ替えができるようになっている。

 

タッチインターフェイスによってより触るためのさらにリッチなデザインが採用され、iPhone のアプリではカレンダーなど革張りのようなヘッダー、メモ帳では紙のような質感など現実に即したスキューモーフィズムと呼ばれるデザイン手法が加速する。

f:id:x67x6fx74x6f:20181203173939p:plain
旧 iOS のメモアプリ
 

その一方で、Ableton の Live という DAW アプリでは音楽制作系には珍しくフラットな UI デザインを持つアプリが現れ始める。
(実は Ableton Live かなり昔からあるアプリで使用用途も今とは若干違った)

f:id:x67x6fx74x6f:20181203152656p:plain
Ableton Live

 

フラットデザイン

iOS 7 からのフラットデザインや tvOS、Android 5.0 Lollipop から始まるマテリアルデザインがその代表的だが、
Windows Phone や Windows 8 から採用された Metro UI のちの Modern UI が先行しており、その知名度を上げるものとなる。

f:id:x67x6fx74x6f:20190213142233p:plain
Windows8

f:id:x67x6fx74x6f:20111227191143j:plain
Windows Phone

Modern UI には更に元があり、 Zune という iPod に対抗するためにつくられたミュージックプレイヤー端末の UI と
iTunes の様な Zune を同期するための Zune Software というものがあった。
個人的に Zune Software の UI は今も好きだ。

f:id:x67x6fx74x6f:20181203152501j:plain
Zune

f:id:x67x6fx74x6f:20181203152538p:plain
Zune Software

 

Zune の UI は Modern UI に酷似ており、Metro UI (Modern UI) は地下鉄のサインのように明瞭にという話だがこれは説明用の後付けらしい。

2012年に聴講した Windows Developer Days で
Microsoft が目指した UI は Crisp(カリッとしたなグラフィック)と言っていたのが印象的だった。
アプリにおいてコンテンツが中心であり Chrome(装飾)を排除するという構想の元、基本的にはコンテンツの境界に罫線を入れずにタイポグラフィだけで表現している。

Windows プラットフォームは Modern UI を採用することで、視認性を高めるとともに、端末の描画負荷を減らす工夫が行われた。

フラットデザインの説明であまりされないのだが、端末の描画負荷を下げることもこのデザインを採用する利点である。

 

フラットデザインの視認性

フラットデザインで視認性について書かれることはあるが、なぜ視認性が高くなるのか書かれているものを見たことがない。
個人的な意見で学術的なものではないが、色や階調を単色にすることで眼はその物体を光っている様に認識するためだと思われる。

写真など強い光が発光する場合は単色で周囲が潰れるし、3DCG などで物体の表面が発光している場合も光が強い場合は単色に近くため、単色というのは光に近いものなのだろう。

f:id:x67x6fx74x6f:20181203175406p:plain
Physically Based Rendering で右側の方に Emission のパラメータを入れ発光している様に設定。ほぼ単色となっており認識がしやすい。

 

人の目が光に対して注目する点を考えると、単色にすることは理にかなっている。
また、自然界において単色のみで彩られたものほとんどないため、 目が向くのもおかしくないだろう。

一応、人の目や脳は光の強さや、どのようなものの光沢なのかなど、色以外にも光の質を判別できる。

 

AR の UI

本題。

一応、AR を軽く説明すると Augmented Reality / 拡張現実 の略称で、 知覚する現実環境をコンピュータにより拡張する技術や拡張された現実環境そのものを指す言葉。
要するに AR とは現実を書き換えることである。

AR のコンテンツはスマートフォン・タブレット(以降スマートデバイス)型とグラス型に分かれ、共通する UI はあるが、ほぼ別物と考えた方がよいだろう。

 

AR と VR の UI の違い

AR は現実空間と合成するため空間上の制限があるが、
VR の場合、360 度の完全な仮想空間でコンテンツを体験をするため仮想空間上の制限がない。

例えば、VR は仮想的に表示している日本の風景からアメリカの風景へ空間移動を行うことができるが、
AR では長距離の空間移動は難しく、現実空間と密接になっており物理に縛られる点には注意して欲しい。
そのため、VR での操作や UI で手軽に行えるものが AR でそのまま流用できない可能性もある。

 

スマートデバイス型の AR と メガネ型の AR

スマートフォン・タブレット(スマートデバイス)とメガネ型の AR で UI というよりもインプットデバイスが異なる。

スマートデバイスは画面をタッチすることとなるが、メガネ型の場合は画面を触ることができない。

メガネ型に関しては、先行してプロダクトが出ている Google Glass や Microsoft HoloLens などがわかりやすいだろう。

f:id:x67x6fx74x6f:20181203182824j:plain
Google Glass

f:id:x67x6fx74x6f:20181203182845j:plain
Microsoft HoloLens

 

Google Glass はツルの部分にタッチセンサがありタッチかスワイプをさせ、 Microsoft HoloLens の場合は視点がカーソルとなり、エアタップと呼ばれるジェスチャで仮想空間のオブジェクトを掴んだり、動かすことで移動させたりしてコントロールを行う。 また、互いに音声でのコントロールを行うことができる。

Microsoft HoloLens ではクリッカーと呼ばれる手持ちのコントローラーがあり、タップをクリッカーのボタンで行うことができる。

f:id:x67x6fx74x6f:20181203183229j:plain
クリッカー

 

AR と広告

Google Glass では広告を表示する事を許可しなかった。頻繁に現れると視覚的に邪魔になったり、視線が移るため事故を起こす可能性が高い。

多分、Apple も仮想空間での広告表示を許さないだろうし、
広告の表示を消すため、数メートル先のバツボタンを押して視界から無くしていく作業が何回続いたら、もう AR を使うことはなくなるだろう。

 

AR とジェスチャーとコントローラー

Microsoft HoloLens では空間を認識する震度センサーとは別に眉間の部分に深度センサーが付いており手の動きによるジェスチャーを認識する。
使用できるのはタップ動作の指を曲げるエアタップとメニューを開く指を上方向につぼめてから開くブルームという動作。

f:id:x67x6fx74x6f:20181203183259j:plain
エアタップ

f:id:x67x6fx74x6f:20181203183319g:plain
ブルーム

 

画面を触る事ができないため、このようなジェスチャーが用意されている。
用意されてはいるのだが、Microsoft 的には他のジェスチャーを推奨していない。
ジェスチャーは国によって意味合いが真逆なるためだと思われる。

スマートデバイスでも、メガネ型でも、手を使用したジェスチャーはわりと面倒で、Microsoft HoloLens でも時折エアタップはミスるし、腕が疲れる。

コントローラーは手を使用したジェスチャーよりは操作がしやすいのだが、物理的に機材をもう1つ持つことになるため、手軽さがなくなるし、充電機器が増える。
スマートデバイスの場合、物理的に持てない場合がある。

 

AR と音声コントロール(音声コマンド)

音声での操作といえば、スタートレックなどの SF やスパイク・ジョーンズ監督の her という映画がわかりやすいだろう。
また、現状のデバイスでも Siri や Google アシスタント、Cortana などのバーチャルアシスタントシステムでコントロールする方が楽な場合もあると思われる。

スマートデバイスの AR では、大抵の場合、画面をタップするため画面にボタンを置く必要がある。
画面自体がコンテンツであるため、操作するためのボタンをたくさん置くことができない。

メガネ型についてはジェスチャーでも書いているが、画面を触ることができない。

そのため、音声でコントロールする事が最短で機能にアクセスできる可能性がある。
すでにスマートスピーカーで音声でコントロールしている場合は便利さがわかると思う。

自分は Microsoft HoloLens でウインドウ操作する際、視線を動かすのが面倒だったので、Adjust、Close など音声でコントロールをしていた。

 

AR と音

現実空間に仮想オブジェクトが配置されるが、仮想オブジェクトの操作などのフィードバックとして SE などの音は有効だと思われる。

VR ではより没入してコンテンツ体験を行なってもらうため、ヘッドフォンなどを使用し外部からの音の情報を遮断する。
AR では現実空間と音をミックスさせるため AirPods など外界の音が拾える様なサウンドデバイスを使用することになるだろう。

また、Microsoft HoloLens は耳の付近にアレイスピーカーが搭載されており、音の距離感なども現実空間とミックスし体験の向上を打ち出している。

 

AR と香り

なぜ香りについて書くかというと、人の記憶で深く記憶するものの1つが匂いだから。
生物が生きぬく上で匂いや香りの嗅ぎ分けが重要であり、 匂いは何かを引き起こすトリガーにできるのではと思っている。

ちなみに、聴覚・視覚・触覚・味覚・嗅覚の順で人はその記憶を忘れていく。

VAQSO Inc. が VAQSO VR という VR コンテンツと連動させるカードリッジ式で匂いを体験させる機材を開発しており、このようなプロダクトが AR でも使用できそうではある。

f:id:x67x6fx74x6f:20181203183651p:plain
VAQSO VR

vaqso.com

 

AR UI パターン

ARKit を参考に他のデバイスや今後予想されうるパターンを考えてみる。

 

2タイプの AR UI

AR アプリでの UI は、画面の前面に表示されるオーバーレイの UI、コンテンツ内 の UI に分かれるとと思われる。
そのため、グラス型の AR コンテンツでのオーバーレイ UI は OS やシステムからのメッセージやアラートになるため、ほぼコンテンツ内 UI となる。

スマートデバイスタイプの場合でも直感的な操作を行うべきなので、 可能な限り表示しているコンテンツ内で操作を行うことができる様にし、
オーバーレイの UI の使用を避ける方向を検討した方がよいだろう。

 

オーバーレイ UI パターン

スマートデバイスでは何らかのオーバーレイの UI が1つ以上必要になるだろう。
基本的にはスマートデバイスの OS の標準 UI である。
そして、そのパターンは以下のものが必要になるのでは予想される。

 

ラベル

画面操作や状態、項目に対して説明や注釈などを使用する際に用いる UI。
ARKit では主にトラッキングの状態やワールドマップのスキャンと読み書き、イメージやオブジェクトトラッキングの状態など、
文字や画像で伝えるべき説明として配置する。
スマートフォンでは画面が iPhone 5 SE など小さいものがあるため、複数を配置するより状態によって内容が書き換わる方が望ましいだろう。

f:id:x67x6fx74x6f:20181203180355p:plain
現実空間で平面認識状態を示すテキストのラベルと状態を再更新させるボタン
 

ボタン

スマートデバイス同様に何かを追加、削除など、行うことに対して決定やキャンセルを行う UI。
個人的には、ゲーム以外で画面上に5個以上ボタンを置く場合は他の UI を検討して見た方が良いと思われる。

 

セレクター

複数ある項目を選択する際に使用する。
日付選択やカラーパレットなども。
タブなどもこちらに含む。

f:id:x67x6fx74x6f:20181203182052p:plain
ピンクで囲っているところに UISegmentedControl があり、周囲の反射画像(環境マップ)の取得をオートにするかマニュアルにするか選択できる

 

スライダー

物の数や大きさなどをボタンをスライドして設定する UI。
コンテンツ内で仮想オブジェクトの状態を変える場合はそのオブジェクトを選択し、ピンチイン・アウトで拡大したりして変更するため、
あまり使用する機会はないかもしれない。
主に、光の加減や、エフェクトなど全体に影響するものを変更する場合に使用する場面で使用することになるだろう。

 

モーダルウインドウ

ウインドウを画面に表示する。
設定など画面に収まらないものを配置し表示するウインドウ。

f:id:x67x6fx74x6f:20181203180754p:plain
+ボタンを押すとポップオーバーが表示され平面に配置するオブジェクトの選択ができる

ここでは ARKit を使用した iOS アプリでのポップアップ/ポップオーバー (UIPopoverController) もその範疇としている。
理由は ARKit の場合、画面が ViewController で覆われると裏にある画面がリセットされてしまうため、 半分覆う様なモーダルウインドウやポップオーバーを使用することがメインになるだろう。

 

アラート / 通知

通常のアラートや通知の UI。
画面が止まってしまうため、危険な状態など注意を引かせたい強い警告などでない限りアラートを使用するケースは少なくラベルで事足りると思われる。
通知に関しては何らかの通知の履歴を残したい場合だろうか。
(iOS の場合アプリ立ち上がっているとその通知は出ないが)

 

コンテンツ内 UI について

オーバレイの UI とは異なり、UI は 現実空間に合成し配置されるため、
配置されるものはできるだけ認識しやすい表示であることが望まれる。
ただし、ゲームでは一見解りづらいアイテムなど認識しづらさに意味を持つものがあるのでその類は除く。

また、現実空間でのジオメトリや UI の設置は距離を伴うので、重要な操作はユーザーが近くで操作できる必要があるだろう。

 

認識しづらい状況や使いづらい状況を回避するには?

現実空間に 3D のジオメトリを UI として合成するため、基本的には現実にある広告や広告看板などを参考にしてもらえば良いと思われる。

とはいえ、現実世界の様に 360度で UI を配置するのはかなり不便だろう。
後ろは目視できないため、スマートデバイスかグラス後ろに向けないと UI 自体が確認できない。
視界に入る場所に設置する様に工夫するべき。

状況によっては、視界に入る場所の UI となると表示領域が狭くなるため、電光掲示板の様な文字が流れる UI も有効だろうと予想される。

視界に入る状況でも、近距離や遠距離に表示される平面状の UI は移動の際に見忘れる可能性がある。
4面や球状のもの、もしくはカメラに表示したい面を必ず向ける様にするとよいだろう。

状況にはよるが 3D の文字も積極的には使わない方が良いと思われる。
インパクトは高いが、真横など見る場所によっては文字が認識ができない。

最も重要なのは仮想オブジェクトで操作するできるものに関しては、必ず操作を促すものを表示すること。
状況によっては背景と同化し仮想オブジェクトと見分けがつかなくなるため。

また、空間上で多量にある類似情報は間引く必要性がある。

f:id:x67x6fx74x6f:20181212184612p:plain
多すぎるアノテーション

 

Google Maps が解りやすく、引いた状態では主要なピンの情報しかないが、ズームするとピンの情報が細かく表示される。

f:id:x67x6fx74x6f:20181211135327p:plain
Google Maps

AR も遠くの情報は省き、近くのものはより詳しい情報を表示した方が良いと思われる。

 

コンテンツ内 UI のインタラクション

Apple の Human User Interface Guidelines の ARKit の箇所でも書かれている様に、仮想オブジェクトに対しては、スマートデバイスのアプリでも使用されている直感的な操作を使うとよいだろう。

仮想オブジェクトをタップでの選択、スワイプでの移動 、ピンチイン/アウトでの拡大縮小など。
Maps のアプリを使用しているとわかると思うが二本指でのスワイプが通常のスワイプになったり、回転がスワイプにミスする事があるのでジェスチャーは注意が必要。

また、ゲームなどのエンタメを除き空間に物理ボタンや操作する UI をできるだけ配置しない方が良いだろう。

自分の様な昔の人間は、テレビに物理的なダイアルやボタンが付いてそれを手で操作していた時代があった。
(物差しとか物理的に長いものとか使ったりも)

その不便さからテレビリモコンというものが生まれたのであり、その過去をまた繰り返す必要はない。

 

コンテンツ内 UI パターン

仮想オブジェクトの設置に関する UI は割愛。

 

ラベル

オーバーレイ UI 同様に文字情報を表示する。
UI は人と機械との会話と書いたように、機械側が機械側がユーザーに投げかけるメッセージである。
グラス型の AR 場合、コンテンツが UI であるため、多用する事になるだろう。

背景と同化するため、わかりやすい表示を心がけるべし。
野外だと外の看板と見分けがつかなくなる可能性があるため。

f:id:x67x6fx74x6f:20181213182611p:plain
わかりやすくするため縁取りをつけてみる

 

ビルボード/電光掲示板

ほぼラベルと同様のもの。
文字数で表示しきれないものや時間で変更する文字を表示する。

一応、映画字幕では1秒に4文字まで決まりがあるので、速い文字のスクロールはされるべきだろうし、
いくつかスクロールする文字があると、目が行きにくくなるので程々に。

 

アノテーション(ピン)

これもラベルに近いもの。
Google Maps 等のピンの様な目印になるオブジェクト。
ラベルやビルボードとは異なり、目的地など完全に固定するものに使用する感じではあるだろう。

 

ガイド

アノテーションなどで目的地を示すことが可能だが、アノテーションの設置場所が遠い場合はその場所への誘導が必要になる。
距離や位置をわかりやすく示す矢印などの UI。

また、空間認識後に平面など現実空間の障害物を示すガイドの表示させる。

f:id:x67x6fx74x6f:20181213192300p:plain
目的地まで矢印を表示する

 

セレクト/セレクター

PC/Mac やスマートデバイス同様に選択状態を表す。
こちらも現実世界と合成するため、周りを回転させるもの、立方体など、球体など、360度で目に付きやすいものを心がける。

f:id:x67x6fx74x6f:20181213171754p:plain
チューブ、立方体、球体での選択領域

 

ハンドル

仮装オブジェトなど操作できる状態を示し、操作可能な UI。

グラス型の場合はオーバーレイの UI に対してタッチなど操作ができないため コンテンツ内に仮装オブジェクトを操作する UI が必要になる。

f:id:x67x6fx74x6f:20181213192545p:plain
キャラクターを動かすためのハンドル

 

フォロアー

AR 空間の中で、重要な仮想オブジェクトがあり、画面上に常に表示しておきたい場合にカメラについていく振る舞いをする。

情報を表示させるためのウインドウやキャラクターなどカメラに追従してくるなど。

 

トラッキング

ARKit の機能である様な現実空間の画像、オブジェクト、顔のトラッキングをして、仮想オブジェクトなどを配置する。

画像をトラッキングして画像に動画を貼り付けたり、トラッキングしたオブジェクトの説明を表示したり。

 

アバター

ARKit 2.0 で追加された空間共有で相手を表すとしてキャラクターを実現させる。

また、操作説明やメニューの補助機能としてのアバター(キャラクター)がコントローラーがわりになっても良いだろう。

 

キーボード/インプット

基本的には OS のものが表示されるだろう。
グラス型の AR の場合スクリーンを触れられないため、コンテンツに UI を表示させるか、音声でコントロールを促すための UI を表示させる必要がある。

 

マップ

ゲームでよくある地図の様なもの。 広範囲に AR の空間を移動する際に迷わなくするためのもの。

 

AR コンテンツでの特殊効果(エフェクト)

UI とは外れるがエフェクトについて。
基本的には仮想オブジェクトを目立たせるために使う。

 

フィルター

現実空間の画像にフィルターをかける事で仮想オブジェクトを注目させることができる。
また、仮想オブジェクトにフィルターをかける事でも。

f:id:x67x6fx74x6f:20181213180813p:plain
通常 / 背景をモノクロ化

 

パーティクル

粒子状のテクスチャやジオメトリを使用し仮想オブジェクトや空間全体を目立たせる。
パーティクル自体のアニメーション動作を伴うためかなり雰囲気が変わる。

f:id:x67x6fx74x6f:20181213181856p:plain
キャラクタの周囲から上方向星のパーティクルが流れることでキャラクタの位置を確認し易くする。

 

ライト

霧に光の筋やスポットライトのボリュームライトなど、空間や仮想オブジェクトの印象を変える演出ができる。

 

カメラエフェクト

光が強く色が飽和するブルーム効果、ピントが合っている部分以外ボケる被写界深度、レンズに反射が映るレンズフレアなど。

f:id:x67x6fx74x6f:20181213173823p:plain
通常カメラ / 露出を上げて Bloom エフェクトを追加したカメラ

 

f:id:x67x6fx74x6f:20181213174634p:plain
カメラからカラーコレクションを適応

 

必要のないものを消す

いずれかの AR 開発環境で実装されているわけではないが、AR は現実を書き換えることができるのであれば逆に消す事も可能だと思われる。(PhotoShop の Content-Aware の様なもの)

例えば、空間共有する際に相手が自分のカメラに映らない様にし、アバターを代わりに設置するなど。

 

仮想オブジェクトの影

仮想オブジェクトの影は可能な限り入れるべし。
影がある場合、仮想オブジェクトがそこにある感じがして、設置位置がわかりやすくなる。
影がない場合は位置以外にもどのぐらいの大きさなのか、宙に浮いているかも認識しづらくなる。

f:id:x67x6fx74x6f:20181213173009p:plain
影あり / 影無し

 

VR へのスイッチ

AR はカメラで背景画像を作成しているため、任意の画像に書き換えてしまうと VR が実現できる。

AR ゲームである場所に行くと完全な仮想空間でボス戦を行うなどに使用できそう。

 

参考書

  • インタフェースデザインの心理学シリーズ
  • デザイニング・インターフェース 第2版
  • ノンデザイナーズ・デザインブック
  • 誰のためのデザイン?

 

インタフェースデザインの心理学に関しては UI に関心がない人でも読むのも良いと思われる。

デザイニング・インターフェースは若干古いが UI パターン網羅されている。

ノンデザイナーズ・デザインブックは文字デザイン向け。デザインや UI の殆どは文字なので勉強という点では良いと思う。
ちなみに古本が安いので旧版でも良いと思われる。

誰のためのデザイン?は良いデザインを考えるための本。こちらも昔のものでも問題はない。

UI に関しては About Face という本も紹介したかったのだが、絶版になってしまった。

 

UI / UX の部分は少ないが、AR の教科書は広範囲に書かれているため、上の本よりまず読む本だろう。

 

AR UI の今後の発展

今回、ARKit 2.0 ベースで考えているため、現実世界の障害物で遮蔽される処理は省いているが、これに関連する有用な UI の出現も考えられる。

カメラ性能の向上や NPU など Neural Engine 用チップを使用し現状のデバイスでは処理できない表現が可能になるかもしれない。

現状では想像可能な UI を羅列したが今後も進化あり、3次元空間での UI の模索をこれからも行う必要がある。