Moodle in English: Dear moodle, can we stop having the YUI lib yet?

Re: Dear moodle, can we stop having the YUI lib yet?

by Martin Dougiamas - Friday, 21 October 2011, 10:51 AM

OK, I'm very interested in this whole issue, particularly as I want our core team focussing heavily on usability and interface in 2.3 and 2.4.

The main reason I'm looking at jQuery at all is because every single developer that walks in here for an interview has already used it. It's more efficient to be working ith a mainstream product (in terms of users). I think at this point a switch from YUI to jQuery is fairly possible using rosetta stones etc, if we do it soon, although it's a lot of work for core and contrib devs.

I don't understand how we can be library agnostic in a practical way. Are you saying that every developer can just pick whatever library they want, and we will just load more and more per page? Won't this kill efficiency? How will developers communicate effectively and share code and review each others code? Can you explain this?

Average of ratings: Useful (5)

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Friday, 21 October 2011, 5:30 PM

Thanks for jumping in Martin.

I'll try and clarify, but about to go on holiday so have to be quick...

The concept -

Baseline moodle.

When a standard user (i.e. none-editing) loads a standard moodle page there should be no js libs included. None for primary navigation, none for drop down menus, none for onclicks etc etc...

If you are a standard user on a standard page and you view the html you shouldn’t see any js libs included.

If organisations want primary or secondary nav to be carried out with a js lib, then they can easily with a theme - but this should not be a part of the baseline of moodle.

Have a click through a course as a student and see if you can identify how many pages really need any kind of js lib (or even js at all) in moodle, then look at how many are loaded on that page.

This is a high concept.

It means a focus on getting the cms pages to work without the temptations to just drop in an effect from a js lib here and there.

It would make moodle into a sleek, mean learning machine

None-editing user pages which do require js -

For desktop / laptop users this means js fallbacks for media (video and audio) - but only load it when necessary. The base code should be http://slides.html5rocks.com/#video-audio

For desktop / laptop user this includes a js rich text editor - but only load it when necessary.

In moodle it also means key features like chat and any other rich interaction mods.

Any code to perform these should be built when possible using standard js e.g. http://html5demos.com/web-socket. Design and write to be agnostic of a library as standard, and only when necessary load your lib, shims or polyfils as the fallback.

Editor pages which require js interactions -

We all know adding students to a course and other boring ‘admin’ type jobs can be made a bit nicer with a little magic in the ui - which in the browser means js.

Any code to perform these should be built when possible using standard js e.g. http://slides.html5rocks.com/#drag-and-drop. Design and write to be agnostic of a library as standard, and only when necessary load your library as the fallback.

So while operations such as native drag and drop are currently only supported by modern browsers we have to use libs, shims or polyfils as an unpleasant necessity - but only load them when you know its necessary.

Restrictions to libs?

When your customising your moodle, building an extension or a mod you should be able to use whatever is best for your users requirements - js/flash/silverlight(cough!)/processing/web gl/sproutcore or anything you feel is appropriate for the interaction required. Moodle2 makes it possible to load these only on the page you require them on. Caching, cdns, minifying and gziping are all good

Guidelines on how to properly use and include these (footer, defer etc) are all pretty good

The default lib

Moodle does still needs to pick a default lib for fallback, admin and editing user interaction etc - which might well be loaded on a high percentage of ‘dahboard task’ pages. Personally i don’t think YUI is the right one.

These are a set of guiding principles it would be great to have at the core of moodle, and i think are essential to its future.

Hope this rather rushed reply makes sense - I’m on holiday sans internet till tuesday - but it will be interesting to see how this thread develops!

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Tim Hunt - Friday, 21 October 2011, 5:45 PM

This is what you want, as good web developer employed to tailor Moodle to your institution's needs. A blank slate that you can build on.

If you look back through these forums, you will find many delighted comments when people discovered the built-in navigation menu and so on that comes as standard in Moodle 2.x. These users are important too.

I would also argue agains using any old lib in any old plugins. We need standard things like in-page pop-up windows througt Moodle, and it would suck if we all use different libraries to generate them, so that they all look different. Do not suggest that I should use TinyMCE in the quiz, and you should use HTMLArea in your block, do you?

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Tuesday, 25 October 2011, 6:33 PM

