情報系の忘備録: 7月 2012

2012年7月24日火曜日

LaTeXで表と本文の間のマージンのサイズを指定したい

figureやtableを [h] を使って、ソースに記入したそのままの場所に挿入した場合は \intextsep にて設定されている。
\begin{document}の前あたりに、下の行を追加すれば調整できるようになりました。

\setlength{\intextsep}{30pt}

2012年7月14日土曜日

Reading Text on a Smart Phone: Scrolling vs. Paging: Toward Designing Effective Electronic Manuals [Fukaya et al., 2011]

Reading Text on a Smart Phone: Scrolling vs. Paging: Toward Designing Effective Electronic Manuals [Fukaya et al., 2011] を読みました。
International Conference on User Science and Engineering (i-USEr) っていうカンファレンスの論文らしいんですが、このカンファレンスは聞いた事無いです。
2011年で第2回目という、新しい学会のようですね。

PCのモニタではスクロールレイアウト vs. ページレイアウトのどっちがいいの？という研究が数多くなされていますが、スマホを対象にした研究はまだそれほどなされていないので、そこにフォーカスした論文です。

1. Introduction

スクロールレイアウト/ページレイアウトに関する既存研究はPCのモニタに関するものが多いが、スマートフォンでテキストを読む場合はどうなのか
レシピやマニュアルなどの手続き的なテキストにはスクロールとページのどちらが適しているのか？

手続き的な文書はWeb上ではありふれていて、スマホのようなデバイス上でより読まれるようになるだろう

研究の目的は、スマホ上でのスクロールやページレイアウトがテキストの理解力、パフォーマンス、メンタルロードワークにどのように影響を与えるかを調査すること
2つのタスクを用意

記憶力タスク
操作タスク

2. Experiment

被験者

12人の日本人(男性8人女性4人で、平均年齢35.3歳)
5人はスマートフォンをほとんど使ったことがないが、7人は使い慣れている

装置

タッチパネル式デバイスとしてiPod Touch 4Gを使用
テキストの表示には、スクロール式とページ式の場合にそれぞれDocument Reader と Perfect Reader Mini というアプリを使用）
操作タスクでは19インチのモニタも同時に使用（後述）

Materials

2つのタイプのテキストを使用

物語
手続き的なテキスト

物語は1500字程度のものを4種類用意
手続き的なテキストは6ステップからなるものを5つ用意
どちらのタイプのテキストも、スクロール式のものとページ式のものを両方用意した

記憶力タスク

物語を読んでもらった後に、10個の穴埋め式の設問に回答してもらう。
テキストの位置が記憶力に影響するかどうかを見るために、半分の設問はテキストの端（最初と最後の3行）の部分に関する設問にした

操作タスク

iPodでマニュアルを読んでもらいながら、仮想コンソールをPCで操作してもらう
操作ミスがあったら、正しく操作できるまでやり直し

ワークロードの評価

スクロール式、ページ式の双方で操作タスクを終えたあとに、NASA-TLXを用いてワークロードを評価した

実験手順

実験を行う前に、5分間スクロールやページめくりの練習
仮想コンソールの操作の練習も7分間行う
ページめくりは横方向に指をスライドさせるが、スクロールは縦方向に指をスライドさせて行う
記憶力タスク --> 操作タスク　の順で行う
スクロール式とページ式を両方つかてもらうが、どちらを先に使うかは被験者を半々に分けてバイアスがかかるのを避けた
操作タスク終了後、NASA-TLXを使ってワークロードを評価

3. Results

一番好まれた操作方法は、物語・手続き的テキストの双方でスクロールであった
記憶力タスクの結果

回答の平均スコアは、ページレイアウトで読んだ場合のほうがわずかに高かった（統計的有意差あり）
回答のある位置（テキストの端か中央部分か）に関してはスクロールの場合は統計的有意差はなかったが、ページの場合は有意差があった（中心部のほうがスコアが高い）

操作タスクの結果

仮想コンソールの操作に要した時間に有意差はなかった
スクロールを好む人と、ページを好む人を別々に考える

