インテル® Perceptual Computing SDK

ヒューマン・インターフェイスのガイドライン

Revision 1.0

2012 年 10 月 2 日

目次

1 はじめに ........................................................................................................................................................................................................... 3

1.1 ようこそ ................................................................................................................................................................................................ 3

1.2 カメラについて ................................................................................................................................................................................ 4

2 高レベルの設計方針 ................................................................................................................................................................................ 7

2.1 入力形式 ................................................................................................................................................................................................ 7

2.2 設計方針 ................................................................................................................................................................................................ 8

2.3 複数形式 ................................................................................................................................................................................................ 9

3 ジェスチャー・デザインのガイドライン ........................................................................................................................... 10

3.1 キャプチャー・ボリューム ................................................................................................................................................. 10

3.2 ハンド・ジェスチャー入力における推奨事項...................................................................................................... 11

3.3 認識されるポーズ ...................................................................................................................................................................... 12

3.4 一般的なジェスチャー・プリミティブ ...................................................................................................................... 13

3.5 その他の考慮事項 ...................................................................................................................................................................... 15

3.6 サンプルおよび API ................................................................................................................................................................... 16

4 音声設計のガイドライン ................................................................................................................................................................. 17

5 顔認識設計のガイドライン ........................................................................................................................................................... 17

6 ビジュアル・フィードバックのガイドライン ................................................................................................................ 18

6.1 ガイドライン ................................................................................................................................................................................. 18

6.2 ユーザーの表現 ............................................................................................................................................................................ 18

6.3 オブジェクトの表現 ................................................................................................................................................................. 20

6.4 2D と 3D ............................................................................................................................................................................................ 20

6.5 従来の UI 要素 ............................................................................................................................................................................... 21

6.6 キーボード、マウス、タッチの統合 ........................................................................................................................... 22

7 質問およびご意見 ................................................................................................................................................................................. 23

3

1 はじめに

1.1 ようこそ パーセプチュアル・コンピューティングの世界へようこそ! より多くの感覚とセンサーが統合された将来のコンピューティング・プラットフォームにより世界を操作する新しい方法を想像してください。アプリケーションを楽しみながら体験できる、新しく自然で魅力的な操作方法をユーザーに提供してみませんか? インテルでは、この世界を実現する基本的なツールとして、インテル® Perceptual Computing SDK を提供します。このツールにより、ユーザーと PC が対話する方法を根本的に変える近距離のハンド・ジェスチャー、指の間接の動き、音声認識、顔追跡、拡張現実感などの体験を含む新しい機能をアプリケーションに実装することができるでしょう。

パーセプチュアル・コンピューティングは、自然かつ自由な操作による直感的な方法で、ユーザーの動作を感知するデバイスを利用した新しいヒューマン・コンピューター・インタラクションにより、魅力的なユーザー体験をもたらします。

この記事では、将来のパーセプチュアル・コンピューティング・アプリケーション向けで、革新的で楽しく、機能的で、一貫性のある強力なユーザー・インターフェイスを作成する開発者にさまざまな情報を提供します。特に、次のような場合に役立ちます。

• プラットフォームに適した優れたユーザー体験を作成する • 直感的で親しみやすい対話処理を設計する • さまざまな入力形式を適切に利用する

パーセプチュアル・コンピューティングは新しい分野であり、その技術は日々進歩しています。現在の機能に合わせて設計するのではなく、設計者および開発者として、将来の機能にも対応できる拡張性、モジュール性、スケーラビリティーのある創造的な設計を行うことを心がけてください。新しい機能は利用可能になり次第お知らせします。

4

1.2 カメラについて インテルは、パーセプチュアル・コンピューティング・アプリケーションに対応する周辺機器として、Creative* Interactive Gesture Camera を発表しました。これは、ジェスチャー、音声、その他の入力形式を知覚できる、インテルの最初のテクノロジー・プラットフォームです。ここで紹介するガイドラインは、このデバイスだけでなく、より広い意味で他のテクノロジー・プラットフォームにも当てはまります。

Creative* Interactive Gesture Camera の主な仕様を次に示します。

サイズ: 4.27 インチ × 2.03 インチ × 2.11 インチ (10.8 センチメートル × 5.2 センチメートル × 5.4 センチメートル) 重さ: 9.56 オンス (271 グラム) 電源: USB 2.0 (シングル) (<2.5 W)

RGB カメラ

実効解像度: 720p (1280×720 ピクセル) フレームレート: 30fps 視野: 73 度 (対角) 範囲: 0-23 フィート (0-7.01 メートル) RGB + 深度フレーム同期

IR 深度センサー (3D 深度マップ)

実効解像度: QVGA (320×240 ピクセル) フレームレート: 30fps 視野: 73 度 (対角) 範囲: 6 インチ-3.25 フィート (15-100 センチメートル) 距離測定: Time-of-flight 法

オーディオ

デュアルアレイ・マイク

3D 深度センサー

HD 720p イメージセンサー

パワー LED インジケーター

デュアルアレイ・マイク

マルチアタッチ・ベース

5

推奨システム構成

第 2 世代、第 3 世代、または第 4 世代インテル® Core™ プロセッサーを搭載した PC Windows* 7 SP1 以上 / Windows* 8 デスクトップ UI 4GB システムメモリー USB 2.0 ポート

