David Scotson

I would suggest you spell that out more when mentioning this topic as "support" on its own has some ambiguity. Reading that line basically put our plans for upgrading our 2.3 setup to 2.5 rather than 2.4 over the summer on hold. Some other people might not have sought clarification and just decided to stick with what they've got on that basis.

Which is a problem that Google Apps don't really have. If they upgrade and break something on IE8 then your choice is like it or lump it. Everyone running their own Moodle has to take that upgrade decision independently, so you might want to put the emphasis on the carrot (e.g. the drag'n'drop functionality has been really good for getting people onto Chrome/Firefox at our institution) rather than the stick.

You might also want to be explicit, in the dev docs, about exactly which versions of IE you are happy to actively and intentionally break. I had a conversation in a bug report in the last couple of weeks that suggested that "supporting" IE7 was still a requirement for any change, and your comment here similarly focuses on "new bugs" rather than on development decisions that will knowingly exclude IE8 from working for large swathes of Moodle e.g. adopting JQuery 2.0 (I realise that Moodle doesn't use JQuery, but it's the most prominent 3rd party library example I could think of that has dropped IE8 support and provides a benefit, they claim it's faster, as a result) so you might end up in a worst of both worlds situation where you're actually doing the work (or holding back progress) in order to support IE7/8, while also scaring off people from upgrading by announcing you don't support them.

Finally, will there be any kind of popup or notification for users of old browsers built into Moodle? I'd quite like it if there was an admin settings that let you tick off browsers and actively exclude anyone using say IE6 or IE7 and present them with a page of information and links to upgrade, whereas say users on IE8 or Firefox 3.5 just got a nag screen and were allowed to continue. We'll probably end up doing something internal anyway, particularly as we want to be a bit harsher with people coming from within our own institution, rather than someone forced to use old IE in a developing nation or government department but if the idea is to use Moodle to actually shepherd people forward then something built into the platform would be good.

I'm looking at the renderers for the file-picker and manager and something has confused me.

In files/renderer.php there is the HTML for most of the pop-ups that you navigate when uploading and managing files in the file-picker. In this file's HTML most, but not all, of the class names have {!} inserted before them, e.g.:

<div class="{!}fp-toolbar">

Immediately after the string is initialized with multiple of these "{!}" a regexp is used to strip them back out again.

return preg_replace('/\{\!\}/', '', $rv);

https://github.com/moodle/moodle/blob/master/files/renderer.php#L262

Just one would look like a mistake but 10 or so of them makes me think I'm missing something clever that's happening.

If you added a list of courses you're enrolled in to the top of the "Settings" block as another collapsable section (I'll try and mock that up if I get time), and killed the current "Navigation" block, I'd be happy with calling the combined entity "Navigation Block" (though I realise that on the web, that's a bit of a tautology as clicking any link is generally navigation). It would be good to be able to lock that combined block in the top corner and know that everyone would see all those things in the same place.

Other very generic and general suggestions: "Moodle Block", "Main Block", "Context Block", "Dashboard Block", "Primary Block", and getting desperate and turning to the thesaurus now, "Thingy Block", "Whatchamacallit Block", "Paraphernalia Block".

edit: added mockup, note that the courses are just links, if you want to access anything about a course you need to click on the link, which will take you to the course, and then you'll see a) the front page of the course with list of activities etc, b) the course administration tab will appear and expand, giving you access to the contextual actions for a course. If you need to access the contextual actions for a student or module then you'd need to click into that item and see its primary content and contextual menu. This is an intentional design decision, I think the attempt to allow you to dig 6 levels deep in the current Navigation Block is the worst thing about it.

The currently named "Settings" Block appears to be the only available place to collect context-sensitive links that are actually visible in the UI and consistently located and as a result that's where *everything* goes.

If you go to your profile it shows profile related stuff, if you go to admin it shows admin related stuff, if you go to a course it shows course related stuff, same for categories, modules, gradebook etc.

It's hardly elegant but it seems to be all we've got. Maybe if someone can come up with a name that reflects what it actually does then things will make some more sense. Someone could go through and count but there's a whole bunch of things in there that aren't Settings (e.g. there's several links that are "actions" like "purge caches", "backup", "restore", "import", "export", "publish"), possibly as many as half the items, so banishing anything that's not a "setting" doesn't seem like it would work, and where would they go if not here?

On the other hand, going the opposite direction and moving profile related stuff out of the "Navigation" Block and putting it into "Settings" and thereby leaving a list of enrolled courses seems like it could be an improvement. And then move everything below the level of the course name (e.g. participants list, reports) also back into "Settings" under the "course" sub-heading.

This also seems to be the relevant place for any other reports, particularly as there's already a bunch of things that could happily described as reports that live there already (e.g. Grader Report, Outcomes Report, Overview Report, User Report, Enrolled Users, Groups Overview, Check Permissions, Other Users, This User's Role Assignments, Browse List of Users, Cohorts, everything under Site administration -> Reports etc.)

The built in developer tools for Firefox and Chrome should display a little diagram that tells you the padding, borders and margin on the currently selected item (as well as it's dimensions), that's often handy for tracking down stray margins. Then, once you've found which part of the page has the extra padding/margin the list above it will also tell you where that rule is coming from.

Are you only having this problem on "short" pages? Sometimes you need to set height to 100% on html and body if the content doesn't take up enough space.

edit: just re-read one of your earlier posts: "The body part of the page stops just above the footer, but the html part encompases the footer. "

The footer (tag or div) should really be inside the body tag so you may have an extra open, or missing close, tag somewhere.