I (quiz maintainer) agree with most of what you are saying.
However, what annoys, and surprises, me is the following scenario, that has played out several times in the quiz forum:
1. I think I have identified an overcomplicated feature in the quiz that cannot possibly be of any educational benefit,
2. I post in the quiz forum saying "surely we can remove this"
3. There are howls of protest.
4. Then someone comes up with a situation where that feature does serve a valuable educational goal, and there is really no substitute, and so convinces me not to remove the feature.
As I say, very infuriating, but really rather interesting. Martin often says that Moodle is not really a development community building a better Moodle, but a social-
constructionist learning community, learning, through peer interaction what a better Moodle should be like. He is absolutely right.
So I agree that the quiz interface sucks, and I would like to spend time improving it (indeed I have made a number of minor improvements) but it is hard. Also, it is very hard to get your bosses to agree to you spending months on a system, making it work the same, but better. They are always asking for new features.
The next point I want to make is that when arguing bout complexity/flexibility in software, you really need to separate out what features are available in the underlying infrastructure, and then how that is explained in the user interface. It is essential that the core Moodle code is as general-purpose and flexible as possible. It is good that we have a totally configurable roles system, so all access everywhere in Moodle can be controlled in the same way. It is good that we now have a gradebook that has all the flexibility of a spreadsheet. It is good that we have plugin-able question types, so that you can use any sort of question you like in the quiz.
However, at the User Interface end, it is essential that most of this underlying flexibility is hidden at first. If you have not already heard of it, the key concept here is Progressive disclosure, which Jakob Nielsen explains better than I could:
http://www.useit.com/alertbox/progressive-disclosure.html)
But as an example, think about a word processor. You run it, and you can just start typing. And there are a few simple buttons like 'bold'.
Then you are writing an important document, so you want to make sure your formatting is consistent, at which point you can choose to start learning about and using styles to apply the formatting.
When you want to start working collaboratively, you can turn on track changes. Actually, you don't enable the track changes functionality. It has been there all along, you really just reveal the track changes toolbar to make the UI for that functionality visible.
You want to mail-merge, there is a whole lot of UI waiting for you that you had previously ignored.
And so on.
However, currently the Moodle interface is not great. And (as I have said in previous forum posts) what we really need is the
Firefox experience for Moodle. In the bad old days, the Mozilla project produced a great web browser, wrapped in a a rather baroque interface that very nearly ended up including everything
and the kitchen sink (see this spoof bug report
https://bugzilla.mozilla.org/show_bug.cgi?id=122411), so it was only used by a minority of geeks.
Then a few developers who really cared about usability started a sub-project to strip as much as possible out of the interface to make it as friendly as possible to new users. The result was Firefox, which is great. It is much more efficient for everyone to use, even die-hard geeks, and if you are a power user, you can
download all sorts of easy-to-install extensions to add on to the slick, efficient default interface.
Now, browsing the web is a much simpler task than creating an online course, so we will not be able to simplify the interface that much, but there is a lot we can do. However, note that Firefox fundamentally relies on having a powerful, flexible HTML+
CSS+
JavaScript rendering engine, and a flexible preferences system, and a plugin system, and a
database engine, and ... at its core. They have just done a great job of exposing all that through the interface in a way that makes sense to people.
Similarly, Moodle needs lots of powerful flexible infrastructure at its core, but it also needs a better interface around it.
And we are already on the right lines. We already have a plugin architecture rather than having everything hard-coded into core. We have good internationalisation and preferences and database abstraction libraries. We did not complicate Moodle by building in an ePortfolio, instead we made it work with a choice of
Mahara or MyStuff or ... instead (and we will make the integration better in Moodle 2.0).
However, we also have to struggle against the fact we are a web application, where every click on a link or form submission takes a second or two. So making someone work through a multi-page wizard to do a task an a clearly explained way is going to be quite infuriating. (Whereas the current 'put all the settings in one big form' interface is terrifying
)
Ajax can help a bit there, but it is not a panacea.
So, there is much to be done, but it is all in the interface layer. We have not been wasting our time with the changes in Moodle core over the last 2 years, they are all steps in the right direction. As a community, we can fix the interface, but it is going to be hard, and it will take time.
) the way university and college instructors and many corporate trainers do. Don's post is spot-on in describing this IMO.