物理デバイスの設定 カメラの設定

パーセプチュアル・コンピューティング・カメラはモニターの上部に設置するように設計されています。ここがカメラの位置であると仮定してアプリケーションを設計してください。カメラは通常、ユーザーの頭や上半身が見えるように向けられます。これは、ビデオ会議のような一般的な使用状況の場合です。各ケースで頭と上半身が見える必要があるかどうかに関係なく、この視野設定を仮定します。

コンピューターのフォームファクター

タッチ対応デバイスの増加に伴い、さまざまなプラットフォームでアプリケーションを動作させる必要性が生じています。ユーザーは、ノートブック、Ultrabook™ デバイス、一体型、従来の PC とモニターなどでアプリケーションを実行します。これらの異なるプラットフォームでは、人間工学的な制限が異なります。次のことを覚えておきましょう。

画面のサイズ 軽量薄型のノートブックや Ultrabook™ の代表的なサイズは 13 インチです (12 インチ以下のものもあります)。デスクトップでは 24 インチ以上が一般的です。この違いは、アプリケーションの UI と関連する画像処理および対話処理の設計を行う上で課題となります。異なる画面サイズに対応する柔軟性が必要です。

画面との距離と画面の高さ ノートブックの画面とキーボードは一体になっているため、ノートブックでは画面との距離がデスクトップよりも短くなります。同様に、ノートブックの画面はデスクトップの画面よりも低く、ユーザーから見下ろすようになります。画面との距離および画面の高さに対応する柔軟性も必要です。

モニター上に適切に設置されたカメラ ノートブック上に適切に設置された カメラ

6

カメラの高さ カメラの高さもプラットフォームによって異なります。デスクトップの大画面モニター上に設置した場合、カメラの高さはユーザーの頭よりも高く、ユーザーから見上げるようになります。ユーザーの膝の上で Ultrabook™ を使用する場合、カメラの位置は非常に低く、ユーザーから見下ろすようになります。アプリケーションは、これらの異なるカメラ設定に対応する必要があります。

オクルージョン 空中のジェスチャーを使用するアプリケーションでは、ユーザーの手で画面が見えなくなる問題に注意しなければいけません。ユーザーが画面上のオブジェクトをつかむために手を上げると、手でオブジェクトが隠され、オブジェクトを見ることができません。これらの問題ができるだけ起こらないようにアプリケーションを設計します。

ノートブックの場合、ユーザーの手は画面に近くなります。画面は通常、ユーザーの頭よりも低くなります。

デスクトップの場合、ユーザーの手は画面から離れています。画面は通常、ノートブックよりも高くなります。

7

2 高レベルの設計方針

パーセプチュアル・コンピューティング向けの適切なアプリケーションを設計するには、その長所を理解する必要があります。パーセプチュアル・コンピューティングにおけるキラー・アプリケーションは、従来のプラットフォームだけでなく、電話やタブレットなどの最近のプラットフォームで見かけるアプリケーションとも異なるものとなるでしょう。

2.1 入力形式 パーセプチュアル・コンピューティングで利用可能な入力形式は、従来のプラットフォームとは異なります。これらの形式の長所を理解し、必要に応じてアプリケーションに取り入れます。複数の形式を組み合わせるとさらに強力です。

空中のハンド・ジェスチャー: 2D または 3D オブジェクトとの豊富で魅力的な対話処理を考慮します。この入力形式はすぐに理解できるでしょう。しかし、空中ジェスチャーは長時間続けると疲れてしまいます。また、精度にも限界があります。

タッチ: この入力形式もすぐに理解できます。イベントにタッチしてフィードバックできる利点があります。ただし、タッチは 2D の対話処理に制限されます。空中ジェスチャーほどの柔軟性はありません。

音声: 人の言葉は強力で説得力のある表現の手段です。より適切に対話処理が行えるように、物理的な入力操作と音声による入力操作を併用する場合もあります。音声はユーザーがコンピューターのほかのセンサーの範囲内にいない場合にも有効です。しかし、その性質により、解釈される言葉が曖昧になることがあります。システムが他者の言葉をシステム入力として解釈してしまうリスクもあります。また、コンピューター

への音声入力は騒音の元にもなるでしょう。

マウス: 2D の位置を正確に示す最適な形式です。

キーボード: 現在、一貫性のある正確なテキスト入力に最も適している、一般的な形式です。

8

2.2 設計方針 パーセプチュアル・コンピューティング・プラットフォームに対応するアプリケーションの設計および実装には、Windows* や OS X* のような従来のプラットフォーム、あるいは iOS* や Android* のような新しいプラットフォーム向けの設計とは全く異なる考え方が必要です。アプリケーションを設計するときに、次のような点を考慮します。

• 現実に基づいているが現実をそのまま再現しないこと。実世界の着想を活用するべきです。パーセプチュアル・コンピューティングでは、毎日の生活で行われる自然なスキルを作り直して構築します。毎日、私たちは手でオブジェクトをつかんで動かし、音声で他者とコミュニケーションをとります。このような自然な人間の能力を活用します。ただし、現実をそのまま再現する必要はありません。仮想環境では、対話処理がより簡単になるように、物理世界の規則を緩和することができます。例えば、仮想の指で仮想オブジェクトを正確に包んで拾い上げることは困難です。仮想オブジェクトの近くで仮想オブジェクトをつかむ動作を行って拾い上げるほうがはるかに簡単です。