スクロールを好む人は、スクロールで読んでいる場合のほうがページで読んでいる場合よりも操作時間が有意に短くなっていた
一方ページを好む人の場合は、ページで読んでいる場合のほうが操作時間は少し短くなっているものの、統計的に有意な差はなかった

操作ミスの回数に有意差はなかった

メンタルワークロード

Mental workloadに関してはスクロールの方がかなり少なかった
Temporal workload, performance, effort, frustrationについてもスクロールのほうが低いスコアだった
Physical workloadに関してはほとんど差がなかった

4. Discussion

物語に関しては理解力はページレイアウトで読んでいる場合のほうが高い

PCモニタの場合と同じ結果

手続き的なテキストに関しては、操作ミスの回数や操作時間に差はなかったものの、スクロールを好む人だけに注目すると、スクロールレイアウトの場合に短い時間で操作を終えていた
メンタルワークロードは、全体的にスクロールの方が低い
PCモニタの場合だけでなくスマートフォンにおいても、ページレイアウトのほうが読解には向いているのではないか
スマホユーザにとっては、手続き的なテキストに関してはスクロールの方が効率良く読めるのではないか

5. Conclusion

教科書などの記憶力を要するテキストの場合は、ページレイアウトを使ったほうが良い
マニュアル、レシピ、how-to本などはスクロールレイアウトのほうが、スマホに慣れ親しんでいるユーザにとっては効率良く読める

2012年7月13日金曜日

Scrolling Behaviour with Single- and Multi-column Layout [Braganza et al., 2009]

Scrolling Behaviour with Single- and Multi-column Layout [Braganza et al., 2009] を読みました。
以下、簡単なまとめ。結構色々端折ってます。

1. Introduction

デジタルデバイスで文書を作成する際に決めなければいけないものの一つに、レイアウトモデルがある。
レイアウトモデルは大きく分けて3つ

縦スクロール (vertical scroll)

現在のWebブラウザ向けの文章の大半はこれ
single-columnの場合には良いモデルだが、multi-columnだと次のcolumnの先頭を探すために余計なスクロールが必要となる
single-columnの場合でも、大きなスクリーンのスペースを活用しようと思うと、テキストの幅が広くなり読みにくい

ページレイアウト (page layout)

文書を表示する際にページのサイズや内容を動的に決定しない限りは、電子デバイスには適していないように思える

横スクロール (horizontal scroll)

レイアウトは動的に行われるので、ページレイアウトの際に生じる画面サイズに合っていないページサイズ等の問題が避けらる
--> 電子デバイスでmulti-columnの文章を読むには一番適しているように思える

Scrolling mechanism

キーボード、マウスのホイール、スクロールバー、etc...
1行ごとのスクロール、連続的なスクロール、page-at-a-time movement, ページの先頭へなどの機能、etc...

本論文の貢献は下記の通り

縦スクロールと横スクロールのユーザビリティを調査した初めての論文
各scrolling mechanismに対するユーザーパフォーマンスやリーディングパフォーマンスとの関係を調査した
スクロールの戦略(scrolling strategy)も調査した。そのような研究は少ない。
様々なscroll mechanismをもった閲覧ツールを実装した

実験の結果、被験者の1/3は横スクロールを、2/3は縦スクロールを使いやすいを感じていた

縦スクロールが選ばれた理由は慣れているからなのに対し、横スクロールが選ばれた理由はスクロールのしやすさや、テキストの幅が短くなることなど

スクロール戦略やscroll mechanismと、快適なレイアウトには関係がある
縦スクロールと横スクロールでタスクをこなす時間に有意な差はなかったが、そのうちスクロールにかけた時間に関しては横スクロールのほうが短かった

2. Related Work

スクロールについての先行研究との違いは主に以下の3つ

横スクロールを考えた初めての研究
ユーザにブラウザの設定(ウィンドウサイズ、フォントサイズなど)を自由に選ばせた
アイトラッキングで得られたデータを使ってスクロール戦略を区別した

3. Browser

HTML/CSSのサブセットをサポートする独自のブラウザを実装した
横スクロールレイアウトの場合は、以下のような挙動をする

