「開発:ユーザビリティ」の版間の差分

提供:MoodleDocs
移動先:案内検索
(Done ... needs some brush up.)
(Done!!!)
 
(同じ利用者による、間の8版が非表示)
1行目: 1行目:
作成中です - [[利用者:Mitsuhiro Yoshida|Mitsuhiro Yoshida]] 2008年2月8日 (金) 16:37 (CST)
Moodleのユーザビリティに関する指針、リンクおよびリソースです。
Moodleのユーザビリティに関する指針、リンクおよびリソースです。


7行目: 5行目:
Moodleのようなプロジェクトで継続的に必要とされるのは、コードの成熟と共にインターフェースの使い勝手を保つことです。プログラマーおよび管理者の観点から、改善および機能の追加は素晴らしい革新のように見えます。しかし、それによりエンドユーザが混乱したり、ストレスを感じたり (または素晴らしさを理解できなかったり!) すると、実用性は劇的に下落してしまいます。
Moodleのようなプロジェクトで継続的に必要とされるのは、コードの成熟と共にインターフェースの使い勝手を保つことです。プログラマーおよび管理者の観点から、改善および機能の追加は素晴らしい革新のように見えます。しかし、それによりエンドユーザが混乱したり、ストレスを感じたり (または素晴らしさを理解できなかったり!) すると、実用性は劇的に下落してしまいます。


ユーザビリティテストのアイディアはシンプルです: Moodleに精通した人、テクノロジー・エキスパートではなく、Moodleを使用したことのない少数の自発的参加者 (ウェブデザイナー等) が集まります。それらの人は、「代表的なユーザ」 (例えば、高校生) に近いほど良いでしょう。テストを実施する人は、参加者が多くのタスクの達成を試みる状況を観察するだけです。参加者に対する事前承諾をもとに、ビデオ/音声によるレコーディングを実施することは、後の分析に有用です。
ユーザビリティテストのアイディアはシンプルです: Moodleに精通した人、テクノロジー・エキスパートではなく、Moodleを使用したことのない少数の自発的参加者 (ウェブデザイナー等) を集めます。それらの人は、「代表的なユーザ」 (例えば、高校生) に近いほど良いでしょう。テストを実施する人は、参加者が多くのタスクの達成を試みる状況を観察するだけです。参加者に対する事前承諾をもとに、ビデオ/音声によるレコーディングを実施することは、後の分析に有用です。


テストを実施する人は、ほとんどの参加者に共通な問題点をまとめて、Moodle開発者がユーザインターフェースの改善に利用できる、短く簡潔なレポートを作成します。
テストを実施する人は、ほとんどの参加者に共通な問題点をまとめて、Moodle開発者がユーザインターフェースの改善に利用できる、短く簡潔なレポートを作成します。
17行目: 15行目:
==自転車置き場 (Bike sheds)==
==自転車置き場 (Bike sheds)==


ユーザビリティの変更は、ビジュアルおよび概観にとって必然的なことなので、潜在的に自転車置き場の議論 (Bike Shed issue) になる可能性があります。これは、(短く言えば) 「僅かな修正をするためには、フォーラムやメーリングリストで多大な議論をする必要がある」と提案するオープンソースの社会で、不用意に使われるメタファー (隠喩) です。Moodleに関して僅かな改善を提案する人は、この現象を理解し、提案に暗黙の批評を含めるといったレベルのディスカッションに陥らないようにすべきです。
ユーザビリティの変更は、ビジュアルおよび概観にとって必然的なため、潜在的に自転車置き場の議論 (Bike Shed issue) になる可能性があります。これは、(短く言えば) 「僅かな修正をするためには、フォーラムやメーリングリストで多大な議論をする必要がある」と提案する、オープンソースの社会で不用意に使われるメタファー (隠喩) です。Moodleに関して僅かな改善を提案する人は、この現象を理解し、提案に暗黙の批評を含めるといったレベルのディスカッションに陥らないようにすべきです。


このメタファーに関して、よく書かれた説明をBSDメーリングリストで読むことができます: http://a.mongers.org/clueful/1999-phk-bikeshed
このメタファーに関して、よく書かれた説明をBSDメーリングリストで読むことができます: http://a.mongers.org/clueful/1999-phk-bikeshed
25行目: 23行目:
(定義: [http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=444 直感的])
(定義: [http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=444 直感的])


