• 検索結果がありません。

スマートフォンにおける近接センサを利用した操作手法の提案

N/A
N/A
Protected

Academic year: 2021

シェア "スマートフォンにおける近接センサを利用した操作手法の提案"

Copied!
34
0
0

読み込み中.... (全文を見る)

全文

(1)

平成27年度卒業論文

スマートフォンにおける

近接センサを利用した操作手法の提案

情報・通信工学科 コンピュータサイエンスコース

1211213 渡辺 友康

指導教員 寺田 実 准教授

提出日 2016年 2月 1日

(2)

1

概要

目的

スマートフォンは日本国内においても広く普及し,日々の生活には欠かせないアイテムとなりつつある.それ に伴い,日常生活の様々な場面で使用されることも増加しているが,既存の操作方法は周辺環境からの影響を受 けることがあり,スムーズな操作の妨げとなることがあった. そこで,周辺環境からの影響が少ない近接センサ を用いることで,周辺環境からの影響が小さい操作方法が実装できると考えた. 本研究では,近接センサを用いたアプリケーションを2つ実装し検証する.

方法

本研究では, Android端末上で動作する「近接モールスIME」と「近接ショートカットアプリ」の2つを実 装する.また,評価実験として複数の被験者にそれぞれ使用してもらい,アンケートに答えてもらうことで本提 案の有用性を検証した.

結論

近接センサを用いたスマートフォンの操作は周辺環境からの影響が小さく,一定の操作をすることが可能で あることを確認した. しかし,本システムを使用する上で,ユーザへのフィードバックや操作速度に関してなど,改良点もあった.

(3)

2

目次

第1章 序論 6 1.1 背景 . . . 6 1.2 問題点 . . . 7 1.3 着目点 . . . 7 1.4 目的 . . . 8 1.5 本論文の構成 . . . 8 第2章 関連研究 9 2.1 Androidスマートフォンにおける近接センサによる画面ロック手法の開発[2] . . . 9 2.1.1 概要 . . . 9 2.1.2 本研究との関連 . . . 9 2.2 3指を用いたタッチパネル入力の評価と考察について[3] . . . 10 2.2.1 概要 . . . 10 2.2.2 本研究との関連 . . . 10 2.3 高速手指動作認識による携帯端末向け多指ARタイピングインタフェース[4] . . . 11 2.3.1 概要 . . . 11 2.3.2 本研究との関連 . . . 11 2.4 Google日本語入力 . . . 12 2.4.1 概要 . . . 12 2.4.2 本研究との関連 . . . 12 第3章 提案システム 13 3.1 システム概要 . . . 13 3.1.1 近接モールスIME . . . 13 3.1.2 近接ショートカットアプリ. . . 14 3.2 システム利用の流れ. . . 15 3.2.1 近接モールスIME . . . 15 3.2.2 近接ショートカットアプリ. . . 15 3.3 画面構成 . . . 16 3.3.1 近接モールスIME . . . 16 3.3.2 近接ショートカットアプリ. . . 17

(4)

目次 3 第4章 実装 19 4.1 開発環境 . . . 19 4.2 近接センサの値の取得 . . . 19 4.3 符号の判別. . . 20 4.4 近接モールスIMEの動作. . . 20 4.4.1 パーミッション . . . 20 4.4.2 文字の入力 . . . 20 4.4.3 しきい値の変更 . . . 21 4.5 近接ショートカットアプリの動作 . . . 21 4.5.1 ショートカット先の追加 . . . 21 4.5.2 常駐サービスの開始 . . . 21 4.5.3 電話への応答 . . . 22 第5章 評価実験 23 5.1 実験1:近接モールスIMEの入力速度と誤入力率の検証 . . . 23 5.1.1 目的 . . . 23 5.1.2 被験者・環境 . . . 23 5.1.3 実験内容 . . . 24 5.1.4 結果 . . . 24 5.1.5 考察 . . . 26 5.2 実験2:近接ショートカットアプリの使用感について . . . 27 5.2.1 目的 . . . 27 5.2.2 被験者・目的 . . . 27 5.2.3 実験内容 . . . 27 5.2.4 結果 . . . 28 5.2.5 考察 . . . 30 第6章 結論 31 6.1 結論 . . . 31 6.2 今後の課題. . . 31 6.2.1 入力のフィードバック . . . 31 6.2.2 しきい値の変更 . . . 31 参考文献 33

(5)

4

図目次

1.1 情報通信端末の世帯保有率の推移.([1]より.) . . . 6 1.2 スマートフォン上での近接センサ . . . 7 2.1 近接ロック動作イメージ([2]より) . . . 9 2.2 3指タップ入力画面([3]より) . . . 10 2.3 多指タイピングインタフェースシステムの動作画面([4]より). . . 11 2.4 Google音声入力動作画面. . . 12 3.1 かなモールス符号一覧 . . . 14 3.2 近接モールスIMEの流れ. . . 15 3.3 近接ショートカットアプリの流れ . . . 16 3.4 IME選択画面 . . . 17 3.5 IME起動時 . . . 17 3.6 文字入力時. . . 17 3.7 モールス符号表示部. . . 17 3.8 アプリケーション起動時 . . . 18 3.9 符号列登録画面 . . . 18 3.10 円表示部 . . . 18 3.11 ショートカット先(他のアプリケーション)登録画面 . . . 18 3.12 ショートカット先(Webページ)登録画面 . . . 18 3.13 常駐アプリ起動時の通知バー. . . 18 5.1 回答の分布. . . 29

(6)

5

表目次

5.1 アンケート内容 . . . 23 5.2 アンケート結果 . . . 24 5.3 文字列1の入力時間の平均(s) . . . 24 5.4 文字列2の入力時間の平均(s) . . . 25 5.5 1文字あたりの入力時間[s]とp値. . . 25 5.6 文字列1での正しく入力できなかった文字とその回数 . . . 25 5.7 文字列2での正しく入力できなかった文字とその回数 . . . 26 5.8 各文字列の平均符号数(トンを1,ツーを2,符号間を1として算出) . . . 26 5.9 誤入力先上位4つ . . . 26 5.10 登録済みの符号列とショートカット先 . . . 28 5.11 アンケート内容 . . . 28 5.12 符号列の組み合わせごとの誤入力回数 . . . 28 5.13 アンケート結果(1:そう思わない, 5:そう思う) . . . 29