ユーザはコラムの数をボタンで選択できる
ウィンドウ幅が変わった場合、コラムの幅も変わる
様々なscrolling mechanismを実装 (詳細略)

Grab-and-drag
Scroll ball
Scrollbar
Keys
Overview

上記scrolling mechanismの最後の2つに関しては、コラムの左端と画面の左端がくっつくようなシステムを採用

4. The Experiment

実験概要：被験者にそれぞれ縦、横スクロールレイアウトで表示されている2つの物語を読んでもらい、さらに設問に回答してもらう。回答の際には、物語を再度読みなおすことができる。
検証したい仮説

横スクロールは多くの人に気に入ってもらえる
横スクロールは目的の場所を探しやすい
横スクロールレイアウトでの"自然な"スクロール方法は、ひとつのコラムごとにスクロールすることである
ユーザにとっては、スクロール回数やスクロールに費やす時間を少ないほうが良い
スクロール戦略の選ばれかたは、レイアウト(縦or横)によって異なる

被験者は24人の大学生or院生。データ不備等の為、多少データを捨てた。
使用した物語は2000語程度の英語の文章
実験の前後に質問に回答してもらう

前の例: 週に何時間程度コンピュータのモニタで文書を読みますか？
後の例: 縦スクロールと横スクロール、どちらが気に入りましたか？またその理由は？

実験の流れは以下を縦と横レイアウトについて、繰り返す（順番はバイアスがかからないように被験者ごとにシャッフルされる）

操作の練習
実験の説明
アイトラッカー(FaceLAB)のcalibration
物語を読む
設問に答える

5. Data Analysis and Results

5.1. Dana analysis

各ユーザのログから以下のアクションの順番と所要時間を解析した

ブラウザのリサイズ
フォントサイズの変更
コラム数の変更(横スクロールレイアウトのみ)
Grab-and-dragによるスクロール
Scroll ballによるスクロール
Scrollbarによるスクロール
Page up, page down, スペースキーによるスクロール
その他のキーによるスクロール
Overviewによるスクロール

5.2. User preference

Layout model preference

24人中、8人は横スクロールの方を好み、16人は縦スクロールの方を好んだ
縦スクロールのほうが良かった理由としては、縦スクロールには慣れているが横スクロールには慣れていないというものが主だった
3人の被験者は、横スクロールの場合視線を上下に動かさないと行けない（次のコラムに移るときなど）のが嫌だと言っていた

縦スクロールの場合は、スクロールして好みの高さに読みたい文章を持ってこれる
視線の移動は上下よりも左右のほうが楽？

Preferred scrolling mechanism

使用したscrolling mechanismを分析しても、縦スクロールと横スクロールの場合で統計的に有意な差は得られなかった
ただし、縦スクロールの場合はscroll ballやscroll barを使う人が多かったのに対し、横スクロールでは矢印キー、scroll ball、grab&dragを使う人が多かった
grab-and-dragを使った人は6人中5人が縦スクロールのほうが快適だと回答。矢印キーを使った人は6人中5人が横スクロールのほうが快適だと言っている。

どのレイアウトが好まれるかは、使われるscroll mechanismに依存しているのではないか

5.3. Performance

横スクロールのほうが少ないスクロール回数・時間だと予想していたが、リーディング、設問への回答のどちらの場合にも、実際そうだった（統計的有意差あり）

その理由としては横スクロールのほうが縦スクロールよりも文書全体を表示するのに必要なスクロール量が少ないことが考えられる

横スクロールの場合には、コラムが目印となって設問の回答時間が短くなる（関連箇所を探すのに要する時間が短くなる）と予想していたが、そのような結果は得られなかった

5.4. Scrolling strategies

スクロール戦略は、大きく分けて次の3つが観察された

Page: 画面に表示されているテキストを（ほとんど）全部読んでから、一画面分スクロールする
Continuous: 画面の中のごく限られた位置のみのテキストを読む。細かくスクロールを駆使して、読みたいテキストがその位置に来るように調整する。
Region: PageとContinuousの中間。ある一定の範囲（だいたい画面の半分程度）にあるテキストを読みきったら、その範囲に次のテキストが来るようにスクロールする戦略。