ユーザビリティの議論において、その意味がしばしば混乱を生じさせるため、「直感的」という言葉は避けるべきです。
ユーザビリティの議論において、その意味がしばしば混乱を生じさせるため、「直感的」という言葉の使用は避けるべきです。


ユーザビリティの多くの部分は「親しみやすさ」および「経験」 (familiarity and experience) を基にしていると一般的に認められています。学習がさらに簡単に、経験がもっと有益になるよう、AppleやGnomeのような人々が論理的一貫性に関するヒューマンインターフェースのガイドラインを公開しています。慣れ親しんだものが「直感的」だという理由で「直感的」という言葉を使う場合、事前の学習や経験を無視するため、すべての人において同じく真実であることになってしまいます。インターフェースの「良い点」または「悪い点」は、ユーザおよびインターフェースの関係性にあるのではなく、インターフェースそれ自体の内部にあると考えられます。
ユーザビリティの多くの部分は「親しみやすさ」および「経験」 (familiarity and experience) を基にしていると一般的に認められています。学習がさらに簡単に、経験がもっと有益になるよう、AppleやGnomeのような人々が論理的一貫性に関するヒューマンインターフェースのガイドラインを公開しています。慣れ親しんだものが「直感的」だという理由で「直感的」という言葉を使う場合、事前の学習や経験を無視するため、すべての人において同じく真実であることになってしまいます。インターフェースの「良い点」または「悪い点」は、ユーザおよびインターフェースの関係性にあるのではなく、インターフェースそれ自体の内部にあると考えられます。
31行目: 29行目:
Windowsソフトウェアのみ使ったことがある場合でも、「AppleソフトウェアはWindowsソフトウェアよりも直感的です」という発言に反対する人は、ほとんどいないでしょう。これは明らかに事実と異なります。あなたが「直感的」という言葉の使用を避け、他の人が使う「直感的」という言葉を「私が好きなもの」等に置き換えると良いでしょう。「Moodleブロックシステムは直感的ではありません = Moodleブロックシステムは好きではありません」という置き換えで、ソフトウェアに関する客観的な見解を隠しているより、むしろ明確に個人的な見解である「直感的」に対して、難しい議論を避けることができます。
Windowsソフトウェアのみ使ったことがある場合でも、「AppleソフトウェアはWindowsソフトウェアよりも直感的です」という発言に反対する人は、ほとんどいないでしょう。これは明らかに事実と異なります。あなたが「直感的」という言葉の使用を避け、他の人が使う「直感的」という言葉を「私が好きなもの」等に置き換えると良いでしょう。「Moodleブロックシステムは直感的ではありません = Moodleブロックシステムは好きではありません」という置き換えで、ソフトウェアに関する客観的な見解を隠しているより、むしろ明確に個人的な見解である「直感的」に対して、難しい議論を避けることができます。


従って、Moodleにおいて「直感的」と呼ぶ場合、それは他の教育システム、ウェブアプリケーションまたはサイト、同様にソフトウェア一般に関するあなたの経験および期待に左右されます。ですから、人によって感じ方が異なってしまいます。ユーザビリティに関する研究では、多くの人が「直感的」だと感じることに対する平均すべきであり、異なるグループ (例 特定の代替システムのユーザ、完全な初心者) が異なる期待を持っているかどうか調査すべきです。
従って、Moodleにおいて「直感的」と呼ぶ場合、それは他の教育システム、ウェブアプリケーションまたはサイト、同様にソフトウェア一般に関するあなたの経験および期待に左右されます。ですから、人によって感じ方が異なってしまいます。ユーザビリティに関する研究では、多くの人が「直感的」だと感じることを平均すべきであり、異なるグループ (例 特定の代替システムのユーザ、完全な初心者) が異なる期待を持っているかどうか調査すべきです。


次の記事では、(図解付きで!) さらに良く説明されています: http://www.uie.com/articles/design_intuitive/
次の記事では、(図解付きで!) さらに良く説明されています: http://www.uie.com/articles/design_intuitive/
37行目: 35行目:
==「学習可能性」対「ユーザビリティ」==
==「学習可能性」対「ユーザビリティ」==