• 抽象的ではなく具体的であること。実世界の等価物から構築された視覚情報 (ビジュアルキュー) と対話形式は、抽象的な象徴物よりも簡単に理解することができます。また、象徴物は地域や文化によって異なり、翻訳されない場合もあります。スイッチと取っ手のような具体的な設計メタファーは、さまざまな文化圏でも普遍的です。

• 直感的であること。アプリケーションは受け入れやすく、すぐに利用可能であるべきです。ビジュアルキューは、ユーザーがアプリケーションの使い方を直感的に理解できるように構築します。音声入力コマンドは自然言語の使用法に基づき、アプリケーションは入力の解釈を柔軟かつ寛容に行うべきです。

• 一貫性があること。アプリケーションのさまざまな部分における同様の操作は同じ方法で実行するべきです。対話処理のガイドラインが存在する場合は、そのガイドラインに従います。パーセプチュアル・コンピューティング・エコシステムのアプリケーションで一貫性を保つことにより、ユーザーの理解と信頼が深まります。

• 拡張可能であること。将来の SDK の拡張を考慮します。マウス・インターフェイスと異なり、パーセプチュアル・コンピューティング・プラットフォームの性能、安定性、柔軟性は今後、向上するでしょう。手のポーズの知覚が大幅に向上した場合、アプリケーションはどのように機能するでしょうか。自然言語に対する理解が向上した場合はどうでしょうか。テクノロジーの向上に伴って機能が向上するようにアプリケーションを設計します。

• 信頼性があること。誤検出や無視される入力を最小限に抑えて、アプリケーションに対するユーザーの期待を裏切らないようにします。

• 境界条件を適切に処理できること。例えば、ユーザーの手がカメラの視界から消えるときに、アプリケーションがクラッシュしたり想定外の動作を行わないようにします。これらの状況が適切に処理できることを確認してください。

• 長所を活かすこと。空中のジェスチャー入力はマウス入力やタッチ入力とは全く異なります。各形式には長所と短所があるので、状況に応じて適切な形式を採用します。

• 内容に適していること。ゲーム、医療アプリケーション、企業のコンテンツ共有アプリケーションに最適な処理はそれぞれ異なります。内容に即した対話処理を利用してくだ

9

さい。例えば、ゲームにはより楽しい対話処理を、シリアスなアプリケーションにはより単純な対話処理を使用します。

ユーザー中心の設計を行ってください。最適な設計でも、想定したユーザーによるテストが必要です。テストはアプリケーションや製品の発売直前に行わないでください。予期しない問題が発生し、アプリケーションの調整が必要になることがあります。ユーザーを決定する前に、対象ユーザーが分かっていなければいけません。

2.3 複数形式 SDK に機能が追加されると、利用できるセンサーや入力の数も増えますが、不要な入力形式は実装せずに適切な設計を考えます。また、同期と非同期両方の異なる入力形式の組み合わせを活用してください。その結果、ユーザー体験がより魅力的で自然なものとなり、手、指、音声の無駄な動作を最小限に抑えることができます。さまざまな形式を組み合わせると、正しい情報を伝えていることをユーザーがイメージしやすくなります。例えば、手でイメージをスワイプし、音声により電子メールを作成するようなことができます。異なる形式に拡張でき、形式の組み合わせが容易な方法で設計します。精神的および身体的の両面から形式の切り替えがユーザーにとって快適であることを確認します。一部のユーザーは特定の形式や異なる能力を好む場合があることに注意してください。

10

3 ジェスチャー・デザインのガイドライン

ここでは、空中のハンド・ジェスチャーを設計して実装するベストプラクティスを説明します。

3.1 キャプチャー・ボリューム すべてのパーセプチュアル・プラットフォームにはさまざまな長所と短所があります。アプリケーションを設計する際は、各パーセプチュアル・プラットフォームの短所を理解しておく必要があります。カメラには特定の視界 (キャプチャー・ボリューム) があり、この範囲を超えると何も見えなくなります。深度を検出するほとんどのカメラでは、オブジェクトを検出可能な最小距離と最大距離が設定されています。最小距離よりも近いオブジェクトや最大距離よりも遠いオブジェクトは検出できません。

アプリケーションを設計および実装するときにプラットフォームの知覚能力を考慮することは重要です。キャプチャー・ボリュームの制限により、ユーザーの動きの範囲は制限されます。特にゲームでは、ユーザーが常にキャプチャー・ボリューム内で操作を行うとは限りません。フィードバックと対話処理でこのような状況を考えなければいけません。

ジェスチャーを行うときに、ユーザーが身体を後ろに反らすこともあります。ユーザーの手はカメラから約 30 センチ手前にある仮想平面で動きます。この仮想平面は次の目的に使用されます。 (a) ユーザーの手がカメラから 30 センチ以内にある場合は、手の追跡を行います。 (b) スワイプ・ジェスチャーでは、この平面を用いて左スワイプと右スワイプを区別します。

ユーザーの頭と手は常に 20 センチ以上離してください。ハンド・ジェスチャーを追跡するソフトウェアは、手と頭が非常に近い場合、その違いを正確に区別することができません。

