Student projects/Usability issues

Note: This page outlines ideas for the Usability issues project. It's a specification under construction! If you have any comments or suggestions, please add them to the page comments.

The main objective of this project is to detect and solve specific usability issues.

Main tasks

• Research in the tracker, forums, etc. to create a hitlist of the top 10 (or 20) specific usability issues.
• For each issue, identify the problem clearly (screenshots) and clearly describe one or more solutions (incl mock screenshots) for the community to evaluate.
• Create code to solve the problem with the best decided solution (optional, depending on Moodle community thoughts).
• Take a look at Fluid Project (who we are involved with already) to see where some of their components can be used in Moodle (optional).

The project will adhere to the following plan:

• T1:Research the tracker, forums, wikis, mailing lists, etc. in order to find bugs and create a hitlist of the top 10 (or 20) most important specific usability issues to address.

• T2: Try to find out other possible usability issues to address. Some possible problems may be related to: o Navigation o Functionality o User control o Language and Content o Scrolling and paging o Links o Text appearance o Homepage o Online Help and User Guides o System and User Feedback (fortunately Fluid Project would help) o Web Accessibility (another proposal of GSoC is related to this item, because requires the deployment of a W3C's Tools) o Consistency o Error Prevention and Correction o Architectural and Visual Clarity: this has to do with Architecture information. It would be required that some kind of method (for example card sorting open and closed) verify that the architecture information is valid. For that it would be strongly advisable to implement open and closed card sorting with an open source tool such as cardsword o I have written in bold the areas which in my opinion may be the ones having most issues.

• T3:See what components from Fluid Project can be reused, in order to provide a continuous feedback of usability problems and try to prevent them in the future.

• T4:For each issue, identify the problem clearly (providing screenshots) and describe in detail one or more solutions (including mock screenshots) for the community to evaluate. Documenting and classifying the solutions will be an important step to allow us to know in which direction Moodle is in most need of improvement.

• T5:Write code to solve the problem with the best agreed-upon solution.

• T6:Writing the documentation of the project.

• T7: [OPTIONAL] It would be possible to develop a guideline for the developers to help them avoid problems in the future, by reminding them of several points and conventions such as: o Enable quality streaming video for the sign-language interpreter, which can be viewed promptly and without unnecessary waiting time. o Make the user interface simple and clear, avoiding adding an unnecessarily large number of options. o Make the user interface as visual as possible without graphically exaggerating it. o Keep navigation tools in a determined and clearly-defined position. o Avoid unnecessary pop-up windows, since they can confuse users that have just started to work with computers. o Simplify the language and explanations used - we advise the use of uncomplicated technical expressions. o Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the interface? o Efficiency: Once users have learned the design, how quickly can they perform tasks? o Memorability: When users return to the design after a period of not using it, how easily can they re-gain their proficiency? o Errors: How many errors do users make on avarage after a certain time of use, how severe are these errors and how easily can they recover from the errors? o Satisfaction: How pleasant is it to use the design? It would be desirable to try the guidelines with people from the outside (optional, although it would be very interesting). This phase would have the following points: Goal definition, Task definition, Variables to measure, Determining the user profile to take the test, Preparation and setting - up of the test, Analysis of the usability test, and Conclusions of the usability test. In the last step, we should analyse the results in order to extract conclusions of the current Moodle Usage. This is the timeline I envision:

T1: Research tracker, research forums, wikis, mailing lists(2 weeks)

T2: Try to find out other possible usability issues to address(1 weeks)

T3: See how Moodle's usability can benefit from the Fluid project (2 weeks)

T4: Classify and propose different solutions for the found usability problems (3 weeks)

T5: Solve the problem (3 weeks)

T6, (T7): Writing the documentation of the project (the guideline is optional) (2 weeks)

The timeline considering that in May/June I will be working half time in GSoC:

• T1: Deadline 1st May
• T2: Deadline 15th June
• T3: Deadline 4th July
  • Google: July 7: Mentors and students can begin submitting mid - term evaluations
  • Google: July 14th: Mid - term evaluations deadline
• T4: Deadline 20th July
  • Google: August 11: Suggested 'pencils down'. Take a week to scrub code, write tests, improve documentation
• T5: Deadline 16th August
  • Google: August 18: Firm 'pencils down' date. Mentors, students and organization administrators can begin submitting final evaluations to Google.

• T6/T7: Deadline 29th August
  • Google: September 1: Final evaluation deadline.
  • Google: September 3: Students can begin submitting required code samples to Google.

T1

Research in the tracker

Top 10 usability problems

1. Order problem: 1 usability problems
2. Too many popup windows: 1 usability problems
3. Problems when finding buttons: 1 usability problems
4. Problems with the usage of icons: 1 usability problems
5. Problems with the buttons' colours: 1 usability problems

Usability problem's table

#Usability problem ID	Short description	URL of the tracker	Kind of problem	Proposed solution
1	Usability Problem with Moodle File Management System	[1]	Order problem	Change the order of the several columns: checkbox - filename - action column - file data
2	Quiz usability: too many popup windows when manually grading	[2]	Too many pupup windows	Solve manual overriding of grade in /mod/quiz/report.php
3	Capability definition should include list of contexts where usable	[3]	Confusing where each capability can be assigned	In capability definition (access.php file) contextlevel means the lowest level
4	Usability issue: send in ratings	[4]	Problems when finding buttons	If users could send in their ratings as they make them with a button available next to each rating, or some other mechanism contextlevel means the lowest level
5	Usability issue: send in ratings	[5]	Problems with the usage of icons	Addinng a field / script
6	If the "Turn editing on" was of a different color or shape the usability would be better	[6]	Problems with buttons' colours	If the "Turn editing on" was of a different color or shape the usability would be better: the button would be easier to find.

See also

• GSOC/2008
• Using Moodle GSOC: Moodle Usability Guidelines forum discussion