Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Student projects/Usability issues

From MoodleDocs


This project was an original GSoC 2008 project and it succeeded.

This page is a specification under construction! If you have any comments or suggestions, please share them with us.

Objectives

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

  • 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).
  • Create usability tests to find new usability issues (optional).
  • 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).

Timeline

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)

T7, (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.

Tasks

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:

  • Navigation
  • Functionality
  • User control
  • Language and Content
  • Scrolling and paging
  • Links
  • Text appearance
  • Homepage
  • Online Help and User Guides
  • System and User Feedback (fortunately Fluid Project would help)
  • Web Accessibility (another proposal of GSoC is related to this item, because requires the deployment of a W3C's Tools)
  • Consistency
  • Error Prevention and Correction
  • 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
  • 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:

  • Enable quality streaming video for the sign-language interpreter, which can be viewed promptly and without unnecessary waiting time.
  • Make the user interface simple and clear, avoiding adding an unnecessarily large number of options.
  • Make the user interface as visual as possible without graphically exaggerating it.
  • Keep navigation tools in a determined and clearly-defined position.
  • Avoid unnecessary pop-up windows, since they can confuse users that have just started to work with computers.
  • Simplify the language and explanations used - we advise the use of uncomplicated technical expressions.
  • Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the interface?
  • Efficiency: Once users have learned the design, how quickly can they perform tasks?
  • Memorability: When users return to the design after a period of not using it, how easily can they re-gain their proficiency?
  • Errors: How many errors do users make on average after a certain time of use, how severe are these errors and how easily can they recover from the errors?
  • 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.

Work done and future work

Work done:

  • 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: MDL-9513, MDL-4151, MDL-12753, MDL-10120, MDL-13969 and MDL-14294.
  • Create usability tests to find new usability issues.
  • Take a look at Fluid Project (who we are involved with already) to see where some of their components can be used in Moodle.

Future work:

  • Coding some of the usability errors analyzed after the community answers
  • Coding the errors founded at the usability project
  • Link the Moodledocs pages and/or tutorial pages with the videos uploaded at http://www.moodletutorials.org/
  • Add a new popup with a video icon that allows to see a demo

Status

TO BE UPDATED

See also