旅行好きなソフトエンジニアの備忘録

プログラミングや技術関連のメモを始めました

【Docker】 Docker Quick Start Terminal起動時のエラー(Looks like something went wrong)のメモ

Dockerコンテナ内のUbuntuからapt-get出来なくなったので、「とりあえずDocker再インストールするか」と思い再インストール後にDocker Quick Start Terminalを起動しようとすると、表題のエラーが出て起動すらできなくなりました。何度Docker Toolboxをアンインストール⇒インストールしても同様のエラーが出たのですが、調べてみるとC:\ユーザー\ユーザー名\に.dockerというフォルダが残っていました。これを削除してDocker Toolboxを再インストールするとTerminalを起動できるようになりました。

【Docker】 Docker Quick Start Terminal起動時のエラー(Looks like something went wrong)のメモ

Dockerコンテナ内のUbuntuからapt-get出来なくなったので、「とりあえずDocker再インストールするか」と思い再インストール後にDocker Quick Start Terminalを起動しようとすると、表題のエラーが出て起動すらできなくなりました。何度Docker Toolboxをアンインストール⇒インストールしても同様のエラーが出たのですが、調べてみるとC:\ユーザー\ユーザー名\に.dockerというフォルダが残っていました。これを削除してDocker Toolboxを再インストールするとTerminalを起動できるようになりました。

【Docker】基本コマンドのメモ

書籍「Docker入門」のChapter3-02で紹介されている、「まず覚えた方が良いサブコマンド」のメモです。

$ docker run イメージ名

ローカル環境に取得済みのイメージから新たなコンテナを作成して実行する。指定したイメージが無い場合、Docker Hubからイメージを取得する。コンテナ名は自動で割り当てられる

$ docker run --name="コンテナ名" イメージ名

コンテナ名を指定して実行する

$ docker run -it ubuntu:14.04 /bin/bash

Ubuntuイメージを取得してコンテナを実行する典型的なコマンド。-itはシェルのような対話的なプログラムをコンテナ内で稼働させる場合に必要なオプション。/bin/bashBashシェルを実行するという意味

$ docker ps -a

稼働中、停止中のコンテナを一覧表示する

$ docker stop コンテナ名

指定したコンテナを停止させる

$ docker images

ローカル環境に取得したイメージを一覧表示する

$ docker rmi イメージ名

ローカル環境に取得したイメージを削除する

$ docker rm コンテナ名

コンテナを削除する

$ docker rm $(docker ps -qa)

コンテナを全て削除する

$ docker search 文字列

イメージ名に文字列で指定した文字を含むイメージをDocker Hubから検索する

$ docker commit コンテナ名 リポジトリ名:タグ

指定したコンテナからリポジトリ名:タグというイメージを作成する

$ docker commit -a author -m "Commit test" コンテナ名 リポジトリ名:タグ

イメージを作成し、イメージの作者(=author)とメッセージ(=Commit test)を付加する

Docker入門

Docker入門

Eye Tracking The User Experienceのまとめ - Chapter11

データの可視化

グラフの種類
グラフの種類 対象 形式 データタイプ
Gaze Plot / Scanpath 個人 静止画 空間/時間
Gaze Video 個人 動画 空間/時間
Bee Swarm 個人/集計 動画 空間/時間
Heatmap 集計 静止画 空間
Focus Map / Gaze Opacity Map 集計 静止画 空間
Dynamic Heatmap 集計 動画 空間/時間
Gaze Plots / Scanpaths
  • 固視をドット、サッカードを線で表す
  • ドットの大きさで固視していた時間を表現する(固視の時間が長ければドットを大きくする)
  • ドットの中心に番号を書き、固視の順番を表現する
  • コンテンツが動的コンテンツを含む場合、逐次コンテンツを記録する必要がある
  • Gaze Plotsはユーザビリティの問題を検知したり説明するため、被験者がどのようにモニタを見ていたか、といった定性分析に主に使われる
  • 定性分析だけでなく、何回固視があったか/平均固視時間を例示するためにも時々利用される
Gaze Videos
  • 視線の動きを動的に表現する
  • テスト中にリアルタイムでGaze Videoを観察することで洞察を得ることができ、テスト終了後に被験者により深い質問ができる
  • テスト中にGaze Videoを観察することが出来ない場合でも、後からGaze Videoを見返すことで何らかの知見を得ることができるかもしれない
Bee Swarms
  • 被験者グループの固視位置を時間軸に沿って一度に小さなドットで表現する
  • 期待する視覚効果が得られているか確認するのに利用できる
  • 全ての被験者が同じコンテンツを同じタイミングで見ている必要がある
Heatmaps
  • 静的コンテンツに対する固視の頻度を色で表す
  • 個人にも適用できるが、被験者の集計データに対して適用する方が役に立つ
  • 個人、時間情報を表さないため、定性分析で利用が制限される
  • 定量分析で正確な数字を出す場合にも利用が制限される