カ メ ラ の キ ャ プ チ ャ ー ・ ボリュームが近く/遠くの 2 つの平面で定義された角錐台と視界で 視 覚 化 さ れ て い ま す 。

ユーザーはカメラのキャプチャー・ボリューム内でハンド・ジェスチャーを行っています。

ユーザーはキャプチャー・ボリューム外でハンド・ジェスチャーを行っています。カメラはこのジェスチャーを検出できません。

11

3.2 ハンド・ジェスチャー入力における推奨事項 多くのパーセプチュアル・コンピューティング・アプリケーションでは、空中ジェスチャー入力がプライマリー入力方式になります。対話処理を設計する場合やジェスチャーの選択について検討する場合は、次の点を考慮してください。

• 可能であれば一般的なジェスチャー・プリミティブを使用する。必要な場合に限り、独自のジェスチャー・プリミティブを使用します。大きな独特のジェスチャー・セットよりも小さく自然な汎用ジェスチャー・セットを利用します。

• 順序や姿勢を記憶する必要がある抽象的なジェスチャーを使用しない。抽象的なジェスチャーは、実世界に同等のジェスチャーがなく、既存のメンタルモデルと一致しないジェスチャーです。混乱しやすいジェスチャーの例に、「サムダウン」による項目の削除があります。項目を削除するジェスチャーとしては、項目をごみ箱に入れるジェスチャーのほうが適切です。

• 相対的な動きと絶対的な動き。相対的な動きでは、画面上の現在の手の位置をより快適な位置に変更する (例えば、マウスを持ち上げてマウスパッドの別の場所に移動する) ことができます。絶対的な動きでは、空間的な関係が維持されます。アプリケーションは、特定のコンテキストで感度が最大になるモーションモデルを利用するべきです。

• 左右のジェスチャーは上下のジェスチャーよりも簡単。可能な場合は常に、左右のジェスチャーを選択します。

• 必要な場合は両手を使う。一部のタスクは両手で行うほうが良いこともあります。必要な場合は両手の対話処理をサポートします。

• 利き手の違いを考慮する。右手のジェスチャーと左手のジェスチャー両方に対応するように注意します。

• 柔軟な設定。サイズや動きの異なる手をコードで処理できることを確認します。一部のユーザーが標準設定で適切に動作させることできない場合、アプリケーションの設定を変更できるようにします。例えば、手が震える人を対象に含める場合は、手のゆれ (ジッター) のしきい値をカスタマイズします。また、想定外の小さなジェスチャーまたは大きなジェスチャーの人を対象に含める場合も同様です。

• 自然なジェスチャーと覚える必要があるジェスチャー。ユーザーにとって自然なジェスチャー (例えば、画面のオブジェクトをつかむ) と覚える必要があるジェスチャー (例えば、ウェーブしてモードを終了する) があります。覚える必要があるジェスチャーの数はできるだけ少なくします。

• 静的ジェスチャーと動的ジェスチャー。異なる種類のジェスチャーに注意します。静的ジェスチャーは手を握ってアイテムを選択するような動作で、動的ジェスチャーはスワイプしてページをめくるような動作です。それぞれの動作が理にかなったものにします。

• ジェスチャーの使い方を表示する。アプリケーションのチュートリアルを提供するか、ジェスチャーを初めて使用するときに使い方の説明を表示します。一定の時間や回数が経過したら表示をオフにするオプションを用意すると便利です。

12

• 人間工学的に快適なジェスチャーを優先する。

• 特定の自然なジェスチャーを無視する。ユーザーが髪を整えたり、コーヒーを飲んだり、知人に話しかけた場合はどう対応しますか。このような状況をアプリケーションが誤って認識しないように、ジェスチャーを明確なものにします。

• 中止できるようにする。ユーザーが簡単にジェスチャーやモードを中止、またはリセットできるようにします。

3.3 認識されるポーズ ポーズとジェスチャーは異なります。ポーズは 1 つの姿勢を保ちますが、ジェスチャーはポーズとポーズを移動します。SDK の一部として現在認識されるポーズを次に示します。

手を開く/閉じる

SDK を使用して、「手を開く」ポーズと「手を閉じる」ポーズを、LABEL_OPEN および LABEL_CLOSE 属性でそれぞれ認識することができます。

サムアップ

「サムアップ（親指を立てる）」ポーズは、LABEL_POSE_THUMB_UP 属性で認識することができます。

サムダウン

「サムダウン（親指を下げる）」ポーズは、LABEL_POSE_THUMB_DOWN 属性で認識することができます。

ピース

「ピースサイン」ポーズは、LABEL_POSE_PEACE 属性で認識することができます。

13

3.4 一般的なジェスチャー・プリミティブ あらかじめ定義された動作として予約された、いくつかのジェスチャーが用意されています。通常、これらのジェスチャーは定義された動作にのみ使用するべきです。逆に、これらの動作がアプリケーションに存在する場合、指定されたジェスチャーを使用して行われるべきです。これらのガイドラインを常に守る必要はありませんが、これらのガイドラインから外れる際は、特別なユーザー体験を行う理由がある場合のみにしてください。この一般的なジェスチャー・セットは今後、進化するでしょう。

これらのジェスチャーは、SDK で部分的にサポートされています。一部のジェスチャーは全体でサポートされ、一部は限定されたポーズ数でサポートされ、一部はサポートされていません。SDK の更新に伴い、より完全にサポートする予定です。