(7)

6

1

章 序論

1.1

背景

スマートフォンは,従来の携帯電話をより高性能にした携帯情報端末(PDA)である.現在では日本国内に おいても広く普及し,日々の生活には欠かせないアイテムとなりつつある.総務省が発表している「平成26年 版情報通信白書」[1]によると,平成25年末時点におけるスマートフォンの世帯保有率は約62.6%であり(図 1.1*1),多くの人がスマートフォンを所持していることが分かる. また,スマートフォンの普及に伴い,スマートフォンの役割は電話をかけることや,メールを書くだけではな くなってきた.料理中でのレシピの検索や,外出時での地図の利用というように,スマートフォンが様々な場面 で使用されることも増加してきた. 図1.1:情報通信端末の世帯保有率の推移.([1]より.) *1総務省情報通信白書. http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h26/html/nc253110.html

(8)

第1章 序論 7

1.2

問題点

現在普及しているスマートフォンの操作は,そのほとんどがタッチパネルを用いたタッチ操作を採用してい る. タッチ操作では画面に表示されたコンテンツを直接選択することができ,スムーズな操作が可能であると いう利点がある. しかし,直接画面に触れなければならないので,衛生面での不安があり,タッチパネルの多く が静電容量方式を採用しているため,手袋をしていると反応しにくかったり水滴などに誤反応をしてしまった

りするということがあった.また,最近では「Hey Siri」*2や「Ok google」*3といったフレーズで知られるように

なった,音声を用いた操作も普及してきた.音声での操作は声を出すだけで良いため,タッチパネルよりもっと スムーズな操作が可能であったり,両手がふさがっている状況でも操作ができるという利点があった. しかし, 周辺の騒音などの影響を受ける,声を出さなくてはならないために,図書館などの静かにしなければならない場 所では使用できないという問題がある. このように,既存の操作方法は自身の状況や,周辺環境からの影響を受けることがあり,思ったとおりの操作 ができないことがある.

1.3

着目点

ほとんどのスマートフォンには,近接センサが搭載されている.これは,赤外線などを利用し,物体が近づいて いるかを検出することができるものである. 主な利用用途としては,通話時にスマートフォンを顔に近づけた 際,タッチパネルの誤動作を防止するために用いられている.このセンサは近接しているかいないかを表す2値 しか取得することができないが,周囲の影響を受けにくいという点に着目した. 図1.2:スマートフォン上での近接センサ *2Siri. http://www.apple.com/jp/ios/siri/ *3Google. https://www.google.co.jp/intl/ja/about/

(9)

第1章 序論 8

1.4

目的

本研究の目的は,スマートフォンに搭載されている近接センサを利用することで,前述した自身の状況や周辺 環境からの影響が小さい操作方法の実装を目的とする.操作としては,文字の入力やアプリケーションの操作等 を想定し,入力される文章は検索に使用される1文程度を想定する.

1.5

本論文の構成

論文の構成を簡単に説明する. 本章では,序論として研究の背景と問題点,着目点と目的について述べた. 第2章では,本研究に関連する研究について述べる. 第3章では,提案するシステムについて述べる. 第4章では,提案するシステムの実装について述べる. 第5章では,実験の概要と結果,考察について述べる. 第6章では,結論と今後の課題について述べる.

(10)

9

2

章 関連研究

2.1

Android

スマートフォンにおける近接センサによる画面ロック手法の

開発

[2]

2.1.1

概要

長谷川らはスマートフォンを対象に,近接センサを利用した端末ロックを行うアプリケーションを開発した. これは,従来のロック手法の電源ボタンを押すことによる手動ロックと,タイムアウトによる時間ロックの2つ の方法に対し,近接センサを用いることで,手をかざすだけで容易にロックを掛けることができるようにすると いうものであった.また,近接センサの性質上,スマートフォンをポケットに入れるとき,机に裏向きでおいた時 などにもセンサが反応し,画面ロック忘れを減らし,他者の盗み見を防止できる点からセキュリティの向上に繋 がるというものであった. 図2.1:近接ロック動作イメージ([2]より)

2.1.2

本研究との関連

スマートフォンにおける近接センサを用いて,既存の操作手法をより利用者にとって使いやすくするための アプリケーションを提案するという点で共通するが,本システムでは画面ロックではなく,文字の入力や他のア プリケーションの起動を行う.

(11)

第2章 関連研究 10

2.2

3

指を用いたタッチパネル入力の評価と考察について

[3]

2.2.1

概要

井上らはソフトウェアキーボードを用いた入力は, 1指を用いて特定の狭い入力領域をタップすることに操作 性での問題点があると考え, 3指の認識と各指の圧力を用いたタップ及びフリック入力を提案することで,文字 入力の精度向上を目的とするシステムを提案した. 図2.2: 3指タップ入力画面([3]より)

2.2.2

本研究との関連

既存の入力手法に代わる文字入力手法を提案するという点で共通するが,本システムでは周辺環境の影響を 小さくするために近接センサを用いる.

(12)

第2章 関連研究 11

2.3

高速手指動作認識による携帯端末向け多指

AR

タイピングインタ

フェース

[4]

2.3.1

概要

樋口らは,スマートフォンは画面が小さく,狭い画面での操作のしづらさは利便性を損ねており,特に文字入 力においてその影響は顕著であると考え,スマートフォンの背面空間に仮想キーボードを表示し,手指を用いて キー入力可能なシステムを作成した.このシステムでは,スマートフォンの背面に設置されたカメラからユーザ の手指を含んだ画像を取得した後に, AR(拡張現実感)を用いて仮想キーボードと手指の画像を重ねてスマー トフォン上に表示する. 図2.3:多指タイピングインタフェースシステムの動作画面([4]より)

2.3.2

本研究との関連

タッチパネルを用いずに文字の入力を行うという点で共通するが,本システムではカメラを用いたARでは なく,近接センサを用いるという点で異なる.

(13)

第2章 関連研究 12

2.4

Google

日本語入力

*1

2.4.1

概要