当然のことながら、「学習可能性」と「ユーザビリティ」には共通点が多くあるため、人々はこれらのトピックにしばしば混乱してしまいます。一般的に「ユーザビリティ」の改善として言及されるものは、学習および経験豊かなユーザの両者に対して物事を簡単にします。時々、一方を選択するという決断が必要になるときがあります。この場合、あなたがどちらを言及するか明確にすることが決断の手助けとなります。パワーユーザが有能になる、学習可能性を犠牲にした素晴らしいソフトウェアは数多くあります。これらのケースでは、Moodleは学習可能性に関してさらに学び続けるように思えます。しかし、再度99%の時間、これらのゴールは衝突することはありません。
当然のことながら、「学習可能性」と「ユーザビリティ」には共通点が多くあるため、人々はこれらのトピックにしばしば混乱してしまいます。一般的に「ユーザビリティ」の改善として言及されるものは、「学習」および「経験豊かなユーザ」の両者に対して物事を簡単にします。時々、一方を選択するという決断が必要になるときがあります。この場合、あなたがどちらを言及するか明確にすることが決断の手助けとなります。パワーユーザが有能になる、学習可能性を犠牲にした素晴らしいソフトウェアは数多くあります。これらのケースでは、Moodleは学習可能性に対して傾くように思えます。しかし、再度、99%の場合、これらのゴールは衝突することはありません。


==無意識に新たなプリファレンス (preference) を提案しない==
==無意識に新たなプリファレンス (preference) を提案しない==


オープンソースプロジェクトでは、(短期的には) あらゆる意見の相違を「プリファレンスを追加する」ことで鎮めることは簡単です。これは、同じことをすることに対して、あなたが2倍 (または3倍 ...) のコードを追加することで結末を迎えることを意味します。さらに記述する必要のあるコード、デバッグ、メンテナンス等です。そして、あなたがプリファレンスの追加で終わった場合、潜在的な組み合わせは天文学的になり、結果的に2人の人が実際に同じプログラムを動作させるという状況がなくなってしまいます。
オープンソースプロジェクトでは、(短期的には) あらゆる意見の相違を「プリファレンスを追加する」ことで鎮めることは簡単です。これは、同じことをすることに対して、あなたが2倍 (または3倍 ...) のコードを追加するという結末を迎えることを意味します。さらに記述する必要のあるコード、デバッグ、メンテナンス等です。そして、あなたがプリファレンスの追加で終わった場合、潜在的な組み合わせは天文学的になり、結果的に2人の人が実際に同じプログラムを動作させるという状況がなくなってしまいます。


これは長期的に考えると、それぞれのメリットに対して重みをかける必要のある、夥しい量のプリファレンスの追加に繋がってしまいます。すべての人に (ある程度まで) 喜ばれる解決法を見つけるためには、可能な限りそれぞれのアイディアが加味されたプリファレンスを追加することも良いでしょう。
これは長期的に考えると、それぞれのメリットに対して重みをかける必要のある、夥しい量のプリファレンスの追加に繋がってしまいます。すべての人に (ある程度まで) 喜ばれる解決法を見つけるためには、可能な限りそれぞれのアイディアが加味されたプリファレンスを追加することも良いでしょう。


このことに関して、オープンソースおよびユーザインターフェースに関するHavoc Pennington氏の文章でさらに詳しく説明されています。特にページの中頃にある「The Question of Preferences」に詳しく説明されています: http://www106.pair.com/rhp/free-software-ui.html
オープンソースおよびユーザインターフェースに関するHavoc Pennington氏の文章で、このことに関して、さらに詳しく説明されています。特にページの中頃にある「The Question of Preferences」に詳しく説明されています: http://www106.pair.com/rhp/free-software-ui.html


==Moodleはウェブサイトですか?==
==Moodleはウェブサイトですか?==
54行目: 52行目:


* 37 Signals Blog: メッセージ vs 雑音 (versus Noise) http://www.37signals.com/svn/ - 英語
* 37 Signals Blog: メッセージ vs 雑音 (versus Noise) http://www.37signals.com/svn/ - 英語
* Jabkob Neilson's website http://useit.com/ - 英語
* Jabkob Neilson's ウェブサイト http://useit.com/ - 英語
* Joel Spolsky's プログラマーのためのユーザインターフェースデザイン http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html - 英語
* Joel Spolsky's プログラマーのためのユーザインターフェースデザイン http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html - 英語
* 相互作用デザインの第一原則 by Tog (Bruce Tognazzini) http://www.asktog.com/basics/firstPrinciples.html - 英語
* 相互作用デザインの第一原則 by Tog (Bruce Tognazzini) http://www.asktog.com/basics/firstPrinciples.html - 英語