つかむ/はなす

画面上のオブジェクトをつかむジェスチャーを次に示します。ユーザーは親指とほかの指を離した状態から、指でつかむポーズをとります。この逆の動作は、オブジェクトをはなします。限定的なつかむ/はなす動作は、SDK の「手を開く/閉じる」パラメーターおよび「ポイントにタッチ」を利用して実現することができます。

オブジェクトをつかむ

動かす

オブジェクトをつかんだ後、手を動かしてオブジェクトを移動します。つかむことができるオブジェクトを設計する際の一般的なガイドラインを次に示します。

動かせるオブジェクトと動かせないオブジェクトがユーザーに明白であること。 インターフェイスがつかむ動作と動かす動作に極度に依存する場合、つかんだオブジェ

クトを落とせる場所がユーザーに明白であること。 微妙な手のゆれを反映できる程度の大きなオブジェクトであること。 ユーザーが誤ってほかのオブジェクトをつかまない程度の大きなオブジェクトであるこ

と。

ユーザーがオブジェクトを動かしているときに手がはなれた場合、そのオブジェクトを元の位置にリセットして、追跡に失敗したことをユーザーに伝えます。この機能は、手追跡に閉じた手を示す手を開く/閉じる値を含めることにより実現できます。

14

オブジェクトを動かす

パン

アプリケーションがパンをサポートしている場合、平手でパンを行います。パンは手がほぼフラットになると開始します。平手を横に移動して、ビューをパンします。パンは手が自然なポーズに戻ると終了します。

ビューをパン

ズーム

アプリケーションがズームをサポートしている場合、両方の平手を使って行います。ズームは両方の手がほぼフラットになると開始します。ズームは 2 つの手の間の距離に関連付けられます (タッチのピンチズームに似ています)。ズーム機能には、ユーザーがズームを変更しないでズームを終了できる動作が必要です。

ビューをズーム

オブジェクトのサイズ変更もほぼ同様です。2 つの手を開いたままにする代わりに、一方の手でオブジェクトの片側をつかみ、もう一方の手でオブジェクトの反対側をつかみます。次に、互いに手

15

を移動します。オブジェクトを縮小するには手を互いに近づけ、オブジェクトを拡大するには手を互いに遠ざけます。ユーザーが一方の手をはなすと、動作は終了します。

ウェーブ

リセット、モード終了、階層移動のジェスチャーを次に示します。ユーザーは素早く前後に手を振ります。これは「ここから出して」という汎用ジェスチャーです。ウェーブは、SDK の LABEL_HAND_WAVE に含まれています。

モードをリセット

スワイプ

スワイプは基本的なナビゲーション・ジェスチャーです。ただし、スワイプを正確に認識することは技術的な課題でもあります。多くの場合、左スワイプはカメラの視界から見た右スワイプと全く同じです。スワイプは SDK の LABEL_NAV_SWIPE_LEFT および LABEL_NAV_SWIPE_RIGHT に含まれています。混乱を避けるため、ユーザーはスワイプ・ジェスチャーを次のように行うべきです。

カメラから約 30 センチ離れたところに仮想平面があると想像します。スワイプは最初にこの平面に入り、平面の内部で左から右または右から左に移動してから、平面を出ます。

3.5 その他の考慮事項 右手か左手か

片手のジェスチャーはすべて、右手または左手で行うことができます。操作の順序が重要な両手のジェスチャー (例えば、両方の手でオブジェクトをつかむサイズ変更ジェスチャー) では、どちらの手で操作を開始するかは重要ではありません。

指の数

多くのジェスチャーでは、伸ばした指の数は重要ではありません。例えば、パン操作はすべての指が伸びていても、数本の指が伸びていても行えます。指の数による制約は、ある操作に指が使われる場合にのみ存在します。例えば、伸ばした人差し指が 2D の位置を指す場合、同じ指をパンに使用することはできません。

ポーズの解釈における柔軟性

手の各ポーズは似ていますが、ポーズによって多少異なることがあります。例えば、正確なパンを行うには指を一緒に閉じて別々に広げます。

16

回転と移動の比率制御と絶対制御

回転、(オブジェクトまたはビューの) 移動、ズームレベルのようなジェスチャー調整パラメーターの制御には、絶対制御モデルまたは比率制御モデルを利用することができます。絶対制御モデルでは、ジェスチャーで手が回転または移動した量が調整 (回転または変換) するパラメーターにそのまま変換されます。例えば、手が 90 度回転すると、仮想オブジェクトは 90 度回転します。比率制御モデルでは、回転/移動の量はパラメーターの変化率 (回転速度や線速度など) に変換されます。例えば、90 度の回転は 10 度/秒の変化率 (またはその他の一定の比率) に変換されます。比率制御モデルでは、ユーザーはオブジェクトをはなすか、手を開始状態に戻して変更を停止します。

疲労を最小限に抑える方法

ジェスチャー入力は腕全体を空中に持ち上げた状態で行われるため、入力を続けると疲れがたまります。これは重大な問題であり、無視するべきではありません。この問題を無視すると、ユーザーはアプリケーションを利用しなくなる可能性があります。次のガイドラインのバランスを上手くとることにより、疲労の問題を最小限に抑えられます。