Google日本語入力はスマートフォン上で動作するIMEである.その機能のうちの1つに,音声入力への対応 がある.この機能は,タッチパネルには触れず,入力したい単語をスマートフォンに向かって話しかけることで 音声認識をし,漢字変換後の単語を入力できるというものである. 図2.4: Google音声入力動作画面

2.4.2

本研究との関連

タッチパネルを用いずに文字の入力を行うという点で共通するが,本システムでは音声ではなく,近接センサ を用いるという点で異なる. *1Google 日本語入力 https://www.google.co.jp/ime/feature/platform.html

(14)

13

3

章 提案システム

3.1

システム概要

本研究では近接センサを利用して,文字を入力する「近接モールスIME」と,常駐アプリとして他アプリを起 動する「近接ショートカットアプリ」の2種類の操作手法を提案する.どちらのシステムも, Android上で動作 するように作成する. 前述のように,近接センサは2値しか取ることができないため,手などをかざして近接状態になってから離し て非近接状態になる時までの時間を計測し,その時間に応じてトン・ツーを判別し,操作に利用する.

3.1.1

近接モールス

IME

近接モールスIMEは,文字の入力を行うためにIME(Input Method Editor)として動作する部分と,近接セ

ンサの値を取得し,モールス符号に変換した後に文字へ変換する部分から成り立つ. 今回は1文程度の長さの文章の入力に主眼を置くため,漢字変換等は行わず,かな入力のみを行う.このとき, 入力される「かな」は五十音の「あ」から「ん」,「長音」,「撥音」,「小文字」,「濁点」,「半濁点」である. システムはIMEとして動作するため, Google日本語入力*1などのように,実際のアプリケーション内での入力 に使用することができる. また,トン・ツーの判別には「しきい値」をあらかじめ決定しておき,近接センサに手をかざしていた時間が そのしきい値より短かった場合はトン,長かった場合はツーであると判別する.最後のトン・ツーが入力されて から一定時間が経過したときに,それまでに入力されたトン・ツーの組み合わせから入力する文字を決定する. このしきい値は入力に使われたトン・ツーの値を参考に随時変更が行われ,入力速度が速い利用者の場合はし きい値が短く,遅い利用者の場合はしきい値が長くなるようになっている. 文字の決定にはモールス符号を用いる.これは,モールス符号が短点(トン)と長点(ツー)の組み合わせの みで表現される単純な符号であり,スイッチのON・OFFの2値で表すことができることと,使用されてきた歴 史が長く,広く一般に知られている手法であると考えられるためである.また,モールス符号では削除(訂正) は「・・・−・」であるが,使用しやすさを考慮し「手をしきい値の3倍の時間以上かざす」という動作で代用 する.さらに,「・・・−・」には検索時に使用する改行を割り当てた. *1Google 音声入力 https://www.google.co.jp/ime/feature/platform.html

(15)

第3章 提案システム 14 ア --・-- イ ・- ウ ・・- エ -・--- オ ・-・・・ カ ・-・・ キ -・-・・ ク ・・・- ケ -・-- コ ---- サ -・-・- シ --・-・ ス ---・- セ ・---・ ソ ---・ タ -・ チ ・・-・ ツ ・--・ テ ・-・-- ト ・・-・・ ナ ・-・ ニ -・-・ ヌ ・・・・ ネ --・- ノ ・・-- ハ -・・・ ヒ --・・- フ --・・ ヘ ・ ホ -・・ マ -・・- ・・-・-ミ ム- -・・・-メ -・・-・モ ヤ ・-- -・・--ユ --ヨ ラ ・・・ --・リ -・--・ル ---レ ・-・-ロ ワ -・- ・-・・-ヰ ・--・・ヱ ・---ヲ ・-・-・ン 長音(ー) ・--・- 濁点(゛) ・・ 半濁点(゜) ・・--・ 区切り点(、) ・-・-・- 改行 ・・・-・ 図3.1:かなモールス符号一覧

3.1.2

近接ショートカットアプリ

近接ショートカットアプリは,あらかじめ符号列と起動するアプリや電話の発信先などを登録しておき,常駐 アプリとして近接センサの値を取得し,符号列に応じて登録されているアプリの起動などを行う. 常駐アプリ はAndroidのServiceとして動作し,常に端末上で近接センサの値を取得し続け,符号列を判別してアプリの起 動などを行う.ここでいうAndroidのServiceとは,常にバックグラウンドで動作し続け,起動元のアプリケー ションとは独立したライフサイクルで動くコンポーネントである*2. 登録できるショートカットは以下の5つである. • 他のアプリケーションの起動. . .端末内の他のアプリケーションを起動する

• Webページヘのショートカット. . .登録したURLのWebページを開く

• HOMEキー. . .端末のHOMEキーの動作をする • 電話の応答. . .電話の着信があったときに通話モードにする • 電話の発信. . .登録した電話番号に電話をかける 近接センサを用いた常駐アプリとしてショートカットを行うことで,手が濡れていたりふさがっている状況 であったり,アプリケーションを起動中であっても,他のアプリケーションの起動などを行うことができる. *2Android Developers. http://developer.android.com/intl/ja/reference/android/app/Service.html

(16)

第3章 提案システム 15

3.2

システム利用の流れ

本節ではシステム利用時の流れを説明する.近接モールスIMEは図3.2,近接ショートカットアプリは図3.3 に沿って行う.

3.2.1

近接モールス

IME

近接モールスIMEはIMEとして動作するため,ブラウザなどの入力窓をタップするとアプリケーションが 起動し,入力受付状態となる. その状態で端末の近接センサに手をかざす(図3.2(a)).かざし始めの時間とか ざし終わりの時間を取得し,その時間の差をもとにトン・ツーを判別する(図3.2(b)).判別された符号をもと にモールス符号からかなへ変換し,入力窓に文字が入力される.(図3.2(c)). 判別に使用された時間はログファイルに保存され(図3.2(d)),その保存された時間をもとにしきい値を計算 し(図3.2(e)),新たなしきい値として符号を判別するために利用される. 図3.2:近接モールスIMEの流れ

3.2.2

近接ショートカットアプリ