Heatmapのタイプ
内容 制約
Fixation Count Heatmap 固視回数が多い箇所の色を赤くする。回数基準のため、100msecの固視と900msecの固視を同等に扱う 1. 同じ色でも固視時間は異なる。 2. 同じ色でも見た人数は異なる。 3. 被験者毎のテスト時間が異なる場合は、テスト時間が長い被験者に重みがかかる
Absolute Gaze Duration Heatmap 固視時間の多い箇所の色を赤くする 1. 同じ色でも見た人数は異なる。 2. 同じ色でも見た回数は異なる。 3. 被験者毎のテスト時間が異なる場合は、テスト時間が長い被験者に重みがかかる
Relative Gaze Duration Heatmap 試験時間に対する固視時間の割合の多い箇所の色を赤くする 1. 同じ色でも見た人数は異なる。 2. 同じ色でも固視回数は異なる。
Heatmapの使いどころ
  • Heatmapで概要を掴み、何を深堀すべきか仮説を立てるのに役立つ
  • 視覚に訴えるため、プレゼンに利用すると効果的。ただし、Heatmapが根拠や発見の説明に役立つ場合のみ提示すること。例えばユーザビリティの問題を説明したい時はHeatmapよりもGaze plotsの方が有用なことが多い
Heatmapの見た目の変更
  • 固視周辺のカーネルサイズを変える
  • カラースケールの上限を変える(例えば何回以上固視した場合を赤色とする等)
Heatmapの見た目を変える場合のルール
  • 統計的に重要な差異が見られる箇所が区別できるような閾値を設定すること。例えばAOI1が10回見られており、AOI2が20回見られていた場合に閾値を10と設定してしまうと、AOI1, 2共に赤く表現されてしまう
  • Heatmapを比較する場合は設定を同じにすること
  • 閾値等の設定値をHeatmapに記載すること

Eye Tracking the User Experience: A Practical Guide to Research

Eye Tracking the User Experience: A Practical Guide to Research

Eye Tracking The User Experienceのまとめ - Chapter9

テスト環境の構築

照明
  • 照明がアイトラッカーに干渉しないことを確認しておく
  • 白熱電球や太陽光は赤外光を含んでおりアイトラッカーの精度に影響を与える可能性がある
  • 窓が無い、もしくはブラインドがあり、蛍光灯が使われている部屋がベスト
干渉
  • 被験者の視界に余計な物が入らないようにする
  • 度々人が出入りするような部屋で試験を実施しない
椅子
  • 動いたり回転しない椅子を選ぶ
  • 高さ調整できる椅子を選ぶ
  • オフィスチェアは通常の椅子よりも快適なため、被験者が試験中に自分の座っている位置を変える可能性が下がり、椅子の候補として良い

パイロットテスト

本番で起こりそうなトラブルを事前検知するためパイロットテストを実施することが望ましい。パイロットテストの目的は以下の通り。

  1. アイトラッカーや付随するソフトウェアの動作を事前確認できる
  2. 試験の流れが自然かどうか、タスクの支持が明確かを事前確認できる
  3. テスト担当者が事前に本番環境に慣れることができる
アイトラッカーのセットアップ
  • アイトラッカーが瞳孔や角膜反射を検知しているか表示する機能を持っていれば、それを利用して設置位置を決める
  • 測定を阻害する要因を把握しておく
要因 問題 解決策
眼鏡 余分な反射が発生する。フレームの影が瞳孔検出の邪魔になる カメラの設置角度を変えてみる
コンタクトレンズ レンズ内の空気の泡から余分な反射光が発生する 僅かにピントをずらす
マスカラ 瞳孔の誤検出に繋がる クレンジングしてもらう
垂れたまぶた 瞳孔を隠してしまう アイトラッカーを下に移動させ、角度を付けて撮影する
キャリブレーション
  • キャリブレーションは各被験者毎に行う
  • キャリブレーション時とテスト時の環境は同じでなければならない。例えば部屋の照明だったり、アイトラッカーと被験者の位置関係等
  • もし被験者が椅子を前後に動かした(リモートタイプ)、アイトラッカーがずり下がった(装着タイプ)場合は再キャリブレーションが必要
  • キャリブレーション後は正しくキャリブレーションできているか確認すべき。例えば特定の場所を見てもらい、測定値がその付近にあるかどうか検証する
  • 複数回キャリブレーションを行っても期待した精度が得られない場合、その被験者にテストを実施しないか、キャリブレーションに問題があることを記録した上で測定を行う
  • もしキャリブレーションが上手くできなかったエリアが重要な場所でない場合、例えばモニタの中心付近の視線が取得できれば良く、モニタの端付近で精度が出ないようなケースでは、そのまま測定を行っても良いかもしれない