OT @tim - re:dialogue box (in-page pop-up windows?).

This would appear to be quite a fundamental misunderstanding of what a dialogue box is. A dialogue box is simply a div or other dom element on the screen. As with any dom element, we use css to control what it looks like/where it is displayed etc.

Have a look at this example -

http://jsbin.com/obofoh/6/edit

It is a standard html element with css. There is no magic. No js. No lib. No ui lib.

Using a js lib and a UI lib to control how interface elements on the page looks is a valid paradigm (see jquery mobile) normally applied to closed source or products with a single look/feel. I don't think i have seen this paradigm used in the user facing core of any open source products which allows users to build/apply user themes.

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Hubert Chathi - Tuesday, 25 October 2011, 10:15 PM

I'm pretty sure that Tim knows how to construct something that looks like a dialog box using HTML and CSS. But to make the dialog box do anything useful (including popping up when needed), you need JS. As well, JS libraries do a lot more than just creating something that looks like a dialog box; they add things like: making the dialog box draggable, making them modal, laying out the contents, making it pop up in a sensible location (e.g. if you're scrolled half-way down the page, it needs to pop up so that it's visible) etc. And they do these things by structuring the dialog box's DOM tree in a specific way. And they probably all do things slightly differently.

The thing is, Moodle already has inconsistent dialog boxes: there's the YUI style, and then there's TinyMCE's dialog. To see them both at the same time, start composing a forum reply, click on the "Insert/edit image" button, and then click on "Find or upload an image".

Yes, it's all DOM elements, and they can be styled similarly, but it's harder to make two different dialog styles look similar (and look good at the same time). And there will still be differences that you can't get around (e.g. if you drag TinyMCE's dialog, you get a semi-transparent placeholder that indicates where the dialog will go, whereas if you drag a YUI dialog, the whole dialog box follows the mouse).

And then there's all the other UI widgets as well.

Average of ratings: Useful (1)

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Wednesday, 26 October 2011, 4:49 AM

Hubert - somtimes i'm a bit naughty so appologies to yourself and tim ;)

Your right in that libs can add lots of fun stuff to your standard dialogue, but most of what they do you can do with css.

for your model - try adding a semi transarent bg to that overlay div in the example. for your positioning - again, just try messing with the css (fixed etc). laying out the content is a simple as any html, and i'm sure you know how to make a dialogue apear without a js lib - either with standard js or just a clever html structure.

I'll make a another (hopefully) final post in this thread, which should hopefully explain my reasoning behind which i think using such tightly coupled js ui elements is not a great idea for moodle, which i hope you understand.

cheers

stuart

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Hubert Chathi - Wednesday, 26 October 2011, 10:33 PM

Sure, you can add your own semi-transparent overlay, calculate the correct position of the dialog on your own, etc, but they you'd be reinventing the wheel, and creating your own JS library, which is exactly the opposite direction that everyone seems to want to go. Everyone wants to use a JS library that is more commonly used, not less.

And I never said that you needed a JS library to make the dialogue appear. I said you needed JS. And again, why would you write your own JS when it's already been written already (and re-written, a dozen times)?

Average of ratings: Useful (1)

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Thursday, 27 October 2011, 7:03 PM

Hubert - At the previous london js conference there was an interesting talk by one of the microsoft IE team (i think?).

He discussed how many pretty simple websites load large amounts of js libs and how over-reliance on js and libs to do things that are trivial in html and css is a bad trend, and i'd tend to agree.

He showed some rather large sites (cnn or bloomberg maybe?) and using firebug and other tools demonstrated the amount of js from libs being loaded either to do things that should really be done with css or html, and lots of js from these libs never being used at all. He talked about how using standard css and html makes things much easier to understand or debug, makes them more accessible and faster to load, and is just a whole heap nicer.

The IE developer was talking about the exact same thing as Colin says - "Have developers become lazy because there are fast processors, rapid transfer speeds, and size no longer matters?".

In the example i posted the transparent overlay and positioning can easily be done with two lines of css :

background-color:rgba(0,0,0,0.5) or an image in your IE specific style sheet
position fixed or percentages for positioning