被験者は物語を読む間に一貫した戦略を使う傾向がある（途中で戦略を変えたりしない）
縦スクロールと横スクロールの場合に、似た戦略を使う傾向がある
それぞれの比率

縦スクロール

page: 13%, continuous: 46%, region 31%

横スクロール

page: 50%
64%は見えてるコラムのうち幾つかを読んで、その分スクロール
一人だけcontinuous

横スクロールの場合は、テキストは画面中央で読まれることが多い
縦スクロールの場合は、画面の下の方で読まれることが多かったが、上から3分の1程度の箇所にもピークがあった

6. Discussion

得られた所見をまとめると次の通り。

被験者の1/3は横スクロールのほうが快適だと感じた。読むこと自体や設問への回答のパフォーマンスは、どちらのレイアウトでもほぼ同じだった。
縦スクロールの際、46%の被験者は視線の動きが最小限で済むようなスクロール戦略を採用している。逆に、ページ全体を読んでからスクロールという戦略を採っていたのは13%しかいなかった。画面の下の方が注視されやすい。
横スクロールに関しては、64%の被験者が1or2個のコラムを読んでからスクロールをしていた。表示されているコラム全部を読んでからスクロールという戦略も50%いた。画面の中央が注視されやすい。
横スクロールでは、スクロールの頻度は少なく、スクロールにかける時間も少ない。縦スクロールに比べ、キーでのスクロールはよく使われるが、scroll ballやscrollbarはあまり使われない。
縦スクロールで使うスクロール戦略は、レイアウトの好みに影響する（continuous scrollをする人は縦スクロールを好む）。Scrolling mechanismも同様に影響する(grab-and-dragを使う人は縦スクロールを好み、keyを使う人は横スクロールを好む)。

タッチスクリーン式のデバイスには、grab-and-dragを使う人に好まれる縦スクロールが適している？

画面の下の方が注視されやすいということが結構書かれていたけれど、見やすい場所って頭の高さや、画面の高さに大きく影響されると思うんです。

そのあたりの装置の配置状況などは書いてないですし、画面下が注視されやすいという点に関してはこの結果を見ただけじゃなんとも言えない気がします。

2012年7月8日日曜日

eshellのalias登録したコマンドで引数が処理されない

[環境]
OS: Windows 7 Home Premium Service Pack 1
Emacs: emacs 23.3-3

[背景]
JDK SE 7u5をインストールし、eshell上で java や javac などのコマンドを入力すると出力が文字化けする。
こちらの記事などを参考にしたところ、java には -Dfile.encoding=UTF-8 というオプションを、 javac には -J-Dfile.encoding=UTF-8 というオプションをそれぞれ指定して、出力されるメッセージの文字コードを指定してあげれば良いことが分かった。
eshell上で java -Dfile.encoding=UTF-8 と打っても、文字化けせずにヘルプが表示される。

alias java 'java -Dfile.encoding=UTF-8'
alias javac 'javac -J-Dfile.encoding=UTF-8'

と alias を登録し、いざ javac Foo.java と何かをコンパイルしようとしたら、表示されるのはヘルプのメッセージ。（ただ javac と入力した場合と同じメッセージ）
何度試しても同じ結果で、どうやら引数を受け取ってない模様…。

[問題]
eshellで

alias java 'java -Dfile.encoding=UTF-8'
alias javac 'javac -J-Dfile.encoding=UTF-8'

などとエイリアス登録し、 java foo とコマンドを入力しても、fooなどの引数がプログラムに渡されない

[解決策]
EmacsWikiに書いてありました。

alias java 'java -Dfile.encoding=UTF-8 $*'
alias javac 'javac -J-Dfile.encoding=UTF-8 $*'

最後に $* をつけて、引数をjavaなりjavacなりに渡しますよということを明示的に書かないといけないらしい。
bashとかだと、aliasって単純に 'java'って文字列を'java -Dfile.encoding=UTF-8'って文字列に置き換えるだけだったと思っていたので（違ったらすいません）、eshellも同じかと思い込んでおりハマリました。

