Talk:Usability/Improve Moodle User Experience Consistency
Feedback "too technical"
Olli - Under "Some potential things that require change, to be researched further" you mention Feedback being too technical and unhelpful feedback to normal users - could you cite an example or two to show what you mean? Thanks - Anthony
- Response at Usability/Improve_Moodle_User_Experience_Consistency#Issues.2C_to_be_researched_further--Olli Savolainen 10:33, 24 April 2009 (UTC)
Some feedback from Martin D
Firstly, this is a huge topic and I applaud you getting into it and giving it a try!
I think overall you are asking the right questions.
After reading the whole page, my suggestions for a plan at this point are:
- don't start out trying to write a usability book with general principles (plenty of those around already)
- define exactly what a "standard" Moodle interface currently is, with plenty of best practice examples of all the major parts of Moodle (course, activities, blocks), parts of pages (header, footer, navigation etc) and processes (login from front page, login when following link to protected page, checking for new posts, grading things etc) It's not going to be easy because there are a lot of inconsistencies and unfinished refactorings but I and other core developers can really help you to define what the "state of the art" is.
- for each of the items in the standard:
- list all the exceptions to the standard (eg Lesson module doesn't support blocks, etc).
- include information for developers on how to achieve that standard (eg use of mforms, weblib etc)
- think about the future for that aspect
- develop mockups of alternatives or code if required
- plan usability testing
(I know this is somewhat similar to Usability/Improve_Moodle_User_Experience_Consistency/Detailed_project_plan but I hope this way of explaining it makes your job clearer!).
- Thanks, Martin. In general, that sounds good, and gives some further structure on in what order to approach things. The progressive disclosure page is, while crucial for Moodle too as a subject, mainly a place to refine the format of the guideline pages.
- The main priority is to keep each guideline light. Ultimately I think the exceptions are the rule in user experience design (each UI has to be created exactly for the most impotant persona and his most important goals, and then accommodating other users, using the common elements available). That is why I am in general a bit suspicious about listing all the exceptions:
- that would seem to make the guidelines heavy with information that is not critical (though it can be useful), and
- it would actually go closer to modeling the entire Moodle UI a second time (in addition to the PHP implementation), which I do not think is useful or necessary - the actual implementation is good, and an alternative modeling of it would be doomed to obsolence from birth.
- So, at the moment, I am thinking I will describe the main screen types, interaction styles, elements etc. like you outline, and then have links to everywhere the thing described by the guideline appears in some form. If the interaction/element is described sufficiently, the exceptions will be obvious from looking at the actual implementations and can be used to guide future UI design decisions.
- Also, thinking about the future of each aspect, while bound to happen naturally while examining the interaction styles, is not in the scope of this project: few real recommendations can be made on basis of no user research and a few usability tests.