http://jsbin.com/obofoh/17/edit - no js.

Just for fun, here is some triggering of the dialogue to open and close - no js.

http://jsbin.com/enaren/4/edit (i wouldn't recommend copying this code, but it was fun!)

I find it odd if you think using html and css is re-inventing the wheel - but i'm sure you don't really.

The same goes for using a js lib to do things that are trivial with standard js.

take the example -

document.body.onclick = function (e) { // when clicks occur, do stuff };

By using a single event handler i can capture all my page events and handle events based on the elements that trigger them.

This is a simple and basic js pattern.
It's understood by all js developers, independent of whether they know a lib or not.
It's not my own js - it's been writen already (and re-written, foo* times).
It's faster for the browser to execute and less code for you to write a than any lib.

I love js libs - don't get me wrong. I just think over-reliance on them, and using them badly is a modern trend we really don't need.

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Tim Hunt - Thursday, 27 October 2011, 7:34 PM

document.body.onclick = function (e) { ... }

is a classic mistake, particularly in a system like Moodle where a page is made up from mulitple plugins. Think about what happens when your block does document.body.onclick = yourfunction, and my block does document.body.onclick = myfunciton.

The right API design for this is

document.body.addEventListener('click', yourfunction);

which is why they designed the DOM API standard that way.

But then you get the problem that not all browsers support the DOM API flawlessly (at least not when YUI started out, perhaps the situation is better now), which is why you want a JavaScript library that deals with crappy browsers for you, so you don't have to.

Which is what we do in Moodle.

Average of ratings: Useful (1)

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Thursday, 27 October 2011, 8:59 PM

tim - i'm not advocating any pattern for moodle in the comment for Hubert, but trying to illustrate that using standard js isn't re-inventing a wheel.

I'm glad you recognised the pattern i used in the example

document.body.addEventListener('click', yourfunction) is indeed another great example of a simple js pattern which is understood by all js developers, independent of whether they know a lib or not, not your own js, been written already (and re-written, foo* times) and faster for the browser to execute and less code for you to write a than any lib.

This is getting rather silly now

I'm really more interested in your comments on http://moodle.org/mod/forum/discuss.php?d=188627&parent=822687

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Hubert Chathi - Friday, 28 October 2011, 4:14 AM

Thanks for the HTML popup example. I didn't know about the :target pseudo-class, and I probably wouldn't have thought to use it that way. Nevertheless, I don't think such an implementation would be used in real life, for a few reasons:

Using the '#' anchor to escape from the dialog will bring you back to the top of the page, no matter where you were before.
IE8 and below apparently don't support :target
It doesn't degrade gracefully.
You can't have one dialog box up another one up (á la "Insert/edit image" -> "Find or upload an image")
Most dialog boxes are not just of the "pop up, then hide" variety -- you usually want to do something else that requires JavaScript anyways, and if you're already using JavaScript...
Even if you have some dialog boxes that fit this pattern well, you probably have others that don't. And if one dialog box is generated by JS, and one is pure HTML/CSS, then you need to make sure that they're both style consistently.

But it was certainly a neat implementation, and a nice example.

Regarding the semi-transparent overlay, you probably also want to add in a z-index, to make sure that it appear over any other element. And you'll either want a dynamically-generate z-index (because you never know what other z-indexes are already used), in which case you need JavaScript, or else you'll have to say that nobody will ever use a z-index of, say over 1000, and cross your fingers. And yes, you'll need to use a semi-transparent image for old browsers that don't support rgba colours (not just IE, but also older versions of any other browser). You certainly don't want to use both rgba and the image, so you'll probably need to use JavaScript browser detection. And ... does IE6 even support semi-transparent images as backgrounds? I don't know. And that's one of the great things about the JS libs, is that I don't need to worry about these things; the library is supposed to take care of it for me transparently (no pun intended).

I certainly agree with you about over-reliance of JS libs. And I'm happy about Moodle's requirement that things should work without JS. But I don't think that Moodle's usage of JS is an example of over-reliance of JS libraries.

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Monday, 31 October 2011, 10:18 PM

hubert - glad you like the code - as i said, don't use it - for all the reasons you mention.

i'd say it's worth you taking a look at the uncompressed code for some of the js libs - specifically for functionality you might think they 'take care of'. The way they handle it is sometimes good to learn from, and other time they don't do any of what your actually describing. It's worth knowing they are not magic, or how to do the things they do you might currently think are magic.

as for moodles tight coupling with libs with ui in its core - let us just agree to disagree

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Tim Hunt - Wednesday, 26 October 2011, 5:16 AM

I failed to respond to your point about coupling of JS/CSS/HTML before, because I had other things to argue about, but it is an interesting point.

I think there has to be some coupling, but it only needs to be one-way.

That is, the JavaScript code has to depend on the static HTML code that was served by PHP. That is, if you want to do progressive enhancement of a particular HTML page, then the JavaScript needs to go and find certain DOM elements.

Of course, the JavaScript may end up generating more DOM nodse.

Then, the CSS exists to style the HTML that is there (both the static HTML from PHP, and any DOM nodes that were added by JS). So, the CSS is coupled to the HTML and JS.

Of course, in Moodle, for a particular page, all that depends on the current theme.

I don't think I explained that very well, but the summary is: The theme generates the HTML; the JS must serve the HTML; the CSS must serve the HTML, including the HTML generated by JS; therefore the JS and CSS also need to be generated by the theme.

I don't think it is helpful to say 'everything is a div'. You might as well say "everything in Moodle is a row in the database". It is true, but unhelpful. What is helpful is to invent higher level abstractions: "Stuart is a user", "This is a forum post", a quiz is made up of questions. This languages of higher leverl abstractions is what lets us build (the back end of) meaningful educational experiences.

Similarly, rather than thinking "this UI is a lot of divs with CSS", we need ot think, "This is a form with these elements"; "this is a navigation bar"; "this is a dialogue box"; "this is a warning"; ... It is only be creating the right language of UI elements that we can build a consistent experience for our users across all the different activities and other parts of Moodle.

Finding the right language will be hard. It is a mixed blessing that over the last 10+ years moodle has evolved into what it is today. That means that there is a lot of existing UI that can be catalogued and classified; but also the evolution has happened without much direction. I suppose I am saying that Moodle's UI languagle is currently English (a hodge-podge of many different things) rather than Esperanto (designed). We need to find our Dr Johnson.

Average of ratings: Useful (4)

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Wednesday, 26 October 2011, 6:55 AM

* looks for fb like button *

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Stuart Lamour - Wednesday, 23 November 2011, 4:37 PM

Some slides on how to do mvc & library agnostic js from Nicholas Zakas of Yahoo.

http://www.slideshare.net/nzakas/scalable-javascript-application-architecture

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Urs Hunkler - Saturday, 29 October 2011, 7:05 PM

Martin, welcome in the reality

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Urs Hunkler - Saturday, 29 October 2011, 8:04 PM

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

Average of ratings: Useful (6)

Re: Dear moodle, can we stop having the YUI lib yet?

by Danny Wahl - Friday, 4 November 2011, 10:28 AM

While I agree with what you say about using css/html as much as possible and js for the progressive enhancement I do take issue with your point about theme designers needing freedom to structure folders/files.

I find it refreshing that I know that stylesheets are in styles/ and js are in javascript/ You only need to look at Moodle 1.9 themes and the variety of ways that different things were pieced together: includes, requires, calls, hard coding, etc... etc... Moodle2 fixes a LOT of that.

Is it more complex than it needs to be? Probably, is it maybe a little too restrictive? Probably again, but some order is very refreshing. Because at the end of the day, you're themeing a webapp that's designed to be an LMS - it is designed to function a certain way. And function always takes priority over fashion, e.g. this isn't WordPress (as much as I love WP).

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Mauno Korpelainen - Friday, 4 November 2011, 5:24 PM

I agree pretty much with everything that Urs said in that previous post and find this kind of discussions very useful

There are many good new features in the new theme system http://docs.moodle.org/dev/Theme_changes_in_2.0 and in most cases we do not actually need to /have to do exactly like the guide says. We don't need to use the recommended way to add javascripts to javascript folder, we can for example use layout files like web pages do and add normal script tags there - or add css file tags to layout files - and these files can be even outside moodle itself.

It's good to have consistency to be able to keep main features like headers, main block styles, dialog boxes etc similar looking - like http://tracker.moodle.org/browse/MDL-28198 tries to achieve (in the future when all the yui 2 things are gone...)

What typical cms themes like WP, Joomla or Drupal themes handle better than moodle is still modularity - core moodle is growing all the time like core YUI since people try to build all new features inside the core files while cms systems add optional plugins.

In moodle the capabilities to add/drop/change themes, filters, activities (modules, blocks) and finally in moodle 2 also editors are just great - although partly unfinished.

The main goals for moodle 2 theme changes (set by developers) were:

1) easier theme customisations - both CSS and images
2) simplify core and themes code
3) significant performance improvements
4) solve majority of browser caching problems
5) use YUI CSS foundation
6) allow themes to be stored in separate directory without www access (such as dataroot)

