OpenCourseWare(OCW)を勉強するWiki
6.170 Laboratory in Software Engineering, Fall 2005: Lecture 16
最終更新：
匿名ユーザー
-
view
MIT OpenCourseWare ＞ 6.170 Laboratory in Software Engineering, Fall 2005 ＞ 6.170 Laboratory in Software Engineering, Fall 2005: Lecture 16
MIT OpenCourseWare 6.170 Laboratory in Software Engineering, Fall 2005, Lecture 16: Usability 1 のまとめ
ラジオの方では vol.14- にあたりました。Lecture Noteを読むときの助けにしてください。
6.170 Laboratory in Software Engineering, Fall 2005のLecture NoteのPDFはこちら
6.170 Laboratory in Software Engineering, Fall 2005のLecture NoteのPDFはこちら
註）pp.2-6 のチャートは著作権上の理由から削除されています。iarchitect.comなどから引用したと推測されますが、明言されていないため詳細はわかりかねます。また、節番号が陽になかったため、このWikiの中の人が適当につけています。プレゼン形式なためそのまま訳すとわかりづらいので、いつにもまして超訳です。
16.1 Hall of Fame or Hall of Shame?
ユーザビリティとは良いユーザーインターフェース(UIs)を作ること。綺麗なWindowインターフェースを作ればユーザビリティーが良くなるというものじゃないことに注意しなきゃいけない。
p.2-4はInterface Hall of Shameの例。グラフィカルだし、複雑なコマンドはいらないマウスドリブンだし、WYSIWYG(what-you-see-is-what-you-get)だけど使いにくい。何で？
まずアフォーダンス（affordance）に従ってない。この例ではスクロールバーが、普通と違う使われ方がされてる。アフォーダンスとは、「僕をこう動かしてね！」っていうモノの主張。例えばドアノブは「回してね！」って言ってる。水平のスクロールバーはcontinuous scrollingのアフォーダンス（affordance）であって、discrete selectionではない。この例では水平についてるスクロールバーがaward templateの選択に使われてるんだけど、普通は横方向の画面移動に使うから、画面が見えてる限りは無視するよね。スクロールバーが不連続な動き方をするのも変。普通は連続的な動き方。
次に、慣れた人のためのショートカットがない。初めての人にも良く使う人にも使いやすくするためには、ランダムアクセスができて、それを一本のプロセスに変換できなきゃいけない。
あと左にあるヘルプメッセージ。新聞や雑誌を見慣れてる人は左端のぎざぎざ部分は広告の場所だから読まないし、そもそもやることは簡単なはずなのに左側に長いヘルプがあるってことは、開発した後に開発者が使いづらさに気づいたんだろう。でもユーザビリティーってのは、ソフトウェア開発の最後までほっとくものじゃなくて、ちゃんと開発プロセスの一部分になってなくてはいけない。
p.4に、この例の修正例の説明。
他のInterface Hall of Shameの例としては、
- 時計(p.5)
- Gimp (オープンソースの、Photoshopみたいな画像編集プログラム) (p.6)
- Clippy (p.7)
16.2 UIの特徴
UIはとても大事。
ユーザーは、ソフトウェアの知覚できる部分にとても影響を受ける。ユーザブルなソフトウェアは良く売れる。
開発者にとって不幸なことに、ユーザーが知覚できる部分ってのは表面上なこともある。ユーザーは機能自体ではなくUIの失敗に文句を言ったりするし、そのソフトウェアを買うことを決める人はいつもエンドユーザー（実際に使う人・機能を使う人と言ってもいいかも）であるとは限らない。本当にusableなソフトウェアではなく“user friendly”なソフトの方がユーザーに好評だったりする。
でもパフォーマンスやセキュリティと違って、なかなかレポートされないから問題の露呈や改善が難しい。
ユーザーは、ソフトウェアの知覚できる部分にとても影響を受ける。ユーザブルなソフトウェアは良く売れる。
開発者にとって不幸なことに、ユーザーが知覚できる部分ってのは表面上なこともある。ユーザーは機能自体ではなくUIの失敗に文句を言ったりするし、そのソフトウェアを買うことを決める人はいつもエンドユーザー（実際に使う人・機能を使う人と言ってもいいかも）であるとは限らない。本当にusableなソフトウェアではなく“user friendly”なソフトの方がユーザーに好評だったりする。
でもパフォーマンスやセキュリティと違って、なかなかレポートされないから問題の露呈や改善が難しい。
UIのデザインは難しい
我々はユーザーではなくエンジニアだから。我々は開発者間ののコミュニケーション方法（Specifications, assertions, and object models）に長けているけど、ユーザー、場合によっては自分たちとは違うタイプの人たち、とのコミュニケーションはわからない。
ユーザーは常に正しい。
でもユーザーが本当に常に正しいとも限らない。ユーザーが操作に失敗するとしたら、ユーザーのせいではなくて開発者のせいだ。
1950年代の実験では、ユーザー本当に求めてるものと表層に出てくる意見は違うってことがわかった。(Klemmer, Ergonomics, Ablex, 1989, pp 197-201)。それにユーザーはデザイナーではない。実際、ユーザーにカスタマイズを許すと、もとのデザインよりも2倍のエラーが出た。(Grudin & Barnard, “When does an abbreviation become a word?”, CHI ’85)
ユーザーは常に正しい。
でもユーザーが本当に常に正しいとも限らない。ユーザーが操作に失敗するとしたら、ユーザーのせいではなくて開発者のせいだ。
1950年代の実験では、ユーザー本当に求めてるものと表層に出てくる意見は違うってことがわかった。(Klemmer, Ergonomics, Ablex, 1989, pp 197-201)。それにユーザーはデザイナーではない。実際、ユーザーにカスタマイズを許すと、もとのデザインよりも2倍のエラーが出た。(Grudin & Barnard, “When does an abbreviation become a word?”, CHI ’85)
UIの開発はデザイン、実装、評価の反復プロセス
UIの開発は、
- デザイン imagining it (design)
- 実装 realizing it physically (implementation)
- 評価 testing it (evaluation)
の反復プロセス。
でも大概のUIのプロジェクトは、買ってくれたお客さんに評価を任せてその結果で次のバージョンをリリースしてるのが現状。かといって全部自分たちでやるのはコストがかかりすぎる。
でも大概のUIのプロジェクトは、買ってくれたお客さんに評価を任せてその結果で次のバージョンをリリースしてるのが現状。かといって全部自分たちでやるのはコストがかかりすぎる。
このジレンマを解決するのがspiral model。最初はできる限りコストを安く、デザイン、実装して回す。
ユーザビリティとは、そして指標は
Usabilityとは、どのくらい良くユーザーがシステムの機能を使えるか。
ユーザビリティの次元は5つ。
- Learnability 簡単に学習できるか
- Efficiency 一度学習したらすばやく使えるか
- Memorability 学習したのを思い出せるか
- Errors エラーが少なく一度エラーしてもリカバリが可能か
- Satisfaction 楽しく使えたか
これらはちゃんと数値化できる、というのが重要。
today's visitor： -
total visitor： -
total visitor： -