2008年2月17日 (日) 21:41時点における最新版

Moodleのユーザビリティに関する指針、リンクおよびリソースです。

ユーザビリティテストを通じてMoodleに貢献する

Moodleのようなプロジェクトで継続的に必要とされるのは、コードの成熟と共にインターフェースの使い勝手を保つことです。プログラマーおよび管理者の観点から、改善および機能の追加は素晴らしい革新のように見えます。しかし、それによりエンドユーザが混乱したり、ストレスを感じたり (または素晴らしさを理解できなかったり!) すると、実用性は劇的に下落してしまいます。

ユーザビリティテストのアイディアはシンプルです: Moodleに精通した人、テクノロジー・エキスパートではなく、Moodleを使用したことのない少数の自発的参加者 (ウェブデザイナー等) を集めます。それらの人は、「代表的なユーザ」 (例えば、高校生) に近いほど良いでしょう。テストを実施する人は、参加者が多くのタスクの達成を試みる状況を観察するだけです。参加者に対する事前承諾をもとに、ビデオ/音声によるレコーディングを実施することは、後の分析に有用です。

テストを実施する人は、ほとんどの参加者に共通な問題点をまとめて、Moodle開発者がユーザインターフェースの改善に利用できる、短く簡潔なレポートを作成します。

この種の貢献には、HTMLも含めて、コーディングスキルを一切必要としません。あなたに必要なことは、学習者としてMoodleの使用に慣れ親しむことだけです。

このページの末尾にあるブックリストには、Steve Krug氏の著書「Don't make me think!」を掲載しています。この本は、私が知っている中で、ユーザビリティテストに関する最良の手引書です。

自転車置き場 (Bike sheds)

ユーザビリティの変更は、ビジュアルおよび概観にとって必然的なため、潜在的に自転車置き場の議論 (Bike Shed issue) になる可能性があります。これは、(短く言えば) 「僅かな修正をするためには、フォーラムやメーリングリストで多大な議論をする必要がある」と提案する、オープンソースの社会で不用意に使われるメタファー (隠喩) です。Moodleに関して僅かな改善を提案する人は、この現象を理解し、提案に暗黙の批評を含めるといったレベルのディスカッションに陥らないようにすべきです。

このメタファーに関して、よく書かれた説明をBSDメーリングリストで読むことができます: http://a.mongers.org/clueful/1999-phk-bikeshed

「直感的」という言葉を避ける

(定義: 直感的)

ユーザビリティの議論において、その意味がしばしば混乱を生じさせるため、「直感的」という言葉の使用は避けるべきです。

ユーザビリティの多くの部分は「親しみやすさ」および「経験」 (familiarity and experience) を基にしていると一般的に認められています。学習がさらに簡単に、経験がもっと有益になるよう、AppleやGnomeのような人々が論理的一貫性に関するヒューマンインターフェースのガイドラインを公開しています。慣れ親しんだものが「直感的」だという理由で「直感的」という言葉を使う場合、事前の学習や経験を無視するため、すべての人において同じく真実であることになってしまいます。インターフェースの「良い点」または「悪い点」は、ユーザおよびインターフェースの関係性にあるのではなく、インターフェースそれ自体の内部にあると考えられます。

Windowsソフトウェアのみ使ったことがある場合でも、「AppleソフトウェアはWindowsソフトウェアよりも直感的です」という発言に反対する人は、ほとんどいないでしょう。これは明らかに事実と異なります。あなたが「直感的」という言葉の使用を避け、他の人が使う「直感的」という言葉を「私が好きなもの」等に置き換えると良いでしょう。「Moodleブロックシステムは直感的ではありません = Moodleブロックシステムは好きではありません」という置き換えで、ソフトウェアに関する客観的な見解を隠しているより、むしろ明確に個人的な見解である「直感的」に対して、難しい議論を避けることができます。