Now when I look back to those goals performance was partly improved by many good changes to caching etc but at the same time YUI css and other YUI stuff spread all over moodle and I actually never wanted to use YUI css in themes and I was wrong in

http://moodle.org/mod/forum/discuss.php?d=131219#p574615

We can select many things in moodle 2 themes but yui javascripts and css are loaded in any case - you can just override the code you don't want to use.

After all there should not be so much difference in designing themes to cms or lms systems. They all have pretty much similar activities (forums, poll/survey blocks/modules, image galleries, repository plugins,...), they all use Wysiwyg editors for editing data and database for saving data. They all are used by different user groups (educational/commercial/...) and they all try to be the best available systems on earth

So you could as well turn that old mantra "Moodle isn't WordPress" to "WordPress isn't Moodle". Moodle has many things that could be improved if things were as freely pluggable as they are in WordPress, Drupal or Joomla. I have used them all

I suppose that our main problem in implementing KISS principle to flexibility of modern web 2 systems (no matter what they are called) was that everything in moodle 1.X was originally so inbuilt that building the new and glorious, fully pluggable Modular Object-Oriented Dynamic Learning Environment took too much developers time with so many old and new features pushing and pulling moodle to different directions... and now we are stuck in situation where developers are tired to even talk about changing some core features to optional features

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Amy Groshek - Wednesday, 30 May 2012, 3:00 AM