近接ショートカットアプリを起動すると符号列とショートカット先を登録するためのシステムが表示される ので,任意の符号列と前述のショートカット先を選択し,登録・保存する(図3.3(a)).ショートカットを使用 する際は, AndroidのServiceとして常駐サービスを起動する(図3.3(b)).このとき,あらかじめ保存されてい たショートカットが読み込まれる.常駐サービス起動中は,スマートフォン上の近接センサに手をかざす事によ り(図3.3(c)),近接センサの値が変動し,符号を判別する(図3.3(d)).常駐アプリではその符号を符号列へ変 換した後にショートカット先を判別し,他のアプリを実行するためのIntentを発行する(図3.3(e)).スマート フォンでは発行されたIntentを受け取った時点で,ショートカット先を実行する(図3.3(f)).

(17)

第3章 提案システム 16

図3.3:近接ショートカットアプリの流れ

3.3

画面構成

3.3.1

近接モールス

IME

近接モールスIMEを使用するためには,入力モードになった状態でIMEの選択をタップし,表示されるIME

一覧の中から本システムを選択する(図3.4).近接モールスIMEが起動すると,画面下部にモールス符号表が

表示され(図3.5),その上部に現在入力された符号列が表示される(図3.7).文字の入力中には,現在入力さ

れたモールス符号ではどの文字が入力されるのかがわかりやすいように,対応する文字が赤枠で囲まれ強調さ

(18)

第3章 提案システム 17 図3.4: IME選択画面 図3.5: IME起動時 図3.6:文字入力時 図3.7:モールス符号表示部

3.3.2

近接ショートカットアプリ

近接ショートカットアプリを起動すると,登録済みの符号列とショートカット先の一覧が表示される(図 3.8). この一覧はRecyclerViewを用いて表示しているため,登録したショートカットが多くなっても,スク ロールをして確認することが出来る.画面上部の“Service start”と書かれたスイッチをタップすることで常駐 サービスが開始され,スマートフォン上の通知バーに実行中であることを示す表示がされる(図3.13).常駐 サービスが起動している間は,常に近接センサから符号を入力できるようになっており,符号列が入力された時 点で起動中のアプリが一時中断され,ショートカット先が起動する. また,新しい符号列とショートカットの登録は画面右下に表示されている“+”マークをタップすることで登 録画面(図3.9)が表示される.登録画面では,近接センサに手をかざすことにより,登録したい符号列を設定す ることができ,画面上部には手をかざしたときにトンならば青,ツーならば橙の円が表示がされ,どちらの符号 を入力したかが視覚的に確認しやすいようにしてある(図3.10).その下部には現在設定されている符号列が 表示され,確認できるようにしてある.さらにその下部には,ショートカット先を選択するためのボタンを設置 してあり,タップすることによりそれに応じたショートカット先を登録することができる. “APP”と書かれたボタンをタップすると端末内にインストールされているアプリケーションの一覧が表示 され,さらにそれをタップすることで符号列とショートカット先をセットにして登録することができる(図 3.11).

(19)

第3章 提案システム 18 入力することが出来る.入力した後にOKボタンをタップすることで,符号列とショートカット先をセットにし て登録することができる(図3.12). “HOME”と書かれたボタンをタップすると,設定した符号列のショートカット先をHOMEキーに設定して 登録する事ができる. “CATCH PHONE”と書かれたボタンをタップすると,設定した符号列のショートカット先を電話への応答に 設定して登録することができる. 図3.8:アプリケーション起動時 図3.9:符号列登録画面 図3.10:円表示部 図3.11: ショートカット先 (他 のアプリケーション)登録画面 図3.12:ショートカット先(Web ページ)登録画面 図3.13: 常駐アプリ起動時の通 知バー

(20)

19

4

章 実装

4.1

開発環境

提案システムはJavaを用いて, Android4.0.3(API15)以上のバージョンを対象として動作する

InputMeth-odEditorとネイティブアプリケーションとして実装した.それぞれのシステムは近接センサの値の取得部,符号 の判別部,動作部から成り立つ.今回は近接センサを用いたスマートフォンの操作を行うために, 2つのアプリ ケーションを提案しているが,これらは動作部が異なるのみで,近接センサの値の取得部,符号の判別部は基本 的に同じ挙動をする.

4.2

近接センサの値の取得

近接センサの値を取得するためには, SensorEventListenerインタフェースを実装して使用する.取得する ためにはリスナーを登録する必要があるため,アプリケーション起動時にコード4.1を実行する.   1 /∗ SensorManagerを登録 ∗/

2 SensorManager sensorManager = ( SensorManager ) getSystemService ( C ont ext . SENSOR SERVICE ) ; 3 Sensor sensor = sensorManager . g e t D e f a u l t S e n s o r ( Sensor . TYPE PROXIMITY ) ;

4 i f ( sensor ! = n u l l ) {

5 sensorManager . r e g i s t e r L i s t e n e r ( t h i s , sensor , SensorManager . SENSOR DELAY GAME ) ; 6 }   コード4.1:リスナーの登録 また,このリスナーは解放しないかぎりメモリを使用し続け端末に負荷をかけてしまうため,アプリケーショ ン終了時にはコード4.2を実行し,リスナーを解放する必要がある.   1 / / SensorManagerの解放

2 SensorManager sensorManager = ( SensorManager ) getSystemService ( C ont ext . SENSOR SERVICE ) ; 3 sensorManager . u n r e g i s t e r L i s t e n e r ( t h i s ) ;   コード4.2:リスナーの解放 近接センサのリスナーを登録した後は, onSensorChangedメソッドを実装する必要がある.このメソッドは センサの値が変更されるとき,つまり,手のかざし始めとかざし終わりに呼ばれる.呼ばれたときには引数に指 定されているeventにセンサの情報が渡されているため,コード4.3のようにすることで,近接センサの値が変 更されたことと,その値がどのように変更されたかを取得することが出来る.  