従って、Moodleにおいて「直感的」と呼ぶ場合、それは他の教育システム、ウェブアプリケーションまたはサイト、同様にソフトウェア一般に関するあなたの経験および期待に左右されます。ですから、人によって感じ方が異なってしまいます。ユーザビリティに関する研究では、多くの人が「直感的」だと感じることを平均すべきであり、異なるグループ (例 特定の代替システムのユーザ、完全な初心者) が異なる期待を持っているかどうか調査すべきです。

次の記事では、(図解付きで!) さらに良く説明されています: http://www.uie.com/articles/design_intuitive/

「学習可能性」対「ユーザビリティ」

当然のことながら、「学習可能性」と「ユーザビリティ」には共通点が多くあるため、人々はこれらのトピックにしばしば混乱してしまいます。一般的に「ユーザビリティ」の改善として言及されるものは、「学習」および「経験豊かなユーザ」の両者に対して物事を簡単にします。時々、一方を選択するという決断が必要になるときがあります。この場合、あなたがどちらを言及するか明確にすることが決断の手助けとなります。パワーユーザが有能になる、学習可能性を犠牲にした素晴らしいソフトウェアは数多くあります。これらのケースでは、Moodleは学習可能性に対して傾くように思えます。しかし、再度、99%の場合、これらのゴールは衝突することはありません。

無意識に新たなプリファレンス (preference) を提案しない

オープンソースプロジェクトでは、(短期的には) あらゆる意見の相違を「プリファレンスを追加する」ことで鎮めることは簡単です。これは、同じことをすることに対して、あなたが2倍 (または3倍 ...) のコードを追加するという結末を迎えることを意味します。さらに記述する必要のあるコード、デバッグ、メンテナンス等です。そして、あなたがプリファレンスの追加で終わった場合、潜在的な組み合わせは天文学的になり、結果的に2人の人が実際に同じプログラムを動作させるという状況がなくなってしまいます。

これは長期的に考えると、それぞれのメリットに対して重みをかける必要のある、夥しい量のプリファレンスの追加に繋がってしまいます。すべての人に (ある程度まで) 喜ばれる解決法を見つけるためには、可能な限りそれぞれのアイディアが加味されたプリファレンスを追加することも良いでしょう。

オープンソースおよびユーザインターフェースに関するHavoc Pennington氏の文章で、このことに関して、さらに詳しく説明されています。特にページの中頃にある「The Question of Preferences」に詳しく説明されています: http://www106.pair.com/rhp/free-software-ui.html

Moodleはウェブサイトですか?

Moodleのユーザビリティに関する少々トリッキーな考え方は、(2つの境界は曖昧ですが) Moodleをウェブサイトではなく、この類いの本が数冊執筆されていたとしても、ウェブアプリケーションとみなすことです。そのため、 (ウェブ、ソフトウェアまたは製品のユーザビリティガイドからの) 適用できる多くの忠告は、Moodleの本質を念頭に置いて再評価されるべきです。

外部リンク

ブックリスト

ウェブ関連

  • Don't Make Me Think by Steve Krug, a really good book, full of good info yet brief, well written and accessible. sample chapter
  • Defensive Design For The Web by 37 Signals (Matthew Lindeman and Jason Fried) sample chapter

コンピュータ関連

  • The Humane Interface by Jeff Raskin Jeff, who sadly passed away recently, has been more and more research focused for the last 15 years, since his days helping to create the first Macintosh. This led to a discarding all practical considerations to concieve of the 'perfect' UI, rather than attending to the pragmatic, checklist-style "improve your site in 15 minutes" genre. However his wrting is excellent in consistently laying the blame for problems with the computer and it's software, not the user. It is often easy to fall into the trap of thinking 'stupid' users are the problem, rather than simply a design parameter. It is however worth remembering that (unless you are a research fellow) many of these technical faults must be worked with to a certain degree, and that "perfection can often be the enemy of the good".

一般

  • Psychology of Everyday Things by Donald Norman (aka The Design of Everyday Things), It's a classic, so some of the examples are a bit dated, but the basic message that it is fundamentally hard for a designer (no matter how smart) to place themselves mentally in the position of a user is put across well. I think about this book's simple message every time I push a door I was supposed to pull and vice versa.
  • Emotional Design: why we hate or love everyday things by Donald Norman