JP6015719B2

JP6015719B2 - ユーザインタフェース評価装置およびユーザインタフェース評価方法

Info

Publication number: JP6015719B2
Application number: JP2014148912A
Authority: JP
Inventors: 光古賀; 政登藤井; 元裕中村; 山崎　誠; 誠山崎
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2014-07-22
Filing date: 2014-07-22
Publication date: 2016-10-26
Anticipated expiration: 2034-07-22
Also published as: US10365801B2; WO2016013407A1; JP2016024666A; US20170160893A1; EP3173917A1; EP3173917A4

Description

本発明は、ソフトウェアのユーザインタフェースを評価する装置に関する。

近年、車両に搭載されたコンピュータ（車載端末）上で動作するソフトウェアが数多く開発されている。車載端末上で、経路案内アプリケーションや、メディアプレーヤアプリケーションといった様々なアプリケーションを動作させることで、移動中に情報を収集したり、娯楽を提供したりといったことが可能になる。

一方、車載端末の画面は、運転しながら視認する可能性があるため、当該画面に出力されるＧＵＩは、運転の妨げにならないような（すなわち、集中力を低下させないような）デザインであることが好ましい。具体的な内容については、例えば、米国運輸省道路交通***（ＮＨＴＳＡ）の「Driver Distraction Guidelines for In-Vehicle Electronic Devices（注意散漫対策ガイドライン）」において定義されている。

また、設計対象のＧＵＩが、所定のガイドラインに沿って設計されているかを確認するための技術として、例えば、特許文献１に記載のＧＵＩ評価装置がある。

特開平０８−２４１１９１号公報

車載端末で実行されるソフトウェアを設計するうえで特に重要なのが、一つの画面に出力された一連の情報を人が認知するために、どの程度の時間が必要か、という点である。例えば、前述したガイドラインには、「連続した視認時間が２秒を超えないこと」という基準が明記されている。

しかし、画面に表示された情報を認知するために必要な時間は、画面上に配置されたコンポーネントの配置位置や数、大きさなどによって変わるため、開発環境上で画一的に評価することができない。すなわち、設計したＧＵＩが前記ガイドラインを満たしているか否かは、実機でテストを行ってみるまではわからないという課題がある。

本発明は上記の課題を考慮してなされたものであり、対象のソフトウェアについて、当該ソフトウェアが出力する画面の表示内容を人が認知するために必要なリソースが、所定の要件を満たしているかを推定するユーザインタフェース評価装置を提供することを目的とする。

上記課題を解決するために、本発明に係るユーザインタフェース評価装置は、
対象のソフトウェアが出力する画面の表示内容を人が認知するために必要なリソースが、所定の基準を満たすかを評価するユーザインタフェース評価装置であって、前記ソフトウェアのユーザインタフェース画面上に配置された複数のコンポーネントに関する情報を取得する設計情報取得手段と、前記コンポーネントをそれぞれ認知するために必要なリソースである部品認知リソースを、コンポーネントごとに取得する部品認知リソース取得手段と、前記取得した部品認知リソースの合計を確率変数とし、確率密度関数を用いて、前
記ユーザインタフェース画面に出力された情報を認知するために必要なリソースである必要認知リソースが、所定の基準を満たす確率である適合確率を算出する適合確率推定手段と、を有することを特徴とする。

設計情報取得手段は、対象ソフトウェアのユーザインタフェース画面上に配置されたコンポーネントに関する情報を取得する手段である。コンポーネントとは、例えば、ラベル、リストボックス、ボタン等といった、情報の入出力を行うための部品である。ユーザインタフェース画面上に配置されるものであれば、対象はどのようなものであってもよい。
また、部品認知リソース取得手段は、前述した各コンポーネントを認知するために必要なリソース（部品認知リソース）を取得する手段である。認知とは、当該コンポーネントを視認してその内容を把握することを指す。部品認知リソースは、例えば時間で表すことができる。