1 public void onSensorChanged ( SensorEvent event ) {

2 / / 近 接 セ ン サ か ど う か の 検 出

3 i f ( event . sensor . getType ( ) == Sensor . TYPE PROXIMITY ) {

4 p r o x i = event . v a l u e s [ 0 ] ; 5 i f ( p r o x i == 0 ) { 6 / / 近接時の処理 7 / / 近接時の時間をミリ秒で取得 8 s t a r t T i m e = System . c u r r e n t T i m e M i l l i s ( ) ; 9 } else i f ( onsw ) { 10 / / 非 近 接 時 の 処 理 11 / / 非 近 接 時 の 時 間 を ミ リ 秒 で 取 得

(21)

第4章 実装 20 12 endTime = System . c u r r e n t T i m e M i l l i s ( ) ; 13 14 / /モールス符号の判別処理 15 . . . 16 17 } 18 } 19 }  コード4.3: onSensorChangeメソッド

4.3

符号の判別

符号の判別は前述のコード4.3内のモールス符号の判別処理に記述する.具体的にはコード4.4のように,手

をかざし始めた時間をstartTime,かざし終わりの時間をendTimeとし, endTime - startTimeで差の時間を

とり,それをしきい値と比較してトン・ツーを判別する. このコードでのmorseは入力中の符号を保持するた

めのString型変数であり, “・・−”のようなときは, “001”と保持される.

 

1 / /モールス符号の判別

2 i f ( ( endTime − startTime ) <= aveBorder ) {

3 morse = morse + ” 0 ” ; 4 } else { 5 morse = morse + ” 1 ” ; 6 }   コード4.4:モールス符号の判別

4.4

近接モールス

IME

の動作

4.4.1

パーミッション

本システムをIMEとして使用するためには, Manifestにパーミッションを追加する必要がある.   1 <s e r v i c e

2 a n d r o i d : p e r m i s s i o n = ” a n d r o i d . p e r m i s s i o n . BIND INPUT METHOD ”> 3 </ s e r v i c e>   コード4.5:パーミッションの記述

4.4.2

文字の入力

モールス符号とかなとの対応はHashMapに保持されている.符号入力中の時間経過はハンドラで監視し,最 後の符号が入力されてからしきい値の3倍の時間が経過した時点でのモールス符号をもとに, HashMapに保持 されているかなを,コード4.6を実行して入力する.   1 g e t C u r r e n t I n p u t C o n n e c t i o n ( ) . commitText (入 力 す る 文 字) ;   コード4.6:文字の入力

(22)

第4章 実装 21

4.4.3

しきい値の変更

しきい値の変更はIMEのライフサイクルに依存して変更される. IMEのライフサイクルは以下の順序で行わ れる. 1. 入力ビューの作成 2. 入力モードの開始 3. 入力モードの終了 4. 入力ビューの終了 入力モードが開始されると,保存されているログファイルから今までの入力に使われた値が読み込まれる.こ の時の初期のしきい値を「しきい値A」とすると,しきい値Aより短いものを「トン」,長いものを「ツー」と みなし,トンの時間の平均値とツーの時間の平均値を出し,その平均値同士の平均値を新たなしきい値「しきい 値B」とする.入力モード中はこのしきい値Bがトン・ツーの判別に用いられる.入力モードが終了するとしき い値Bが保存され,次に入力モードが開始したときに新たなしきい値Aとして用いられる. しきい値B= しきい値Aより短い符号の時間の合計 しきい値Aより短い符号の個数 + しきい値Aより長い符号の時間の合計 しきい値Aより長い符号の個数 2 (4.1)

4.5

近接ショートカットアプリの動作

4.5.1

ショートカット先の追加

前述した符号列の判別を行い,登録したい符号列を設定した後に,ショートカット先を登録する. ショート カット先はIntentとして保持される.

4.5.2

常駐サービスの開始

常駐サービスを起動するには,コード4.7のようにNotificationを発行する必要がある.   1 N o t i f i c a t i o n . B u i l d e r b u i l d e r = new N o t i f i c a t i o n . B u i l d e r ( g e t A p p l i c a t i o n C o n t e x t ( ) ) ; 2 f i n a l N o t i f i c a t i o n n o t i f i c a t i o n ; 3 n o t i f i c a t i o n = b u i l d e r . b u i l d ( ) ; 4 s t a r t F o r e g r o u n d ( NOTIFICATION ID , n o t i f i c a t i o n ) ;   コード4.7:常駐サービスの開始

(23)

第4章 実装 22

4.5.3

電話への応答

本システムでは,符号列とショートカット先として電話への応答を設定しておくことにより,電話がかかって きたときにその符号列を近接センサに入力することで,電話に応答することが出来る.電話がかかってきたこと を検出するためには,ブロードキャストされた暗黙的Intentを受け取るためのBroadcastReceiverと,着信か どうかの判別をするためのPhoneStateListenerを継承し,コード4.8のように実装する.  

1 public class c a l l R e c e i v e r extends B r o a d c a s t R e c e i v e r {

2 @Override

3 public void onReceive ( Con text c o n t e x t , I n t e n t i n t e n t ) {

4 / / 電 話 の 状 態 を 取 得 す る リ ス ナ ー

5 TelephonyManager tm = ( TelephonyManager ) c o n t e x t . getSystemService ( C onte xt . TELEPHONY SERVICE ) ; 6 MyPhoneStateListener p h o n e L i s t e n e r = new MyPhoneStateListener ( ) ;

7 tm . l i s t e n ( p h o n e L i s t e n e r , P h o n e S t a t e L i s t e n e r . LISTEN CALL STATE ) ; 8 }

9

10 p r i v a t e class MyPhoneStateListener extends P h o n e S t a t e L i s t e n e r {

11 public void onCallStateChanged ( i n t s t a t e , S t r i n g callNumber ) {

12 / / N o t i f i c a t i o nがO N、 入 力 さ れ た 符 号 列 がC A L Lを 含 む

13 i f (近 接 セ ン サ の 符 号 列 が 入 力 さ れ, シ ョ ー ト カ ッ ト 先 が 応 答 か ど う か) {

14 / / 電 話 が 鳴 っ て い る か

15 i f ( s t a t e == TelephonyManager . CALL STATE RINGING ) {

16 / / 受 話 ボ タ ン を 押 す

17 I n t e n t i n t e n t = new I n t e n t ( I n t e n t . ACTION MEDIA BUTTON ) ;

18 i n t e n t . p u t E x t r a ( I n t e n t . EXTRA KEY EVENT , new KeyEvent ( KeyEvent . ACTION UP , KeyEvent . KEYCODE HEADSETHOOK ) ) ; 19 } 20 } 21 } 22 } 23 }   コード4.8:電話への応答

