Laboratory)」による共同研究(ファーストオーサーは前者の研究室)。ユビキタスコンピューティングカンファレンスUbiCompで2016年に発表された論文。論文タイトルを直訳すると「身の回りのシステムにおける、モデルベースUI開発と認知モデリングの組み合わせによるユーザーエラーの予測」といった感じ。「身の回りのシステム」というのは例えば「レシピ検索システム」のような、ふだんの生活の中で使うシステムのこと。「ユーザーエラー」は「そのシステムの使用中にユーザーが起こす間違い」という意味合い。「モデルベースUI開発」と「認知モデリング」については後述。研究の目的としては単純で、下記2点である。どちらも実現できれば非常に有意義なものである。・リリース後に起こりうるユーザーエラーを開発の早期段階で予測することでUIの品質を高める・その予測を自動化することで、開発にかかる時間、費用面でのコストを下げるということで読み始めたのだけど、なかなか理解できない。いうのも、「モデルベースUI開発」の「認知モデリング」の組み合わせに関する論文なのに、それぞれに関する基礎知識が自分になさすぎるのだ。そのため、それぞれに関して論文に出てくる用語等をまとめるのをこの記事の主題にする。研究自体の理解をまとめるのは次にまわす。モデルベースUI開発まず「モデルベースUI」という用語自体に馴染みがなかったので基本的なところから調べようと思い、W3Cの文章を読んで下のポストにまとめた。UI」という階層構造のフレームワークが一般的である。Workbenchと呼ばれるものである。Testing」と題された文章で「汎用ユーザーシミュレーションフレームワーク」と説明されている。Workbenchでは「必ずしも専門家とは限らないターゲットユーザーの、現実的にありえる操作の誤りを含めた、ユーザーからどのようにそのUIが評価されるのか」をシミュレーションすることができるらしい。具体的にどのようにシミュレーションを行うのかがわからないので、気が向いたらそちらの文章も読むかもしれない。Workbench」を組み合わせるのが本論文の方式らしい。Workbenchの評価に必要なUIモックアップはCAMELEONで言うところのFUIだが、その代わりにCAMELEONで定義されるAUIを用いることで、UI設計のより前工程で評価を行うことができる。error」とに分類している。・ミステーク:知識ベースとも呼ばれるが、そもそもやろうとしていたことそのものが間違っているパターン。omission)するパターン。スリップと似ているが、記憶に基づいているエラーとのことなので、どちらかというとラプスに近いっぽい。ヒューマンエラーの分類を知らずして安全を実現できるのかヒューマンエラーの分類や種類について、わかりやすく解説しています。ヒューマンエラーの要因には発生要因と人的要因とがありますresilient-medical.com本論では手続きエラー、特に省略に焦点を当てているが、それは省略エラーがもっともUIに起因して起きやすいためである。Theory手続きエラーを説明するためには、そもそも「正しい振る舞い」を記述する必要が出てくる。Theory(MFG理論)である。プライミング」が発生するとしている。activation:我々の頭の中に蓄えられている知識の総体のことをスキーマと呼ぶ。その中から、今から行おうとする行為の目的に関連するスキーマを活性化させることで、その行為に関する記憶を正しく引き出すことができる。洗濯物を畳みたいときは、洗濯物の畳み方に関するスキーマを活性化させる必要がある。Interference)とも呼ばれる。異なる複数の刺激を受けてしまうと意識をそちらに持っていかれてしまい、ステップの実施に悪影響を及ぼす。MFG理論では「実施したい目的に関するスキーマの活性化が干渉の度合いを下回ってしまうとエラーが発生する」としている。このひとつの例がストループ効果とされる。priming)とも呼ばれ、「先行の学習もしくは記憶課題が、後続の別の学習もしくは記憶課題の成績に、無意識的に影響を与えること」とされている。連想ゲームをする前に車に関する話をしていると、「赤」という言葉から「信号」「スポーツカー」といった車に関する言葉を連想しやすいらしい。model」と呼ばれている。何かの行為をする際の目的が人間の記憶にどのように保存され、そしてどのように取り出して実際に行動に移されるかについての理論である、という理解。これも気が向いたら読んでみる。タスク指向ステップ、デバイス指向ステップ手続きエラーによくあるのは完了後エラー(コピー機でコピーして原本を取り忘れるなど)と初期化エラー(文字をタイピングする前にCapsLockを外し忘れるなど)である。これらに共通しているのは、ユーザーの目的に直接貢献していないステップで生じているということである。コピー機ではコピーを取ることが目的であって、原本を回収すること自体は直接目的とは関係がないし、入力したい文字をタイピングしたいときにCapsLockは余計なステップである。これらはいずれも目的の達成には直接関係がなく、ただその行為を行うデバイスの都合上行わなくてはならないステップであり、本論文ではそうしたステップをデバイス指向ステップと呼んでいる。逆に、目的の達成に直接寄与するステップのことをタスク指向ステップと呼んでいる。ユーザビリティの評価、特に自動ツールによる評価においてはデバイス指向ステップがしばしば見落とされがちだとされている。人間には目的を達成するためのステップがタスク指向なのかデバイス指向なのかは比較的簡単に理解できるが、ツールにはそれを理解することが難しいからである。ユーザーの目的は何で、それをタスク指向とデバイス指向に分類できるほどに細かくしていき、さらにそれぞれのステップに対応するUIを判断する、ということができない、というのが本論の課題感のひとつでもある。まとめというのが、この論文を読むにあたっての前提知識であるっぽい。それぞれを完全に理解した、とは言えないが、そもそもこのあたりを調べておかないとこの研究が何をしようとしている研究なのかがまったくわからない...というわけで、研究の内容自体はまたまとめなおす、はず。ダウンロード#UIこの記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。サポートをする「スキ」を押してクリエイターを応援しよう!23toofuWebサービスのIA、UI。誰の役にも立たない文章を書くのが好きです。Interfaces"この記事が入っているマガジンUIの論文などを読むユーザーインターフェースの設計などに関する論文を読んで感想を書く。クリエイターへのお問合せnoteカイゼン目安箱クリエイターの。