また、適合確率推定手段は、取得した部品認知リソースの合計値に基づいて、画面全体を認知するために必要なリソースが、所定の基準（例えばガイドラインで定められた時間）を満たす確率を算出する手段である。前述したように、画面全体を認知するために必要なリソースは、画面のデザインや内容によって変わるため、基準に適合するか否かを装置が評価することは極めて困難である。そこで、本発明に係るユーザインタフェース評価装置は、部品認知リソースの合計値を確率変数とし、確率密度関数を用いて、基準に適合するかどうかの目安となる確率値を算出する。
かかる構成によると、対象のソフトウェアが出力するインタフェース画面全体を認知するためのリソースが、所定の基準を満たしているかを、簡便な処理で推定することができる。

なお、前記確率密度関数がとる確率分布は、前記所定の基準に対応する値を中央値とする正規分布であることを特徴としてもよい。このようにすることで、適合確率をより精度良く算出することができる。

また、前記適合確率推定手段は、前記確率分布の標準偏差を、評価対象のソフトウェアに応じて設定することを特徴としてもよい。
推定に用いる確率分布の標準偏差は、対象のソフトウェアの特性に応じて選択するようにしてもよい。例えば、ソフトウェアのカテゴリごとに（例えば、ジャンルや種別、特徴ごとに）異なる値を用いるようにしてもよい。ソフトウェアごとに異なる基準を用いることで、より精度の良い推定を行うことができる。

また、前記部品認知リソースおよび必要認知リソースは、対象を人が認知するために必要な時間であることを特徴としてもよい。
本発明は、画面に表示された情報をユーザが認知するために必要な時間が、所定の基準を満たしているかを評価する装置に好適に適用することができる。

本発明は、上記処理の少なくとも一部を含む、ユーザインタフェース評価装置として特定することもできる。また、ユーザインタフェース評価装置が実行するユーザインタフェース評価方法として特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

本発明によれば、対象のソフトウェアについて、当該ソフトウェアが出力する画面の表示内容を人が認知するために必要なリソースが、所定の要件を満たしているかを推定するユーザインタフェース評価装置を提供することができる。

第一の実施形態に係るソフトウェア作成装置の構成図である。第一の実施形態におけるユーザインタフェース画面の例である。第一の実施形態におけるリソースデータの例である。部品認知リソースの合計を算出する例である。第一の実施形態における確率密度関数の例である。第一の実施形態における結果表示画面の例である。第一の実施形態における処理フローチャートである。第二の実施形態における確率密度関数の例である。

（第一の実施形態）
<システム構成>
第一の実施形態に係るユーザインタフェース評価装置は、車載端末２００上で動作するソフトウェアを作成する機能と、当該ソフトウェアが有するユーザインタフェースを評価する機能を有する装置（ソフトウェア作成装置１００）である。図１を参照しながら、第一の実施形態に係るソフトウェア作成装置１００について説明する。
ソフトウェア作成装置１００は、プロセッサ、主記憶装置、補助記憶装置を有するコンピュータであり、補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、プロセッサによって実行されることによって、後述する各手段が機能する（プロセッサ、主記憶装置、補助記憶装置はいずれも不図示）。

車載端末２００は、ソフトウェア開発のターゲットデバイスであり、車両に搭載される車載型のコンピュータである。車載端末２００は、ディスプレイ３００を有しており、当該ディスプレイに、ソフトウェアの実行画面を出力することができる。

次に、ソフトウェア作成装置１００について説明する。ソフトウェア作成装置１００は、入出力部１０１、設計部１０２、記憶部１０３、リソース情報保持部１０４、評価部１０５、コード生成部１０６からなる。

入出力部１０１は、ユーザが行った入力操作を受け付け、ユーザに対して情報を提示する手段である。具体的には、液晶ディスプレイ、キーボード、マウス等とその制御手段から構成される。

設計部１０２は、ソフトウェアの設計を行う手段である。具体的には、ソフトウェアの設計を行うための画面（例えばコードエディタや画面エディタ）を、入出力部１０１を通してソフトウェア開発者に提示し、当該開発者によって入力されたソフトウェアの設計データを取得する。ソフトウェアの設計データとは、ユーザインタフェース画面の設計データ（以下、ＧＵＩ設計データ）と、ロジックに関する設計データである。