(24)

23

5

章 評価実験

本研究では,提案するシステムが期待される正しい動作をし,スマートフォンを快適に操作することが出来 るかどうかを確認するため,近接モールスIMEと近接ショートカットアプリのそれぞれについて評価実験を 行った.

5.1

実験

1

:近接モールス

IME

の入力速度と誤入力率の検証

5.1.1

目的

近接モールスIMEの目的は,周辺環境からの影響が小さく, 1文程度の文字入力が可能なシステムの作成で ある.よって,本システムの評価実験では,実際の使用を想定し,以下の2点を確かめることを目的とする. • 入力速度は既存の入力方法と比べてどの程度のものであるか • 誤入力をしやすい文字・符号列は何であったか

5.1.2

被験者・環境

評価実験は,本学の学生4名に協力してもらい行った.ただし,被験者Aのみ近接モールスIMEを30分/日 で1週間使用した後に実験を行った.実験は本研究室の一室で行い,使用したスマートフォンはau Xperia ZL2 (sol25)である.被験者には本実験に入る前に,近接モールスIMEの入力方法になれるための練習時間を10分 とった.比較に用いた既存の入力方法は,フリック入力としてGoogle日本語入力を,音声入力としてGoogle日 本語入力の音声入力機能を使用した. また,実験に先立ち,被験者が普段から使用している入力方法について表5.1のアンケートを実施し,表5.2の 結果が得られた. 表5.1:アンケート内容 質問番号 解答方法 質問内容 1 2択(Y/N) 普段,フリック入力を使用しますか 2 2択(Y/N) 普段,音声入力を使用しますか 3 2択(Y/N) 普段,上記以外の入力方法を使用しますか 4 自由記述 3で「はい」を選んだ場合,それは何ですか

(25)

第5章 評価実験 24 表5.2:アンケート結果 被験者名 回答1 回答2 回答3 回答4 被験者A はい いいえ いいえ 被験者B はい はい はい キーボード入力 被験者C はい いいえ いいえ 被験者D はい いいえ いいえ

5.1.3

実験内容

実験では,本システムとフリック入力,音声入力で文字列を入力してもらい,文字列を入力するのにかかった 時間を計測する.入力する文字列は「でんきつうしんだいがく」(以下,文字列1と呼ぶ)と「いろはにほへと」 (以下,文字列2と呼ぶ)の2文を各5回ずつで, 1文ごとの時間を計測する.時間の計測にはWebアプリケー ションの「qqTimer*1」を用いて施験者が計測した. また,近接モールスIMEは入力時に,入力に使用された符号の時間と文字をログファイルに出力しており,正 しく入力されなかった文字と,誤動作で入力された文字を調べる.

5.1.4

結果

各被験者と文字列,入力手法ごとの入力時間の平均と,従来手法を1としたときの提案手法による入力時間の 比を表5.3, 5.4に示す. また,これらの結果から各入力方法と文字列における1文字あたりの入力時間(s)と, 文字列長による入力時間への影響を調べるために,その有意差をt検定(両側5%)を用いて算出したp値を表 5.8に示す. 表5.3:文字列1の入力時間の平均(s) 被験者 近接モールスIME フリック入力 音声入力 近接/フリック 近接/音声 被験者A 49.93 4.93 5.29 10.13 9.44 被験者B 78.76 4.98 3.57 15.82 22.06 被験者C 151.76 6.23 3.39 24.36 44.77 被験者D 146.70 6.54 3.21 22.43 45.70 次に,正しく入力することができなかった文字とその回数を被験者ごとに表5.6, 5.7に示す. また,トンを1, ツーを2,符号間を1として各文字列の平均符号数を算出したものを表5.8に示す. さらに,誤入力先として多かったものの上位4つを表5.9に示す. *1qqTimer. http://mzrg.com/qqtimer/

(26)

第5章 評価実験 25 表5.4:文字列2の入力時間の平均(s) 被験者 近接モールスIME フリック入力 音声入力 近接/フリック 近接/音声 被験者A 24.64 2.93 4.27 8.41 5.77 被験者B 38.65 3.21 3.31 12.04 11.68 被験者C 32.52 3.66 2.65 8.89 12.27 被験者D 39.71 5.54 2.94 7.17 13.51 表5.5: 1文字あたりの入力時間[s]とp値 被験者 近接モールスIME フリック入力 音声入力 文字列1 文字列2 文字列1 文字列2 文字列1 文字列2 被験者A 4.54 3.52 0.49 0.42 0.48 0.61 被験者B 7.16 5.52 0.45 0.46 0.32 0.47 被験者C 13.80 4.65 0.57 0.52 0.31 0.38 被験者D 13.34 5.67 0.59 0.79 0.29 0.42 p値 0.10 0.74 0.0062 表5.6:文字列1での正しく入力できなかった文字とその回数 文字 モールス符号 被験者A 被験者B 被験者C 被験者D 合計 で ・ − ・ − − 0 0 1 3 4 ん ・ − ・ − ・ 2 0 3 2 7 き − ・ − ・ ・ 0 2 4 1 7 つ ・ − − ・ 1 2 3 0 6 う ・ ・ − 0 0 1 0 1 し − − ・ − ・ 0 2 4 1 7 ん ・ − ・ − ・ 1 0 2 2 5 だ − ・ 0 1 4 1 6 い ・ − 0 0 0 0 0 が ・ − ・ ・ 0 0 0 1 1 く ・ ・ ・ − 0 2 0 0 2

(27)

第5章 評価実験 26 表5.7:文字列2での正しく入力できなかった文字とその回数 文字 モールス符号 被験者A 被験者B 被験者C 被験者D 合計 い ・ − 0 0 3 1 4 ろ ・ − ・ − 1 2 0 2 5 は − ・ ・ ・ 0 0 0 0 0 に − ・ − ・ 0 1 2 0 3 ほ − ・ ・ 0 0 0 0 0 へ ・ 0 0 0 0 0 と ・ ・ − ・ ・ 1 0 1 0 2 表5.8:各文字列の平均符号数(トンを1,ツーを2,符号間を1として算出) 文字列 文字数 符号数合計 平均符号数 文字列1 11 105 9.55 文字列2 7 47 6.71 表5.9:誤入力先上位4つ 文字 モールス符号 回数 ね −−・− 5 む − 5 や ・−− 4 ろ ・−・− 4