2012年7月2日月曜日

CSS3の Multi-column Layout Module を使ってみる

CSS3にはMulti-column Layout Moduleというものがあります。
http://www.w3.org/TR/css3-multicol/

私は従来のHTMLは遊び程度に少し触っていた程度の経験しかないのですが、CSSのfloat機能を使うかtableなんかを使ってmulti-columnを実現することが多かったのではないでしょうか。

その場合大変なのは、コンテンツを各columnにどう振り分けるか、という処理。
動的に生成されるテキストだったりすると、はじめからテキストを振り分けることもできず、なかなか美しいレイアウトを作るのは難しかったんではないでしょうか。

CSS3で提供されるMulti-column Layout Moduleを使えば、コンテンツの各columnへの割り当てはレンダリング時に自動でやってもらえます。
細かい使用等の説明は他のサイト等に譲るとして（私用の忘備録なので）、例えば次のようなcolumnクラスを定義し、divタグなどでこのクラスを指定してあげると、画像のサイズを変えてもちゃんとmulti-columnのレイアウトになってくれます。

.column {
    column-width: 30em;
    -webkit-column-width: 30em;
    -moz-column-width: 30em;
    column-gap: 5em;
    -webkit-column-gap: 5em;
    -moz-column-gap: 5em
}

ちなみに-moz-*はFireFoxで表示させるのに、-webkit-*はGoogle ChromeやSafariで表示させるのに必要みたいです。

2012年7月1日日曜日

DeNAインターン一次面接で落ちました

タイトルの通り、DeNAのインターンシップ、一次面接で落ちました。
一次面接は渋谷ヒカリエにて行われました。　私が参加した時間帯は、1グループ5人程度で、3グループ同時に面接が行われました。
全員の人数はちゃんと数えてないけど、おそらく15人、そのうち私服は2人でした。ちなみに面接官や部屋まで案内してくれた社員さんは私服でした。

面接で行われた内容は、まずは30秒で簡単に自己紹介（過去の面接で行われたことがあるらしい、自分の過去の人生で映画を作るとしたら～みたいなものはなく、普通の自己紹介でした）。

次に、「みなさんの共通点を3つ見つけてください」と言われ、3分間時間を与えられる。3分間グループで話し合い、3分後に1人が面接官に報告するという形。

それが終わったらいよいよグループディスカッションです。一つ目は、面接官に関する情報（例えば、「私はお酒を飲むことができません」や「私は最近映画を見ていません」など）が与えられ、その理由を10分間で推測するものです。10分間のうち、どのタイミングでもいいのですが、3回だけYES/NOで答えられる質問を面接官にすることができます。
これが結構難しかったですね～。直後にもらったフィードバックによると、質問はなるべく解空間を半分にするような質問を選ぶことが大事とのこと。YESだったら理由が特定できるけど、NOだったらほとんど解空間が減らせない…みたいな質問を投げると評価が高くないようです。ちなみに、うちのグループはそういう観点からいくと全然ダメな質問を結構投げていましたね。
10分間が終わったあと、本当の理由を説明される前に、参加者に一人ずつ別々の質問もされました。「最初の質問を変更できるとしたら変更しますか？」「4つ目の質問をするとしたら、どのような質問をしますか？」などなど。

その後はグループディスカッション2つ目です。これは過去の面接について書いてあるブログにもあった、「直前の相手の発言を否定し、なおかつ新しいアイデアを出す」という制限つきのディスカッション。テーマは「○○の売上を2年間で2倍にするにはどうすればよいか」というようなものが与えられ、アイデアはできる限り具体的であることが求められます。抽象的な発言をすると、「ということは、どういうことですか？」みたいに突っ込まれます。

最後に自己PRが30秒（私の時は、今までに頑張ったこと、というテーマが与えられました）あり、挙手制で手を挙げた人から順に自己PRをして、質問タイムがあって終了という感じでした。

私自身が落ちたので、私の主観が入っているところはあまり参考にしないほうがいいかもしれません。

登録: 投稿 (Atom)