ＧＵＩ設計データとは、開発対象のソフトウェアが有するユーザインタフェース画面（以下、フォーム）上に配置された部品（以下、コンポーネント）の配置を表すデータである。図２に、コンポーネントの配置例を示す。本例は、複数のラベル（文字領域）、ボタン、イメージ等をそれぞれフォーム２０１上に配置した例である。なお、本例では、コンポーネントとしてラベル、ボタン、イメージを例示したが、画面上に配置されるものであれば、コンポーネントはどのようなものであってもよい。例えば、リストボックス、セレクトボックス、チェックボックス等であってもよい。
ソフトウェアの開発者は、設計部１０２が生成したエディタ画面を通して、フォーム上にコンポーネントの配置を行う。また同様に、設計部１０２が生成したエディタ画面を通して、ロジックのコーディングを行う。

ソフトウェアが実行される際は、このようにフォーム上に配置されたコンポーネントが、設計されたロジックに従って動作する。設計部１０２が取得した設計データは、例えば、コードが記述されたテキストファイルや、画面デザインを表すＸＭＬファイルによって、記憶部１０３に一時的に記憶される。

記憶部１０３は、ソフトウェアの設計に関するデータを一時的に記憶する手段である。記憶部１０３には、高速に読み書きでき、かつ、大容量な記憶媒体を用いることが好ましい。例えば、フラッシュメモリなどを好適に用いることができる。

リソース情報保持部１０４は、フォーム上に配置されるコンポーネントを、ユーザが視覚によって認知するために必要なリソースについての情報を保持する手段である。より詳しくは、対象のコンポーネントを認知、すなわち内容を把握するために必要な時間を、「部品認知リソース」として、コンポーネントのクラスごとに事前に記憶する。
図３は、コンポーネントのクラス名と、部品認知リソース（秒単位）を表形式で対応付けたデータ（リソースデータ）の例である。なお、図３の「部品認知リソース」フィールドに例示した文字列は定数であり、例えば、「Ｒ＿Ｔａｂ＝０．１[秒]」といったように、数値が割り当てられている。

評価部１０５は、設計部１０２が取得したＧＵＩ設計データと、リソース情報保持部１０４が記憶しているリソースデータに基づいて、設計中のソフトウェアのユーザインタフェース画面が、所定の基準に適合する確率を算出する手段である。所定の基準の内容、および具体的な演算方法については後述する。

コード生成部１０６は、設計部１０２が取得したソフトウェアの設計データ（コード）に基づいて、実行形式のプログラムをビルド（生成）する手段である。ビルドされたプログラムは、配布形式のソフトウェアパッケージとして最終的に出力される。なお、コード生成部１０６は、有線接続または無線接続によって、当該ソフトウェアパッケージを車載端末２００に転送する機能を有していてもよい。

<インタフェースの評価方法>
次に、設計対象のソフトウェアが満たすべき基準について説明する。本実施形態における基準とは、フォームをディスプレイ３００に表示した場合に、当該フォームを見たユーザ（例えば車両の運転者）が、その内容を認知するのにかかる時間に関する基準（以下、認知基準）である。第一の実施形態では、認知基準として、「２．０秒以下」という値を用いる。この値は、認知心理実験等に基づいて決定された値である。
なお、「画面全体を認知する」とは、表示されている全ての情報をユーザが認識する必要はなく、当該画面において伝達すべき情報を最低限認識したことをもって足りる。例えば、対象が音楽プレーヤの楽曲選択画面である場合、曲名・アルバム名・アーティスト名を全て正確に把握する必要はなく、どの楽曲が表示されているかをユーザが認識できればよい。

画面に表示された情報を認知するための時間は、当該画面に配置された複数のコンポーネントをそれぞれ認知するための時間を求め、合計すれば求まるようにも思える。しかし、ユーザは、表示されたコンポーネントを一つずつ順に視認することはしないため、単純な合計値を用いただけでは、ソフトウェアが認知基準に適合しているかどうかを判断することができない。

例えば、画面上に配置されたコンポーネントを全て認知するのに合計５秒程度かかる場合であっても、ユーザにとって必要な情報が画面の中央にあり、重要でない情報が画面の
周辺部にあるような場合は、画面に表示された情報を２秒以内で認知できる場合がある。
また、反対に、配置されたコンポーネントをそれぞれ認知するための時間の合計が２秒以内である場合であっても、画面のデザインによっては、画面に表示された情報を２秒以内で認知できない場合がある。例えば、重要な情報がそれぞれ離れた位置に表示されており、複雑な視線の移動を必要とする場合などである。