5.1.5

考察

まず,入力速度について考察する.表5.3, 5.4の結果から,どちらの文字列に関しても入力時間の平均は,既存 の入力方法に比べて,最低でも5倍以上長いという結果が得られた.これは,近接センサに手をかざして文字を 入力するという性質が関係していると考えられる.フリック入力は1文字を入力するために指先のみの動きで すむのに対し,近接モールスIMEは手を動かすというより大きな動作が必要になるためである. また,近接モールスIMEでは1文字入力する際も,長いモールス符号を入力しなければならない. そのため, 表5.8の結果が得られ,既存の入力方法と比べて1文字あたりの入力時間が約10倍になっていると考えられる. さらに,文字列1と文字列2の1文字あたりの入力時間を比較する.近接モールスIMEのp値は0.10であり, 有意差はなかった.しかし,すべての被験者において明らかに文字列2より文字列1の方が1文字あたりの入 力時間は大きくなっている.これは,以下の3つの理由が考えられる. • 文字列1の方が文字列2に比べて平均符号数が多く, 1文字入力するためにより多くの符号を入力する 必要があった. • 入力する文字列が長くなるほど手を動かすことによる疲労が蓄積し,操作速度が落ちやすくなる.

(28)

第5章 評価実験 27 • 実験は文字列1を5回入力した後に文字列2を5回入力する,という順序で行ったため,文字列2の方 が入力に慣れていた. 次に,誤入力について考察する.表5.6, 5.7の結果から,「へ(・)」や「い(・ −)」のように短いモールス符 号で入力ができる文字は誤入力回数が少なく,「ん(・ − ・ − ・)」や「き(− ・ − ・ ・)」のように長い モールス符号での入力が必要な文字は誤入力回数が多くなることがわかった.また,これらに共通する要因とし て,符号が長いという点もあるが,「トン」と「ツー」が交互に繰り返されているものほど誤入力回数は増加傾 向にあると考えられる.  しかし,「だ(− ・)」のように短いモールス符号での入力が可能であるのにもかかわらず,誤入力回数が多 いという結果が得られたものもあった.これは表5.9の結果から,「た」を入力する際に以下の2つの事象が発 生したためだと考えられる. • 始めの「ツー」が認識された後に,次に手をかざすまでの時間が空いてしまい,「ツー」のみの入力だと 認識された結果「む(−)」が入力された. • 始めの「ツー」を入力しようとしたが手をかざす時間が短く「トン」が入力される.誤入力に気づいた が, 2つ目の「トン」を入力するために手をかざし始めていたため,「ツー」が入力される.その直後に削 除をするために手をかざしたが,かざす時間が短かったため「ツー」が入力された結果「や(・ − −)」 が入力された.

5.2

実験

2

:近接ショートカットアプリの使用感について

5.2.1

目的

近接ショートカットアプリの目的は,周辺環境からの影響が小さくいアプリケーションの起動や, Webページ ヘのジャンプなどの動作をスムーズに行うことが可能なシステムの作成である.本システムの評価実験では,日 常での使用を想定し,入力しづらい符号列の組み合わせを調べ,実際に使ってみた時のアプリケーションとして の使用感などの感想も集計する.

5.2.2

被験者・目的

評価実験は,本学の学生8名に協力してもらい行った.実験は本研究室の一室で行い,使用したスマートフォ

ンはSoftBank AQUOS Phone 104SHである.被験者には本実験に入る前に,操作になれるための練習時間を10

分とり,自由に操作してもらった.

5.2.3

実験内容

システムにはあらかじめ表5.10に示す符号列とショートカット先を登録してある.実験では本システムを用 いて以下の順序でスマートフォンの操作を行ってもらった.以下の順序を1周とし,同様の操作を5周行っても らい,上手く動作できなかった符号列をカウントする. 終了後,被験者には表5.11のアンケートに回答しても らった. 1. Webページヘのジャンプ

(29)

第5章 評価実験 28 2. HOMEキーの作動 3. アプリケーション1の起動 4. アプリケーション2の起動 5. HOMEキーの作動 表5.10:登録済みの符号列とショートカット先 ショートカット先 符号列 Webページヘのジャンプ ・ ・ HOMEキー ・ − アプリケーション1 − ・ アプリケーション2 − − 表5.11:アンケート内容 質問番号 回答方法 質問内容 1 選択式 思った通りの操作ができた 2 選択式 操作中の画面は見やすかった 3 選択式 周辺環境の影響が少ない 4 選択式 システム全体として使いやすい 5 記述式 自由記述(良かった点・悪かった点・その他) 選択式のアンケートは5段階リッカート尺度を採用

5.2.4

結果

表5.12に符号列の組み合わせごとの誤入力回数を,表5.13,図5.1にアンケートの結果を示す. 表5.12:符号列の組み合わせごとの誤入力回数 符号列 誤入力回数 ・ ・ 3回 ・ − 20回 − ・ 6回 − − 11回 また,以下に設問5の自由記述で得られた意見を示す. • トンはやりやすいが,ツーの長さの基準がつかめなかった • 手が少し疲れた • 一度ハマってしまうと動作の修正が行いにくいように感じた

(30)

