I'm fairly sure Moodle user images used to be JPEGs, but now they seem to be PNGs. Does anyone know when and why this change happened?
Here on Moodle.org you can use the 3rd party service Gravatar which provides the user images as JPEGs. As a result some user's images from that service are 10x smaller than others provided by Moodle itself. (It also resizes the image as required, so when displayed at 60x60 it will provide a 60x60 image, not a larger one and then resize it in the browser).
Modern web design trends often emphasis the use of large user images to inspire users to interact with each other. Moodle seems to be anticipating this by introducing a new user icon size of f3 at 512x512px, but since these are PNGs, they are about 500K in size, which I think makes them basically unusable.
I think some users that have been around for a while and not changed their avatar still have JPEGs, in case that confuses anyone looking into this.
But has anyone else investigated this before? I'm thinking a shift back to JPEG would make a lot of sense, and allow us to use visually larger yet faster to download images but wanted to do some more research first to find out why the opposite switch was made in the past.
David Scotson
Interventi di David Scotson
I tried using body.dir-rtl but one complication is that Moodle puts a lot of classes on the body tag so you need to treat those differently, and can't just prepend the same string as other lines, which is a bit of a pain.
If you use the dir=RTL marker that Moodle puts on the HTML tag instead then you only have to worry about CSS targeting the HTML tag.
Doing the former took many lines of shell script, with the new system you take the ltr and rtl CSS and make a .less file by wrapping them like so:
[dir=ltr] {
All LTR CSS
}
[dir=rtl] {
All RTL CSS
}
And then compile it. Initial testing seemed positive.
If you use the dir=RTL marker that Moodle puts on the HTML tag instead then you only have to worry about CSS targeting the HTML tag.
Doing the former took many lines of shell script, with the new system you take the ltr and rtl CSS and make a .less file by wrapping them like so:
[dir=ltr] {
All LTR CSS
}
[dir=rtl] {
All RTL CSS
}
And then compile it. Initial testing seemed positive.
My thoughts are that the best approach for RTL is:
1. Moodle serving a single rtl.css or ltr.css file to the user, depending on the language used on the current page.
2. Moodle core and theme developers using rtl-flipping technology so that they only have to maintain a single theme file.
In the meantime, until that is all done, a potential workaround that lets us get most of the work done in parallel while waiting is to provide a setting in a theme that allows the admin to select ltr, rtl or both.
The ltr file is the main one that people work on. The rtl file is an automatically flipped version of that, possibly with some hand-crafted rtl-only tweaks appended.
The combined file is trickier, but my current approach would be to fuse the previous two files together and add [dir="ltr"] to the start of every line intended for ltr, and [dir="rtl"] to the start of every line intended for rtl. This basically means that the page would ignore half of the CSS based on which language direction it was using.
I believe the above should work, and I have a basic prototype, but I haven't had much time recently to test it out.
The immediate reaction to sending double Moodle's already quite large CSS to those sites that use both language directions is probably horror. But if you do some maths, with fairly rough numbers like 5% of Moodle users needing both RTL and LTR within a single theme and 10% of Moodle's current CSS being RTL specific you can see that:
current way = everyone gets a slightly larger CSS file = 1 x 1.1 = 110%
half way = most people get a slightly smaller CSS, some people get double = (.95 x 1) + (.05 x 2) = 105%
best way = everyone gets only the CSS they need = 1 x 1 = 100%
So overall the amount of CSS sent by Moodle could actually fall overall (depending on what the real numbers are) even though certain sites would be sending double. Of course, as mentioned above the real solution is to send only rtl for rtl pages and ltr for ltr pages. I'd guess this would be better even for sites that use both.
Generally, like most of the CSS it could just generally do with a tidy up e.g. part of the RTL CSS that is sent to every user is for the TinyMCE editor. And it's sent even if you're not using RTL, and even if you are using RTL but not using the TinyMCE editor. A few hundred extra lines of CSS here and there soon adds up.
1. Moodle serving a single rtl.css or ltr.css file to the user, depending on the language used on the current page.
2. Moodle core and theme developers using rtl-flipping technology so that they only have to maintain a single theme file.
In the meantime, until that is all done, a potential workaround that lets us get most of the work done in parallel while waiting is to provide a setting in a theme that allows the admin to select ltr, rtl or both.
The ltr file is the main one that people work on. The rtl file is an automatically flipped version of that, possibly with some hand-crafted rtl-only tweaks appended.
The combined file is trickier, but my current approach would be to fuse the previous two files together and add [dir="ltr"] to the start of every line intended for ltr, and [dir="rtl"] to the start of every line intended for rtl. This basically means that the page would ignore half of the CSS based on which language direction it was using.
I believe the above should work, and I have a basic prototype, but I haven't had much time recently to test it out.
The immediate reaction to sending double Moodle's already quite large CSS to those sites that use both language directions is probably horror. But if you do some maths, with fairly rough numbers like 5% of Moodle users needing both RTL and LTR within a single theme and 10% of Moodle's current CSS being RTL specific you can see that:
current way = everyone gets a slightly larger CSS file = 1 x 1.1 = 110%
half way = most people get a slightly smaller CSS, some people get double = (.95 x 1) + (.05 x 2) = 105%
best way = everyone gets only the CSS they need = 1 x 1 = 100%
So overall the amount of CSS sent by Moodle could actually fall overall (depending on what the real numbers are) even though certain sites would be sending double. Of course, as mentioned above the real solution is to send only rtl for rtl pages and ltr for ltr pages. I'd guess this would be better even for sites that use both.
Generally, like most of the CSS it could just generally do with a tidy up e.g. part of the RTL CSS that is sent to every user is for the TinyMCE editor. And it's sent even if you're not using RTL, and even if you are using RTL but not using the TinyMCE editor. A few hundred extra lines of CSS here and there soon adds up.
I'd be surprised if SVG was the answer to this problem. I think SVG only gets served, and used, by older versions of iOS. Modern browsers should be using WOFF by preference.
If you're locally hosting you'll need to specify all the formats to cover every user but Google Web Fonts should detect the kind of browser that is visiting and only send a single format as required e.g. if I visit:
http://fonts.googleapis.com/css?family=Roboto
In Firefox, it only servers a .woff file.
Maybe check your .woff file that you're serving locally isn't corrupt or otherwise odd (and don't directly grab the one served by Google, they send different files to Mac/Linux/Windows).
If you're locally hosting you'll need to specify all the formats to cover every user but Google Web Fonts should detect the kind of browser that is visiting and only send a single format as required e.g. if I visit:
http://fonts.googleapis.com/css?family=Roboto
In Firefox, it only servers a .woff file.
Maybe check your .woff file that you're serving locally isn't corrupt or otherwise odd (and don't directly grab the one served by Google, they send different files to Mac/Linux/Windows).
That all looks very positive, I agree with the general direction.
Some miscellaneous feedback:
1. I'd like to see some thought given to how a 3rd party developer, who may not be a professional software developer, can quickly and easily create a UI that will work in multiple versions (2.6, 2.7, 2.8 etc.) and multiple themes (Standard, Clean, a Bootstrap3 or PureIO-based theme) and fit in and work in all of them. There should be functions that they can call that take care of making it all work, but it seems today a lot of things are simply hardcoded and so are fragile and break compatibility easily.
2. Any existing API that simply takes the classname from the dev and outputs it into the DOM needs to go, it's impossible to support the stated goals and that at the same time. This also allows for the API to be improved e.g. the current notification renderer going from notification("anything_you_want") to alert_danger, alert_warning, alert_info, alert_success or similar (and then cleaning up the oddities that do other stuff, like "notifytiny").
3. I'd like to see the stuff that can be fixed within a current theme shipped immediately to get feedback. There's no reason why, for example, the code that just landed to provide Bootstrap compatible progress bars should not be shipped as soon as possible in 3rd party themes. There's no need to wait till the next version of Moodle ships and then the 6-12 months till that actually gets widely deployed before checking our progress on this. In general this is a powerful feature of Moodle's existing renderer system which I think is criminally underutilized.
4. The current continue renderer doesn't return a "A message and a button to continue to the next page", but only a button. We do need one that takes a message but since the current one doesn't we'll need to come up with a new one and transition to it.
5. Any time the "single button" renderer is used twice to create a form with two buttons side by side, then that renderer should not be used, probably one or more new renderers should be created to fulfill those use cases.
6. Totally minor but... some of your table entries are duplicated (navbar_item, progress_bar).
7. Converting the non-renderer code that does the same thing (or subtly different thing for no good reason) as a current renderer to call that renderer would be a very good place to start this project. There's a fair bit of this, but it's fairly mindless, easy work and you basically can't do anything interesting with a renderer till all the "fake" versions of it have been cleaned up.
8. There's a lot of independent things here that can be worked on in parallel. What is the plan for coordinating everyone's work?
Some miscellaneous feedback:
1. I'd like to see some thought given to how a 3rd party developer, who may not be a professional software developer, can quickly and easily create a UI that will work in multiple versions (2.6, 2.7, 2.8 etc.) and multiple themes (Standard, Clean, a Bootstrap3 or PureIO-based theme) and fit in and work in all of them. There should be functions that they can call that take care of making it all work, but it seems today a lot of things are simply hardcoded and so are fragile and break compatibility easily.
2. Any existing API that simply takes the classname from the dev and outputs it into the DOM needs to go, it's impossible to support the stated goals and that at the same time. This also allows for the API to be improved e.g. the current notification renderer going from notification("anything_you_want") to alert_danger, alert_warning, alert_info, alert_success or similar (and then cleaning up the oddities that do other stuff, like "notifytiny").
3. I'd like to see the stuff that can be fixed within a current theme shipped immediately to get feedback. There's no reason why, for example, the code that just landed to provide Bootstrap compatible progress bars should not be shipped as soon as possible in 3rd party themes. There's no need to wait till the next version of Moodle ships and then the 6-12 months till that actually gets widely deployed before checking our progress on this. In general this is a powerful feature of Moodle's existing renderer system which I think is criminally underutilized.
4. The current continue renderer doesn't return a "A message and a button to continue to the next page", but only a button. We do need one that takes a message but since the current one doesn't we'll need to come up with a new one and transition to it.
5. Any time the "single button" renderer is used twice to create a form with two buttons side by side, then that renderer should not be used, probably one or more new renderers should be created to fulfill those use cases.
6. Totally minor but... some of your table entries are duplicated (navbar_item, progress_bar).
7. Converting the non-renderer code that does the same thing (or subtly different thing for no good reason) as a current renderer to call that renderer would be a very good place to start this project. There's a fair bit of this, but it's fairly mindless, easy work and you basically can't do anything interesting with a renderer till all the "fake" versions of it have been cleaned up.
8. There's a lot of independent things here that can be worked on in parallel. What is the plan for coordinating everyone's work?