• ユーザーが肘を置いて操作できるようにする。腕の疲労を和らげる最良の方法は、椅子の肘掛に肘を置くことです。可能であれば、この種の入力をサポートしてください。ただし、この種の入力では、手を動かすことができる範囲が制限されます。制限された状態でも対話処理を設計できるかどうかを確認してください。

• 静止時間の短いジェスチャーにする。静止時間の長いジェスチャー (特に静止したポーズで腕を上げままにするジェスチャー) では、ユーザーの腕と肩はすぐに疲れてしまいます (例えば、数秒間腕を上げて選択するジェスチャー)。

• 休憩を考慮する。ユーザーは、無意識のうちに自然に休憩をとります (例えば、チョークで黒板に書くとき)。長く少ない休憩よりも、短く頻繁な休憩のほうが良いでしょう。

• 正確な入力を要求しない。正確な操作を行おうとする場合 (例えば、暗い場所で写真を撮るときに手ぶれをなくそうとする場合)、ユーザーの筋肉は自然に緊張します。その結果、疲労が急激にたまります。ジェスチャー全体を考慮し、操作するオブジェクトを大きくしてください。

• 何度も繰り返すジェスチャーを行わない。長い時間一定の方法でユーザーの手を継続して動かす (例えば、長い項目のリストを右にパンして移動する) ような場合、ユーザーの疲労と不満は急速に高まります。

3.6 サンプルおよび API SDK の /doc フォルダーにある sdksamples.pdf ファイルには、手追跡、ポーズ/ジェスチャー認識、イベント通知 (gesture_viewer、gesture_viewer_simple) の C++ および C# の例が含まれています。

また、sdkmanual-gesture.pdf には、RGB、深度、あるいは IR ストリームを入力とし、Blob 情報、幾何ノード追跡結果、ポーズ/ジェスチャー通知、アラート通知を返す、ジェスチャー・モジュールの最新バージョンが含まれています。

近距離の手/指追跡のオンライン・チュートリアルは、http://software.intel.com/en-us/sites/default/files/article/328725/perc-gesturerecognition-tutorial-final.pdf (英語) を参照してください。

17

4 音声設計のガイドライン

音声ベースの対話処理設計のガイドラインは、将来のリリースで提供する予定です。更新情報を確認してください。現在は、sdksamples.pdf の audio_recorder サンプルをご覧ください。

sdkmanual-core.pdf の、PXCAudio、PXCAccelerator、および PXCCapture::AudioStream インターフェイスを使用したオーディオ抽象についての情報も参照してください。

5 顔認識設計のガイドライン

顔認識ベースの対話処理設計のガイドラインは、将来のリリースで提供する予定です。更新情報を確認してください。現在は、sdksamples.pdf の face_detection サンプルをご覧ください。

また、sdkmanual-face.pdf の情報も参照してください。PXCFaceAnalysis モジュールは、顔検出、目標検出、顔認識、顔属性検出を含む、顔追跡アルゴリズムのセットを提供します。

顔検出モジュールの使用方法は、http://software.intel.com/en-us/articles/intel-perceptual-computing-sdk-how-to-use-the-face-detection-module (英語) を参照してください。

18

6 ビジュアル・フィードバックのガイドライン

パーセプチュアル・コンピューティング・アプリケーションの外観と動作は、従来のデスクトップ PC のアプリケーションとは全く異なります。カーソル、クリック、アイコン、メニュー、フォルダーのようなよく知られている概念は、ジェスチャーや音声が主なインターフェイス形式である環境にはそのまま当てはまりません。ここでは、視覚的にパーセプチュアル・コンピューティング対話モデルに準拠するアプリケーションを開発する設計ガイドラインを説明します。

6.1 ガイドライン • 迅速なフィードバック。ユーザーのジェスチャーや移動と画面上の視覚的なフィード

バックの間に遅れが発生しないようにします。

• スムーズな動作。視覚的な動作が振動するのを防ぐために必要な場合は、ユーザーの動作にフィルターを適用します。

• 異なる種類のフィードバックを組み合わせる。ユーザーは対話処理がよりリアルに感じることができます。オーディオ・フィードバックに対処する方法については、次のバージョンで説明する予定です。

• 操作可能なものを表示する。ユーザーが操作できないものを操作しないように、操作可能なものを表示します。

• システムの現在の状態を表示する。現在のオブジェクトは選択されているか。選択されている場合、視覚的に表示するにはどうすれば良いか。オブジェクトに異なる色を使用する、オブジェクトを傾ける、オブジェクトの向きを変更する、オブジェクトのサイズを変更する、などの方法があります。

• 認識しているコマンドや対話処理を表示する。ユーザーは追跡が正しく行われているかどうかを知ることができます。

• 進行状況を表示する。例えば、短いアニメーションやタイマーを表示します。

• 物理的現象を考慮する。ユーザーにリアルで満足できる体験を提供できるように、使用する物理的現象について考慮します。例えば、簡単に選択できるようにオブジェクトに対する磁気スナップのシミュレーションを行います。ユーザーがリストをパンしているときはリストの移動速度を速くして、ユーザーがパンを終了した後は元の速度に戻します。