第5章 評価実験 29 表5.13:アンケート結果(1:そう思わない, 5:そう思う) 質問番号 質問内容 平均回答 標本分散 1 思った通りの操作ができた 3.6 0.23 2 操作中の画面は見やすかった 4.5 0.50 3 周辺環境の影響が少ない 3.8 0.94 4 システム全体として使いやすい 3.5 0.25 • トンとツーが含まれるパターンでは,しきい値ではなく2つの入力の長さをクラスタリングで決めては どうか • 登録アプリが増えると操作性が落ちそう • 安定しない場所での使用は少し難しいかもしれない • 慣れれば切り替えはかなり速くできそう • 誤爆が心配 • 自分がどんな入力をしているのか確認できると良いと思った • 思ったより間違えず入力できたが,長短混ざる入力は誤入力をしたので,しきい値を自分で設定できると 良いと思った • 最初は慣れずにミスが多かったが,後半はミスが無く,慣れが大切だと感じた • 連続して使用し続けた際,手がつかれた • トンとツーの感覚をつかめば,便利になるだろうとは感じた 1 2 3 4 5 0 1 2 3 4 5 6 1 の回答 評価値[ 点 ] 選 択 人 数 [ 人 ] 1 2 3 4 5 0 1 2 3 4 5 6 2 の回答 評価値[ 点 ] 選 択 人 数 [人 ] 1 2 3 4 5 0 1 2 3 4 5 6 3 の回答 評価値[ 点 ] 選 択 人 数 [人 ] 1 2 3 4 5 0 1 2 3 4 5 6 4 の回答 評価値[ 点 ] 選 択 人 数 [人 ] 図5.1:回答の分布

(31)

第5章 評価実験 30

5.2.5

考察

まず,近接ショートカットアプリの有用性について考察する.表5.13によると,本システムは周辺環境の影響 が少なくスマートフォンを操作することができると感じている被験者が大半であった.自由記述の結果を見る と,実験前半に比べて後半では操作に慣れたことにより,誤動作が減ったと感じている被験者も多く,日常的に 本システムを使用して慣れていくことで,よりスムーズに操作を行うことができるようになるのではないかと 考えられる. 次に,入力しづらい符号列の組み合わせについて考察する.表5.12から, 2つ目の符号に「ツー」が入力され る組み合わせは誤入力回数が多いことがわかった.これは, 1つ目の符号は入力前に落ち着く時間が十分にある のに対し, 2つ目の符号は入力までに余裕がない点と,「トン」は手をかざしてすぐ離せば良いが,「ツー」は一 定時間かざし続ける必要があり,感覚が掴みづらかった点が影響しているものと考えられる. 以上のことから,手をかざしている際のフィードバックが無い点や,しきい値は既定値で固定されていたこと から,「トン」と「ツー」の区別がしづらいという意見も多く,本システムの改善すべき点も明らかになった.

(32)

31

6

章 結論

6.1

結論

本研究では,周辺環境からの影響の少ない操作として,近接センサを用いた操作を提案し,近接モールスIME と近接ショートカットアプリを実装した. 評価実験の結果,操作速度などに関して改善点も多く見つかったが,周辺環境からの影響が少ない操作方法と しては一定の成果が得られた.また,提案手法は今までに試したことがない方法であったため,既存の方法と比 べて慣れるための時間が短く,日常的に使用することによって改善されていく可能性がある.今後,以下に挙げ る点を改善することによって,より良い結果を得られる可能性がある.

6.2

今後の課題

6.2.1

入力のフィードバック

評価実験では,入力に対してのフィードバックが少なく,入力している符号がわかりづらいという意見が寄せ られた.入力中の符号の表示方法などを工夫し,操作の妨げにならないように配慮しつつ,わかりやすいフィー ドバックを示す必要がある.

6.2.2

しきい値の変更

「トン」と「ツー」を判別する「しきい値」は,ユーザが任意で設定することができず,近接モールスIMEで は入力に使われたログから自動的に算出し,近接ショートカットアプリでは固定値であった.これは入力に慣れ ていないうちは誤入力を誘発しやすく,慣れてくると素早い動作の妨げになると考えられる. よって,入力された符号同士の長さを比べて判別する,ユーザが任意で設定できるようにする,といった改善 をする余地があると考えられる.

(33)

32

謝辞

本研究は,電気通信大学 情報理工学部 情報・通信工学科 コンピュータサイエンスコースの寺田研究室におい て,寺田 実准教授のご指導のもと行われました. 寺田 実准教授には,本研究の方針やアイディア,卒業論文の書き方など様々な部分でご指導頂きました.心から 感謝を申し上げます. また,寺田研究室の海老沢 雄太さん,長利 槙吾さん,齊藤 令さん,阿部 真之さん,鈴木 佑樹さん,平田 吉久さん, 本田 裕人さん,安倍 文紀さん,布川 大地さん,山本 愛美さん,渡邊 裕貴さんにはさまざまな研究のアイディアや アドバイスを頂き,また研究室での生活など数多くの面でお世話になりました.心からの感謝を申し上げます. 最後になりましたが,お忙しい中評価実験に協力していただきました皆様に,深く感謝致します.

(34)

33

参考文献

[1] 総務省, “平成26年版情報通信白書”,第3節インターネットの利用動向, 2014. [2] 長谷川達人,越野亮,木村春彦, “Androidスマートフォンにおける近接センサによる画面ロック手法の開発”, 情報処理学会論文誌vol.54(12), pp.2513-2517, (2013). [3] 井上育美,棟方渚, RafalRzepka,荒木健治, “3指を用いたタッチパネル入力の評価と考察について”,電子情 報通信学会技術研究報告vol.114 num.73, pp.63-70, (2014). [4] 樋口政和,小室孝, “高速趣旨動作認識による携帯端末向け多指ARタイピングインタフェース”,情報処理学 会インタラクション2015, pp.520-525, (2015).

参照

関連したドキュメント

本節では本研究で実際にスレッドのトレースを行うた めに用いた Linux ftrace 及び ftrace を利用する Android Systrace について説明する.. 2.1

Instagram 等 Flickr 以外にも多くの画像共有サイトがあるにも 関わらず, Flickr を利用する研究が多いことには, 大きく分けて 2

【通常のぞうきんの様子】

6-4 LIFEの画面がInternet Exproler(IE)で開かれるが、Edgeで利用したい 6-5 Windows 7でLIFEを利用したい..

パキロビッドパックを処方入力の上、 F8特殊指示 →「(治)」 の列に 「1:する」 を入力して F9更新 を押下してください。.. 備考欄に「治」と登録されます。

※ 本欄を入力して報告すること により、 「項番 14 」のマスター B/L番号の積荷情報との関

※2 Y zone のうち黄色点線内は、濃縮塩水等を取り扱う作業など汚染を伴う作業を対象とし、パトロールや作業計 画時の現場調査などは、G zone

★分割によりその調査手法や評価が全体を対象とした 場合と変わることがないように調査計画を立案する必要 がある。..