試験中の被験者の目の動きの観察
  • 試験中の被験者の目の動きを観察することで、測定値の消失や大きな誤差にその場で気付くことができる
  • 問題が被験者側にある場合(例えば前屈みになった、椅子に深くもたれかかった)、再キャリブレーションを行い、被験者に注意を促す必要がある
  • ただし、例えば前屈みになった理由がモニタのテキストが読み辛い等、コンテンツ側に問題がある場合は、そのデータを無かったことにするのではなく、コンテンツ側にフィードバックが必要
トラブルをログに残す
  • 「測定中ソフトウェアがクラッシュしたため測定をやり直した」等のイベントはログに残しておく

Eye Tracking the User Experience: A Practical Guide to Research

Eye Tracking the User Experience: A Practical Guide to Research

Eye Tracking The User Experienceのまとめ - Chapter10

データ分析までの手順

  1. 固視と見なす基準を決める
  2. AOIを決める
  3. 測定値を取り出す
  4. データクレンジングを行う
  5. データを分析する

固視を特定する方法

  • 位置基準と速度基準がある
  • 位置基準の場合、最大偏差(0.5~1.5°)、最小固視時間(70~100msec)を設定する
  • 速度基準の場合、最大速度(20~30°/s)、最小固視時間(70~100msec)を設定する(サッカードの最低速度が30°/sのため)
  • Holmqvistによれば速度基準を採用した方が良い。位置基準はサンプリングレート200Hz以下の装置でのみ向いている
  • 固視の基準を設定したら、比較できるようその基準を全ての被験者に適用しなければならない

AOIについて

  • AOIの最小サイズは1inch x 1inchが望ましく、更にパディングを加えることが望ましい
  • AOIにパディングを加えることでアイトラッカーの誤差を吸収できる

測定値の取り出し

  • エクセル等にデータを出力することでデータクレンジングが容易になる

データクレンジング

データの破棄を考慮しなければならないケース
  • アイトラッカーのキャリブレーションにミスがあり測定結果が信用できない
  • 視線捕捉率が一定値以下(例えば70%)
  • 測定結果に偏りが出来ている。例えばまぶたが垂れている被験者で、画面上部の視線は測定できるが、画面下部の視線が上手く測定できなかった場合、被験者は画面上部ばかり見ていると勘違いしてしまう。
  • 他の被験者と比較して特定の被験者の視線の動きが明らかに異なる場合(被験者が測定の目的を理解していない時等に発生しうる)

Eye Tracking the User Experience: A Practical Guide to Research

Eye Tracking the User Experience: A Practical Guide to Research

Eye Tracking The User Experienceのまとめ - Chapter7

データの解釈は目的と見るものに依存する

  • 「被験者がある対象物を長時間見ていた場合、それは何を意味するの?」と聞かれることがあるが、「何を何故見ていたのかによる」としか答えることができない
  • 例えば「固視が発生した回数が多かった」という観察結果が出たとして、被験者がWebページから"Contact Us"を探しているような状況であれば、"Contact Us"を見つけにくかったと考えられ、観察結果はマイナスの意味として捉えることができる。しかし、被験者がオンラインフォトアルバムを見ているような状況であれば、興味を惹く写真が多かったと考えられ、観察結果をプラスの意味として捉えることができる

UXリサーチにおける(単純化した)測定の種類

1. Attractionの測定

エリアの見やすさ、理解しやすさの測定

エリアのサイズ、位置、場所、被験者の過去の経験等が影響を与える

パラメータ例

  • あるAOIを見た被験者の割合
  • あるAOIを見るまでの固視回数
  • あるAOIを見るまでにかかった時間
エリアの興味の測定
  • あるAOIでの固視回数
  • あるAOIに滞留したトータルの時間(必ずしも滞留時間が長い=興味があるではない事に注意!単に理解に時間がかかっただけかも)
  • あるAOIを見ていた割合(被験者毎のテスト時間が異なる場合に有効)
感情の高まりの測定
  • 瞳孔径(必ずしも瞳孔径が大きい=感情が高まっているではないことに注意!部屋の明るさや精神的な作業負荷にも影響される)

2. パフォーマンス測定

作業負荷の測定
  • 瞳孔径
認識過程の測定
  • 平均固視時間
ターゲットの見つけやすさの測定
  • ターゲットを固視した被験者の割合
  • ターゲットを初めて見るまでに発生した固視回数
  • ターゲットを初めて見るまでに要した時間
ターゲットの認識しやすさの測定
  • ターゲットを選択するまでにターゲットを見た回数
  • ターゲットを初めて選択するまでに要した時間

Eye Tracking the User Experience: A Practical Guide to Research

Eye Tracking the User Experience: A Practical Guide to Research