Development:Usability - Revision history

Tsala: category

2008-10-14T12:26:08Z

Mits: ja link

2008-02-17T21:42:37Z

ja link

← Older revision		Revision as of 21:42, 17 February 2008
Line 74:		Line 74:

	[[Category:Developer\|Usability]]		[[Category:Developer\|Usability]]

			[[ja:開発:ユーザビリティ]]

Mits: fixed typo: Principals >> Principles

2008-02-14T15:32:13Z

fixed typo: Principals >> Principles

← Older revision		Revision as of 15:32, 14 February 2008
Line 54:		Line 54:
	* Jabkob Neilson's website http://useit.com/		* Jabkob Neilson's website http://useit.com/
	* Joel Spolsky's User Interface Design for Programmers http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html		* 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		* First Principles of Interaction Design by Tog (Bruce Tognazzini) http://www.asktog.com/basics/firstPrinciples.html

	==Booklist==		==Booklist==

Tsala: cat edit

2007-06-18T10:15:24Z

cat edit

← Older revision		Revision as of 10:15, 18 June 2007
Line 73:		Line 73:
	* Emotional Design: why we hate or love everyday things by Donald Norman		* Emotional Design: why we hate or love everyday things by Donald Norman

	[[Category:Developer]]		[[Category:Developer\|Usability]]

Nicolasconnault at 07:59, 22 March 2007

2007-03-22T07:59:31Z

← Older revision		Revision as of 07:59, 22 March 2007
Line 1:		Line 1:
	Some pointers, links, and resources on the topic of Usability (with respect to Moodle).		Some pointers, links, and resources on the topic of Usability (with respect to Moodle).

			==Contribute to Moodle through Usability testing==

			An ongoing need of a project such as Moodle is to keep the interface usable as the code matures. Improvements and added functionality may seem like a wonderful innovation from the coder's or administrator's point of view, but if the end-user is confused or frustrated by it (or can't even find it!), its usefulness drop dramatically.

			The idea of usability testing is simple: a person who is well-versed in Moodle gets together a small number of willing participants, who have no previous experience of using Moodle, and who are not technology experts (such as web designers etc...). The closer these people are to the "typical user" (for example a high school student), the better. The person conducting the test simply observes the participant as he/she tries to achieve a number of tasks. A video/sound recording can also be made with the prior consent of the participant, and is useful for later analysis.

			The person conducting the test then pools together the issues that were common between most participants, and produces a short and concise report that is then used by Moodle developers to improve the user interface.

			This sort of contribution requires no coding skills whatsoever, not even HTML. You just need to be familiar with using Moodle as a learner.

			The links at the bottom of this article include Steve Krug's book, "Don't make me think!". This books is the best introduction to Usability testing I know of.

	==Bike sheds==		==Bike sheds==

Nicolasconnault: /* Booklist */

2007-03-22T07:43:00Z

Booklist

← Older revision		Revision as of 07:43, 22 March 2007
Line 48:		Line 48:
	Web specific		Web specific

	* Don't Make Me Think by Steve Krug, a really good book, full of good info yet brief, well written and accessible. [http://www.sensible.com/chapter.html sample chapter]		* [http://www.sensible.com/ Don't Make Me Think] by Steve Krug, a really good book, full of good info yet brief, well written and accessible. A [http://www.sensible.com/chapter.html sample chapter] is made available on his site, as well as [http://www.sensible.com/secondedition/index.html 3 complete chapters] from the 1st edition in pdf format, covering a complete script for usability testing.

	* [http://www.digital-web.com/articles/defensive_design_for_the_web/ Defensive Design For The Web] by [http://www.37signals.com/ 37 Signals] (Matthew Lindeman and Jason Fried).		* [http://www.digital-web.com/articles/defensive_design_for_the_web/ Defensive Design For The Web] by [http://www.37signals.com/ 37 Signals] (Matthew Lindeman and Jason Fried).

Nicolasconnault: /* Booklist */

2007-03-22T07:40:02Z

Booklist

← Older revision		Revision as of 07:40, 22 March 2007
Line 49:		Line 49:

	* Don't Make Me Think by Steve Krug, a really good book, full of good info yet brief, well written and accessible. [http://www.sensible.com/chapter.html sample chapter]		* Don't Make Me Think by Steve Krug, a really good book, full of good info yet brief, well written and accessible. [http://www.sensible.com/chapter.html sample chapter]
	* Defensive Design For The Web by 37 Signals (Matthew Lindeman and Jason Fried) ~~sample chapter~~		* [http://www.digital-web.com/articles/defensive_design_for_the_web/ Defensive Design For The Web] by [http://www.37signals.com/ 37 Signals] (Matthew Lindeman and Jason Fried).

	Computer specific		Computer specific

Nicolasconnault: /* Booklist */

2007-03-22T07:37:37Z

Booklist

← Older revision		Revision as of 07:37, 22 March 2007
Line 48:		Line 48:
	Web specific		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		* Don't Make Me Think by Steve Krug, a really good book, full of good info yet brief, well written and accessible. [http://www.sensible.com/chapter.html sample chapter]
	* Defensive Design For The Web by 37 Signals (Matthew Lindeman and Jason Fried) sample chapter		* Defensive Design For The Web by 37 Signals (Matthew Lindeman and Jason Fried) sample chapter

Nicolasconnault: /* Don't automatically suggest a new preference */

2007-03-22T07:31:28Z

Don't automatically suggest a new preference

← Older revision		Revision as of 07:31, 22 March 2007
Line 29:		Line 29:
	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.		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 its benefit. Sometimes finding a solution that pleases everyone (to some degree) is ~~preferably~~ to adding preferences for each idea,		This can, over time lead to a profusion of preferences, each of which has a cost that needs to be weighed against its benefit. Sometimes finding a solution that pleases everyone (to some degree) is preferable 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		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

Nicolasconnault: /* Don't automatically suggest a new preference */

2007-03-22T07:30:55Z

Don't automatically suggest a new preference

← Older revision		Revision as of 07:30, 22 March 2007
Line 29:		Line 29:
	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.		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 can, over time lead to a profusion of preferences, each of which has a cost that needs to be weighed against its 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		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

← Older revision		Revision as of 12:26, 14 October 2008
Line 1:		Line 1:
	Some pointers, links, and resources on the topic of Usability (with respect to Moodle).		Some pointers, links, and resources on the topic of Usability (with respect to Moodle).


	==Contribute to Moodle through Usability testing==		==Contribute to Moodle through Usability testing==
Line 74:		Line 75:

	[[Category:Developer\|Usability]]		[[Category:Developer\|Usability]]
			[[Category:Usability]]

	[[ja:開発:ユーザビリティ]]		[[ja:開発:ユーザビリティ]]