そこで、本実施形態に係るソフトウェア作成装置は、フォーム上に配置されたコンポーネントをそれぞれ認知するのにかかる時間を定義し、その合計値に基づいて、対象のソフトウェアが前述した認知基準に適合する確率を数値で出力する。

第一の実施形態では、対象のソフトウェアが認知基準に適合する確率を、以下のステップを実行することによって求める。

（１）各コンポーネントを認知するのに必要な時間の取得
まず、対象のソフトウェアが有するフォームに配置された複数のコンポーネントを特定し、リソースデータを参照して、当該複数のコンポーネントを認知するために必要なリソースの合計値を取得する。本例では、図４に示したように、１８個のコンポーネントがフォーム上に配置されており、当該１８個のコンポーネントの、部品認知リソースの合計（以下、合計認知リソース）が２．５秒であったものとする。

（２）確率密度関数を用いた確率演算
次に、算出した合計認知リソースと、確率密度関数を用いて確率を演算する。本実施形態で用いる確率密度関数が有する確率分布は、図５に示したような正規分布である。なお、横軸は時間であり、その中央値は、認知基準に対応する時間（すなわち２．０[秒]）である。
そして、合計認知リソースを確率変数とした場合における推定確率Ｐを取得する。推定確率Ｐは、式１によって得ることができる。なお、Ｒは合計認知リソース [秒]、Ｓは確
率分布の中央値（２．０[秒]）である。なお、本実施形態では、σ＝１とする。

前述した条件によって推定確率Ｐを算出すると、０．３０８５…という値が得られる。すなわち、対象のソフトウェアが有するユーザインタフェース画面が、「２．０秒以内に画面全体を認知できる」という認知基準に適合する確率は、約３１％となる。

本実施形態に係るソフトウェア作成装置では、このように、配置されたコンポーネントを認知するために必要なリソースと、確率密度関数を用いることで、画面全体を認知するために必要な時間が基準に適合する確率を演算する。
算出した適合確率は、入出力部１０１を通してソフトウェア開発者に提示される。例えば、図６のようにダイアログによって出力してもよいし、コンソール画面に出力してもよい。また、ログに出力してもよい。

<処理フローチャート>
次に、以上に説明した機能を実現するための処理フローチャートについて説明する。
図７は、本実施形態に係るソフトウェア作成装置が行う評価処理のフローチャートである。当該処理は、ユーザの指示に基づいて（例えば、開発環境においてチェック機能を起動したタイミングで）、評価部１０５によって実行される。

まず、ステップＳ１１で、設計部１０２によって取得されたＧＵＩ設計データを取得する。
次に、ステップＳ１２で、リソース情報保持部１０４に記憶されたリソースデータを取得し、記憶されたＧＵＩ設計データと照合して、配置されている複数のコンポーネントに対応する部品認知リソースを取得する。続いて、ステップＳ１３で、取得した部品認知リソースを合計し、合計認知リソースを取得する。
次に、ステップＳ１４で、確率密度関数と合計認知リソースを用いて、前述した方法によって、認知基準に対する適合確率を算出する。結果は、ステップＳ１５にてユーザに提示される。

以上に説明したように、第一の実施形態によると、ソフトウェアを開発するための開発環境上で、当該ソフトウェアが、認知基準に対してどの程度適合するかを推定することができる。すなわち、実機上でのテストを行わずとも、認知基準との適合度合いを判断することができるため、実機テストでの不合格に伴う差し戻し等といったような、無駄な工数を削減することができる。

（第二の実施形態）
第一の実施形態では、標準偏差σを１とする正規分布を用いて、認知基準に対する適合確率を算出した。しかし、適合確率を算出するのに最適な標準偏差は常に１であるとは限らない。図８は、標準偏差が１以外の場合における確率分布を説明する図である。例えば、ソフトウェアの特性によっては、部品認知リソースの合計値が基準値（例えば２．０秒）を大きく外れていても、実際は認知基準を満たしている場合がある。このような場合、σ＝０．５のケースのように、確率密度関数は偏平になる。また、逆の場合、σ＝１．５のケースのように、確率密度関数は突出した形状になる。
第二の実施形態は、このようなケースに対応するため、対象となるソフトウェアに応じて、用いる標準偏差σの値を決定する実施形態である。

