Urs Hunkler

Martin, the discussion at MDL-28198 will shed some light on the state of the Moodle user interface awareness and how Moodle developers handle the Moodle UI.

Some aspects which hopefully help to enforce you to use jQuery in Moodle:

With jQuery and jQuery UI the actual UI situation would not have emerged as it did with YUI
With jQuery and jQuery UI we would already have consistent dialogs all over Moodle and could use the jQuery Roller to make the dialogs fit in the design. YUI offers one standard UI theme and hardly anybody has managed to create alternatives for it.

YUI is more difficult and you need to write more code
From my experience trying to write code in YUI again and again I learned YUI is more difficult and you need to write more code yourself. Which leads to more errors and a higher rate of different implementations.

Some persons in this discussion say it doesn't matter if you use YUI or jQuery
That's wrong. jQuery know-how you need in many projects - YUI know-how mainly in Moodle.

Many other projects changed their JS libraries to jQuery with great benefit for their users
It's good to know, that others have successfully thrown out their JS they have worked with and switched to jQuery (for example Drupal, Joomla, Wordpress).

The UI JavaScript needs to be rewritten anyhow
As described in MDL-28198 the dialogs need to be rewritten. Why write lots of code with YUI? Take jQuery UI and write the content code and fill it in - all theme designers and most users will thank you for the resulting consistency. And with jQuery much less code needs to be written as a bonus for the developers.

Some quite personal aspects
I am very frustrated in the moment with the possibilities to design the Moodle 2 interface. With the change to 2 I hoped visual Moodle interface design would become more easy. I am very sad to say that this is not true. In some areas you can do more, but in several areas inconsistency and strange development decisions make my live more difficult than with Moodle 1.9.

For example it is a hell to change the look of the custommenu. Digging through the CSS, fighting with IE incompatibilities etc. makes it a nightmare. And I think the basic decision to use a JavaScript generated menu system was wrong. The better way is to use a CSS menu system with JavaScript enhancements. Whenever possible I use the Superfish menu system.

For example why is the theme folder structure hard coded? JS must go into the "javascript" folder, images must to go into the "pix" folder, CSS must go into the "style" folder. Theme designers need the freedom to structure the folder according to their project needs - I feel treated like a child and what for?

Hopefully this long lasting discussion about the Moodle JavaScript library will come to a good end by using jQuery in Moodle.

Urs

Tim, can you explain why in Moodle two as I see it contradicting strategies for JS and CSS loading are used?

On one side all JS and CSS is pre-processed and cached in one file to need as few as possible requests on page loading. On the other hand YUI uses lazy loading only the needed JS and CSS.

To implement one strategy or the other I understand - but why both strategies are used at the same time I don't get.

Tim you ask the wrong question here - you should ask instead who may be so kind to help re-write the existing "crappy" code to get a consistent user interface. And re-writing it in jQuery instead of YUI will be less work.

Martin, welcome in the reality

@Acutally, no. The only bug is with the W3C web standards. Or at least a very annoying 'feature'.

We talk here about a JavaScript library which should make working with JavaScript and browsers easier. The basic getElementByID() gets ":", jQuery gets ":" in ID {name}. YUI fails. This I call a bug because it does not work as expected.

From the JavaScript point of view it can't play a role how a library finds elements. I just expect no differences between basic JavaScript and a library.

Differences lead to unnecessary frustrating experiences as we see.