Hi all,
I am applying for Google Summer of Code for 2009 to improve the overall consistency of Moodle.
http://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency
My own motivation for this was born from last summer's work with the Quiz module, where it was often a question whether it looked moodlish enough. So I would like us to get started on the path to make the practical work of building user interfaces for Moodle easier.
The goal is creating something that would really be used as a reference anytime a new UI is created, so I am keen to get your feedback on this right from the start.
So developers!
My question to you is: when you are developing an user interface for Moodle, what is your way of deciding what it should be like?
Do you just have a gut feeling about what is "a Moodle interface" like and are capable of winging it?
Or do you have an uncertainty at the back of your head about whether it is consistent with the rest of Moodle, and expect community feedback to help you know if it is?
Please comment these questions and my proposition at the above address.
Thanks!
Great Olli,
my +1 for that project!
I really think having a MUIG is a must to keep things consistent and a to have both one reference and one decision tool in the hands of every developer, knowing what can be done and what cannot (and how).
Obviously, one of the main problems about that sort of interface guidelines is to keep it updated and agreed and, obviously, fulfilled by Moodle. But that's another history (thought we could also stabilise the rules to keep it useful along the time).
Ciao
my +1 for that project!
Obviously, one of the main problems about that sort of interface guidelines is to keep it updated and agreed and, obviously, fulfilled by Moodle. But that's another history (thought we could also stabilise the rules to keep it useful along the time).
Ciao
That is a good question. What do I think about when designing a new bit of Moodle interface? Some things I consider:
- I certainly try to work with the tools available as far as possible. That is, I think "is there a natural way to do this with HTML form controls (or links)". Generally, working with technologies they way they were deigned to be used tends to work best. For example, using form control the way they were intended to be used is generally a good start for making a usable and accessible interface.
- Going a step further, Moodle has formslib and YUI for adding sophistication, so working with what they offer (rather than fighting against it) is generally the way to go.
- But, so far, that is taking a very technology based approach to the question, which is just one angle. Still it is an angle that tends to lead to KISS and least effort.
- I also think about what I have read about usability, to see if there are any general principles that apply.
- The other thing is to think if I have seen something similar elsewhere in Moodle (that I think is worth copying) or failing that in another web application.
It would be terrific to see this given the attention it deserves.
Apart from isolated bits of the interface (eg mforms) there's never been much interest in this before (probably because it's so hard to come up with something that has a good balance between providing guidelines for consistency and allowing flexibility).
I see you found the dusty old interface guidelines page (last mentioned in this discussion).
I would also look at the iPhone Guidelines as a good example. (I added it to your page at the bottom).
And yes, the Navigation 2.0 stuff should be very closely involved, as it could probably automate a lot of the principles.
Apart from isolated bits of the interface (eg mforms) there's never been much interest in this before (probably because it's so hard to come up with something that has a good balance between providing guidelines for consistency and allowing flexibility).
I see you found the dusty old interface guidelines page (last mentioned in this discussion).
I would also look at the iPhone Guidelines as a good example. (I added it to your page at the bottom).
And yes, the Navigation 2.0 stuff should be very closely involved, as it could probably automate a lot of the principles.
Unfortunately, Google does not accept documentation work for GSoC. (See http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#doc_proposals) I see that your proposal does include "Fixes to Moodle 2.0 UI code". However, it would probably make Google happier if you put more emphasis on the coding aspects in your written proposal. Right now, your proposal reads like the documentation/guidelines is the primary goal, with coding as the secondary goal. It would probably help if you could rework it to be the other way around.
Just my 2 cents.
Just my 2 cents.
Thank you, Hubert.
From the overview: "Review Moodle's overall user interface. As an intermediary step, create a lightweight Human Interface Guidelines style documentation for Moodle. After having gathered the principle interaction styles and elements, discuss them with the community and fix the most obvious inconsistencies found."
I do not really see any other way of fixing consistency problems in code, than to first discover them by means of writing them down somewhere. This is not end-user documentation, but a tool for development, and I see no fundamental difference between this and creating a tool for, say, finding performance bugs for the use of a single open source project, and then using it within the GSoC project it was created in to fix code. Admittedly, a large part of the time may go in discovering what the design should really be, before starting implementation, but then, so should it in any other projects that aim to produce software.
Helen, being in charge of GSoC, do you see a need to emphasize this further in the application? Tim?
From the overview: "Review Moodle's overall user interface. As an intermediary step, create a lightweight Human Interface Guidelines style documentation for Moodle. After having gathered the principle interaction styles and elements, discuss them with the community and fix the most obvious inconsistencies found."
I do not really see any other way of fixing consistency problems in code, than to first discover them by means of writing them down somewhere. This is not end-user documentation, but a tool for development, and I see no fundamental difference between this and creating a tool for, say, finding performance bugs for the use of a single open source project, and then using it within the GSoC project it was created in to fix code. Admittedly, a large part of the time may go in discovering what the design should really be, before starting implementation, but then, so should it in any other projects that aim to produce software.
Helen, being in charge of GSoC, do you see a need to emphasize this further in the application? Tim?
Hi Olli,
I'm just giving my impressions based on my reading of your proposal. I know that different people can read the same and come to different conclusions, so other people could see different things in your proposal. I know that you are planning on doing some coding, and I can see the value of your project to Moodle, so I'm not critisizing your project in any way.
A couple more concrete suggestions, that may help to make your proposal read like it's more code-focused:
I'm just giving my impressions based on my reading of your proposal. I know that different people can read the same and come to different conclusions, so other people could see different things in your proposal. I know that you are planning on doing some coding, and I can see the value of your project to Moodle, so I'm not critisizing your project in any way.
A couple more concrete suggestions, that may help to make your proposal read like it's more code-focused:
- give an example or two of current inconsistencies in the Moodle interface, and explain how you might go about making it more consistent. (e.g. port more forms to formslib, improve formslib to be more flexible, write a JavaScript library, etc.) At this point, your proposed solution doesn't have to be the solution that you finally take, because it will depend on what your mentor says, and feedback from the community, but it will help to put more emphasis on coding.
- change your executive summary to put "Improve Moodle's consistency" at the front, instead of "create ... Human Interface Guidelines". e.g. "Improve Moodle's consistency by first creating a lightweight Human Interface Guideline, and modifying Moodle to comply with these guidelines. ..."
Thanks again for the feedback, Hubert,
I did not take an offense of your previous writing, just clarifying the fundamental goals. Your ideas are worth considering.
I am just hesitating to emphasizing either aspect of the project too much, since the point is I guess conceptually more complex than in a usual GSoC project (meaning by no means to devalue others' ideas since there are certainly lots of worthwhile projects).
I did not take an offense of your previous writing, just clarifying the fundamental goals. Your ideas are worth considering.
I am just hesitating to emphasizing either aspect of the project too much, since the point is I guess conceptually more complex than in a usual GSoC project (meaning by no means to devalue others' ideas since there are certainly lots of worthwhile projects).
- Improve usability (which is on an abstraction level higher than code)
- by means of research (which obviously needs to be documented)
- ending up in ideas implemented in code.