For example it is a hell to change the look of the custommenu.

Second that.

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Mauno Korpelainen - Thursday, 3 November 2011, 5:07 AM

Martin,

since there is clearly one area that yui3 handles worse than jQuery - mobile UI - could some core team start testing at least mobile jquery framework in addition to mymobile theme?

See http://jquerymobile.com/blog/2011/10/28/announcing-themeroller-for-mobile-beta/ and the actual mobile theme roller

http://jquerymobile.com//themeroller/

https://github.com/jquery/web-jquery-mobile-theme-roller

It is great to get mymobile theme to core http://tracker.moodle.org/browse/MDL-27622 but it might be even better to make mymobile editable with mobile themeroller ?

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Mauno Korpelainen - Thursday, 3 November 2011, 3:31 PM

Well, YUI3 can in fact offer basic ScrollView for mobiles

http://yuilibrary.com/yui/docs/scrollview/scrollview-base.html

if somebody has time to implement it to themes of moodle 2...

On the other hand companies like Adobe, Google and Microsoft are working in co-operation with jQuery developers to create ready-to-go applications - see for example http://blogs.adobe.com/adobeandjquery/

YUI developers are still discussing about YUI Mobiles - http://yuilibrary.com/forum/viewtopic.php?p=28522 - and at the same time jQuery folks can say:

jQuery mobile framework takes the "write less, do more" mantra to the next level: Instead of writing unique apps for each mobile device or OS, the jQuery mobile framework will allow you to design a single highly branded and customized web application that will work on all popular smartphone and tablet platforms.

Tools like http://jquerymobile.com/themeroller/ make editing of themes available for such people who can't write code or don't know even basic css but have visual talent to design something beatiful - like mobile themes for moodle ( ... and nothing prevents using mobile theme jQuery UI / css classes for desktop themes as well - mobile themeroller is open source and downloadable from GIT )

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Urs Hunkler - Saturday, 5 November 2011, 5:48 AM