6.2 ユーザーの表現 仮想世界ではユーザーを表現する必要があります。ユーザーを具体化することにより、ユーザーはシーンの要素と対話することができます。従来の環境では、この具体化はマウスカーソルです。パーセプチュアル・コンピューティング環境におけるユーザーの表現は、対話処理の形式と問題におけるアプリケーションの性質を反映するべきです。一般に、ハンド・ジェスチャーを用いる場合、手の表現を画面に示すべきです。頭の位置が対話処理と関連している場合、頭の表現を追加する必要があります。同様の規則はほかの形式にも適用されます。

19

手の表現は、極度にリアルにしたり、極度に単純化しないでください。極度にリアルな手は、「不気味の谷」によるユーザーの嫌悪感を引き起こすリスクがあります。極度に単純化された手は、手の複雑な状態を表現できません。また、カーソルと区別がつかなくなるリスクがあります。

手の表現はアプリケーションに依存します。マジックゲームでは、マジックワンドとして表現します。3D モデリング・アプリケーションでは、明確な手のモデルとして表現します。カーソルは静止オブジェクトにできます。また、ユーザーの手の動きや位置によって向き、サイズ、色を変更することもできます。

センサーの制限により、ユーザーを追跡できなくなることがあります。例えば、ユーザーがカメラから離れすぎた場合やカメラの横に移動した場合、カメラの視界から消えてしまいます。ユーザーは、いつこの状況になったか分からないことがあります。アプリケーションは、いつ追跡に失敗したのか、なぜ追跡に失敗したのか、どうすれば状況を修正できるのかをユーザーに知らせるべきです。このフィードバックは、ユーザーの表現の設計に追加することができます。追跡に失敗した場

明確な手のモデルによる手の表現。直接オブジェクトを操作するアプリケーションに適しています。

マジックワンドによる手の表現。マジックゲームに適しています。

追跡に失敗したときの手の表現。追跡に失敗したため、修正が必要なことが分かります。

20

合、ほかの方法を使用します。ゲームで追跡に失敗してユーザーがゲームに負けるようなことがあります。このような場合、追跡が再度確立されるまで動作を大幅に遅くすると良いでしょう。

一般に、センサーの制限を認識し、作成するユーザー体験が現在のテクノロジーで適切に動作することを確認するべきです。例えば、実生活では遅いものを追跡するときに、ユーザーの対話処理で非常に高速で敏感な追跡が必要になる設計は、優れた設計とはいえません。この場合、現在のテクノロジーの範囲内で動作するように対話処理とビジュアル表現を調整します。

6.3 オブジェクトの表現 シーンにおけるオブジェクトの理想的な表現は、オブジェクトと対話する方法によって大きな影響を受けます。パーセプチュアル環境では、オブジェクトとさまざまな方法で対話することができます。押したり、つかんだり、ねじったり、伸ばしたり、マウスでできることよりもはるかに多くのことができます。一方、手の精度はマウスよりも低くなります。オブジェクトの表現では、これらの現実を反映するべきです。アプリケーションのオブジェクトでは次の点を考慮します。

• 手の豊富な操作能力を活用します。 • 何ができるかユーザーが理解できるように、インタラクティブな操作で可能なことを明確に

伝えます。 • 容易に操作できるサイズにします。 • 大量のエラーが発生したり、疲れる細かい操作を要求しないようにします。

オブジェクトにおけるジェスチャー動作

アプリケーションでオブジェクトと対話するときに考慮すべき動作状態には次のようなものがあります。

ターゲット ホバリング 選択 ドラッグ リリース

6.4 2D と 3D パーセプチュアル・コンピューティング・グラフィカル・アプリケーションは、2D または 3D インタラクティブ環境で表示されます。2D 環境は 2D 画面で簡単に操作できます。3D 環境が必要でない場合は、2D 環境を採用するべきです。ただし、2D 環境での対話にジェスチャーを使う場合、3D キューで対話処理を拡張することを検討してください。例えば、つかんだオブジェクトのドロップシャドウを少し大きくして、2D 表面から持ち上げられていることを表現します。完全な 3D 環境では、パーセプチュアル環境の多くの長所を活かすことができます。使用状況で必要な場合は、3D 環境を利用します。一部のアプリケーション (特にゲー

ム) は、3D で操作することで利点が得られます。

21

6.5 従来の UI 要素 主にジェスチャーで操作するインターフェイスのインタラクティブな要素は、主にマウスで操作する環境の要素とは異なります。ここでは、空中ジェスチャーに使用できる従来の UI 要素について説明します。これらの要素は分かりやすさや効率の点で役立つもので、多くのユーザーがこのようなモデルに親しんでいます。もちろん、より優れたソリューションがあるにもかかわらず、ユーザーがこれまで使用していた UI 要素をそのまま使うことは適切ではありませんが、ユーザーがすでに利用している UI 要素を無視すべきではありません。

水平リスト

水平リストは、右手のより自然な左右の動きに依存している点で優れています。アーチ状に選択肢を表示するように線形リストにすると、ユーザーは肘を固定して休ませた状態で選択することができます。ただし、このアプローチは利き手に依存することに注意してください。下記の例は左利きのユーザーには快適な操作ではありません。左利きのユーザーを考慮する場合は、オプションでインターフェイスの左右を反転できるようにします。

水平リストの例

放射リスト