第二の実施形態に係るソフトウェア作成装置の構成は、第一の実施形態と同様であるため説明は省略し、処理が異なる部分についてのみ説明を行う。
第二の実施形態では、ステップＳ１４において、式１におけるσを決定する処理が追加される。σは、例えば、対象のソフトウェアのカテゴリごとに、蓄積された実測値（画面全体を実際に認知するのにかかった時間についての試験データ）に基づいて決定される。
例えば、最も推定精度が良くなるσをソフトウェアのカテゴリごとに求め、プリセットデータとして記憶してもよいし、実測値そのものを記憶させ、ソフトウェアの属するカテゴリにおいて、最も推定精度が良くなるσをその都度決定するようにしてもよい。
なお、ソフトウェアのカテゴリとは、ソフトウェアを分類した結果であれば、どのようなものであってもよい。例えば、ソフトウェアのジャンルであってもよいし、フォーム上におけるコンポーネントの数や配置に基づいて分類された結果であってもよい。

第二の実施形態によると、推定確率の算出に用いる標準偏差をソフトウェアのカテゴリごとに決定することで、より精度の高い推定結果を得ることができる。

（変形例）
なお、各実施形態の説明は本発明を説明する上での例示であり、本発明は、発明の趣旨を逸脱しない範囲で適宜変更または組み合わせて実施することができる。
例えば、各実施形態では、確率分布が正規分布である関数を用いたが、正規分布以外の分布を用いてもよい。

１００ソフトウェア作成装置
１０１入出力部
１０２設計部
１０３記憶部
１０４リソース情報保持部
１０５評価部
１０６コード生成部
２００車載端末
３００ディスプレイ

Claims

対象のソフトウェアが出力する画面の表示内容を人が認知するために必要なリソースが、所定の基準を満たすかを評価するユーザインタフェース評価装置であって、
前記ソフトウェアのユーザインタフェース画面上に配置された複数のコンポーネントに関する情報を取得する設計情報取得手段と、
前記コンポーネントをそれぞれ認知するために必要なリソースである部品認知リソースを、コンポーネントごとに取得する部品認知リソース取得手段と、
前記取得した部品認知リソースの合計を確率変数とし、確率密度関数を用いて、前記ユーザインタフェース画面に出力された情報を認知するために必要なリソースである必要認知リソースが、所定の基準を満たす確率である適合確率を算出する適合確率推定手段と、
を有する、ユーザインタフェース評価装置。
前記確率密度関数がとる確率分布は、前記所定の基準に対応する値を中央値とする正規分布である、
請求項１に記載のユーザインタフェース評価装置。
前記適合確率推定手段は、前記確率分布の標準偏差を、評価対象のソフトウェアに応じて設定する、
請求項２に記載のユーザインタフェース評価装置。
前記部品認知リソースおよび必要認知リソースは、対象を人が認知するために必要な時間である、
請求項１から３のいずれかに記載のユーザインタフェース評価装置。
対象のソフトウェアが出力する画面の表示内容を人が認知するために必要なリソースが、所定の基準を満たすかを評価するユーザインタフェース評価装置が行うユーザインタフェース評価方法であって、
前記ソフトウェアのユーザインタフェース画面上に配置された複数のコンポーネントに関する情報を取得する設計情報取得ステップと、
前記コンポーネントをそれぞれ認知するために必要なリソースである部品認知リソースを、コンポーネントごとに取得する部品認知リソース取得ステップと、
前記取得した部品認知リソースの合計を確率変数とし、確率密度関数を用いて、前記ユーザインタフェース画面に出力された情報を認知するために必要なリソースである必要認知リソースが、所定の基準を満たす確率である適合確率を算出する適合確率推定ステップと、
を含む、ユーザインタフェース評価方法。
請求項５に記載のユーザインタフェース評価方法の各ステップをコンピュータに実行させるプログラム。