A lot of developer specials are discussed here. A very important aspect is what you can do with jQuery. I created a course format with the jQuery plugin http://isotope.metafizzy.co and an inline editing jQuery plugin. This course format would never have been possible to create within a reasonable time with YUI - the wide variety of plugins/extensions is missing in YUI and jQuery is used by many designers.

You may have a look at " "

A screencast from Urs Hunkler on Vimeo.

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Dan Poltawski - Saturday, 5 November 2011, 8:31 AM

Urs - that is a very subjective point, especially considering how specialist Moodle is as an application, one could say the same in reverse about a course format which was heavily biased towards a YUI course format.

I think community contributions are a great point to bring up though - jquery has a very extensive community of contributions, that makes me favour it too. But do we have any convincing 'look at the code' examples where jquery would really help, and YUI is being restrictive?

My non-scientific way to test this was to see if there was something which would give the majority of the filepicker UI in jquery (partly because I hate the filepicker, and perhaps if I could come up with a jquery alternative I could theme it to my liking) but I couldn't find any easy wins here. In fact even just a basic popup I found nothing that was convincingly better in jquery than YUI.

Average of ratings: Useful (1)

Re: Dear moodle, can we stop having the YUI lib yet?

by Mauno Korpelainen - Saturday, 5 November 2011, 5:12 PM

Dan,

if you check for example the homepage of Moxiecode - the creator of TinyMCE - you get a link to http://www.plupload.com/ that is open source and http://www.plupload.com/example_jquery_ui.php has the Theme switcher button (using the old desktop jQuery theme roller css)

In most cms systems file managers and and image managers are separate applications and you can select different core or commercial plugins for uploading/managing files - like http://www.tinymce.com/js/tinymce/jscripts/tiny_mce/plugins/filemanager/pages/fm/index.html - but moodle 2 is of course a special case since it has a custom way to "store" files.

I was testing 2 days ago implementing https://github.com/jquery/web-jquery-mobile-theme-roller directly to moodle 2 themes and it can be used to add any styles to any activities or tools like file picker if we have certain classes (either the standard mobile-ui css classes or we can use some core moodle classes) with tiny modification to mobile theme roller files. You can check how changing styles of defined classes works in http://jquerymobile.com//themeroller/

Since this is all open source it is actually easy to modify the code to use it even for yui css classes if you want - it just takes some more work to compare yui css and mobile jQuery css classes and implement them to mobile theme roller ui.

Since mymobile theme is coming soon to core themes I would start from that part and create a really functional mobile theming system to moodle 2 with simple core classes (that support consistent look) and ids and customizable additional classes (that support flexible custom css). Then I would continue with simplifying the core javascript stuff like dialogs that Urs mentioned in another post and Sam H had already collected some mixtures of YUI2/YUI3/custom dialogs - if it has to be all yui3 the let it be... and after that I might start looking optional tools for file picker, docks and navigation bars, tool tips etc.

Tim and Sam mentioned that TinyMCE might be the bottleneck of javascript performance. That's partly true if you implement quiz code to init and load 10 separate editors with full init code (with all tinymce buttons, plugins and toolbars) on the same page. TinyMCE supports also jQuery and you could as well implement tinymce to render editor only when needed - when clicked on editable field - and it does not load unnecessary stuff. Furthermore normal pages of moodle that do not use editor should not need editor code (unless you are editing something) and pages of moodle do never need YUIRTE - still if you look at source of this page you can see code including ... yui_combo.php?2.9.0\build\editor\simpleeditor-min.js ... and lots of other unnecessary js and css. If they are loaded why not use YUIRTE instead of tinymce in quizzes and implement the yui file picker to YUIRTE?

I am one of the big fans of TinyMCE and it is the most powerful and flexible open source editor available - CKEditor is the other option - but moodle could use different configuration options that TinyMCE offers in much more flexible way all over moodle. You could for example use different init code based on activities, user selections or create switchers to toolbar of editor or create different skins/editor themes for mobiles (latest versions of tinymce already support contenteditable) etc and if you check for example http://wordpress.org/extend/plugins/tinymce-advanced/screenshots/ they had already a couple of years ago a plugin for managing editor toolbars and buttons with easy to use drag and drop method... a jQuery plugin.