放射リスト (パイメニュー) は特にジェスチャー入力に便利です。ユーザーがオプションを選択するのに移動する距離が短く、正確に選択する必要がないため、ミスが少なくなります。また、線形リストよりも必要な空間が少なくなります。放射リストを作成する場合、各オプションの選択可能な領域が最大限になるように、リストの各部分全体を選択可能にします。

放射リストの例。「Paste」が選択されています。

22

スライダー

一般に、スライダーは指定された範囲内で値を調節するのに使用されます。アプリケーションに依存する相対的なパンを使う代わりに絶対的なパンをスライダーに使用したいこともあるでしょう。スライダーを用いる場合は、次のガイドラインに従ってください。

• 連続したスライダーではなく個別のスライダーを作成する。ジェスチャー入力は疲れずに細かい選択を行うには、精度が欠けています。

• 「目盛り」間の距離を十分に空ける。高い精度をユーザーに要求しないようにします。

上のスライダーは目盛りが少ないため、空中ジェスチャーでも値を容易に選択することができます。下のスライダーは目盛りが多いため、値を選択することがはるかに難しくなります。

6.6 キーボード、マウス、タッチの統合 マウス、キーボード、タッチパッドやタッチスクリーンを無視しないでください。これらはユーザーにとって使い慣れた UI 要素で、それぞれ独自の目的があります。多くの場合、オンスクリーン・キーボードではなく、通常のキーボードで情報を入力するほうが効率的です (入力する文字が少ない場合のように、状況によってはジェスチャーを使用しても効率的なこともあります)。正確な 2D の位置を見つけるには、従来と同じように、マウスとタッチスクリーンが便利で効率的です。

23

7 質問およびご意見

この記事では、ヒューマン・コンピューター・インタラクション、ユーザー・インターフェイス設計、ジェスチャー入力における長年の研究に基づいたガイドラインを提供しました。特定のガイドラインが使用状況に適さないと思われる場合や、修正あるいは追加についてご意見がある場合は、フォーラムスレッド “Human Interaction Guidelines-Questions and Suggestions” へポストしてください。検討させていただきます。

その他の参考情報:

• チュートリアル (英語) http://software.intel.com/en-us/articles/intel-perceptual-computing-sdk-tutorials

• FAQ (英語) http://software.intel.com/articles/perc-faq

• インテル® デベロッパー・ゾーンの Perceptual Computing SDK フォーラム (英語) http://software.intel.com/en-us/forums/intel-perceptual-computing-sdk

著作権と商標について

本資料に掲載されている情報は、インテル製品の概要説明を目的としたものです。本資料は、明示されているか否かにかかわらず、また禁反言によるとよらずにかかわらず、いかなる知的財産権のライセンスを許諾するものではありません。製品に付属の売買契約書『Intel's Terms and Conditions of Sale』に規定されている場合を除き、インテルはいかなる責任を負うものではなく、またインテル製品の販売や使用に関する明示または黙示の保証 (特定目的への適合性、商品適格性、あらゆる特許権、著作権、その他知的財産権の非侵害性への保証を含む) に関してもいかなる責任も負いません。

インテルによる書面での合意がない限り、インテル製品は、その欠陥や故障によって人身事故が発生するようなアプリケーションでの使用を想定した設計は行われていません。

インテル製品は、予告なく仕様や説明が変更される場合があります。機能または命令の一覧で「留保」または「未定義」と記されているものがありますが、その「機能が存在しない」あるいは「性質が留保付である」という状態を設計の前提にしないでください。これらの項目は、インテルが将来のために留保しているものです。インテルが将来これらの項目を定義したことにより、衝突が生じたり互換性が失われたりしても、インテルは一切責任を負いません。この情報は予告なく変更されることがあります。この情報だけに基づいて設計を最終的なものとしないでください。

本資料で説明されている製品には、エラッタと呼ばれる設計上の不具合が含まれている可能性があり、公表されている仕様とは異なる動作をする場合があります。現在確認済みのエラッタについては、インテルまでお問い合わせください。

最新の仕様をご希望の場合や製品をご注文の場合は、お近くのインテルの営業所または販売代理店にお問い合わせください。

24

本資料で紹介されている資料番号付きのドキュメントや、インテルのその他の資料を入手するには、1-800-548-4725 (アメリカ合衆国) までご連絡いただくか、http://www.intel.com/design/literature.htm (英語) を参照してください。

性能に関するテストに使用されるソフトウェアとワークロードは、性能がインテル® マイクロプロセッサー用に最適化されていることがあります。SYSmark* や MobileMark* などの性能テストは、特定のコンピューター・システム、コンポーネント、ソフトウェア、操作、機能に基づいて行ったものです。結果はこれらの要因によって異なります。製品の購入を検討される場合は、他の製品と組み合わせた場合の本製品の性能など、ほかの情報や性能テストも参考にして、パフォーマンスを総合的に評価することをお勧めします。

本資料に含まれるソフトウェア･ソース･コードはソフトウェア･ライセンス契約に基づいて提供されるものであり、その使用および複製はライセンス契約で定められた条件下でのみ許可されます。

Intel、インテル、Intel ロゴ、Ultrabook は、アメリカ合衆国および / またはその他の国における Intel Corporation の商標です。© 2012 Intel Corporation. 無断での引用、転載を禁じます。

* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。