開発:ユーザビリティ

作成中です - Mitsuhiro Yoshida 2008年2月8日 (金) 16:37 (CST)

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

自転車置き場 (Bike sheds)

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

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

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

(定義: 直感的)

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

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

Very few people would object to the statement that 'Apple software is more intuitive than Windows software' yet to someone who has only used Windows software, this is clearly not the case. Avoiding using the word yourself and mentally translating other people's use of intuitive as 'something I like' e.g. "Moodle's block system is unintuitive" = "Moodle's block system is something I don't like" may help to defuse arguments because it is harder to argue about personal opinions that are stated explicitly as personal opinion rather than disguised as objective statements about the software.

Therefore what is called intuitive, in the case of Moodle, will depend on your experience and expectations of other learning systems, web applications or sites, as well as software in general and thus varies from person to person. Usability studies should therefore average out the expectations of many people to find what is 'intuitive' and check to see if different groups (e.g. users of particular alternative systems, total beginners) have different expectations.

This article explains more and better (with diagrams!): http://www.uie.com/articles/design_intuitive/

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

People often confuse these topics, understandbly as they do have a great deal in common. Generally what are referred to as 'usability' improvements make things both easier to learn and easier for experienced users. Occasionally decisions need to be made favouring one over the other, and in those situations it helps to be explicit which of the two you are referring to. There are many succesful software tools that sacrifice learnability so that power-users can be more efficient. It seems likely that Moodle will continue to lean towards learnability in these cases, though again 99% of the time these goals are not in conflict. don't automatically suggest a new preference

In open source projects it is often easier (in the short term) to defuse any disagreement by 'adding a preference'. This means you end up with double (or triple..) the code to achieve the same thing. That's more code to write, debug, maintain etc. And once you end up with preferences interacting the potential combinations become astronomical and you end up in the situation that no two people are actually running the same program.

This can, over time lead to a profusion of preferences, each of which has a cost that needs to be weighed against it's benefit. Sometimes finding a solution that pleases everyone (to some degree) is preferably to adding preferences for each idea,

This is explained far better by Havoc Pennington in his piece on Open Source and User Interface, in particular the "Question of Preferences " section about half way through: http://www106.pair.com/rhp/free-software-ui.html

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

The somewhat tricky thing with regard to Moodle's usability is that Moodle is a web application, not a web site (though the line between the two is sometimes blurry) and few, if any, books have been written for that class of software. Therefore many applicable pieces of advice (from web, software or product usability guides) need to be reassessed with Moodle's nature in mind.

外部リンク

• 37 Signals Blog: Signal versus Noise http://www.37signals.com/svn/
• Jabkob Neilson's website http://useit.com/
• Joel Spolsky's User Interface Design for Programmers http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
• First Principals of Interaction Design by Tog (Bruce Tognazzini) http://www.asktog.com/basics/firstPrinciples.html

ブックリスト

Web specific

• 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

Computer specific

• 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".

General

• 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