While looking into this I also noticed that the default user image PNG could be further optimised, though lossily, by using a PNG quantiser so I filed a bug:
https://tracker.moodle.org/browse/MDL-37418
David Scotson
Mezuen egilea: David Scotson
I *think* the performance of the second issue (default fallback gravatars) could be improved by providing a url to a standard image, even if that image happens to be identical to the one currently being used.
So, if that is indeed the case, a better default value might be "moodle.org/pix/user/f1.png"
The difference is that for the "mm" case you are directly being served an image from gravatar which isn't cached for more than 5 minutes. For the second case you are following a url which isn't cached for more than 5 minutes, but if you follow that url you are then redirected to a single URL which has a copy of the original image stored on gravatar's servers.
The extra redirect obviously adds some time, but I'm guessing that overall you're saving because after the redirect your browser is saying, oh I've already got that image in cache and doing so once for every default image so that saving's going to add up.
The one thing that makes me somewhat unsure is wondering why gravatar doesn't use this system for it's own mystery man picture. Most of the other options are unique per user/email address so maybe they couldn't be bothered for the one standard image. Possibly they've optimised for functionality rather than speed, certainly most of the Google hits I turned up where suggesting that comments with gravatars should be loaded after a user click to prevent it slowing down the delivery of your actual content. But that wouldn't work with Moodle's current design as in a forum, the comment are the content.
But, actually, I'm more interested in the first possible saving as our site doesn't use gravatars. I'll try some experiments with losslessly compressing existing profile images and see if I can match Google's claim of 24% space saved. And then see about how much further savings could be made with lower quality jpeg settings.
So, if that is indeed the case, a better default value might be "moodle.org/pix/user/f1.png"
The difference is that for the "mm" case you are directly being served an image from gravatar which isn't cached for more than 5 minutes. For the second case you are following a url which isn't cached for more than 5 minutes, but if you follow that url you are then redirected to a single URL which has a copy of the original image stored on gravatar's servers.
The extra redirect obviously adds some time, but I'm guessing that overall you're saving because after the redirect your browser is saying, oh I've already got that image in cache and doing so once for every default image so that saving's going to add up.
The one thing that makes me somewhat unsure is wondering why gravatar doesn't use this system for it's own mystery man picture. Most of the other options are unique per user/email address so maybe they couldn't be bothered for the one standard image. Possibly they've optimised for functionality rather than speed, certainly most of the Google hits I turned up where suggesting that comments with gravatars should be loaded after a user click to prevent it slowing down the delivery of your actual content. But that wouldn't work with Moodle's current design as in a forum, the comment are the content.
But, actually, I'm more interested in the first possible saving as our site doesn't use gravatars. I'll try some experiments with losslessly compressing existing profile images and see if I can match Google's claim of 24% space saved. And then see about how much further savings could be made with lower quality jpeg settings.
I'm guessing you mean the "can we please get rid of YUI" discussion?
Is there some technical incompatibility that means we can't have both, or is it just the idea of focusing on one javascript library is agreed on by both sides, they just can't decide which one to standardize on? They've always struck me as fairly different beasts despite being vaguely in the same category and often pitted against each other.
Is there some technical incompatibility that means we can't have both, or is it just the idea of focusing on one javascript library is agreed on by both sides, they just can't decide which one to standardize on? They've always struck me as fairly different beasts despite being vaguely in the same category and often pitted against each other.
Looks very nice. In fact, it looks so nice it makes the spinning loading gif look really out of place when you e.g. hide or show an activity.
I filed a bug about it, and it turns out it's really easy to fix, either in core Moodle or in a theme:
https://tracker.moodle.org/browse/MDL-37363
The reason I was checking out the hide and show icon was because I was checking all the various things that had caught me out when working with Bootstrap. Everything I tested seems to be working well in your theme though. I also tested in Firefox on Android (since that's what I use, and it's an often neglected combination) and that was all working as expected.
Three minor niggles:
1. The hover and active highlighting of the Navigation block isn't 100% (but works well in the settings block)
2. The forms can get a bit cramped at phone sizes (though I think this is just standard Moodle showing through, rather than a problem with your theme, it's just more noticeable since everything else works so well at phone sizes.
3. more a personal preference than a bug or problem but I've used the blue "primary button" where you've used green "success" button, and yellow "warning" for cancel buttons, where you've used red (and also use the yellow for editing). I generally don't like the fact that Moodle even has cancel buttons on forms, making them red just draws further attention to them, which I think is unnecessary and maybe even a bit alarming for new Moodle users.
I filed a bug about it, and it turns out it's really easy to fix, either in core Moodle or in a theme:
https://tracker.moodle.org/browse/MDL-37363
The reason I was checking out the hide and show icon was because I was checking all the various things that had caught me out when working with Bootstrap. Everything I tested seems to be working well in your theme though. I also tested in Firefox on Android (since that's what I use, and it's an often neglected combination) and that was all working as expected.
Three minor niggles:
1. The hover and active highlighting of the Navigation block isn't 100% (but works well in the settings block)
2. The forms can get a bit cramped at phone sizes (though I think this is just standard Moodle showing through, rather than a problem with your theme, it's just more noticeable since everything else works so well at phone sizes.
3. more a personal preference than a bug or problem but I've used the blue "primary button" where you've used green "success" button, and yellow "warning" for cancel buttons, where you've used red (and also use the yellow for editing). I generally don't like the fact that Moodle even has cancel buttons on forms, making them red just draws further attention to them, which I think is unnecessary and maybe even a bit alarming for new Moodle users.
If this was considered worth doing, then it wouldn't be impossible to write a script that losslessly compressed all the images and then updated the hashes to the hash of the newly compressed file, though it's obviously harder than standard command line re-compression and more Moodle specific.
For most "content" uploads it probably makes more sense for this all to be automated anyway, so that end-users don't need to care about the image they upload and Moodle would automatically resize and recompress it as appropiate so that you can get an easy overview of the image but also access the original untouched if necessary See for example Flickr or Wikipedia for systems that do this to uploaded images.
For images that are part of the Moodle UI, and therefore accessed much more often and by many more people, I think it makes more sense for these to be compressed by Moodle.org or the Theme designer. They've almost certainly already been resized appropriately already, and it saves everyone having to install lossless compressors. I think this mostly happens already, at least for core images. But if you're doing some customisation for your institution then running these commands over any files you use is well worth it. It's a relatively low risk, low effort activity. You can even upload them to web sites if you're not familiar with the command line e.g.:
Yahoo's Smush.it:
http://www.smushit.com/ysmush.it/
which wraps the various tools already mentioned in an easy to use UI.
For most "content" uploads it probably makes more sense for this all to be automated anyway, so that end-users don't need to care about the image they upload and Moodle would automatically resize and recompress it as appropiate so that you can get an easy overview of the image but also access the original untouched if necessary See for example Flickr or Wikipedia for systems that do this to uploaded images.
For images that are part of the Moodle UI, and therefore accessed much more often and by many more people, I think it makes more sense for these to be compressed by Moodle.org or the Theme designer. They've almost certainly already been resized appropriately already, and it saves everyone having to install lossless compressors. I think this mostly happens already, at least for core images. But if you're doing some customisation for your institution then running these commands over any files you use is well worth it. It's a relatively low risk, low effort activity. You can even upload them to web sites if you're not familiar with the command line e.g.:
Yahoo's Smush.it:
http://www.smushit.com/ysmush.it/
which wraps the various tools already mentioned in an easy to use UI.