The biggest difference between moodle and some common cms systems UI is in the administration part - moodle 2 has lots of long admin pages with lists and tables and color picker element for selecting colours in settings of themes is one of the rare javascript based tools. Many of these admin pages could be made more user frendly with tiny javascript widgets - no matter if they are yui3 or jQuery...

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Mauno Korpelainen - Monday, 7 November 2011, 5:17 AM

This is now terribly long discussion already but I add some more data about Tim's and Sam's suggestion about TinyMCE being a bottleneck of javascript performance (in quizzes with lots of editors on the same page). I made a test on my test site and started adding editors to quiz keeping Chrome audits enabled and checked what was going on. The non-logical time serie of one-run test gave results

6 editors 2.87s
9 editors 8.45s
12 editors 5.72s
15 editors 8.44s
18 editors 10.35s
21 editors 5.79s
24 editors 7.29s
27 editors 18.63s
30 editors 19.20s
33 editors 13.03s
36 editors 11.05s
39 editors 22.70s
42 editors 14.58s
45 editors 8.69s
48 editors 22.65s
51 editors 29.23s

In the last (51 editors) case the main file is loaded once but tinymce (tiny_mce.js) calls 51 times "about:blank" so there are 52 document http requests.

There are 160 css file http requests because

- lib/editor/tinymce/tiny_mce/3.4.2/themes/advanced/skins/o2k7/content.css is loaded 51 times
- lib/editor/tinymce/tiny_mce/3.4.2/plugins/spellchecker/css/content.css is loaded 51 times
- theme/styles.php?theme=nameoftheme&rev=193&type=editor is loaded 51 times

Other 7 css files are loaded once.

In all cases there are 12 yui javascripts, 28 editor plugin javascripts (all these plugins are not even used in toolbars but they are still all loaded in init code), 4 other tinymce javascripts and 6 other javascripts used by moodle itself.
So it makes 50 javascript http requests.

And finally there are 38 image http requests.

Total number of http request with 51 editors on page rises to 300

No wonder why loading times are growing (variation is caused by different waiting times). TinyMCE itself is not at all slow as you can see for example in

http://fiddle.tinymce.com/eaaaab or http://fiddle.tinymce.com/baaaab

Average of ratings: Useful (1)

Re: Dear moodle, can we stop having the YUI lib yet?

by Andrew Lyons - Monday, 7 November 2011, 11:38 PM

Mauno,

I've been looking at other issues with multiple occurrences of TinyMCE on the same page - see http://tracker.moodle.org/browse/MDL-29831 for further information.

I'd be hesitant to read too much into the timestamps that you're seeing there. On pages with multiple occurrences of the editor, as the php generates the HTML for each editor, the browser receives it, and only then does it request the tinyMCE JS which is probably being delivered pretty quickly.

TinyMCE is not the slow part of this process - the true problem in this case is the php behind the repository plugins system. Unfortunately this manifests itself in the way that TinyMCE displays.

Andrew

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Urs Hunkler - Monday, 21 November 2011, 10:17 PM

Martin, what's the state of your plans. Did you decide to switch to jQuery?

If you may need some more info how mainstream jQuery has become you may have a look at the Adobe Fireworks CSS3 Mobile Pack - no more Flash at all but HTML5 and jQuery.

And the O'Reilly classic "JavaScript: The Definitive Guide" added a chapter about one JavaScript framework in the sixth edition: jQuery.

Average of ratings: -

OT: Re: Dear moodle, can we stop having the YUI lib yet?

by Frank Ralf - Tuesday, 22 November 2011, 12:23 AM

That chapter is available as a separate pocket reference: jQuery Pocket Reference - which is the most thorough reference book I know.

In addition O'Reilly provides lots of other jQuery resources: http://oreilly.com/jquery/index.html

Average of ratings: -

Re: Dear moodle, can we stop having the YUI lib yet?

by Vikram Solia - Saturday, 26 November 2011, 8:11 PM

Hi Martin,

We at Ballistic Learning have a steady stream of JavaScript freshers for the next six months. If somebody is ready to mentor our fresheres (2-4 people), I think we may be able to achieve this migration from YUI to jQuery.

Do let me know if this is feasible.

Vikram Solia

Average of ratings: Useful (1)